Re: [netmod] draft netmod charter update proposal

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

The NETCONF list has also been discussing a charter update, as some of
you will know, and part of that consists of taking into a NETCONF I-D
parts of RFC7950.

I see a joint agreement as to just which bits of RFC7950 will be elided
as the starting point for this (followed by a revision of RFC7950).

I am reminded that in the latter days of 6020bis the point was made that
the terminology therein was inconsistent, sometimes using NETCONF XML
and sometimes XML (an inconsistency which has been carried across to
RFC7950).  I see the references to NETCONF XML as something of an
oxymoron, a bit like saying 'HTTP jpeg' or 'railroad cow'; they are
different beasts.  So I would
/NETCONF XML/XML/ * *

Having done that, I think that the XML should stay in 7950bis; it is
like having a worked example (which is how many people learn
languages:-) and would be clearer to those steeped in XML than the YANG
is.  Also, removing it generates problems for NETCONF, that the NETCONF
I-D would then have to include XML, YANG, some explanation thereof,
references therefrom and so on.  The clean boundary is to keep the XML
in 7950bis and have a NETCONF I-D just describe how that XML is then
wrapped up in a transporting protocol, ditto for any other protocol
although were it not to use XML, then it would also have to define the
use of whatever it is using..

The sections such as

5.6.4.  Announcing Conformance Information in NETCONF

7.5.8.  NETCONF <edit-config> Operations

go but I think that 7950bis still needs to talk about
conceptual operations, such as create/delete/update/; else how can you
discuss ordered-by user?  YANG is not a DDL that describes a static,
unchanging set of data but rather one that expects data to be updated so
such
operations are a part of the language.

Likewise on errors, that 7950bis should still talk about the errors in
generic terms, a consequence of talking about operations, but should
leave the encoding to a transporting protocol.

Section 8 is an interesting one.  YANG defines itself as a language for
defining RPC so something needs to be said about RPC but will operations
always be performed by RPC?  Well, not necessarily!

7950bis would still need
urn ...netconf
.
Tom Petch

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
To: "Ladislav Lhotka" <[e-mail]>; "t.petch" <[e-mail]>
Cc: "Jürgen Schönwälder" <[e-mail]>; "NetMod
WG Chairs" <[e-mail]>; <[e-mail]>
Sent: Wednesday, March 01, 2017 4:56 PM
Subject: Re: [netmod] draft netmod charter update proposal


> Hi Lada,
>
> I understand your intention here, but I'm inclined to agree with
others
> that it's better to stick with the term we're using in the documents.
> I'm open to the idea of changing the term used in our RFCs, and I
believe
> that such a change would likely have to begin with the YANG spec, from
> which it could flow into other drafts.  With this in mind, I've added
an
> item to the yang-next tracker:
>
>   https://github.com/netmod-wg/yang-next/issues/17
>
> and I plan to revert this change in the charter text.
>
> Thanks,
> Kent
>
>
>