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.
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
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.
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.
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:
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.
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.
Rob Enns decided not to show slides about the protocol draft because they are boring. Changes from last to current revision:
Work is required in the following areas:
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.
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>.
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.
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:
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.
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.
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.
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.