Subject: IETF62 NETCONF minutes

From: Simon Leinen <[email-masked]>
Date: Fri, 8 Apr 2005 16:37:30 +0200

I have just finished the minutes from the last IETF meeting (sorry for
the delay).  They can be found on

  http://www.ops.ietf.org/netconf/62/minutes.html

I'm also attaching them in the original HTML format and converted to
plain text.  If you notice anything strange, please let me know
ASAP... the proceedings submission deadline is in a few hours - so I
have already sent them to the secretariat - but I'll try to get an
update in if necessary.

Regards,
-- 
Simon.
NETCONF meeting

IETF 62, Minneapolis

Tuesday 09.00-11.30 (actually 09.00-10.00)

Chairs: Andy Bierman, Simon Leinen

Minutes: Simon Leinen

Jabber scribe: Eliot Lear

WG Last Call status

All documents were in Working Group Last Call, lasting until
Friday 18 March (the week after the meeting). As this was the second
WG Last Call, participants didn't find too many problems with the
drafts in this round. There have been comments from people trying to
implement the protocol, which can be viewed as a good sign. The
documents should be ripe for submission to the IESG soon. Discussion
about individual drafts followed.

draft-ietf-netconf-ssh-03.txt

Margaret Wasserman, the editor, couldn't be at the meeting because
of other conflicting IETF duties. The latest revision mainly removed
the option of starting NETCONF from a normal shell session - it must
now be started as a separate netconf SSH subsystem.

Wes Hardaker has thoroughly reviewed the draft and posted some
issues to the mailing list. Margaret will address those issues in a
forthcoming revision.

Simon Leinen had found a small bug in the examples, where the
C: (client) and S: (server) headers were
inverted. This should remind participants of the importance of
reviewing the documents for these kinds of problems also.

draft-ietf-netconf-beep-03.txt

Eliot Lear mentions that Jürgen Schönwälder
provided detailed comments on his BEEP mapping draft, and promised a
new BEEP draft based on these. Required changes include:

Adding some examples

Adding some text on <hello>, which was
missed due to draft skew between the core (-protocol) and -beep
drafts

Address an issue of Jürgen's on the SASL/TLS combination -
after getting Jürgen to explain these in more detail

Reconsider the "application protocol" terminology, which
Jürgen dislikes. Eliot is looking for suggestions for better
terms.

Thorough review to make sure the BEEP mapping covers everything
in the core protocol draft.

Discussion of XML and Schema Definition Issues

Schema Strictness Requirements

Wes asks whether the intent is that an implementor should be able
to use the XSD definitions to do most of the validity checking of
NETCONF requests.

Andy doubts that this is possible, in particular because XSDs
cannot capture the variants related to capabilities.

XML Directorate Review

Bert Wijnen, our responsible Area Director, asked (over Jabber)
whether the XML Directorate has been asked to reviewed the documents
for correct XML usage.

Andy states that this has not yet been done, and noted that one of
our authors (Phil Shafer) is on that directorate.

draft-ietf-netconf-protocol.txt

Rob Enns decided not to show slides about the protocol draft
because they are boring. Changes from last to current revision:

The many requests for clarifications from the mailing list have
been addressed.

All of the closed issues that had come up in the WG Last Call
have been addressed.

The change log was simplified because it was getting too
long.

Work is required in the following areas:

Filtering (section 6) - Some people have asked to clarify the
section that explains how filtering works. Rob would welcome
contributions for improved text. Andy - who had written that
section - suggests that examples would be particularily useful here,
and offers Rob his help to make the text more understandable later
this week.

Examples in general - Past experience shows that implementors
often use examples as a main guidance for implementations.
Therefore, the examples should be given much care, in particular
their correctness. Rob notes that all the examples in the protocol
draft have been verified against the RelaxNG version of the NETCONF
schema.

Clarify error codes for lock operations - LOCK_FAILED
should be used instead of IN_USE.

Secure-Transport Requirement

John Ng asked about the requirement for secure transports (section
2.2 in the protocol draft), in particular whether it would be possible
to use something like unencrypted telnet in a "secure private network"
environment, or in situations where cryptography cannot be used. Andy
assumes that security experts would not let a NETCONF proposal pass
without mandatory security. Bert notes that security is mandatory to
implement, but not mandatory to use.

Detecting Dead Sessions

John Ng raises the issue of how an agent notices when a manager
has gone away (so that locks can be released). Andy says this is
currently indicated by loss of the underlying TCP connection. John
points out that this fails to distinguish between a manager that has
nothing to say and one that has silently gone away. Eliot expresses
his hope that someone who is holding a lock wouldn't be idle [but does
that really help here?]. Andy recalls that we had this discussion
before and decided this was a non-problem - hung sessions can be
broken using <kill-session>.

