NETCONF Minutes for IETF 67 [draft 1]

[Andy Bierman <ietf@andybierman.com>]

Hi,

Here are the meeting minutes for comment before I submit them.

Andy


IETF67
OPS-NM Area
NETCONF WG
November 6, 2006

(Draft 1)
Minutes by Andy Bierman

Documents:

A) draft-ietf-netconf-notification-04.txt

Minutes:

1) WG Status

   The base NETCONF documents are in auth48 state and will be 
   published soon.  The document numbers are RFC 4741 - RFC 4744.

   The WG is trying to finish the Notifications draft and get to 
   WGLC before the next IETF.

   Straw poll: How many people have read the Notifications draft?
   A: Over half the approx. 40 participants present.

2) Notification Issues

The remainder of the meeting was spent discussing technical
issues related to the Notifications draft.  Simon started
with an issues list. (See slides.)  This section has been
organized by issue, not temporal order.

Before the technical issues were addressed, Simon pointed out
that we need more participation in the form of document reviews,
in order to complete the Notifications work.  It was suggested
that we try to simplify the document as much as possible,
in order to finish sooner.  Additional features can be
added in the future, as needed.

2.1) StreamList Design

The group discussed the StreamsList construct introduced
in the -04 draft.  This is a list of 1 to N stream names that
should be combined by the agent to produce the notification
output for a particular session.
 cardinality of streams in <create-subscription>

  Balasz: we don't specify anything about event streams
  Balasz: default NETCONF stream
    Could we specify that this contains all notifications
      understandable in a NETCONF format? [see later discussion]
  DaveH: We should not assume that an agent can multiplex several
    notification streams together
  Eliot: Only way out is to mandate that multiple streams belong to
    the same XSD to be multiplexed

Pros:
  - increases configuration flexibility for the manager
  - reduces the TCP connection and NETCONF session overhead
    if multiple streams are desired, and cannot be configured
    on the agent.

Cons:
 - Streams can have different data formats, and some combinations
    may not make sense, or the agent may not be capable of combining
    them (i.e., the reason streams exist in the first place.)
 - There is no simple way for the manager to know which combinations
   are permitted
 - The agent can have configured streams, but there is no standard
   data model for this purpose yet.
 - The same system event can be conveyed in different ways, across
   multiple streams.  Manager-selected combinations of streams
   would either create duplicate notifications or require complex
   duplicate suppression
 - The manager can simply open another session to receive multiple
   non-configurable streams.

* Straw poll Q: Should the streams list be changed to a single stream?
  A: ACCEPT: Remove streamList and use a single Stream name instead

  Rough consensus for limiting ourselves to a single event stream

2.2) <create-subscription> RPC

 -  different ways to configure the same thing (profiles and filters)
  - Balayz: want choice of filter or profile but not both

  - combining filters and profiles
    - don't need this feature
    - change to choice (1 or the other)

  - Stopping the notification stream
      "mechanisms outside the scope of this document"
      DaveH: This seems to add ambiguity - remove that phrase!
      No objections to removing it.

  - remove statement about kill session outside the scope

2.3) Normative References

  - lot of data modeling : creates a normative reference
    - using template and minAccess/maxAccess

  - Remove normative reference to Datamodel draft

2.4) Notification Replay

 - no tail -f mode
   This removes a gap between the recorded <get> and the
   new notifications that may occur during the <get>.
   The design in the current draft could be achieved with
   the <get> operation and a notification monitoring data model.

 James Balestriere:
    The client can just try:
      <create-description> w/stream, start- and end-time
    Server can return an error if this replay is not supported.

  - Should replay be a capability in the hello message
    or a characteristic of each stream?
    - not needed; just get an error back
    - could have field in the getStreams to indicate
      logging is available
   A: Should not be a capability because it may not apply to
      every stream.  Use an indicator in the <streams> data model
      instead (such as <recording/>).

  Should a stopTime be supported?
  A: Yes. Add stopTime (not just startTime)

  - Is endOfReplay notification needed
    James: This can also be necessary when stop-time is specified
     - take to list

  - When a replay ends, what happens?
  - Does the session end or what?
     - take to list 

  - What happens if an RPC command is received during
    a notification stream?  Does the agent have to respond
    to it?
     - take to list; interim discussion determined the agent
       does not have to respond to any <rpc> requests after
       <create-subscription>.

2.5) Monitoring Data Model

   - a general session monitoring module might be more useful
   - BW: can we move this to another document?

  - Straw poll: ACCEPT:  Move monitoring data model work 
    out of this document.  It will not be part of the '1.0'
    standardization effort for NETCONF Notifications.

2.6) Transport Mappings

  - Transport mappings
    == keep text in this document
    - SSH talks about RPC in the document.
      - BW: Don't put any text we don't need like about SSH
    - BEEP (Eliot to provide text)
    - SOAP (any volunteers)
 
  - DH: remove the transport mappings from the document
  - DH: notifications over SSH may require new text
        ISMS has VACM to deal with
    JS: not a security problem in NETCONF because the receiver
        establishes the notification channel

  Andy: should say as little as possible about specific transports
    In particular, the examples should go away.
  Eliot: This creates a nightmare.
    Should be specified *in* the notifications document.
  !! Action on Eliot to help with the BEEP section [document]

  ?? Who could do the SOAP mapping??

  SSH mapping seems easy (but at present always talks about "RPCs")
  Bert: May be an issue if/when transports get deprecated
  DaveH: Wants transports split off from this document.
  	 Suggests there will be issues with SSH transport
	 as seen in ISMS
  Eliot: Those issues seems to be specific to SNMP's (access control)
  DaveH: At least have to provide a mapping from transport to
  	 principal ID to be used for access control
  DavidP channeling Juergen Schoenwaelder: Doesn't see the issue
  Wes: Seem to be side-tracking here
  Rough consensus to separate them out (Eliot opposed)

  - Straw Poll: ACCEPT: Move transport mappings out of
    this document

  - The Notifications draft will be written such that it
    does not block on any external reference that does
    not currently exist.  This includes extensions to
    the SOAP transport for notification support.

2.7) Security Considerations

  - Security considerations: point out the base protocol
    covers the threats we have.  Identity will be different
    for notification vs. get.


  What has to go in this section?
  DaveH: Security ADs will look for threats and ways that these are
    addressed/mitigated.
  Wes: Haven't read the document yet.
    Two comments: Some people want different AC for notifications
    vs. monitoring (<get>), like it's done in SNMP VACM
  Dan: This needs to be run by security advisor (Wes)
    or by the SAAG before submission
    Effect of notification traffic (DoS?)

2.8) Default NETCONF Stream

The purpose and expected implementation requirements of
the default stream were discussed.

  - Does it have the NETCONF content, or all content?
  A: Streams are coupled to content: not needed because
     namespace URI identifies the content

  - okay if content is unspecified
    - STRAW POLL: Should the Netconf stream be the default
      for the <stream> parameter? 
    A: YES

    - STRAW POLL: What should the content on this stream be?
     - outside this doc
     - anything in netconf format
     - only the netconf specific notifications
     A: --> define the content in this document
     A: --> SHOULD BE ALL NETCONF CONTENT

2.9) Readability

 Andy: Need more explanatory text around the schema definitions

  - increase documentation about data models, not just
    inside the XSD