Re: [Netconf] Draft Charter Proposal for NETCONF WG

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

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
Sent: Tuesday, February 28, 2017 8:51 PM

> >> Even updating 7950 I would expect to be resisted given how long it
took
> >> to appear but for me, it is the only logical first step and not
that
> >> difficult one, just tedious to proof-read.
> >
> > I agree.
> >
>
> As a NETMOD co-chair, I plan to start a preliminary 7950bis discussion
in Chicago.  The scope of such an effort would be the key topic, but
hopefully factoring out all the NETCONF and XML specific parts would be
near the top of the list.  I know some think that we should not waste
resources on housekeeping, but I believe that periodic cleanups are
necessary to keep things running smoothly...
>
> Of course, the XML-specific parts factored out of RFC7950 would go
into another NETMOD WG draft (mirroring RFC 7951) and the NETMOD WG
could ensure to run both the 7950bis and draft-ietf-netmod-yang-xml
drafts at the same time (for as clean a cutover as possible).  However,
it would be up to the NETCONF WG to pick-up the NETCONF-specific parts
factored out of RFC7950, and it would be up to the NETCONF WG to decide
to do this work now, or wait to do it in parallel with the NETMOD WG
(whenever that might be), or wait until after 7950bis comes out.
>
> While it seems like the NETCONF WG could kick-off this activity now if
it wanted to, said activity is nowhere near as important as updating
NETCONF WG maintained documents to support the solution defined in the
revised-datastores draft (namely RFCs 6241, 7895, 8040).  Without said
update, there would be no way for clients to access ephemeral
configuration (i2rs requirement) or operational state (open config
requirement).  So, this is clearly a higher priority, though it seems
that the two could be done at the same time, as is captured by work item
#7 in Mehmet's charter proposal.
>
> So, my opinion is that Mehmet's proposal is nearly spot-on with its
work item #7.  Yes, it’s a "monster", but it must be done ASAP or else
we fail to deliver the datastore solution in a timely manner.  The only
thing I hesitate on is that I don't think the WG has enough information
to decide if it's better to work on new standalone drafts or -bis of
existing drafts (this addresses Andy's point).  To the extent the
charter describes changes being made to specific documents, it may be
better to remove this part from the charter until more information is
known.
>
> PS: the next update to the revised datastores draft will contain an
Appendix section for each RFC believed to be impacted, in both the
NETMOD and NETCONF WGs, along with a proposal for how that RFC might be
changed or updated.  The revised datastore authors plan to request a
NETCONF WG presentation timeslot to go over the impact to NETCONF WG
drafts, with the intent of asking the WG how to proceed (e.g.,
standalone NETCONF WG drafts or -bis on existing drafts).  So, we'll be
having this discussion then, can the charter wait that long?
>


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

> Kent
>