Ever onward

[Phil Shafer <phil@juniper.net>]

In the interest of moving netconf forward, I'd like to make
two proposals.

First that we look at the list of issues Andy posted before the
holidays and see which ones have an existing concensus.  If a
concensus can be declared, let's close these issues asap.

Second that we look at the list of issues and pitch all the
questionable features for which concensus is not appearing.  If we
haven't reached concensus yet, we likely won't and continued debate
risks stalling this work.

In short, let's get a simple, implementable spec out without any
of the bells and whistles and demonstrate that this is real usable
technology.

Here's my take on which issues are where.  Refer to
Steve's handy issue lister thingey for information on
the individual points (http://www.nextbeacon.com/netconf/).

Concensus-Ready Issues: IMHO the following issues have been
sufficiently discussed and can be closed:

  1.1: Feature subset consistency
     Concensus: one common protocol

  1.2: Feature subsetting discovery
     Concensus: use capabilities exchange

  1.3: Base Protocol Operations
     Concensus: the list is detailed in the current draft

  4.1: Multiple <RPY> messages
     Concensus: one reply per request

  6.1: SOAP Proxy
     Concensus: remove proxy-related text

  6.2: SOAP over BEEP
     Concensus: no requirement + no need = no one wants it

  8.1: hould netconf support multiple transport connections per session?
     Concensus: No. No need and difficult to implement

  9.1: DoS attack using global <lock>
     Concensus: not realistic scenario

  9.2, 13.14: <steal-lock>
     Concensus: not required

  9.3.1: Authorization control for protocol operation based access
     Concensus: follow permissions/mechanisms for CLI users

  9.3.2: Authorization control for High-level RPC calls
     Concensus: follow permissions/mechanisms for CLI users

  9.4: Partial locks
     Concensus: simple global locks win

  10.1.1: Databases:
     Concensus: agree

  10.1.2: Files
     Concensus: agree

  10.3.1: Global vs. Per-Session candidates
     Concensus: don't need 'em

  10.4: <running> configuration
     Concensus: one running configuration

  10.5: <startup> configuration
     Concensus: can't delete startup

  11.2: Standard Capabilities: Which capabilities are needed 
     Concensus: keep 'em all

  11.3.1: Session ID
     Concensus: no

  13.1: edit-session
     Concensus: defer

  13.2: kill-session to end ssh
     Concensus: not required (just close the connection)

  13.7.1, 15.1.2: <format> parameter
     Concensus: nuke the format parameter.  Use namespace
      to control text/xml/whatever.

  13.8: <get-all>
     Concensus: 'get-all' is a confusing name, but less
      confusing that 'get-state' and no alternatives
      have been raised, so ....

  13.12.2: <target> Clarification
     Concensus: yes

  13.12.3: Error handling
     Concensus: negative response should indicate lock owner
      (in standard element)

  13.15.1: Early termination
     Concensus: if confirming commit doesn't happen, the device
           should rollback to the previous configuration

  13.16.1: Clarifications [PROT]
     Concensus: bug in spec

  13.17.2: remote configurations
     Concensus: remote configurations should be manipulated remotely
      (outside the netconf server)

  15.1.1: Access control
     Concensus: should follow permissions/mechanism of the cli

  16.1: Distributed unit of work identifier
     Concensus: <rpc> attributes are echoed on <rpc-reply>
        so this is really up to the app


The following issues have been sufficiently discussed with no
concensus appearing:

  2.*, 4.2, 13.9, 13.10, 13.11: Notifications
     Status: no agreeable model, mechanism, or requirement

  3.*: Channels
     Status: no agreeable model, mechanism, or requirement

  12.1: <rpc-abort>
     Status: not proven worthy

  12.2: <rpc-abort-reply>
     Status: useless without <rpc-abort>

  12.3: <rpc-progress>
     Status: not proven worthy


Additionally, the following issues have not generated enough
discussion for a concensus to appear.  Lack of discussion implies
lack of interest implies non-issue.  Let's close 'em fast.  They
can become capabilities in the future.

  13.12.1: Multiple concurrent locks
  13.15.2: Implicit Rollback
  13.17.1: last-known-good config


This leaves us with the following issues:

  5.1: End of message directive
     Status: Need some sort of framing; is "<?eom?>" or "&&" sufficient?

  6.2: SOAP header usage
     Status: unknown

  7.1: Need to compile a list of criteria then prioritize the list
     Status: delay this until we have some experience with netconf

  10.2: User named databases
     Status: Need some thought and some proposals

  11.1.1: How should a capability be represented in the <hello> exchange?
     Status: Not sure what the exactness of precise elements buys us

  12.6: Need to finalize all fields in the <rpc-error> element
     Status: needs work

  14.1) Subset specification
     Status: Element subtree filtering is in the spec now,
      but this issues has an impact on data modeling, and
      is most likely specific to the data model.

  15.2) Data Naming Protocol Impact
     Status: needs heavy thought

Of these eight issues, 1 or 2 should be delayed for now, so the
work list shrinks to something quite manageable.

These lists are strawmen.  Please comment asap.

Thanks,
 Phil

--
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/>