draft-ietf-netconf-soap-04.txt

Ted Goddard, the author, couldn't be at the meeting. He has
prepared the current revision of the draft in the beginning of
2005 and explained the changes on the list.

Andy notes that it would be interesting to know which lower-layer
mappings are actually supported by NETCONF implementors.
Unfortunately we don't have any data on this.

"NETCONF 2.0"?

Since there were no further questions on the current drafts, Andy
suggests to adjourn this part of the meeting to discuss data modeling
issues. There have been discussions about "NETCONF 2.0" style work,
but it would preferable to have specific drafts as a basis for
discussion, rather than doing this "by committee" in rooms like this.
Andy's suggestion was not followed, however:

Protocol Extensions such as Notifications

Eliot asks about the process for defining NETCONF extensions. A
typical NETCONF extension - for instance, "notifications" - would
require at least two drafts, one that defines the feature and others
defining specific lower-layer mappings. Andy emphasizes that we
should get over the current deadlock (with respect to notifications)
that different lower layers suggest quite different approaches to an
asynchronous "channel", and at least the SOAP one doesn't seem to
support this at all. This looks like a tough decision - at one time
we thought about only supporting notifications for specific underlying
protocols (e.g. BEEP), but the WG had decided not to go down that path
because of worries about fragmenting the protocol. It would be useful
for someone to address this issue in a new draft.

Speaking for a group of NETCONF implementors, Jürgen Quittek
relates that they feel the lack of notifications to be the most
significant problem. They consider submitting a draft outlining
possible methods to address notifications. The open question is
whether to do them within or outside the NETCONF framework; that's
probably the first decision to make.

Sharon Chisholm thinks that we now have a better idea on how
notifications should be done than back when we decided to punt them
for "NETCONF 1.0". It is important for people to document their
approaches in drafts - ideally before the Paris meeting - so that we
have a basis for discussion, rather than brainstorming here. A little
discussion ensued between Andy's and Sharon's recollection of why
notifications were postponed. Andy's view is that the driving factor
was that participants felt they weren't worth the effort, and Sharon
found that the reason was mainly tactical - to get the less
contentious parts out first, although everybody eventually wanted
notifications in NETCONF. Sharon doesn't think that we have thought
about notifications enough to be able to say that they don't work on
certain transports - she has seen proposals that have very little
transport dependency.

Eliot tries to reformulate his question about the constraints for
extensions and capabilities, again with notifications as the example.
They could be implemented using another channel in both BEEP and SSH,
but the current SSH mapping draft doesn't talk about the ability to
use additional channels. Another approach would be to to
notifications over a separate TCP connection - they could be encoded
as a large RPC response that could be parsed in an intermediate
("streaming") fashion - this would work over all transports without
modifications to the current mappings.

Remembering previous discussions about notifications, Andy talks
about implementation difficulties with multiple channels, related to
assumptions about locking. Multiple channels could solve the issue of
mixing normal responses and asynchronous notifications, provided that
there are separate code paths for those at each end. But at that
point one could ask what this buys us that we cannot already do with
SNMP traps [or notifications]? We didn't start out to replace SNMP
notifications here - let's continue to use those until we figure
NETCONF notifications out.

General NETCONF Scope Discussion

Sharon claims that notifications are just a subset of more general
"asynchronous messaging" functionality for applications, many of which
are related to configuration. Andy is worried about adding to the
standard without clear requirements. Sharon points to a mailing list
thread about such messages; "configuration change" notifications; and
people looking at asynchronous messages from the monitoring
perspective, as a mechanism for (performance) logging. To Andy, this
sounds like reinventing IPFIX. Sending out accounting records is not
a network configuration protocol's job. Sharon claims there are
applications related to configuration, which will be shown in an
upcoming draft.

Faye Li supports Sharon's point of view. For configuration, an
audit trail must also be supported. Operators want to receive a
record for every configuration change.

Dan Romascanu feels like a few years ago, when we were discussing
whether to do configuration or a generic network management protocol.
He disagrees with Sharon's and Faye's point of view. On the other
hand, he thinks at one point we need a common framework for NETCONF
and SNMP. Should check whether NETCONF plays nice with any security
solutions that the ISMS WG might come up with.

Andy asks Sharon to issue a draft as a basis for discussion.

NETMOD

Passes to Sharon for her presentation on data modeling.

Discussion ended with the suggestion to produce drafts about data
modeling before the Paris meeting, and discuss them there.

Closing Remarks

