Subject: [Netconf] draft minutes NETCONF session at IETF74

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 1 Apr 2009 12:35:55 +0200

First, thanks to Lada and Phil for taking notes.

Below are the draft minutes that I compiled from the two sets of notes.
Pls let us know asap if you see any errors or omissions.

Bert and Mehmet

-------------- 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 <[email-masked]>
Mehmet Ersue <[email-masked]>
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
    <rpc>
  BL: data organization
  AB: central management

Session closed when we ran out of time.

   So 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.