-------------- Draft minutes IETF NETCONF session at IETF74 Minutes of the Network Configuration (NETCONF) WG Session at the IETF #74, San Francisco, CA, USA TUESDAY, March 24, 2009, 1300-1500 WG Chairs: Bert Wijnen Mehmet Ersue AD: Dan Romascanu Many Thanks to the minute takers: Phil Shafer and Ladislav Lhotk jabber scribe: Dvid Partain There were approx. 30 persons in the NETCONF session. Agenda and status: WG status review has been given by Mehmet Ersue. See slides: http://www3.ietf.org/proceedings/09mar/slides/netconf-0.ppt -------------------------------------------------------------------------------------------------------- Chartered work-items 1. Partial lock RPC for NETCONF - Balazs Lengyel http://www3.ietf.org/proceedings/09mar/slides/netconf-1.ppt Status: draft-07 available Recent comments in ML: - lock-id unique for whole server, not just a session - primary use case for writable-running Bert Wijnen: Is lock-id indeed unique on the server? BL: Yes. BW: so we need to make it more clear in the document; these are editorial comments. We consider these as "last call" comments. Dan Romascanu: I'd like to see the edit to understand what the changes exactly mean. DR: Don't need a new version BL: So I can just send a few lines in email? DR: yup: BW: this document is ready for last call DR: from jabber: Washam Fan: It will help to monitor both netconf and non-netconf locks. BL: We can find a way how to distinguish these two. BW: washam should post this to the mailing list David Harrington: Source of the lock should be identified. BL: Now the monitoring draft doesn't cover foreign influences. MB: RFC4741 says for global locks that session-id=0 is returned if the lock is held by a foreign session, we could extend it to partial lock. DR: Basic question - are we monitoring other stuff? BW: Monitoring unknown functions makes little sense, but editors should send proposal. DH greed. Phil Shafer: Session-id 0 doesn't say where it comes from, but the device should know where the lock came from. BL: It's not good to encode the source in lock-id. 2. NETCONF Monitoring Schema - Martin Björklund presenting for Mark Scott http://www.ietf.org/proceedings/09mar/slides/netconf-2.pdf Some items raised require resolution in other drafts: - global lock - dynamic capabilities (can server change capability on the fly?). Lot of text in the draft is written as if it should be supported. BW: We have to agree what to do, I'd urge 4741bis to handle this ASAP. MB: we need to solve that before publishing the monitoring draft BL: the draft can be neutral PS: no, since this makes capabilities session specific PS: The server should be able to change capabilities dynamically (e.g., server upgrades its SW). Andy Bierman: The only problem is breaking the contract stated in hello; in some cases the session should be torn down. PS: Big thing that changes capabilities is SW upgrade, which hopefully needn't require reboot. AB: the issue deals with honoring the contract, so the session has to be torn down BW: do we have to describe these cases PS: triangle of terror when tearing down connection that is installing software AB: with three or four namespaces, I don't know what to do with it MB: on the (interrupted) AB: the manager reads a capability that no longer works AW: we can allow for extensibility without making the current situation worse than current situation MB: counter definitions AB: punting to fact finding trip not acceptable; make per-session and global counters the same. The current counters are useless if you have more than one user BW: we can add a thousand counters, but few will be used. New counters need justification or use case. Focus teams doesn't mean design team. ME: who will be on the team? MB: no idea BW: editors should post message to mailing list asking for suggestions. Give them a chance for the next two weeks and then close the issue. Items for discussion: - One schema defines one NS, true for current schema languages, but should we be more flexible? AB: I don't know any use case from manager POV, I'd just put in a single NS. - Counter definitions: are the current counters sufficient? AB: I don't see a need for a global counter for outgoing notifications. BW: I'd like to limit the number of things we monitor, we shouldn't define new counters arbitrarily - use cases needed. MB: People interested in this should send proposals to ML. BW: But do it now, not during WGLC! - Extensibility: should enums in XSD model be raplaced with QNames? (a la identities in YANG) BW: It makes sense to me. MB: I will send a proposal covering this. Next steps: -05 in April DP: comments from jabber: washam: re: monitoring of non-netconf locks is missing from the draft; BL: we could use ranges or old/even DR: post to mailing list DH: it should identify the source of the lock BL: does monitoring cover non-netconf sessions? DH: does it cover non-netconf locks? If so, it should give details BL: use case is that something is locked, then look in the monitoring data MB: 4741 gives session-id 0 for non-netconf sessions; no indication of source BW: session-id 0 is a sufficient answer for the first draft MB: that matches 4741 use of session-id 0 DR: (lost) BW: don't know enough about other types of lock to know if "session-id" is meaningful; netconf locks are all we need. DH: agree PS: please give a clue about who (cli, web, etc) holds the lock; use a yang identity. DH: washam has written a mib to do this 3: With-defaults capability for NETCONF - Balazs Lengyel http://www3.ietf.org/proceedings/09mar/slides/netconf-3.ppt Basic behaviours for handle defaults (report all, trim, explicit, ...) - with-defaults == true: send all values (i.e., report all behaviour) - with-defaults == false: remove all values equal to default (trim) - with-defaults absent: use basic behaviour Interaction with filtering: Every operation shoud be applied on the full tree with substituted defaults and then the default values removed from the reply. MB: You don't want to force implementations to remove explicit values. BW: Where are we with this draft? PS: Four different behaviours encoded in a two-value boolean. BL: This is not correct. The four behaviours are stated in a parameter of the w-d capability. AB: If you don?'t use w-d, this is itself is a value, but an issue arises when w-d is false. PS: In the capability the agent states which behaviours it supports, so client then could directly select the one it wants. BL: We will think about this. BW: I hope you can do new revision in mid April. 4. RFC 4741bis - Martin Björklund http://www3.ietf.org/proceedings/09mar/slides/netconf-4.pdf Changes in -00: bugfixes - In validate - what is inline conf subtree - edit-config? Alt. 1. validate only full conf, 2. remove inline validation Proposal: add test-only parameter PS: Is the 4741bis intended to change what's available or just clarify? I don't want enhancements. MB: Here the clarification calls for an enhancement. AB: The intention was to do full only, test-only came in later. BL: I support test-only. BW: check the room (10 hands for ALT1; opposed 0; ALT2: 0) PS: Does test-only go to 4741bis or will be a new draft/capability? PS: concern w/ changing 4741; concern this is the first of 12-15 new capabilities BW: We have to check this. AB: You can define new capability validate 1.1 without changing 4741. BW: Go discuss this in ML - Role of XSD: must capabilities use schema extension mechanisms? BW: Let's postpone this question to the XSD discussion. - Is :startup allowed together with :candidate? MB: slide: capabiity combinations Mehmet Ersue: Is there any reason for not allowing it? AB: No, not teh intent - :startup && :confirmed-commit - probably yes, but should be clarified - MB: slide: rpc attributes should all be returned, including xmlns? Proposal: specify all except xmlns AB: why this CLR? PS: xmlns may override ones you use MB: No, you can use yours at the next level of XML hierarchy. AB: echo all; is there confusion over "all"? PS: can't echo when there's a conflict DR: JS: clash between client and device namespaces on attributes DR: JS: conflict when at the same level -------------------------------------------------- **** Non-chartered items 1. Generic solution for msg integrity slide 7 in: http://www3.ietf.org/proceedings/09mar/slides/netconf-0.ppt BW: slide: Generic solution for the message integrityy issue - Should NETCONF over TLS use now the same delimiter as in SSH? Theoretical problems, safe in practice. Lada Lhotka: there may be hidden security issues via injection. BW: This should be avoided by access control. Wes Hardaker: it's a known problem when there is no framing, if everyone fully validates, this is less of an issue. If the manager sends multiple operations, then this is an even bigger issue. multiple RPC requests shouldn't be processed sequentially AB: we have very simple proc. model, no correlation among rpcs - rely on access control DH: In my view, nothing has to be done, except admitting it in security considerations section. (... discussion about escaping and stuffing ...) WH: There is no spec that something must be escaped if it appears in the message. AB: (lost) WH: you check these at the device, don't expect the manager to do it AB: RPCs are serialized, expecting client to handle it ; do we need a batching mechanism? BW: does that mean you want us to work on framing? AB: no; rely on access control WH: you can do anything you want, as long as you document it BW: EOM can appear anywhere; access control will protect you WH: (examples) ISPs allow clients to access counters on their interfaces; are they manually processed? web form may have more access than needed. DH: JS: nothing is needed but updating the security concerns from TLS into the SSH rfc when it is updated. ME: so it's not an issue PS: can we at least escape it? BW: no not needed DH: so we just need to tell crackers to read the note in the security section WH: escaping prevents us doing something wrong BW: someone (looking at PS) needs to write a individual draft AB: Changes cannot be done w/o changing version number. PS: No version change is needed. 2. Robust conf mngmt - Bob Cole http://www3.ietf.org/proceedings/09mar/slides/netconf-5.pdf Verification = checking against set of rules Validation = measuring behaviour against expectations Proposal: enhance v&v capabilities in NETCONF, move part of tests to the agent. Tests can be specified in data modelling language. BW: Do we see value in this type of work? AB: Better justification is needed. Jürgen Schönwälder: Confusing terminology, we have NETCONF server&client, and validation has a very specific meaning in XML. BC: My background is modelling&simulation and verification and validation mean different things there. BC: Is there any interest in this? BW: how many read? ( 6 hands) who is interested? (4 hands) Will Ivancic: NASA sees this as useful BW: are you deploying netconf? WI: no, but might with a transport oriented DR: JS: confusing terminology BW: suggest you do another draft and readdress next time. 3. Use of XSD and/or YANG - Andy Bierman http://www3.ietf.org/proceedings/09mar/slides/netconf-6.pdf How do we extend the basic NETCONF schema with new capabilities? XSD is not correct and cannot cope well with the extensions. OTOH, YANG can't model XML attributes. BW: I thought the idea was to write the schema in YANG and use some extensions for the attributes. AB: can't augment for with-defaults since there's no netconf.yang; will be other issues in the future, so should we make one? issues: attributes, XSD .vs. YANG, and 4741 text appearing (cut-n-paste) in netconf.yang LL: The XSD in RFC4741 has to be fixed in any case. In draft-lhotka-netconf-relaxng-00 I demonstrated how the schema extensions could be handled in RELAX NG. If something similar isn't possible in XSD, it should be abandoned. ME: use extensions to make this happen LH: talked to xml guru who liked it and liked that we don't have attributes AB: LH draft is better MB: like it but we stick to operation layer, since yang doesn't do BL: data organization AB: central management Session closed when we ran out of time. During the NETCONF session, there was a sense in the room for enabling YANG to define XML attributes (only the two we need) based on YANG extensions and using YANG for the definition of NETCONF base module. Additional discussion in the NETMOD session the day after lead to a consensus in this direction. Andy Bierman will bring the consensus in the NETMOD session to the NETCONF maillist for confirmation.