Document authors are expected to produce revised drafts, with the
necessary modifications as discussed here, soon after the I-D queue
opens up after the meeting.

                                NETCONF meeting

   IETF 62, Minneapolis
   Tuesday 09.00-11.30 (actually 09.00-10.00)

   Chairs: Andy Bierman, Simon Leinen
   Minutes: Simon Leinen
   Jabber scribe: Eliot Lear

WG Last Call status

   All documents were in Working Group Last Call, lasting until Friday 18
   March (the week after the meeting). As this was the second WG Last
   Call, participants didn't find too many problems with the drafts in
   this round. There have been comments from people trying to implement
   the protocol, which can be viewed as a good sign. The documents should
   be ripe for submission to the IESG soon. Discussion about individual
   drafts followed.

  draft-ietf-netconf-ssh-03.txt

   Margaret Wasserman, the editor, couldn't be at the meeting because of
   other conflicting IETF duties. The latest revision mainly removed the
   option of starting NETCONF from a normal shell session - it must now
   be started as a separate netconf SSH subsystem.

   Wes Hardaker has thoroughly reviewed the draft and posted some issues
   to the mailing list. Margaret will address those issues in a
   forthcoming revision.

   Simon Leinen had found a small bug in the examples, where the C:
   (client) and S: (server) headers were inverted. This should remind
   participants of the importance of reviewing the documents for these
   kinds of problems also.

  draft-ietf-netconf-beep-03.txt

   Eliot Lear mentions that Jürgen Schönwälder provided detailed comments
   on his BEEP mapping draft, and promised a new BEEP draft based on
   these. Required changes include:
     * Adding some examples
     * Adding some text on <hello>, which was missed due to draft skew
       between the core (-protocol) and -beep drafts
     * Address an issue of Jürgen's on the SASL/TLS combination - after
       getting Jürgen to explain these in more detail
     * Reconsider the "application protocol" terminology, which Jürgen
       dislikes. Eliot is looking for suggestions for better terms.
     * Thorough review to make sure the BEEP mapping covers everything in
       the core protocol draft.

  Discussion of XML and Schema Definition Issues

    Schema Strictness Requirements

   Wes asks whether the intent is that an implementor should be able to
   use the XSD definitions to do most of the validity checking of NETCONF
   requests.

   Andy doubts that this is possible, in particular because XSDs cannot
   capture the variants related to capabilities.

    XML Directorate Review

   Bert Wijnen, our responsible Area Director, asked (over Jabber)
   whether the XML Directorate has been asked to reviewed the documents
   for correct XML usage.

   Andy states that this has not yet been done, and noted that one of our
   authors (Phil Shafer) is on that directorate.

  draft-ietf-netconf-protocol.txt

   Rob Enns decided not to show slides about the protocol draft because
   they are boring. Changes from last to current revision:
     * The many requests for clarifications from the mailing list have
       been addressed.
     * All of the closed issues that had come up in the WG Last Call have
       been addressed.
     * The change log was simplified because it was getting too long.

   Work is required in the following areas:
     * Filtering (section 6) - Some people have asked to clarify the
       section that explains how filtering works. Rob would welcome
       contributions for improved text. Andy - who had written that
       section - suggests that examples would be particularily useful
       here, and offers Rob his help to make the text more understandable
       later this week.
     * Examples in general - Past experience shows that implementors
       often use examples as a main guidance for implementations.
       Therefore, the examples should be given much care, in particular
       their correctness. Rob notes that all the examples in the protocol
       draft have been verified against the RelaxNG version of the
       NETCONF schema.
     * Clarify error codes for lock operations - LOCK_FAILED should be
       used instead of IN_USE.

  Secure-Transport Requirement

   John Ng asked about the requirement for secure transports (section 2.2
   in the protocol draft), in particular whether it would be possible to
   use something like unencrypted telnet in a "secure private network"
   environment, or in situations where cryptography cannot be used. Andy
   assumes that security experts would not let a NETCONF proposal pass
   without mandatory security. Bert notes that security is mandatory to
   implement, but not mandatory to use.

  Detecting Dead Sessions

   John Ng raises the issue of how an agent notices when a manager has
   gone away (so that locks can be released). Andy says this is currently
   indicated by loss of the underlying TCP connection. John points out
   that this fails to distinguish between a manager that has nothing to
   say and one that has silently gone away. Eliot expresses his hope that
   someone who is holding a lock wouldn't be idle [but does that really
   help here?]. Andy recalls that we had this discussion before and
   decided this was a non-problem - hung sessions can be broken using
   <kill-session>.

  draft-ietf-netconf-soap-04.txt

   Ted Goddard, the author, couldn't be at the meeting. He has prepared
   the current revision of the draft in the beginning of 2005 and
   explained the changes on the list.

   Andy notes that it would be interesting to know which lower-layer
   mappings are actually supported by NETCONF implementors. Unfortunately
   we don't have any data on this.

