Notes from Netconf Event Editing Session

["Sharon Chisholm" <schishol@nortel.com>]

hi

The session on November 8th was attended by 11 people from 8
organizations. Most of the people had read the draft prior to the
session.
	
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-event-01.txt

Here are my notes.

1. There were some concerns raised about the filtering mechanisms
defined within the draft and how they would actually work with event
messages. Note that these are the filtering methods originally defined
in base Netconf. Hector agreed to write up some examples to demonstrate
how they would work as well as to test their usability.

2. It was noted that the definition of event class is circular and in
general needs work. Sharon agreed to try to clean this section up.
Clarification should also be added that it is expected that the contents
of the messages are expected to differ for each event class.

3. There was discussion on subscription ID and why more than one
subscription on a single connection was allowed. The answer is that
there is no compelling reason to not allow more than one subscription
per connection and there are some benefits to allowing it. People who
want to keep things simple can choose to only have a single subscription
per connections. Those who would like more than one to support use cases
such as having two different sets of filters applied with the
information handled differently on the receiving end or, if supported, a
replay function and a real-time event stream can do so. This should
probably be discussed more within the document itself. The subscription
ID enables multiple subscriptions per connection and also allows someone
to monitor a subscription from another connection.

4. Discussion about session IDs and more than one beep channel is
needed.

5. Note that sequence numbers detect lost events on a still-up
connection. If you loose the connection, all bets are off and you should
assume that you lost information. Management applications typically
assume this anyways and tend towards re-discovery when the
connection/communication is resumed.

6. The optionality of various bits of content in the appendix needs to
be validated. Hector agreed to do this.

7. In section 2.1.1, it should be noted that event class, filter and
named profile are independent parameters. This means they are not
mutually exclusive, but rather that they have an accumulative effect on
the content of the subscription.

8. In section 2.2.1, discussion needs to be added around the behaviour
of sequence numbers after wrapping and reboot. This is not persistent
across reboots.

9. Section 2.3, which discusses changing a subscription, needs an
example. There was discussion about alterative syntax for modifying
subscription that would be subtractive rather than fully specifying the
new subscription, but this approach seemed to have its own challenges.
After the example is given with the current approach, we can test the
current syntax.

10. We need the read-only schema for querying subscription properties as
identified in section 3.2. Sharon to write this up.

12. Currently the draft discusses named profiles as something dynamic.
When they change, the subscription gets updated. After much discussion,
it was decided it might make more sense to make them static. If they are
changed, this has no affect on the event subscription until an explicit
modify subscription command is sent. This was the preferred approach in
the room.

13. The title of section 3.4.2 should be changed to 'Filtering'. Better
yet, we may want to just roll section 3.4.1 and 3.4.2 to be in the
appropriate places in section 2. It is a bit confusing trying to figure
out where to define things - within the netconf template or within a
paragraph somewhere.

14. In section 3.4.2, better explain that this filtering is specified as
a parameter to the command and is not defined independent (and is not
persistent beyond the subscription) compared to named profiles.

15. In section 3.5, the order that the event classes are explained
should be aligned with the order in which they are listed.

16. In section 3.5, it should be explained that heartbeats do have
sequence numbers, but that the messages themselves should not be
included in any message logging that the system may choose to do.

17. In section 3.5, discussion about whether event classes are an IANA
managed resources should be included. They probably are.

18. In section 3.5, there was discussion around the difference between
fault and alarm. If there are not non-alarm fault events then fault
might be a better term to use. Sharon agreed to look into this a bit
more. There was also discussion about whether a threshold crossing was a
fault event or a class onto its own.

19. In section A.3, it was questioned whether we really needed
sysUptime. It was noted that if it is there, both it and event
generation time need to be separately defined fields, even if they end
up forming parts of the same type. The second paragraph should refer to
RFC3418 and not 1907.

20. In section A.10, there is not discussion about what clear means. If
clear were to be defined, it might handle the issue raised in the second
paragraph about the ambiguity in the RMON model.

21. For sections B.2.5 through B.2.8, there needs to be an explanation
of how the CLI text option would work. Hector agreed to provide this.

22. In section C.2.3, it should be clarified that the intension is to
explore a command  that would allow you to indicate that you want
information to hang around after the connection is terminated. It was
noted that there were resource considerations around this (including
orphaned resources) and potential impacts on sequence numbers.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>