[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ever onward
At 11:58 PM 1/29/2004, Phil Shafer wrote:
>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.
Thanks Phil, for the excellent email. I agree with both
points above. At first I thought the idea of 2 protocols
in one to make both main user communities happy would
work, but it won't. We should simplify and finish up.
I think the core protocol feature set could be extended
to add notifications and management channel support to
a NETCONF session later.
I think people that disagree with this proposal should speak
up soon, or the WG consensus will be declared to pursue this
approach, and Simon or I will ask the WG authors to adjust their
documents accordingly.
>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/).
I've been meaning to go through the minutes from the
past 2 or 3 meetings, plus the WG email, and come up
with a list like you have below -- thanks for doing
my homework for me :-) :-)
It would be great if we could finish up the issue list
before the Seoul IETF, but just in case, we asked for
2 meeting slots. We need to settle all protocol
details and pick a mandatory application mapping
by the end of IETF #59. We need a stable snapshot
of NETCONF so developers can get started.
Andy
>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/>
--
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/>