Re: Difference between get and get-config

[Andy Bierman <ietf@andybierman.com>]

McDonald, Ira wrote:
> Hi,
>
> Andy Bierman wrote:
> > Yes, well, thankfully, the IETF lets us change and correct documents.
> > As Juergen pointed out, the standards process does not actually
> > expect documents to be perfect at the time of Proposed Standard.
> >
> > We are allowed to do any of 4 things (I think) wrt/ IETF Process,
> > subject to IETF Approval:
> >
> >  1) Advance RFC 4741 to Draft Standard as-is
> >  2) Create a clarification-only update to RFC 4741 and advance to DS
> >  3) Create any update to RFC 4741 and cycle at Proposed Standard
> >  4) Reclassify RFC 4741 as Historic (yeah, right ;-)
> >
> > Gather all the clarifications for later...
>
>
> About your options (1) or (2):

NETCONF is at Proposed Standard status now, not Draft Standard.
I was not stating any opinion on which choice (1 - 3) is most
appropriate.  Option (3) is the easiest and most likely.
If and when the protocol reaches DS status, different options
would be available.

> Well, not quite.  Once an IETF Draft Standard is approved,
> that Draft Standard MUST NEVER be revised in a way that 
> breaks backward compatibility.  Also, two independent 
> implementations of a client as well as two independent 
> implementations of a server that implement EVERY operation 
> and element are necessary to advance to Draft Standard. 
> These flaky Netconf error conditions would effectively 
> preclude such advancement, even if the rest of the Netconf
> protocol were bullet-proof (which it isn't).
>
> Your option (3) would be appropriate, but cleaning up the
> error conditions and all the other ambiguities should be
> done before forwarding it to the IESG for last call.

The error ambiguities are due to the separation of protocol
and content layers.

> Your option (4) isn't really such a joke - a clean page
> might be the better approach.

NETCONF isn't starting over because some corner-case error codes
are not spelled out for every conceivable data model that could
ever be used with the protocol.

> IMHO - a management protocol without a data model and
> complete object/attribute/element semantics is of very 
> dubious value.

And yet some people are still bothering to implement the
protocol anyway, believing good proprietary solutions
will lead to good standards someday.

Data models (like those in the Notifications draft) will
get defined one or two at a time, and get fully documented
as well as possible by the WG volunteers doing the work (as usual).

There are plenty of NETCONF data modeling proposals out there already,
and all it takes to make them standards is lots of hard work.

> Cheers,
> - Ira

Andy

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