[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DRAFT minutes from NETCONF meeting at IETF 70
The minutes look good, thanks, Simon.
I have just one comment:
> Dan Romascanu: This is the document that drew the most attention
from
the IESG when the charter came up. There was an early review in the
IESG to make sure that there weren't any red flags.
I was referring to the early security review for NETCONF over TLS which
was not yet performed as it could be understood in the text above, but
was introduced as an explicit milestone in the charter to be performed
by the Security Area experts.
Dan
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Simon Leinen
> Sent: Tuesday, January 01, 2008 12:32 AM
> To: netconf@ops.ietf.org
> Subject: DRAFT minutes from NETCONF meeting at IETF 70
>
> Draft minutes have been posted to the IETF proceedings site on
>
> http://www3.ietf.org/proceedings/07dec/minutes/netconf.html
>
> Please check them and send me your corrections. I'll try to
> make sure that those are applied quickly. Thanks in advance!
> Plain-text version of the draft minutes follows.
> --
> Simon.
>
> NETCONF Working Group meeting
>
> IETF 70, Vancouver, B.C., Canada
> Wednesday, 5 December 2007
> Minutes by Simon Leinen based on notes from David Partain.
>
> Administrativia ([1]slides)
>
> NETCONF is 4.5 years old!
>
> Dan Romascanu: Applause for outgoing chairs! The process
> is ongoing for
> selecting new chairs.
>
> Notifications Document (draft-ietf-netconf-notifications)
>
> The notification document passed WG last call, and is pending proto
> writeup, to then be handed to the IESG. Dan Romascanu
> mentions that the
> writeup can be done by one of the new chairs or someone else.
>
> Bert Wijnen: Shouldn't the proto write-up be written by one of the
> outgoing chairs?
> Simon: That might be an option.
>
> Use of Mailing Lists
>
> Mailing lists: Many mailing lists are used for NETCONF-related
> discussions right now, including the APPS area mailing list. One
> proposal: move all netconf-related discussions into the
> main netconf
> list.
> Sharon Chisholm: keep netconf for chartered items, and keep NGO for
> non-chartered discussion. Axe all the others. After
> discussion, the new
> proposal is to keep all lists except for the netmod list at Nortel
> (netconfmodel@lists.nortel.com). Proposed usage guidelines:
>
> netconf@ops.ietf.org
> For discussions related to work on whatever is the current
> NETCONF charter.
>
> ngo@ietf.org
> For discussions about unchartered NETCONF-related work,
> including data-model proposals in general.
>
> yang@ietf.org
> For discussion about the YANG data-modeling
> language proposal.
>
> netconfmodel@lists.nortel.com
> Can be abandoned.
>
> New Security Advisor
>
> Charlie Kaufman agreed to serve as the new security advisor for the
> working group.
>
> New charter items
>
> The new charter was accepted by the IESG in November. One
> goal of this
> meeting is to determine whether input documents are in a
> good enough
> state for their change control to be moved to the working group.
>
> __________________________________________________________________
>
> Mohamad Badra on NETCONF over TLS ([2]slides)
>
> Balazs Lengyel: The authentication part is welcome, but
> access control
> is outside our current charter.
>
> Dan Romascanu: This is the document that drew the most
> attention from
> the IESG when the charter came up. There was an early review in the
> IESG to make sure that there weren't any red flags.
>
> Show of hands
>
> 8-10 people present have read this document, almost the same number
> thinks this should be adopted as a WG item, with no-one
> objecting. Will
> confirm this decision on the mailing list. Not terribly
> wide review.
>
> __________________________________________________________________
>
> Balazs Lengyel on partial locking ([3]slides)
>
> Balazs Lengyel spent more time explaining the YANG module
> that he has
> written for maintaining configuration of the locks on a system.
>
> Full XPath support vs. (Instance Identifier) XPath subset
>
> Sharon Chisholm: have sent a bunch of comments to the
> list. One of them
> is around XPath: "if you don't support XPath, then you can
> support this
> smaller subset". Should we just mandate XPath if you support this
> capability (fine-grained locking)?
>
> Andy Bierman: absolutely doesn't want to use full XPath. The XPath
> expression can be dynamic.
> Balazs: the XPath is only evaluated once.
> Andy: that's a security hole -- if you don't apply it when it's
> evaluated. Andy wants the
>
> Use of YANG to describe locking data model
>
> Dan Romascanu: about the use of YANG: Not sure whether it
> will be in
> the final draft, but as long as it's not a standard, we
> cannot use it
> normatively - although perhaps in an annex. For
> normatively describing
> the data model, we'd need to use something else.
> Balazs agrees that we'll have to deal with this problem.
>
> Lock semantics, interactions, and security
>
> Phil Shafer: Please talk about the interactions between
> partial locks,
> get-config, and commit. Phil thinks there are interactions
> that Balazs
> doesn't. If two users have locked two different parts of
> the database
> with dependencies between the two, and I change mine based on your
> values which then are not committed, what happens?
> Balazs: there are issues; we need to describe this carefully.
>
> Wes Hardaker: if you do a partial lock on part of the
> config but then
> try to edit outside that part that you've locked, do you
> get feedback
> on that?
> Balazs: no, not at this point.
> Wes: only an interesting management error to consider.
>
> Wes Hardaker reiterates that he's worried about evaluation of XPath
> expressions taking place at a time other than when it's
> being applied.
> Andy: what if one of the things you are changing is in the lock
> expression?
> Balazs: having a very dynamic lock has its own set of problems.
>
> Phil Shafer: Lifespan of the lock, in terms of how long they're
> supposed to last. The global lock was intended to cover
> the duration of
> your edit, whereas you are talking about longer times.
> Balazs: it would be possible to add a timeout to the partial lock.
> Phil: are you intending these to be short-term or long-term locks?
> Balazs: I can't control it, but my intention is that they be
> short-term. Balazs will add a comment to the draft.
>
> Wes Hardaker: one question about the partial lock of a
> tree. If I lock
> the user table, can someone else add a user?
> Balazs: no.
>
> Mark Scott: why can a lock only be unlocked in the same session?
> Balazs: even today, if you have locked (the global lock) in one
> session, you can't unlock it in a different user session and we're
> continuing that.
>
> David Harrington: What session does SNMP lock?
> Balazs: one idea is that all non-NETCONF protocols might have a
> reserved session id range.
> Sharon: the monitoring draft is a good place to report
> these sessions.
>
> Phil Shafer: you mentioned being able to do locks on startup
> configuration, but that config is not writable.
> Balazs: you're probably right.
>
> Show of hands
>
> 11-12 people present have read this document. Nearly all
> of those favor
> WG adoption, with one person against it.
>
> __________________________________________________________________
>
> Mark Scott on monitoring NETCONF ([4]slides)
>
> Balazs Lengyel: the GUI / CLI / locks inside are very much needed.
> Consider locks that are "internal" like a backup process.
> Why aren't
> any counters included?
>
> Mark: simply because it's a different area, and it would
> be hard to get
> it standardized in the short term. We don't think that the
> operational
> data is not relevant to making the configuration process
> more bug-free.
> There is a minimal set still included.
>
> Show of hands
>
> About 8 people present have read this, about 6 in favor of
> adoption, no
> objections.
>
> __________________________________________________________________
>
> Hideki Okita: schema advertisement with WSDL and XSD ([5]slides)
>
> Rohan Mahy: Are you assuming that schemas be transient?
> Hideki Okita: mostly interested in knowing where the
> information is and
> how to get to it.
> Rohan: if I go to my device and ask it about its schemas,
> and there are
> YANG modules, XSD, and there's a RelaxNG schema. Will the
> query tell me
> about all three or only one of them?
> Simon: are you saying it would be useful to be able to get
> the schemas
> in different forms?
> Rohan: yes, it'd be useful.
>
> David Perkins: the user wants to know what the device
> does, not what
> the standards document says it's supposed to do. If the
> device doesn't
> fully comply, you want to know that.
>
> Dan Romascanu reminds presenters to avoid putting company names on
> slides.
>
> Show of hands
>
> About 11 people present have read this document. Polling
> on WG adoption
> is deferred to after the next draft's discussion.
>
> __________________________________________________________________
>
> Mark Scott on schema query ([6]slides)
>
> Scope perhaps a bit narrower than the previous proposal.
>
> Balazs: are you opposed to merging the two drafts?
> Mark: not opposed.
>
> Hideki Okita: what is the use case for the work?
>
> Specific operations (<get-foo>) vs. <get>
>
> Phil Shafer: have we abandoned dedicated RPCs and gone to the
> all-powerful get?
>
> Balazs: I have some rules in my mind when to use them. Can
> the normal
> RPCs accomplish them, then why not use it?
>
> Mark: I had the same question. Maybe we should write down when it
> should be new ones and when not.
>
> David Harrington: I thought NETCONF was going to be
> "task-based" and I
> think it would make it unfortunate if this became
>
> Andy: when you are actually adding a new verb, then do so.
> If you're
> just changing what you're getting, then don't add a new verb.
>
> Sharon: CLIs have a single verb for a show but not for
> changes. I agree
> that there are cases where we should create new verbs.
> Don't see that
> this is a case where a new verb is needed.
>
> Finer-grained semantics
>
> David Perkins: How do you specify that a device has implemented a
> subset of a schema?
> Mark: you'd have to put your own sub-set schema somewhere
> and publish
> that subset somewhere.
> Sharon: not sure that we need this for our requirements
> unless they're
> non-conformant. The manager should be able to handle that
> non-mandatory
> objects aren't there. For the most part, the high-level information
> (name, version number) is sufficient. We're getting 90% of
> the value
> without getting into the specifics.
>
> Wes: David Perkins is absolutely right. NM applications
> can't figure
> out how things are broken.
>
> David Harrington: concerned that this sounds like
> AGENT-CAPABILITIES,
> which failed.
>
> Dan Romascanu: This looks more like the RMON capabilities stuff.
>
> Show of hands
>
> 10-11 people present have read Mark's document. In order
> to gauge the
> relative preference, Simon asked for a show of hands in favor of WG
> adoption for each of the drafts. Because the sample size
> is small, the
> results cannot be used to make a decision. Five people
> think Hideki's
> draft should be adopted, 6-7 people think Mark's draft should be
> adopted.
>
> Dan Romascanu: A suggestion as a contributor: Since there
> doesn't seem
> to be a clear-cut answer, maybe the two groups should try to work
> together.
>
> Andy Bierman: concerned that a NETCONF agent would have to
> use HTTP. A
> lot of overhead for not much information instead of using
> NETCONF to
> get it.
>
> David Harrington: concerned about introducing dependencies on other
> protocols.
>
> Hideki Okita: we have HTTP already, so it's not a concern
> to us, but I
> understand your concern.
>
> Simon: it's clear why your approach is attractive given that you've
> used SOAP.
>
> Phil Shafer: operators often do not enable HTTP on their devices.
>
> __________________________________________________________________
>
> Other business
>
> Sharon: there's some work that's not in the charter
> because we didn't
> know if this would be a new WG or if it'd be in a
> 1. Clarifications of implementation issues in a bis of
> the NETCONF RFC
> 2. Update on transport documents
>
> __________________________________________________________________
>
> Tomoyuki Iijima on experience of implementing a SOAP-based NETCONF
> client-server ([7]slides)
>
> Please contact him if you'd like to see a demonstration.
>
> References
>
> 1. http://www3.ietf.org/proceedings/07dec/slides/netconf-0/sld1.htm
> 2. http://www3.ietf.org/proceedings/07dec/slides/netconf-3/sld1.htm
> 3. http://www3.ietf.org/proceedings/07dec/slides/netconf-1/sld1.htm
> 4. http://www3.ietf.org/proceedings/07dec/slides/netconf-6/sld1.htm
> 5. http://www3.ietf.org/proceedings/07dec/slides/netconf-4/sld1.htm
> 6. http://www3.ietf.org/proceedings/07dec/slides/netconf-5/sld1.htm
> 7. http://www3.ietf.org/proceedings/07dec/slides/netconf-2/sld1.htm
>
> --
> 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/>
>
--
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/>