"NETCONF 2.0"?

   Since there were no further questions on the current drafts, Andy
   suggests to adjourn this part of the meeting to discuss data modeling
   issues. There have been discussions about "NETCONF 2.0" style work,
   but it would preferable to have specific drafts as a basis for
   discussion, rather than doing this "by committee" in rooms like this.
   Andy's suggestion was not followed, however:

  Protocol Extensions such as Notifications

   Eliot asks about the process for defining NETCONF extensions. A
   typical NETCONF extension - for instance, "notifications" - would
   require at least two drafts, one that defines the feature and others
   defining specific lower-layer mappings. Andy emphasizes that we should
   get over the current deadlock (with respect to notifications) that
   different lower layers suggest quite different approaches to an
   asynchronous "channel", and at least the SOAP one doesn't seem to
   support this at all. This looks like a tough decision - at one time we
   thought about only supporting notifications for specific underlying
   protocols (e.g. BEEP), but the WG had decided not to go down that path
   because of worries about fragmenting the protocol. It would be useful
   for someone to address this issue in a new draft.

   Speaking for a group of NETCONF implementors, Jürgen Quittek relates
   that they feel the lack of notifications to be the most significant
   problem. They consider submitting a draft outlining possible methods
   to address notifications. The open question is whether to do them
   within or outside the NETCONF framework; that's probably the first
   decision to make.

   Sharon Chisholm thinks that we now have a better idea on how
   notifications should be done than back when we decided to punt them
   for "NETCONF 1.0". It is important for people to document their
   approaches in drafts - ideally before the Paris meeting - so that we
   have a basis for discussion, rather than brainstorming here. A little
   discussion ensued between Andy's and Sharon's recollection of why
   notifications were postponed. Andy's view is that the driving factor
   was that participants felt they weren't worth the effort, and Sharon
   found that the reason was mainly tactical - to get the less
   contentious parts out first, although everybody eventually wanted
   notifications in NETCONF. Sharon doesn't think that we have thought
   about notifications enough to be able to say that they don't work on
   certain transports - she has seen proposals that have very little
   transport dependency.

   Eliot tries to reformulate his question about the constraints for
   extensions and capabilities, again with notifications as the example.
   They could be implemented using another channel in both BEEP and SSH,
   but the current SSH mapping draft doesn't talk about the ability to
   use additional channels. Another approach would be to to notifications
   over a separate TCP connection - they could be encoded as a large RPC
   response that could be parsed in an intermediate ("streaming") fashion
   - this would work over all transports without modifications to the
   current mappings.

   Remembering previous discussions about notifications, Andy talks about
   implementation difficulties with multiple channels, related to
   assumptions about locking. Multiple channels could solve the issue of
   mixing normal responses and asynchronous notifications, provided that
   there are separate code paths for those at each end. But at that point
   one could ask what this buys us that we cannot already do with SNMP
   traps [or notifications]? We didn't start out to replace SNMP
   notifications here - let's continue to use those until we figure
   NETCONF notifications out.

  General NETCONF Scope Discussion

   Sharon claims that notifications are just a subset of more general
   "asynchronous messaging" functionality for applications, many of which
   are related to configuration. Andy is worried about adding to the
   standard without clear requirements. Sharon points to a mailing list
   thread about such messages; "configuration change" notifications; and
   people looking at asynchronous messages from the monitoring
   perspective, as a mechanism for (performance) logging. To Andy, this
   sounds like reinventing IPFIX. Sending out accounting records is not a
   network configuration protocol's job. Sharon claims there are
   applications related to configuration, which will be shown in an
   upcoming draft.

   Faye Li supports Sharon's point of view. For configuration, an audit
   trail must also be supported. Operators want to receive a record for
   every configuration change.

   Dan Romascanu feels like a few years ago, when we were discussing
   whether to do configuration or a generic network management protocol.
   He disagrees with Sharon's and Faye's point of view. On the other
   hand, he thinks at one point we need a common framework for NETCONF
   and SNMP. Should check whether NETCONF plays nice with any security
   solutions that the ISMS WG might come up with.

   Andy asks Sharon to issue a draft as a basis for discussion.

NETMOD

   Passes to Sharon for her presentation on data modeling.

   Discussion ended with the suggestion to produce drafts about data
   modeling before the Paris meeting, and discuss them there.

Closing Remarks

   Document authors are expected to produce revised drafts, with the
   necessary modifications as discussed here, soon after the I-D queue
   opens up after the meeting.