Hi
As promised, here is the list of issues I think require a bit more discussion. Note that this does not mean that I, as a technical contributor, necessarily disagree with the person who raised the issue or proposed a change.
1. In section 5.2.1.2, do we need this new construct? As this is related to the Beep transport mapping which is currently not properly understood, it is difficult to say for sure. (source Balazs & Andy)
a. We should remove any reference to non-existent BEEP modifications in this document. This is not an option. Stuff like this will only get stuck later anyway in the publication process. - The NETCONF over BEEP authors (and others clueful in BEEP) need to provide input on all of sec. 5.2
2. In section 5.3, paragraph 2 seems a bit unclear, and needs punctuation. Explain why it is more important. (source Andy)
a. This text came from someone. I don’t remember what it means
3. In section 3.2.6.2, it talks about opening either a new session or a new channel on an existing session. Is this appropriate (source: Martin)
a. The reason channels were mentioned is that connection conservation is more of an issue with the loss of ‘mix-mode’
b. Technically, do I run a different session on each channel, rather then how it is currently worded? So, it would be more correct to just talk about sessions and leave multiple channels out of it?
4. In section 3.4, an object called ‘lastModified’ exists. Should this not be called ‘creationTime’ instead since we lost the modifySubscription command? (source Martin)
a. lastModified is more consistent with SNMP
b. What if an implementation defined their own way to modify the subscription. (They could always add their own object later I suppose)
5. In section 3.4, the number of messages sent is defined to be an xs:integer which is not bound, but later in the document (section 4), there is discussion about how sequence numbers roll over the message counter when it reaches its capacity, which is also defined as an xs:integer. These are inconsistent. Change to unsignedInt (Source Martin & Andy)
a. In Netconf we have been taking a general policy of not setting limits to things
b. Is there any value in forcing implementations to keep this in a number larger then a 32 bit integer?
6. In section 7, replay has a startTime associated with it, which leads to some time-related questions. Is the time associated with the event the time it is logged or the time it was generated, or the time was sent out via Netconf? (source Martin)
a. From our implementations perspective, we expect all notifications to contain an event timestamp and we expect logging to happen before it reaches to netconf stack. So, this means we could probably support either the time it was generated or the time it was logged. My preference is the latter.
7. In section 7, why isn’t their a symmetrical stopTime.
a. From the use cases I’ve seen, stopTime is present time, so I don’t think we need an explicit stopTime to be able to specify something else.
8. Do we still need an identifier called subscription ID (source Andy)
a. Given that the base definition of notifications does not support multiple subscriptions per session, do we still need this
b. I only have one Netconf session per connection, but still have a session identifier don’t I?
c. There are a couple of reasons why this is needed. One is to support retrieval of subscription information. We need an identifier that uniquely identifies it. You could argue that this only needs to exist within the XML Schema.
d. Yes, as much as we hate to talk about future features, it will be necessary for some optional capabilities that some implementations may choose to support
e. Are we using this in more ways then the use cases require?
9. The documentation currently defines appinfo to annotate information in the document. Primarily the maxAccess clause and some module Identity. We can’t publish with a dependency on this document since it would block us.
a. We talked about just publishing a short little document that would define the appInfo bits we needed, as appose to full data specification
b. Andy has suggested instead of maxAccess, moving to config or not config, which I think could also work. State versus statistics would also be a nice distinction to be able to make, but perhaps that can wait.
10. In section 3.1, the URN for Netconf Notifications, is this defined correctly? (source Bert)
a. Currently: urn:ietf:params:xml:ns:netconf:notification:1.0
b. Should it be: urn:ietf:params:xml:ns:netconf:capability:notification:1.0
11. Should the XML Schema for retrieving stuff be defined in the main body of the document or in the appendix (source Bert)
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada