Re: [Netconf] Draft Charter Proposal for NETCONF WG

[t.petch <[e-mail]>]

----- Original Message -----
From: "Juergen Schoenwaelder" <[e-mail]>
Sent: Friday, March 03, 2017 1:34 PM

> On Fri, Mar 03, 2017 at 12:24:34PM +0000, t.petch wrote:
> > ----- Original Message -----
> > From: "Kent Watsen" <[e-mail]>
> > Sent: Wednesday, March 01, 2017 8:14 PM
> >
> > > > Kent
> > > >
> > > > 7 is a monster because of the XML encoding rules, not because of
the
> > > > revised datastore concepts.  And datastores, as you say, are
more
> > > > important - revising the XML encoding rules is cosmetic, not
needed
> > > > technically and, as I said, only make sense when the NETMOD WG
has
> > done
> > > > its bit; and the revised charter being discussed on the NETMOD
list
> > > > makes no mention of this work.
> > > >
> > > > So scrap NETCONF XML encoding rules.
> > > >
> > > > Tom Petch
> > >
> > >
> > > Hi Tom,
> > >
> > > Such changes fall under the "maintaining" clauses in the NETMOD
> > charter:
> > >
> > >   a) Maintaining the data modeling language YANG.  This effort
entails
> > >      periodically updating the specification to address new
> > requirements
> > >      as they arise.
> > >
> > >   d) Maintaining encodings for YANG modeled data.  This effort
entails
> > >      updating encodings already defined by the NETMOD working
group
> > >      (XML and JSON) to accommodate changes to the YANG
specification,
> > >      and defining new encodings that are needed, and yet do not
fall
> > >      under the charter of any other active IETF working group.
> >
> > Kent
> >
> > I was going to be sarcastic but resisted the temptation:-)
> >
> > I am unable to reconcile those paragraphs with
> >
> > 'NETCONF XML Encoding Rules from RFC 7950 will
> > be moved to RFC6241bis.'
> >
> > To me, they are on different planets; one puts XML encoding rules in
the
> > NETCONF WG and the NETCONF RFC, the other places them in the NETMOD
WG
> > and the NETMOD RFC.
> >
>
> YANG today defines the language plus its data encoding rules into XML
> plus NETCONF protocol details that NETCONF did not define (and the
> reason is simply that YANG was done after NETCONF and nothing else).
>
> I think the goal is to move the NETCONF protocol details that NETCONF
> did not define to the NETCONF specification. Some may want to factor
> out the XML encoding out of the YANG specification as well, similar to
> how we have JSON as a separate document. On the hand hand this makes
> sense, on the other hand it makes it a bit more difficult to write
> examples down in the YANG specification (since the examples then
> depend on another external specification - or one would have to create
> yet another ad-hoc notation (YAAN).
>
> Back to your question, it seems obvious to me that YANG and the XML
> encoding rules naturally belong to NETMOD, the 'NETCONF protocol
> details that NETCONF did not define' naturally belong to NETCONF.

Makes sense.

I am reminded that in the latter days of 6020bis the point was made that
the terminology therein was inconsistent, sometimes NETCONF XML and
sometimes XML, an inconsistency which has been carried across to
RFC7950.

Really, the use of XML has nothing to do with NETCONF and I am not sure
that it is even an encoding, more a translation from DDL to GML, which
could be used by any transport.

So the word NETCONF should be expunged from RFC7950 and where it conveys
meaning, and I am suggesting that it often does not, then that part
should become part of a NETCONF I-D.  If I understand Juergen aright,
then this covers the NETCONF protocol details, such as

5.6.4.  Announcing Conformance Information in NETCONF

7.5.8.  NETCONF <edit-config> Operations

8.3.  NETCONF Constraint Enforcement Model

15.  NETCONF Error Responses for YANG-Related Errors

but not

urn ....netconf

which 7950bis would still need.

I would like 7950bis to still cover the create/delete/update issues,
that is I am assuming that the structures defined by 7950bis would still
be accessed by a protocol with those capabilities, just that it may not
be NETCONF, but I see that as more debatable although given such as
'ordered-by-user' I think it hard to eliminate that discussion entirely

This is not what I had in mind when this thread started.

Tom Petch

>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>