Re: [Netconf] Draft Charter Proposal for NETCONF WG

["Mehmet Ersue" <[e-mail]>]

Hi Sue,

 

providing add-ons which don’t require republishing of RESTCONF-8040 would be indeed important.

 

I don’t mind if add-ons to RESTCONF specific to I2RS are done in I2RS.

However forcing serious reviews early and publishing them in NETCONF would be my preference. 

In any case we need I2RS people working on it.

 

BR,

Mehmet

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Tuesday, March 7, 2017 5:27 PM
To: 'Andy Bierman' <[e-mail]>
Cc: 'Mehmet Ersue' <[e-mail]>; 'Juergen Schoenwaelder' <[e-mail]>; 't.petch' <[e-mail]>; 'Netconf' <[e-mail]>
Subject: RE: [Netconf] Draft Charter Proposal for NETCONF WG

 

Andy: 

 

Thank you for the clarification.  Since this is an Add-on and not focused on the base specification, where should the Add-on specification be worked on?  I2RS WG with final cross-review in NETCONF?   It seems that NETCONF has lots of other work on the list.  

 

Sue 

 

From: Andy Bierman [mailto:[e-mail]] 
Sent: Tuesday, March 7, 2017 11:25 AM
To: Susan Hares
Cc: Mehmet Ersue; Juergen Schoenwaelder; t.petch; Netconf
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

 

 

 

On Tue, Mar 7, 2017 at 7:01 AM, Susan Hares <[e-mail] <mailto:[e-mail]> > wrote:

Mehmet:

These are clarifying question - not requests.

Do the items #6 and #7 on the charter include revising the NETCONF and
RESTCONF to serve as a control plane protocol that interacts with the I2RS
control plane data store supporting the ephemeral datastore?   If so, based
on the WGs comments it seems key players (Andy Bierman for RESTCONF and a
group of players for NETCONF) do not want this work to be done in the
NETCONF WG.   Do I understand the sense of the mail list?

 

My position is that I2RS features can be done in its own RFC without

republishing the RESTCONF RFC.  Since this functionality is

optional-to-implement, a new protocol version is not required.

 

 

 

Sue Hares

 

Andy

 


-----Original Message-----
From: Netconf [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of Mehmet Ersue
Sent: Friday, March 3, 2017 9:34 AM
To: 'Juergen Schoenwaelder'; 't.petch'
Cc: 'Netconf'
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

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

Basically it is our aim to make the YANG language specification generally
applicable to all protocols and to put protocol-specific details into the
protocol specifications.

Mehmet

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- <mailto:j.schoenwaelder@jacobs-> 
> university.de <http://university.de> ]
> Sent: Friday, March 3, 2017 2:35 PM
> To: t.petch <[e-mail] <mailto:[e-mail]> >
> Cc: Kent Watsen <[e-mail] <mailto:[e-mail]> >; Mehmet Ersue
> <[e-mail] <mailto:[e-mail]> >; 'Netconf' <[e-mail] <mailto:[e-mail]> >; 'Benoit Claise'
> <[e-mail] <mailto:[e-mail]> >
> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
>
> On Fri, Mar 03, 2017 at 12:24:34PM +0000, t.petch wrote:
> > ----- Original Message -----
> > From: "Kent Watsen" <[e-mail] <mailto:[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.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
Netconf mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netconf