Re: [netmod] Opsdir last call review of draft-ietf-netmod-schema-mount-10

[Mehmet Ersue]

Thanks. See below.

Cheers,
Mehmet

> -Original Message-
> From: Martin Bjorklund 
> Sent: Friday, June 29, 2018 8:40 PM

> > - In 2.1.  Glossary of New Terms
> > As there are indeed terms which are not new I would suggest to change
> > the section title to: "Glossary of Used Terms". One can even merge
> > section 2 and section 2.1.
> 
> Ok.  I suggest we remove 2.1 and instead add:
> 
>The following additional terms are used within this document:
Sounds good.
 
> 
> > - As one of the commenters indicated, the words "schema mount" are
> > often used casually and without an article. Though what the author
> > means is "the schema mount mechanism" which is specifically defined in
> this document.
> 
> In the Introduction, the document says:
> 
>   This document introduces a new mechanism, denoted as schema
>   mount, that allows for mounting one data model [...]
> 
> so I wonder if the solution to both these problem is to define "schema
> mount" as a term in 2.1, instead of replacing "schema mount" with "the
> schema mount mechanism" in the whole document?
This is fine. To qualify the specific new term I would like to suggest to
use an article in appropriate cases.

> 
> /martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Opsdir last call review of draft-ietf-netmod-schema-mount-10

[Mehmet Ersue]

Reviewer: Mehmet Ersue
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Intended status: Standards Track
Current IESG state: Waiting for Writeup
IANA review state: Not OK / Expert review needed (see
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/history/)

Summary:
The document defines a mechanism to add the schema trees defined by a set of
YANG modules onto a mount point defined in the schema tree in some YANG modules.

I think the document is well-written and can be published after addressing last
issues indicated by different reviews.

A few nits below:

- In 2.  Terminology and Notation
for both "system-controlled interface" and "YANG library checksum":
s/are not/is not/

- In 2.1.  Glossary of New Terms
As there are indeed terms which are not new I would suggest to change the
section title to: "Glossary of Used Terms". One can even merge section 2 and
section 2.1.

- As one of the commenters indicated, the words "schema mount" are often used
casually and without an article. Though what the author means is "the schema
mount mechanism" which is specifically defined in this document.

Regards,
Mehmet

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] RFC 8340 to 8346 published

[Mehmet Ersue]

A big +1.

 

Mehmet

 

From: Netconf  On Behalf Of Benoit Claise
Sent: Saturday, March 17, 2018 11:36 PM
To: NETMOD Working Group ; NETCONF ; 
i...@ietf.org
Subject: [Netconf] RFC 8340 to 8346 published

 

Dear all,

RFC8340  | 
draft-ietf-netmod-yang-tree-diagrams-06.txt

RFC8341  | 
draft-ietf-netconf-rfc6536bis-09.txt
RFC8342  | 
draft-ietf-netmod-revised-datastores-10.txt
RFC8343  | 
draft-ietf-netmod-rfc7223bis-03.txt
RFC8344  | 
draft-ietf-netmod-rfc7277bis-03.txt
RFC8345  | 
draft-ietf-i2rs-yang-network-topo-20.txt
RFC8346  | 
draft-ietf-i2rs-yang-l3-topology-16.txt

Congratulations to all persons involved.

Regards, Benoit

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joel Jaeggli as a third NETMOD co-chair

[Mehmet Ersue]

+1

Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh
> Jethanandani
> Sent: Saturday, December 16, 2017 6:49 AM
> To: Joel jaeggli 
> Cc: NETMOD Working Group 
> Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair
> 
> Joel,
> 
> Welcome. Look forward to the interaction with NETCONF.
> 
> Cheers.
> 
> > On Dec 15, 2017, at 9:21 AM, Benoit Claise  wrote:
> >
> > Dear all,
> >
> > A lot is happening these days in the world of data modeling-driven
> management at the IETF:
> > NMDA architecture, NETCONF, RESTCONF
> > NMDA-compliant YANG modules: some RFC bis modules but also new
> ones
> > Guidelines: RFC6087bis and the tree diagram
> > The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY,
> telemetry
> > The interaction with routing, where many YANG modules come from.
> > etc.
> > There are a lot of dependencies between all these tasks, which must take
> place in parallel, and, obviously, be completed ASAP.
> >
> > Kent and Lou have a lot on their shoulders these days.
> > To help with the situation and proactively progress documents, I'm happy
> to announce that Joel Jaeggli accepted to serve as a third NETMOD
co-chair.
> Thank you Joel.
> >
> > Please welcome Joel.
> >
> > Regards, Benoit
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] intended status of the tree diagram document

[Mehmet Ersue]

I think the rules and recommendations in this document should be used, once
agreed and published, by all YANG module drafts within and outside of IETF.
As such its content is BCP.
IETF consensus will be achieved during IETF LC.

Cheers,
Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Susan Hares
> Sent: Friday, December 8, 2017 2:07 AM
> To: 'Kent Watsen' ; 'Lou Berger' ;
> netmod@ietf.org; 'Benoit Claise' ; 'Juergen
> Schoenwaelder' 
> Subject: Re: [netmod] intended status of the tree diagram document
> 
> Kent:
> 
> A common way to express tree-diagrams in Yang documents provides a
> common and clear to describe the models.  This would be really helpful to
> those using these yang models.  Seems like a standard or a BCP to me.
> 
> Sue Hares
> 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Thursday, December 7, 2017 7:06 PM
> To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder
> Subject: Re: [netmod] intended status of the tree diagram document
> 
> 
> BCP for tree-diagrams?   This doesn't seem like an appropriate application
> of that designation.  I don't view the format for tree diagrams to be a
> "practice", whereas it definitely seems "informational".
> 
> Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does
not
> represent an Internet community consensus or recommendation" could be
> cause for objection, since this draft is obviously going through a WG
> (NETMOD) and therefore does, in fact, represent some form of consensus,
> but I'm willing to gloss over that line as, clearly, many Informational
RFCs are
> published by WGs, which wouldn't be possible if that line were taken
literally.
> Perhaps we should file Errata against it?
> 
> Kent // co-chair
> 
> 
> = original message =
> 
> Hi Juergen,
> 
> Sorry for the slow response, I missed this message.
> 
> Circling back to this discussion made me go revisit RFC2026.  Based on all
the
> factors/discussions I agree  that standards track isn't quite right for
this
> document, but I also think informational isn't quite right either.  I do
think
> BCP would as described in RFC2026 fits.  This said, I think it would be
good to
> hear from at least Kent (as Chair) and Benoit (as AD) if they
agree/disagree
> with publishing as a BCP.
> 
> Kent, Benoit?
> 
> Thanks,
> 
> Lou
> 
> On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:
> > Lou,
> >
> > right now, the document says standards track, Martin's proposal was to
> > move to informational. So how do I parse "I think you are correct.  We
> > should leave as is."?
> >
> > /js
> >
> > On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:
> >> Martin,
> >>I think you are correct.  We should leave as is.
> >>
> >> I'm sure Kent/the document Shepherd makes sure whatever we do is
> >> right before publication in any case.
> >>
> >> Lou (as contributor)
> >>
> >> On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
> >>> Hi,
> >>>
> >>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> >>> Standards Track.  I think I heard during the meeting today that it
> >>> ought to be Informational.  I think this makes sense.  It would then
> >>> imply that other standards track documents will have the tree
> >>> diagram document as an informative reference.
> >>>
> >>> Should we make this change?
> >>>
> >>>
> >>> /martin
> >>>
> >>> ___
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_ma
> >>>
> ilman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> >>>
> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpv
> oumTA
> >>> -
> 4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byE
> sko
> >>> noVDeyYcQE&e=
> >>>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> >> lman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTX
> >>
> cWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpvou
> mTA-4y
> >>
> jD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsk
> onoVD
> >> eyYcQE&e=
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tree diagram guidelines

[Mehmet Ersue]

Sounds perfect to me.

Mehmet

> -Original Message-
> From: Lou Berger [mailto:lber...@labn.net]
> Sent: Friday, November 17, 2017 7:43 AM
> To: Mehmet Ersue ; 'Mahesh Jethanandani'
> ; 'Robert Wilton' 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] tree diagram guidelines
> 
> To circle back to this.  My sense of this discussion (as contributor) is
> (a) the tree diagrams draft should be updated to point to a "guidelines"
> wiki page for "the most current guidelines"
> (b) the tree diagrams draft should be updated to include a full set of the
> current tree related guidelines
> (c) 6087bis should be updated to point to a "guidelines" wiki page for "the
> most current guidelines"
> (d) 6087bis should have it's tree guidelines point to the tree diagrams
> document -- in addition to pointing to the wiki
> 
> Does this sound right?
> 
> Lou
> (as tree co-author)
> 
> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
> > The Wiki is useful as a starting point providing a collection of pointers to
> guideline RFCs and the bis-revisions in development.
> >
> > Cheers,
> > Mehmet
> >
> >> -Original Message-
> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh
> >> Jethanandani
> >> Sent: Thursday, November 16, 2017 7:39 AM
> >> To: Robert Wilton 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] tree diagram guidelines
> >>
> >> Other SDOs can and follow the work in IETF through the RFCs we publish.
> >> They do not follow wiki’s, unless the document itself says, “here are
> >> the guidelines, but if you are looking for the latest, go to this
> >> wiki”. I therefore would support the proposal outlined below. It
> >> gives the SDO a stable point of reference with a document, which gets
> >> updated occasionally, but also allows them to peak at what is coming
> down the pipeline.
> >>
> >> Thanks.
> >>
> >>> On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:
> >>>
> >>> I liked the suggestion from Chris Hopps:
> >>>
> >>> I think that it was along the lines of ...
> >>>
> >>> The RFC contains a reference at the top that states that updates to
> >>> the
> >> guidelines is available on a wiki at 
> >>>
> >>> Every few years the guidelines on the wiki can be folded into a
> >>> latest
> >> version of the guidelines draft.
> >>>
> >>> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,,
> >>> IEEE, or MEF be
> >> using the latest draft guidelines, or should then use the published
> >> RFC until 6087bis is actually republshed?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> On 15/11/2017 10:14, Martin Bjorklund wrote:
> >>>> Hi,
> >>>>
> >>>> There was a proposal in the meeting today to have the guidelines
> >>>> for tree diagrams in a wiki, instead of having them in 6087bis or
> >>>> in the tree diagram document.
> >>>>
> >>>> Was the proposal really to have a wiki for just the tree
> >>>> guidelines, or was the proposal to withdraw 6087bis from the
> >>>> process and instead publish all guidelines as a wiki?
> >>>>
> >>>> If it is the former, is it really worth it?
> >>>>
> >>>> Advantages with a wiki:
> >>>>
> >>>>+  It can be updated more easily
> >>>>
> >>>> Some drawbacks:
> >>>>
> >>>>-  It can be updated more easily
> >>>>   (meaning they are less stable)
> >>>>
> >>>>-  Wikis tend to not be alive after some time, and are not that
> >>>>   easy to find.  Just try to find the various YANG-related wikis
> >>>>   we've tried to maintain over the years.
> >>>>
> >>>>-  Links in RFCs also have problems.  Sites are re-orginized etc.
> >>>>   As an example, the link to the security guidelines template in
> >>>>   RFC 6087 doesn't work anymore.
> >>>>
> >>>>-  People that are looking for a stable reference will have problems
> >>>>   (I think Rob mentioned that IEEE still refer to RFC 6087 (which
> >>>>   is understandable; that's the published vers

Re: [netmod] tree diagram guidelines

[Mehmet Ersue]

The Wiki is useful as a starting point providing a collection of pointers to 
guideline RFCs and the bis-revisions in development.

Cheers,
Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh
> Jethanandani
> Sent: Thursday, November 16, 2017 7:39 AM
> To: Robert Wilton 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] tree diagram guidelines
> 
> Other SDOs can and follow the work in IETF through the RFCs we publish.
> They do not follow wiki’s, unless the document itself says, “here are the
> guidelines, but if you are looking for the latest, go to this wiki”. I 
> therefore
> would support the proposal outlined below. It gives the SDO a stable point of
> reference with a document, which gets updated occasionally, but also allows
> them to peak at what is coming down the pipeline.
> 
> Thanks.
> 
> > On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:
> >
> > I liked the suggestion from Chris Hopps:
> >
> > I think that it was along the lines of ...
> >
> > The RFC contains a reference at the top that states that updates to the
> guidelines is available on a wiki at 
> >
> > Every few years the guidelines on the wiki can be folded into a latest
> version of the guidelines draft.
> >
> > 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or 
> > MEF be
> using the latest draft guidelines, or should then use the published RFC until
> 6087bis is actually republshed?
> >
> > Thanks,
> > Rob
> >
> >
> > On 15/11/2017 10:14, Martin Bjorklund wrote:
> >> Hi,
> >>
> >> There was a proposal in the meeting today to have the guidelines for
> >> tree diagrams in a wiki, instead of having them in 6087bis or in the
> >> tree diagram document.
> >>
> >> Was the proposal really to have a wiki for just the tree guidelines,
> >> or was the proposal to withdraw 6087bis from the process and instead
> >> publish all guidelines as a wiki?
> >>
> >> If it is the former, is it really worth it?
> >>
> >> Advantages with a wiki:
> >>
> >>   +  It can be updated more easily
> >>
> >> Some drawbacks:
> >>
> >>   -  It can be updated more easily
> >>  (meaning they are less stable)
> >>
> >>   -  Wikis tend to not be alive after some time, and are not that
> >>  easy to find.  Just try to find the various YANG-related wikis
> >>  we've tried to maintain over the years.
> >>
> >>   -  Links in RFCs also have problems.  Sites are re-orginized etc.
> >>  As an example, the link to the security guidelines template in
> >>  RFC 6087 doesn't work anymore.
> >>
> >>   -  People that are looking for a stable reference will have problems
> >>  (I think Rob mentioned that IEEE still refer to RFC 6087 (which
> >>  is understandable; that's the published version).
> >>
> >>   -  Who maintains the Wiki, and what are the rules for updating it?
> >>
> >>
> >> I suggest we have the tree-related guidelines (actually just a few
> >> sentences) in the tree draft, and since 6087bis already refers to
> >> this document it is not a big problem that guidelines are spread out
> >> over several documents that are difficult to find.
> >>
> >>
> >>
> >> /martin
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> .
> >>
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] tree diagram guidelines

[Mehmet Ersue]

Hi All,

I think having the tree-related guidelines in the tree draft and finalizing 
6087bis as planned is useful.
That said a NETMOD wiki explaining the available guidelines with pointers can 
be used as a starting point and would be additionally helpful.

Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert
> Wilton
> Sent: Wednesday, November 15, 2017 6:53 PM
> To: Martin Bjorklund ; netmod@ietf.org
> Subject: Re: [netmod] tree diagram guidelines
> 
> I liked the suggestion from Chris Hopps:
> 
> I think that it was along the lines of ...
> 
> The RFC contains a reference at the top that states that updates to the
> guidelines is available on a wiki at 
> 
> Every few years the guidelines on the wiki can be folded into a latest version
> of the guidelines draft.
> 
> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or MEF 
> be
> using the latest draft guidelines, or should then use the published RFC until
> 6087bis is actually republshed?
> 
> Thanks,
> Rob
> 
> 
> On 15/11/2017 10:14, Martin Bjorklund wrote:
> > Hi,
> >
> > There was a proposal in the meeting today to have the guidelines for
> > tree diagrams in a wiki, instead of having them in 6087bis or in the
> > tree diagram document.
> >
> > Was the proposal really to have a wiki for just the tree guidelines,
> > or was the proposal to withdraw 6087bis from the process and instead
> > publish all guidelines as a wiki?
> >
> > If it is the former, is it really worth it?
> >
> > Advantages with a wiki:
> >
> >+  It can be updated more easily
> >
> > Some drawbacks:
> >
> >-  It can be updated more easily
> >   (meaning they are less stable)
> >
> >-  Wikis tend to not be alive after some time, and are not that
> >   easy to find.  Just try to find the various YANG-related wikis
> >   we've tried to maintain over the years.
> >
> >-  Links in RFCs also have problems.  Sites are re-orginized etc.
> >   As an example, the link to the security guidelines template in
> >   RFC 6087 doesn't work anymore.
> >
> >-  People that are looking for a stable reference will have problems
> >   (I think Rob mentioned that IEEE still refer to RFC 6087 (which
> >   is understandable; that's the published version).
> >
> >-  Who maintains the Wiki, and what are the rules for updating it?
> >
> >
> > I suggest we have the tree-related guidelines (actually just a few
> > sentences) in the tree draft, and since 6087bis already refers to this
> > document it is not a big problem that guidelines are spread out over
> > several documents that are difficult to find.
> >
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Mehmet Ersue]

> Having ' This data is modeled in YANG using "config true" nodes ' sort of
> suggests that the original definition holds sway and so contradicts the
> previous sentence.  And for this sentence to make sense, a reader would
> really have to understand the debates over configuration, state and how to
> model them that have been going on for so long which means that regardless
> of how true it is, it does not really belong in a definition.
> 
> There is no reference back to the previous definition, as to whether or
not
> the latest definition is meant to be the same or not.  I find this
confusing.
> 
> I think that the previous definition has to appear in this I-D, since it
has
> influenced so much work, and this I-D then needs to go on to say

It is indeed confusing to the reader if a document referring to a standard
track RFC defines and uses a term differently.
I agree that revising a term might become necessary though the revision
should be introduced properly.

> 
> 'We are revising it ..
> or
> 'We are not revising it ...
> 
> I have read the later posts but this one seemed to catch the crux of my
> discontent.
> 
> Tom Petch
> 
> > > Even worse, configuring protocol learned values is liable to break
> > > things.  To use one example, many
> protocols
> > > negotiate timers.  The value that a given systems starts with is the
> > > configured value.  The value that it learns from the protocol
> exchange is
> > > the operational value.  In fact, you better not try to configure
> that value
> > > or you are liable to break the protocol.
> >
> > Nobody proposed this, please take a look at the figure in the document
> > to understand the information flow and where the distinction is made.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Kent,

> We do, however, have a "YANG Next" discussion on the agenda, which may or may 
> not lead to the creation of a milestone for it.
It would be good to extend the charter proposal after this discussion with 
agreed goals for 7950bis.
We also need to know what exactly is going to be separated from 7950. E.g. one 
of the topics we discussed on the maillist was guidance on using YANG with 
specific protocols. This can be done in the protocol document.

> > > > >>>>>>>Oct 2017 - Submit draft-ietf-netmod-revised-datastores
> > > > >>>>>>> to IESG
Another question is whether this should be earlier, e.g. August.
As it is a high-priority topic needed at least by 2 WGs, we were saying that 
revised-datastores should be finalized within 4 months and NC/RC-bis will take 
another 4-5 months.

Thanks,
Mehmet

> -Original Message-
> From: Kent Watsen [mailto:kwat...@juniper.net]
> Sent: Wednesday, March 22, 2017 9:48 PM
> To: Mehmet Ersue ; 'Lou Berger' ;
> netmod@ietf.org
> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> 
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Mehmet,
> 
> From a charter perspective, we have:
> 
>  a) Maintaining the data modeling language YANG.  This effort
> entails periodically updating the specification to address
> new requirements as they arise.
> 
> From a milestone perspective, you are correct that we don't have a
> milestone for 7950bis as of yet.  We do, however, have a "YANG Next"
> discussion on the agenda, which may or may not lead to the creation of a
> milestone for it.
> 
> As for NETCONF/RESTCONF revisions depending on a 7950bis, if that is true,
> then it will likely force us to create the milestone in the near-term for it. 
>  That
> withstanding, I think that NETCONF WG could take the lead by
> moving/copying the NETCONF-specific parts from RFC7950 into an rfc6241bis.
> It would be nice if we could decouple the refactoring of these documents
> across our WGs.
> 
> Kent // co-chair hat
> 
> 
> 
> -ORIGINAL MESSAGE-
> Hi Kent, Lou,
> 
> as I see 7950bis has not been mentioned in the charter text and the
> milestones.
> As you know NETCONF and RESTCONF revisions are dependent on the timing
> of 7950bis.
> How is this essential deliverable and its timing going to be addressed in the
> charter?
> 
> Mehmet
> 
> > -Original Message-
> > From: Mehmet Ersue
> > Sent: Friday, March 17, 2017 11:51 PM
> > To: Lou Berger ; 'Kent Watsen'
> > ; netmod@ietf.org
> > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> > 
> > Subject: RE: [netmod] draft netmod charter update proposal
> >
> > Hi Lou, Kent,
> >
> > I promised to provide some minimal text which can be used as WG item
> > description.
> > I'm fine with any fine tuning.
> >
> > See below:
> >
> >a) Maintaining the data modeling language YANG.  This effort entails
> >   periodically updating the specification to address new requirements
> >   as they arise. ADD > revision
> of RFC
> > 7950./>
> >
> >b) Maintaining the guidelines for developing YANG models.  This effort
> >   is primarily driven by updates made to the YANG specification.
> ADD > continuous effort has been recently addressed with a revision of RFC
> 6087./>
> >
> >c) Maintaining a conceptual framework in which YANG models are used.
> >   This effort entails describing the generic context that in YANG
> >   exists and how certain YANG statements interact in that context.
> >   An example of this is YANG's relationship with datastores.
> > ADD > for the
> handling
> > of datastores, which can be adopted by other WGs for their usage
> > scenario./>
> >
> > . . .
> >
> >e) Maintaining YANG models used as basic YANG building blocks.  This
> >   effort entails updating existing YANG models (ietf-yang-types and
> >   ietf-inet-types) as needed, as well as defining additional core YANG
> >   data models when necessary. ADD > work on the models for Syslog, ACL and Common Interface Extensions as
> > well as the model for hardware management. The Schema mount draft will
> > provide a mechanism to combine YANG modules into the schema defined
> in
> > other YANG modules./>
> >
> > BTW: There is no topic description (in a)-f) covering YANG module
> > classification.
> > I assume it can be added with a sentence to a) or b).
> >
> > Thanks,

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Kent, Lou,

as I see 7950bis has not been mentioned in the charter text and the
milestones.
As you know NETCONF and RESTCONF revisions are dependent on the timing of
7950bis.
How is this essential deliverable and its timing going to be addressed in
the charter?

Mehmet

> -Original Message-
> From: Mehmet Ersue
> Sent: Friday, March 17, 2017 11:51 PM
> To: Lou Berger ; 'Kent Watsen' ;
> netmod@ietf.org
> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> 
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> Hi Lou, Kent,
> 
> I promised to provide some minimal text which can be used as WG item
> description.
> I'm fine with any fine tuning.
> 
> See below:
> 
>a) Maintaining the data modeling language YANG.  This effort entails
>   periodically updating the specification to address new requirements
>   as they arise. ADD 7950./>
> 
>b) Maintaining the guidelines for developing YANG models.  This effort
>   is primarily driven by updates made to the YANG specification.
ADD continuous effort has been recently addressed with a revision of RFC
6087./>
> 
>c) Maintaining a conceptual framework in which YANG models are used.
>   This effort entails describing the generic context that in YANG
>   exists and how certain YANG statements interact in that context.
>   An example of this is YANG's relationship with datastores. ADD revised datastore draft will provide a conceptual framework for the
handling
> of datastores, which can be adopted by other WGs for their usage
> scenario./>
> 
> . . .
> 
>e) Maintaining YANG models used as basic YANG building blocks.  This
>   effort entails updating existing YANG models (ietf-yang-types and
>   ietf-inet-types) as needed, as well as defining additional core YANG
>   data models when necessary. ADD the models for Syslog, ACL and Common Interface Extensions as well as the
> model for hardware management. The Schema mount draft will provide a
> mechanism to combine YANG modules into the schema defined in other
> YANG modules./>
> 
> BTW: There is no topic description (in a)-f) covering YANG module
> classification.
> I assume it can be added with a sentence to a) or b).
> 
> Thanks,
> Mehmet
> 
> > -Original Message-
> > From: Mehmet Ersue
> > Sent: Thursday, March 16, 2017 11:59 PM
> > To: Lou Berger ; 'Kent Watsen'
> > ; netmod@ietf.org
> > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> > 
> > Subject: RE: [netmod] draft netmod charter update proposal
> >
> > > From: Lou Berger [mailto:lber...@labn.net] Mehmet,
> > >see below.
> > > On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
> > > > Lou,
> > . . .
> > > > I actually provided a very simple proposal. You guys can fill the
> > > > idea with minimal text better than me. I'm fine whatever the text
is.
> > > > If you think the high-level topic description a)-f) does already
> > > > define the WG item clearly you can simply say "this is achieved
> > > > with WG
> > > item XY".
> > > > If not, you can keep the high-level focus text but set
> > > > additionally the borders of the WG item with a few concrete words.
> > >
> > > I really can't tell for sure, but it feels to me that this comment
> > > boils down to a style comment and you have a preference for
> > > different contents in the charter.  I'd like to be sensitive to
> > > this.  As our style differs, having a concrete proposal on specific
> > > text changes would be really helpful in us (and the WG) evaluating
> > > the changes you'd like to see.  Without such specific examples and
> > > think we're left with the charter as currently proposed.  Perhaps
> > > someone else who
> > has similar feelings can chime in and provide proposed text.
> > >
> > > Anyone else have any comments or proposed changes?
> > I think the wording depends on the time period is for which the
> > charter is prepared.
> > I can try some text once I have time tomorrow.
> >
> > . . .
> > > > I think the DS draft provides a conceptual framework for diverse
> > > > DS usage scenarios to be used by many protocols, where IETF WGs
> > > > may actually decide using a subset of the DS framework for their
> > > > purpose and for their protocol standardization.
> > > > Based on this the conceptual framework cannot be standardized as
> > > > it is but the protocols using a consis

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Lou, Kent,

I promised to provide some minimal text which can be used as WG item
description.
I'm fine with any fine tuning. 

See below:

   a) Maintaining the data modeling language YANG.  This effort entails
  periodically updating the specification to address new requirements
  as they arise. ADD

   b) Maintaining the guidelines for developing YANG models.  This effort
  is primarily driven by updates made to the YANG specification.
ADD 

   c) Maintaining a conceptual framework in which YANG models are used.
  This effort entails describing the generic context that in YANG
  exists and how certain YANG statements interact in that context.
  An example of this is YANG's relationship with datastores. ADD

. . . 

   e) Maintaining YANG models used as basic YANG building blocks.  This
  effort entails updating existing YANG models (ietf-yang-types and
  ietf-inet-types) as needed, as well as defining additional core YANG
  data models when necessary. ADD

BTW: There is no topic description (in a)-f) covering YANG module
classification.
I assume it can be added with a sentence to a) or b).

Thanks,
Mehmet

> -Original Message-
> From: Mehmet Ersue
> Sent: Thursday, March 16, 2017 11:59 PM
> To: Lou Berger ; 'Kent Watsen' ;
> netmod@ietf.org
> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> 
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> > From: Lou Berger [mailto:lber...@labn.net] Mehmet,
> >see below.
> > On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
> > > Lou,
> . . .
> > > I actually provided a very simple proposal. You guys can fill the
> > > idea with minimal text better than me. I'm fine whatever the text is.
> > > If you think the high-level topic description a)-f) does already
> > > define the WG item clearly you can simply say "this is achieved with
> > > WG
> > item XY".
> > > If not, you can keep the high-level focus text but set additionally
> > > the borders of the WG item with a few concrete words.
> >
> > I really can't tell for sure, but it feels to me that this comment
> > boils down to a style comment and you have a preference for different
> > contents in the charter.  I'd like to be sensitive to this.  As our
> > style differs, having a concrete proposal on specific text changes
> > would be really helpful in us (and the WG) evaluating the changes
> > you'd like to see.  Without such specific examples and think we're
> > left with the charter as currently proposed.  Perhaps someone else who
> has similar feelings can chime in and provide proposed text.
> >
> > Anyone else have any comments or proposed changes?
> I think the wording depends on the time period is for which the charter is
> prepared.
> I can try some text once I have time tomorrow.
> 
> . . .
> > > I think the DS draft provides a conceptual framework for diverse DS
> > > usage scenarios to be used by many protocols, where IETF WGs may
> > > actually decide using a subset of the DS framework for their purpose
> > > and for their protocol standardization.
> > > Based on this the conceptual framework cannot be standardized as it
> > > is but the protocols using a consistent subset have to be
standardized.
> > > Following this consideration I think the intended status of the DS
> > > draft should be changed to: Informational RFC If you agree please
> > > indicate this change accordingly.
> >
> > I think Juergen's reply to your previous message highlights that there
> > is a difference of opinion here based on the technical specifics of
> > the draft.  My position as chair is that I'll support whatever makes
> > sense based on the document produced by the WG.  Today the document
> > authors believe PS is appropriate, once we have a version that is
> > stabilizing for LC -- which hopefully will be the next version or two
> > -- then will be a good time to revisit this.
> There are indeed different opinions concerning the goal of the DS draft.
> I agree with the document introduction and see it as a conceptual
framework
> covering many usage scenarios.
> Such a conceptual framework describing possible solutions is informational
in
> nature and is not relevant for standardization.
> 
> > >>> This is as I think also important to avoid an overlapping between
> > >>> NETCONF and NETMOD charters.
> > >> I don't follow this point.  Certainly I'd hope that the protocol
> > >> impact of revised DS are covered in a PS document, unless for some
> > >> reason there are no

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Robert,

I2RS has a different environment and datastore framework than NETCONF. 
NETCONF uses a different datastore framework compared to RESTCONF.

DS conceptual model describes an overall picture and defines how it could
like. 
Such a concept providing the basis for many environments cannot be
standardized.

Protocol WGs are in charge to choose a consistent subset out of the DS
conceptual model and standardize the usage of these DSs as part of the
protocol specification.

BR,
Mehmet

> -Original Message-
> From: Robert Wilton [mailto:rwil...@cisco.com]
> Sent: Friday, March 17, 2017 3:04 PM
> To: Mehmet Ersue ; 'Lou Berger' ;
> 'Juergen Schoenwaelder' 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi,
> 
> Would 7950bis be allowed to have a normative reference to an Informational
> RFC that defined the YANG datastores?
> 
> If we did a 7950bis document (and it isn't clear that one is actually
required to
> support the revised datastores draft) then does that mean we would also
> need to have a new version of YANG?
> 
> That would potentially seem like a backwards step.  Also what would it
mean
> for an implementation that is aware of the new datastores but is using a
mix
> of YANG modules with different versions?
> 
> I don't understand why the revised datastores draft should not be
standards
> track once the various appendices have been moved out, noting that they
> are really only in the one draft at this stage because it seemed like that
would
> make it easier for folks to review and comment on.
> 
> Is the only issue here which WG the draft is being worked on?
> 
> Thanks,
> Rob
> 
> 
> On 17/03/2017 13:22, Mehmet Ersue wrote:
> > I think YANG identities should be standardized with 7950bis.
> >
> > Mehmet
> >
> >> -----Original Message-
> >> From: Lou Berger [mailto:lber...@labn.net]
> >> Sent: Thursday, March 16, 2017 12:28 PM
> >> To: Juergen Schoenwaelder ;
> >> Mehmet Ersue 
> >> Cc: 'Kent Watsen' ; netmod@ietf.org
> >> Subject: Re: [netmod] draft netmod charter update proposal
> >>
> >> Juergen,
> >>
> >> Thank you for the input.  I think your point highlights how the
> >> technical contents of a document drives the intended status of a
> document.
> >>
> >> Lou
> >>
> >> PS as a reminder to all, intended status of documents is *not*
> >> typically included in charters and are not included in the distributed
> version.
> >>
> >>
> >>
> >>
> >> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder
> >>  wrote:
> >>
> >>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:
> >>>
> >>>> That said different people including Netconf WG co-chairs think the
> >>>> DS concept document is Informational in nature and should be
> >>>> published as
> >> an
> >>>> Informational concept to be used in and adopted for the needs in
> > diverse
> >>>> protocol WGs. This is as I think also important to avoid an
> >>>> overlapping between NETCONF and NETMOD charters.
> >>> The current datastore draft includes concrete YANG idenity
> >>> definitions for datastores and origins and these definitions better
> >>> be standards track.
> >>>
> >>> /js
> >>>
> >>> --
> >>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
> >>>
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

I think YANG identities should be standardized with 7950bis.

Mehmet

> -Original Message-
> From: Lou Berger [mailto:lber...@labn.net]
> Sent: Thursday, March 16, 2017 12:28 PM
> To: Juergen Schoenwaelder ;
> Mehmet Ersue 
> Cc: 'Kent Watsen' ; netmod@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Juergen,
> 
> Thank you for the input.  I think your point highlights how the technical
> contents of a document drives the intended status of a document.
> 
> Lou
> 
> PS as a reminder to all, intended status of documents is *not* typically
> included in charters and are not included in the distributed version.
> 
> 
> 
> 
> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder
>  wrote:
> 
> > On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:
> >
> >> That said different people including Netconf WG co-chairs think the DS
> >> concept document is Informational in nature and should be published as
> an
> >> Informational concept to be used in and adopted for the needs in
diverse
> >> protocol WGs. This is as I think also important to avoid an overlapping
> >> between NETCONF and NETMOD charters.
> >
> > The current datastore draft includes concrete YANG idenity definitions
> > for datastores and origins and these definitions better be standards
> > track.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
> >
> 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

> From: Lou Berger [mailto:lber...@labn.net]
> Mehmet,
>see below.
> On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
> > Lou,
. . . 
> > I actually provided a very simple proposal. You guys can fill the idea
> > with minimal text better than me. I'm fine whatever the text is.
> > If you think the high-level topic description a)-f) does already
> > define the WG item clearly you can simply say "this is achieved with WG
> item XY".
> > If not, you can keep the high-level focus text but set additionally
> > the borders of the WG item with a few concrete words.
> 
> I really can't tell for sure, but it feels to me that this comment boils
down to a
> style comment and you have a preference for different contents in the
> charter.  I'd like to be sensitive to this.  As our style differs, having
a concrete
> proposal on specific text changes would be really helpful in us (and the
WG)
> evaluating the changes you'd like to see.  Without such specific examples
and
> think we're left with the charter as currently proposed.  Perhaps someone
> else who has similar feelings can chime in and provide proposed text.
> 
> Anyone else have any comments or proposed changes?
I think the wording depends on the time period is for which the charter is
prepared.
I can try some text once I have time tomorrow.
 
. . . 
> > I think the DS draft provides a conceptual framework for diverse DS
> > usage scenarios to be used by many protocols, where IETF WGs may
> > actually decide using a subset of the DS framework for their purpose
> > and for their protocol standardization.
> > Based on this the conceptual framework cannot be standardized as it is
> > but the protocols using a consistent subset have to be standardized.
> > Following this consideration I think the intended status of the DS
> > draft should be changed to: Informational RFC If you agree please
> > indicate this change accordingly.
> 
> I think Juergen's reply to your previous message highlights that there is
a
> difference of opinion here based on the technical specifics of the draft.
My
> position as chair is that I'll support whatever makes sense based on the
> document produced by the WG.  Today the document authors believe PS is
> appropriate, once we have a version that is stabilizing for LC -- which
> hopefully will be the next version or two -- then will be a good time to
revisit
> this.
There are indeed different opinions concerning the goal of the DS draft.
I agree with the document introduction and see it as a conceptual framework
covering many usage scenarios.
Such a conceptual framework describing possible solutions is informational
in nature and is not relevant for standardization. 
 
> >>> This is as I think also important to avoid an overlapping between
> >>> NETCONF and NETMOD charters.
> >> I don't follow this point.  Certainly I'd hope that the protocol
> >> impact of revised DS are covered in a PS document, unless for some
> >> reason there are no "on-the-wire" changes needed.  TI wouldn't expect
> >> that the document status of the base revised data store document would
> impact that.  Do you?
> >> If so, how?
> > My comment is actually superfluous if you agree with my considerations
> > above.
> > The worst case would in my opinion happen if the DS conceptual
> > framework covering many high-level DS usage scenarios would be
> > attempted to standardize, which at the end would prescribe protocol
> > WGs what they should be standardizing.
> 
> Yang presumes a certain set of functions for the protocols it operates
over.
> I'm not sure why having a document that specifies this would be an issue.
This is again an interesting discussion which SHOULD be discussed in a joint
session.
I don't have a strong opinion but it can be seen differently.

> > In such a case the conceptual framework would most likely cause a
> > competing situation with protocol WG's goals and documents and cannot
> > be adopted successfully.
> 
> If a protocol doesn't provide full support for yang (requirements) it
can't fully
> support all yang features.  If your point is that when NetMod changes
basic
> yang functions/operations that this might constrain the protocols (and
> related WGs) over which it operates, then I agree that this is the case.
How
> could it be otherwise?
Usually modeling languages provide many language constructs and people
modeling models choose which one is best for their purpose.
The same applies to the DS concept framework. The protocol WGs would like to
have the freedom to choose the subset to adopt from the protocol pov.

> Thanks,
> 
&g

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Lou,

> Mehmet,
> 
> On 03/15/2017 09:50 AM, Mehmet Ersue wrote:
> > Hi Lou, Kent,
> >
> > it appears to me the issues I raised below are not closed.
> it wasn't clear from your mail that a response was needed as it seemed to
be
> covering points otherwise discussed, and where we may not agree.
> It's good that you are re-raising them now.
> 
> >
> > I believe at least a "minimal" WG item focus formulation is required
> > to match to the high-level WG focus topics in a)-f). I was thinking my
> > proposal below is acceptable.
> >
> I think we disagree on this point.  That said, perhaps our objection is in
the
> abstract and not the specific.  Can you propose specific text change you'd
like
> to see made to the charter and we can discuss it?

I believe IETF WG charters need to be defined for a particular period of
time with a specific target for development.
The current charter proposal seems to provide a high-level WG focus
definition without time limits.
I think the WG items to develop in the planned time period need to be
defined at least minimally, at least as an indication.
This is the basis for me as a WG member by which I agree or object to the
approval of a charter proposal for the planned development period.

I actually provided a very simple proposal. You guys can fill the idea with
minimal text better than me. I'm fine whatever the text is. 
If you think the high-level topic description a)-f) does already define the
WG item clearly you can simply say "this is achieved with WG item XY".
If not, you can keep the high-level focus text but set additionally the
borders of the WG item with a few concrete words.

> > Netconf WG will ensure avoiding double-work concerning the DS concept
> > draft, however Netconf needs to specify what is required for the use
> > of the DS concept from protocol standards pov.
> 
> okay.  I think we agree that the protocol aspects belong in NetConf - and
> we're expecting those to be covered during the NetConf WG session in
> Chicago.
> 
> > That said different people including Netconf WG co-chairs think the DS
> > concept document is Informational in nature and should be published as
> > an Informational concept to be used in and adopted for the needs in
> > diverse protocol WGs.
> 
> okay.
I'm not sure whether your "okay" means the same as I meant.
I think the DS draft provides a conceptual framework for diverse DS usage
scenarios to be used by many protocols, where IETF WGs may actually decide
using a subset of the DS framework for their purpose and for their protocol
standardization.
Based on this the conceptual framework cannot be standardized as it is but
the protocols using a consistent subset have to be standardized.
Following this consideration I think the intended status of the DS draft
should be changed to: Informational RFC
If you agree please indicate this change accordingly.

> > This is as I think also important to avoid an overlapping between
> > NETCONF and NETMOD charters.
> 
> I don't follow this point.  Certainly I'd hope that the protocol impact of
> revised DS are covered in a PS document, unless for some reason there are
> no "on-the-wire" changes needed.  TI wouldn't expect that the document
> status of the base revised data store document would impact that.  Do you?
> If so, how?

My comment is actually superfluous if you agree with my considerations
above.
The worst case would in my opinion happen if the DS conceptual framework
covering many high-level DS usage scenarios would be attempted to
standardize, which at the end would prescribe protocol WGs what they should
be standardizing.
In such a case the conceptual framework would most likely cause a competing
situation with protocol WG's goals and documents and cannot be adopted
successfully. 

Thanks,
Mehmet

> > PS: I expect that most of the Netconf WG member read also the Netmod
> > maillist and therefor skip sending to both ML.
> >
> 
> Great.
> 
> Thanks.
> Lou
> > Thanks,
> > Mehmet
> >
> >> -Original Message-
> >> From: Mehmet Ersue
> >> Sent: Thursday, March 9, 2017 7:36 PM
> >> To: Lou Berger ; 'Kent Watsen'
> >> ; netmod@ietf.org
> >> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> >> 
> >> Subject: RE: [netmod] draft netmod charter update proposal
> >>
> >> Hi Lou,
> >>
> >>> The charters from the last couple of years don't have the intended
> > status --
> >> at least the ones we checked.
> >>> I actually feel pretty strongly about this (which of course can be
> >>> easily overruled by our A

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

[Mehmet Ersue]

Looks good to me. 

However, I think we should change:

s/and mandatory-to-implement is Secure Shell/

and the mandatory-to-implement secure transport is Secure Shell/

 

Mehmet

 

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, March 15, 2017 5:45 PM
To: netmod@ietf.org
Cc: sec-...@ietf.org
Subject: Re: [netmod] security considerations boilerplate updates to cover
RESTCONF

 

Dear all,

[copying the security ADs to make sure the new security section is fine] 
Let's separate the two issues

1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I agree with Jürgen
I see section 4.7:

   This section MUST be patterned after the latest approved template
   (available at http://trac.tools.ietf.org/area/ops/trac/wiki/
 
   yang-security-guidelines
 ).
Section 7.1

contains the security
   considerations template dated 2013-05-08.  Authors MUST check the WEB
   page at the URL listed above in case there is a more recent version
   available.

Then, I see section 7: 

  The following section contains the security considerations template
   dated 2010-06-16.

Not sure why it contains this cut/paste? It should just say: the latest
version is at this URL.
Then, I see in the same section:

This section MUST be patterned after the latest approved
   template (available at
 
http://www.ops.ietf.org/netconf/yang-security-considerations.txt

This page is not found.
This should be corrected in rfc6087bis.


2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG module.
As an example, 

draft-ietf-lmap-yang-11
 , A YANG Data Model
for LMAP Measurement Agents, on the telechat tomorrow.

As mentioned the most up to date version is
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Here is the proposal, discussed on the YANG doctors list:

 

OLD

The YANG module defined in this memo is designed to be accessed via the
NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF users to a pre-configured subset of
all available NETCONF protocol operations and content.

NEW

 

The YANG module defined in this memo is designed to be accessed via the
NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF layer
is the secure transport layer, and mandatory-to-implement is Secure Shell
(SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the
mandatory-to-implement secure transport is Transport Layer Security (TLS)
[RFC5246]. 

The NETCONF access control model [RFC6536] provides the means to restrict
access for particular NETCONF or RESTCONF users to a pre-configured subset
of all available NETCONF or RESTCONF protocol operations and content.

Any objections?
Have covered all that we need for the new RESTCONF protocol?

Regards, Benoit

 

Hi,
 
this came up during IESG processing of a YANG module - is there a new
security guideline boilerplate text covering RESTCONF? This was
briefly discussed on the yang-doctors but somehow the discussion
stopped because RESTCONF was not published yet at that time. I think
this affects draft-ietf-netmod-rfc6087bis-12.txt.
 
draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
online documents - why do we need several points? I think some are
also not working. Ideally, there should be a single stable URL.
 
/js
 

 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Lou, Kent,

it appears to me the issues I raised below are not closed.

I believe at least a "minimal" WG item focus formulation is required to
match to the high-level WG focus topics in a)-f). I was thinking my proposal
below is acceptable.

Netconf WG will ensure avoiding double-work concerning the DS concept draft,
however Netconf needs to specify what is required for the use of the DS
concept from protocol standards pov.
That said different people including Netconf WG co-chairs think the DS
concept document is Informational in nature and should be published as an
Informational concept to be used in and adopted for the needs in diverse
protocol WGs. This is as I think also important to avoid an overlapping
between NETCONF and NETMOD charters.

PS: I expect that most of the Netconf WG member read also the Netmod
maillist and therefor skip sending to both ML.

Thanks,
Mehmet

> -Original Message-
> From: Mehmet Ersue
> Sent: Thursday, March 9, 2017 7:36 PM
> To: Lou Berger ; 'Kent Watsen' ;
> netmod@ietf.org
> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani'
> 
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> Hi Lou,
> 
> > The charters from the last couple of years don't have the intended
status --
> at least the ones we checked.
> > I actually feel pretty strongly about this (which of course can be
> > easily overruled by our AD).  It's my experience that premature
> > discussions on intended status, i.e., before a document is sufficiently
> mature, leads to process-focused arguments that detracts from making
> technical progress.  While once a document is mature and core
> direction/content is fixed, it is generally obvious what status is
appropriate.
> 
> The charters from the last couple of years have a short WG item
definition,
> which would be IMO sufficient.
> You are right the intended status is not available since a few years, but
IMO it
> is part of the target definition and would be very useful for the draft
authors
> and WG members to regard.
> 
> > > It would be good to bring the high-level topics in relation to the WG
> items.
> > I'm sorry, I don't understand this last sentence can you rephrase it?
> 
> What I meant is that the high-level topics a)-f) might be good as WG focus
> description but are not sufficient as draft target definition.
> If you think the high-level topic description is more or less the WG item
> definition, then we could simply write "this is achieved with WG item XY".
> If not, we could keep the high-level focus text but set additionally the
> borders of the WG item with some concrete words.
> 
> > > BTW: We agreed in diverse discussions that the DS concept is
> Informational in nature.
> > > I think this should be corrected in the draft.
> >
> > So this sounds like an objection to a specific document.  This is a
> > fair point to raise, but in our opinion it is not a charter impacting
> > point or discussion.  If this is in fact the issue you'd like to raise
> > and discuss, lets do so under a document specific thread, e.g.,
"Subject:
> intended status of revised-datastore".
> 
> I am actually raising this point since November meeting. There are
different
> threads where I explained why it is appropriate as Informational.
> The last thread I remember is at:
> https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1
> 1xcY
> The recent position of NETCONF co-chairs is in
> https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd
> 8qr5k
> 
> Thank you for your consideration.
> 
> Regards,
> Mehmet
> 
> > -Original Message-
> > From: Lou Berger [mailto:lber...@labn.net]
> > Sent: Wednesday, March 8, 2017 11:28 PM
> > To: Mehmet Ersue ; 'Kent Watsen'
> > ; netmod@ietf.org
> > Subject: Re: [netmod] draft netmod charter update proposal
> >
> > Hi Mehmet,
> >
> > On 3/8/2017 4:47 PM, Mehmet Ersue wrote:
> > > Kent,
> > >
> > >> we understand that this is how NETCONF charters are structured, but
> > >> it is not our practice,
> > > AFAIK it was the NETMOD practice for the charters until today.
> >
> > The charters from the last couple of years don't have the intended
> > status -- at least the ones we checked.
> >
> > I actually feel pretty strongly about this (which of course can be
> > easily overruled by our AD).  It's my experience that premature
> > discussions on intended status, i.e., before a document is
> > sufficiently mature, leads to process-focused arguments that detracts
from
> making technical progress.
> &

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Lou,

> The charters from the last couple of years don't have the intended status
-- at least the ones we checked. 
> I actually feel pretty strongly about this (which of course can be easily
overruled by our AD).  It's my experience that premature discussions on
intended status, i.e., 
> before a document is sufficiently mature, leads to process-focused
arguments that detracts from making technical progress.  While once a
document is mature and 
> core direction/content is fixed, it is generally obvious what status is
appropriate.

The charters from the last couple of years have a short WG item definition,
which would be IMO sufficient.
You are right the intended status is not available since a few years, but
IMO it is part of the target definition and would be very useful for the
draft authors and WG members to regard.

> > It would be good to bring the high-level topics in relation to the WG
items.
> I'm sorry, I don't understand this last sentence can you rephrase it?

What I meant is that the high-level topics a)-f) might be good as WG focus
description but are not sufficient as draft target definition.
If you think the high-level topic description is more or less the WG item
definition, then we could simply write "this is achieved with WG item XY".
If not, we could keep the high-level focus text but set additionally the
borders of the WG item with some concrete words.

> > BTW: We agreed in diverse discussions that the DS concept is
Informational in nature.
> > I think this should be corrected in the draft.
> 
> So this sounds like an objection to a specific document.  This is a fair
point to
> raise, but in our opinion it is not a charter impacting point or
discussion.  If this
> is in fact the issue you'd like to raise and discuss, lets do so under a
document
> specific thread, e.g., "Subject: intended status of revised-datastore".

I am actually raising this point since November meeting. There are different
threads where I explained why it is appropriate as Informational.
The last thread I remember is at:
https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH11xcY
The recent position of NETCONF co-chairs is in
https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd8qr5k 

Thank you for your consideration.

Regards,
Mehmet

> -Original Message-----
> From: Lou Berger [mailto:lber...@labn.net]
> Sent: Wednesday, March 8, 2017 11:28 PM
> To: Mehmet Ersue ; 'Kent Watsen'
> ; netmod@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Mehmet,
> 
> On 3/8/2017 4:47 PM, Mehmet Ersue wrote:
> > Kent,
> >
> >> we understand that this is how NETCONF charters are structured, but
> >> it is not our practice,
> > AFAIK it was the NETMOD practice for the charters until today.
> 
> The charters from the last couple of years don't have the intended status
--
> at least the ones we checked.
> 
> I actually feel pretty strongly about this (which of course can be easily
> overruled by our AD).  It's my experience that premature discussions on
> intended status, i.e., before a document is sufficiently mature, leads to
> process-focused arguments that detracts from making technical progress.
> While once a document is mature and core direction/content is fixed, it is
> generally obvious what status is appropriate.
> 
> 
> > I did not ask
> > more than written in the current charter.
> > It would be good to bring the high-level topics in relation to the WG
items.
> I'm sorry, I don't understand this last sentence can you rephrase it?
> 
> >> as the information is available at the top of each draft, and also
because
> this information need not be fixed when the milestone is added.
> 
> > I believe a WG charter should be self-sufficient covering the target
> > definition and intended status of the WG items.
> > Otherwise one can change the target for a WG item by simply editing
> > the draft abstract anytime.
> 
> Per IETF process, all it ever takes to make a change in document status is
WG
> consensus, and then IESG and IETF buy-in as part of the publication
process.
> 
> > BTW: We agreed in diverse discussions that the DS concept is
> > Informational in nature.
> > I think this should be corrected in the draft.
> 
> So this sounds like an objection to a specific document.  This is a fair
point to
> raise, but in our opinion it is not a charter impacting point or
discussion.  If this
> is in fact the issue you'd like to raise and discuss, lets do so under a
document
> specific thread, e.g., "Subject:
> intended status of revised-datastore".
> 
> Thanks,
> Lou
> 
> >
> > Mehmet
> >

[netmod] FW: draft netmod charter update proposal

[Mehmet Ersue]

Hi Lou,

no issue at all, we can get in sync again. As I see in exchanged mails we 
discussed to not hurry and to plan a joint session.

AFAIK the timing between 7950bis and NETCONF documents as well as the content 
split is still subject to finalize.
It is not clear yet how and where to address 
draft-voit-netmod-yang-notifications2. Eric Voit's proposal is to do it in 
NETMOD WG.
Kent was asking for a discussion in NETCONF WG on to how we can address NETCONF 
extensions going to be proposed in the new DS concept draft.

I would like to suggest to continue the discussion on the maillist but give WG 
members in IETF 98 some room to comment before calling it final and giving to 
Benoit.
This I believe is necessary because of the dependent work we have on the two 
charters.

Thanks,
Mehmet

-Original Message-
From: Lou Berger [mailto:lber...@labn.net] 
Sent: Wednesday, March 8, 2017 10:50 PM
To: Mehmet Ersue ; 'Kent Watsen' ; 
'Susan Hares' ; netmod@ietf.org
Cc: netmod-cha...@ietf.org; 'Benoit Claise' ; 'Mahesh 
Jethanandani' 
Subject: Re: [netmod] draft netmod charter update proposal

Mehmet,

I'm sorry if we somehow got out of sync.  I certainly agree that we've agreed 
to having the chairs only coordination meeting you suggested, but I (and I 
suspect Kent) never thought this gated work on the NetMod charter but was more 
to ensure smooth cooperation between the groups.  I also thought we made it 
clear that we expected to have per-WG charter discussions in our respective 
session s on Tuesday rather than in a joint session.  It was always our hope 
that the NetMod WG charter would be finalized before Chicago -- I'm sorry if we 
didn't state this explicitly.  We expect to have a lot to discuss in the NetMod 
WG sessions and wanted to allocate time to focus on technical progress vs 
process, as well as ensure that all in the WG had equal opportunity to provide 
input via the list.

Certainly Benoit and the IESG will need to approve both Charters, but the 
timing of this is up to them.  I personally see that NetMod and NetConf efforts 
are largely deconflicted at this point so I don't have reservations with them 
progressing separately.

Lou

On 3/8/2017 4:25 PM, Mehmet Ersue wrote:
> Lou,
>
> I don't understand the plan change.
> We were discussing to have time for a joint charter discussion in Chicago.
>
> Any decision/agreement in a physical WG session will be verified on the 
> maillist.
> In any case once we are finished on the maillist, Benoit will review both 
> together.
> The two charters from NETCONF/NETMOD have to go hand in hand and one cannot 
> be approved by IESG before the other.
>
> Mehmet
>
>> -Original Message-
>> From: Lou Berger [mailto:lber...@labn.net]
>> Sent: Wednesday, March 8, 2017 7:18 PM
>> To: Mehmet Ersue ; 'Kent Watsen'
>> ; 'Susan Hares' ; 
>> netmod@ietf.org
>> Cc: netmod-cha...@ietf.org
>> Subject: Re: [netmod] draft netmod charter update proposal
>>
>> Hi Mehmet/Sue,
>>
>> Our (NETMOD chair's) plan is to have had sufficient on-list 
>> discussion so that we can submit the updated charter to the IESG 
>> *before* the Chicago meeting, and then to review the changes in 
>> Chicago.  We want to ensure that we have full participation and input 
>> on the list as this
>> *is* official process and we want to be sensitive to those who may 
>> not be able to travel to this meeting.
>>
>> Lou
>>
>>
>> On 3/8/2017 11:00 AM, Mehmet Ersue wrote:
>>> What I meant with joint session can be achieved with a (e.g. 
>>> 20-30min)
>> time-slot in NETMOD or NETCONF session on Tuesday where we invite 
>> I2RS people to attend. We can discuss the charter details and agree "all 
>> together"
>> on the plan and work split.
>>> Does this make sense?
>>>
>>> Mehmet
>>>
>>>> -Original Message-
>>>> From: Kent Watsen [mailto:kwat...@juniper.net]
>>>> Sent: Wednesday, March 8, 2017 1:51 AM
>>>> To: Mehmet Ersue ; 'Susan Hares'
>>>> ; netmod@ietf.org
>>>> Cc: netmod-cha...@ietf.org
>>>> Subject: Re: [netmod] draft netmod charter update proposal
>>>>
>>>> Hi Sue,
>>>>
>>>> First, please be aware that the next version of revised-datastores 
>>>> draft further defines the control-plane datastore concept.  This 
>>>> includes providing guidelines that other WGs can follow to define 
>>>> their own control-plane datastores, and includes an Appendix 
>>>> section outlining the creation of an "ephemeral" datastore.  The 
>

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Kent,

> we understand that this is how NETCONF charters are structured, but it is
not our practice,
AFAIK it was the NETMOD practice for the charters until today. I did not ask
more than written in the current charter.
It would be good to bring the high-level topics in relation to the WG items.

> as the information is available at the top of each draft, and also because
this information need not be fixed when the milestone is added.
I believe a WG charter should be self-sufficient covering the target
definition and intended status of the WG items.
Otherwise one can change the target for a WG item by simply editing the
draft abstract anytime.

BTW: We agreed in diverse discussions that the DS concept is Informational
in nature.
I think this should be corrected in the draft.

Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Wednesday, March 8, 2017 7:45 PM
> To: netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> 
> 
> 
> Hi NETMOD WG,
> 
> Please find below draft-4 having the following change:
> 
>  - added "(e.g., I2RS, RTGWG)" to a sentence.
> 
> Hi Sue, Lou and I looked at the proposed charter and found a sentence that
> nicely describes our WG's intent to work with and support other WGs
> (beyond NETCONF), but we felt that the text could be made more clear by
> adding in the above-mentioned change.  Beyond this, and the existing a),
b),
> and c), we believe that the charter proposal covers our support for I2RS,
do
> you agree?
> 
> Hi Mehmet, regarding putting a short description and the intended status
for
> each draft into the charter, we understand that this is how NETCONF
charters
> are structured, but it is not our practice, as the information is
available at the
> top of each draft, and also because this information need not be fixed
when
> the milestone is added.
> 
> All, Any other comments?
> 
> Kent
> 
> 
> 
> 
> Network Modeling (NETMOD)
> -
> 
> Charter
> 
> Current Status: Active
> 
> Chairs:
>Lou Berger 
>Kent Watsen 
> 
> Operations and Management Area Directors:
>Benoit Claise 
>Joel Jaeggli 
> 
> Operations and Management Area Advisor:
>Benoit Claise 
> 
> Secretary:
>Zitao (Michael) Wang 
> 
> Mailing Lists:
>General Discussion: netmod@ietf.org
>To Subscribe:   https://www.ietf.org/mailman/listinfo/netmod
>Archive:https://mailarchive.ietf.org/arch/browse/netmod/
> 
> Description of Working Group:
> 
>The Network Modeling (NETMOD) working group is responsible for the
> YANG
>data modeling language, and guidelines for developing YANG models.  The
>NETMOD working group addresses general topics related to the use of the
>YANG language and YANG models, for example, the mapping of YANG
> modeled
>data into various encodings.  Finally, the NETMOD working group
>also defines core YANG models used as basic YANG building blocks, and
>YANG models that do not otherwise fall under the charter of any other
>IETF working group.
> 
> The NETMOD WG is responsible for:
> 
>a) Maintaining the data modeling language YANG.  This effort entails
>   periodically updating the specification to address new requirements
>   as they arise.
> 
>b) Maintaining the guidelines for developing YANG models.  This effort
>   is primarily driven by updates made to the YANG specification.
> 
>c) Maintaining a conceptual framework in which YANG models are used.
>   This effort entails describing the generic context that in YANG
>   exists and how certain YANG statements interact in that context.
>   An example of this is YANG's relationship with datastores.
> 
>d) Maintaining encodings for YANG modeled data.  This effort entails
>   updating encodings already defined by the NETMOD working (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.
> 
>e) Maintaining YANG models used as basic YANG building blocks.  This
>   effort entails updating existing YANG models (ietf-yang-types and
>   ietf-inet-types) as needed, as well as defining additional core YANG
>   data models when necessary.
> 
>f) Defining and maintaining YANG models that do not fall under the
>   charter of any other active IETF working group.
> 
>The NETMOD working group consults with the NETCONF working group to
>ensure that new requirements are understood and can be met by the
>protocols (e.g., NETCONF and RESTCONF) developed within that working
>group.  The NETMOD working group coordinates with other working groups
>(e.g., I2RS, RTGWG) on possible extensions to YANG to address new
>modeling requirements and, when needed, which group will run the
>process on a specific model.
>

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Lou,

I don't understand the plan change.
We were discussing to have time for a joint charter discussion in Chicago.

Any decision/agreement in a physical WG session will be verified on the 
maillist.
In any case once we are finished on the maillist, Benoit will review both 
together.
The two charters from NETCONF/NETMOD have to go hand in hand and one cannot be 
approved by IESG before the other.

Mehmet

> -Original Message-
> From: Lou Berger [mailto:lber...@labn.net]
> Sent: Wednesday, March 8, 2017 7:18 PM
> To: Mehmet Ersue ; 'Kent Watsen'
> ; 'Susan Hares' ;
> netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Mehmet/Sue,
> 
> Our (NETMOD chair's) plan is to have had sufficient on-list discussion so that
> we can submit the updated charter to the IESG *before* the Chicago
> meeting, and then to review the changes in Chicago.  We want to ensure that
> we have full participation and input on the list as this
> *is* official process and we want to be sensitive to those who may not be
> able to travel to this meeting.
> 
> Lou
> 
> 
> On 3/8/2017 11:00 AM, Mehmet Ersue wrote:
> > What I meant with joint session can be achieved with a (e.g. 20-30min)
> time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS
> people to attend. We can discuss the charter details and agree "all together"
> on the plan and work split.
> >
> > Does this make sense?
> >
> > Mehmet
> >
> >> -Original Message-
> >> From: Kent Watsen [mailto:kwat...@juniper.net]
> >> Sent: Wednesday, March 8, 2017 1:51 AM
> >> To: Mehmet Ersue ; 'Susan Hares'
> >> ; netmod@ietf.org
> >> Cc: netmod-cha...@ietf.org
> >> Subject: Re: [netmod] draft netmod charter update proposal
> >>
> >> Hi Sue,
> >>
> >> First, please be aware that the next version of revised-datastores
> >> draft further defines the control-plane datastore concept.  This
> >> includes providing guidelines that other WGs can follow to define
> >> their own control-plane datastores, and includes an Appendix section
> >> outlining the creation of an "ephemeral" datastore.  The idea is to
> >> give the I2RS WG the ability to define
> >> datastore(s) as needed
> >> (read: future I2RS WG drafts).
> >>
> >> Regarding:
> >>
> >>> Does c) and d) include additions to include I2RS ephemeral state
> >>> as part of an I2RS control plane protocol?   If not, which WG
> >>> works on the I2RS ephemeral additions to Yang for control plane data
> >>> stores?
> >> I don't fully understand the question, but believe that the NETMOD
> >> activities needed to support I2RS are all covered by a), b), and c).
> >> Things that belong to NETCONF WG will include any needed changes to
> >> protocol, YANG-Library, or any other draft maintained by that WG.
> >> Everything else goes to I2RS.
> >>
> >> I'm not sure what Mehmet means by a "joint session", but I think that
> >> it's too late to add such a session to the IETF Agenda at this point.
> >> That said, I plan a schedule another datastore breakout session
> >> (likely on Wed morning) that could be used to discuss I2RS some, and
> >> I also plan on attending the I2RS meeting Wed afternoon.
> >>
> >> Kent
> >>
> >>
> >> -ORIGINAL MESSAGE-
> >>
> >> Sounds good as a first approximation. Though we need to discuss the
> >> details and agree.
> >> It might be useful to plan a joint session on Tue or Wed in Chicago.
> >>
> >> Cheers,
> >> Mehmet
> >>
> >>> -Original Message-
> >>> From: Susan Hares [mailto:sha...@ndzh.com]
> >>> Sent: Tuesday, March 7, 2017 7:27 PM
> >>> To: 'Mehmet Ersue' ; 'Kent Watsen'
> >>> ; netmod@ietf.org
> >>> Cc: netmod-cha...@ietf.org
> >>> Subject: RE: [netmod] draft netmod charter update proposal
> >>>
> >>> Mehmet:
> >>>
> >>> Thank you for the excellent question clarifying my questions.  My
> >> questions
> >>> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF
> >>> or
> >> CoAP.
> >>> I have removed that one.
> >>>
> >>> I restate my question below, and the [xx] indicates my understanding.
> >>>
> >>> Does c and d stat

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

What I meant with joint session can be achieved with a (e.g. 20-30min) 
time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS people 
to attend. We can discuss the charter details and agree "all together" on the 
plan and work split.

Does this make sense?

Mehmet

> -Original Message-
> From: Kent Watsen [mailto:kwat...@juniper.net]
> Sent: Wednesday, March 8, 2017 1:51 AM
> To: Mehmet Ersue ; 'Susan Hares'
> ; netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Sue,
> 
> First, please be aware that the next version of revised-datastores draft
> further defines the control-plane datastore concept.  This includes providing
> guidelines that other WGs can follow to define their own control-plane
> datastores, and includes an Appendix section outlining the creation of an
> "ephemeral" datastore.  The idea is to give the I2RS WG the ability to define
> datastore(s) as needed
> (read: future I2RS WG drafts).
> 
> Regarding:
> 
> > Does c) and d) include additions to include I2RS ephemeral state
> > as part of an I2RS control plane protocol?   If not, which WG
> > works on the I2RS ephemeral additions to Yang for control plane data
> > stores?
> 
> I don't fully understand the question, but believe that the NETMOD activities
> needed to support I2RS are all covered by a), b), and c).
> Things that belong to NETCONF WG will include any needed changes to
> protocol, YANG-Library, or any other draft maintained by that WG.
> Everything else goes to I2RS.
> 
> I'm not sure what Mehmet means by a "joint session", but I think that it's too
> late to add such a session to the IETF Agenda at this point.  That said, I 
> plan a
> schedule another datastore breakout session (likely on Wed morning) that
> could be used to discuss I2RS some, and I also plan on attending the I2RS
> meeting Wed afternoon.
> 
> Kent
> 
> 
> -ORIGINAL MESSAGE-
> 
> Sounds good as a first approximation. Though we need to discuss the details
> and agree.
> It might be useful to plan a joint session on Tue or Wed in Chicago.
> 
> Cheers,
> Mehmet
> 
> > -Original Message-
> > From: Susan Hares [mailto:sha...@ndzh.com]
> > Sent: Tuesday, March 7, 2017 7:27 PM
> > To: 'Mehmet Ersue' ; 'Kent Watsen'
> > ; netmod@ietf.org
> > Cc: netmod-cha...@ietf.org
> > Subject: RE: [netmod] draft netmod charter update proposal
> >
> > Mehmet:
> >
> > Thank you for the excellent question clarifying my questions.  My
> questions
> > (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or
> CoAP.
> > I have removed that one.
> >
> > I restate my question below, and the [xx] indicates my understanding.
> >
> > Does c and d state the following are handled:
> > 1) informational concepts for the DS handling - [Netmod]
> > 2) generic extensions to Yang to describe control plane datastore yang
> > modules - [netmod]
> > 3) generic extensions to Yang to describe the ephemeral state in
> > control plane yang modules - [I2RS]
> > 4) I2RS specific extensions to support the I2RS control plane
> > datastore's validation - [I2RS]
> > 5) Any I2RS Yang modules- [I2RS]
> >
> > To provide precision on this point, I will give examples of work
> > related
> to
> > each question:
> > 1)  draft-ietf-netmod-revised-datastores-00.txt   [netmod]
> > 2) extensions to describe control plane data store yang modules:
> >a) control plane data store definitions added to
> draft-ietf-netmod-yang-
> > model-classification [netmod]
> >b) extensions to the Yang 1.1 - to provide a syntax to describe
> datastores in
> > which a module exists
> >datastore should include syntax to identify identity and
> prioritization
> > config data store. [netmod]
> >c) extension to describe the merged tree in applied datastore and
> opstate
> > datastore  [netmod]
> >d) mount extensions that allow mounting modules in different
> > datastores
> >
> > 3) generic extensions to describe ephemeral state the I2RS control
> > plane datastore  [I2RS]
> >  a) extensions can define validation specific to I2RS control
> > plane datastore.
> >  b) rpc can be used for validation of modules
> > that seek to mounted in either the I2RS control plane
> > datastore or
> the
> > configuration data store.
> >
> > 4) I2RS specific extensions to support I2RS features in the I2RS
> > control
> plane
> >

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Sounds good as a first approximation. Though we need to discuss the details
and agree.
It might be useful to plan a joint session on Tue or Wed in Chicago.

Cheers,
Mehmet

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Tuesday, March 7, 2017 7:27 PM
> To: 'Mehmet Ersue' ; 'Kent Watsen'
> ; netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> Mehmet:
> 
> Thank you for the excellent question clarifying my questions.  My
questions
> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or
CoAP.
> I have removed that one.
> 
> I restate my question below, and the [xx] indicates my understanding.
> 
> Does c and d state the following are handled:
> 1) informational concepts for the DS handling - [Netmod]
> 2) generic extensions to Yang to describe control plane datastore yang
> modules - [netmod]
> 3) generic extensions to Yang to describe the ephemeral state in control
> plane yang modules - [I2RS]
> 4) I2RS specific extensions to support the I2RS control plane datastore's
> validation - [I2RS]
> 5) Any I2RS Yang modules- [I2RS]
> 
> To provide precision on this point, I will give examples of work related
to
> each question:
> 1)  draft-ietf-netmod-revised-datastores-00.txt   [netmod]
> 2) extensions to describe control plane data store yang modules:
>a) control plane data store definitions added to
draft-ietf-netmod-yang-
> model-classification [netmod]
>b) extensions to the Yang 1.1 - to provide a syntax to describe
datastores in
> which a module exists
>datastore should include syntax to identify identity and
prioritization
> config data store. [netmod]
>c) extension to describe the merged tree in applied datastore and
opstate
> datastore  [netmod]
>d) mount extensions that allow mounting modules in different datastores
> 
> 3) generic extensions to describe ephemeral state the I2RS control plane
> datastore  [I2RS]
>  a) extensions can define validation specific to I2RS control plane
> datastore.
>  b) rpc can be used for validation of modules
> that seek to mounted in either the I2RS control plane datastore or
the
> configuration data store.
> 
> 4) I2RS specific extensions to support I2RS features in the I2RS control
plane
> data store.
> 
> My earlier: - is a question for NETCONF/RESTCONF, or CoAP.
> b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF)
>to enable the usage of DS - [protocol group or WG]
> 
> 
> Sue
> 
> 
> -Original Message-
> From: Mehmet Ersue [mailto:mer...@gmail.com]
> Sent: Tuesday, March 7, 2017 12:21 PM
> To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: RE: [netmod] draft netmod charter update proposal
> 
> Hi Sue,
> 
> AFAICS your question kind of mixes between "I2RS control plane protocol"
> and "ephemeral additions to Yang".
> I believe different WGs are responsible for the part they own.
> E.g. protocol-specific part should be done in the WG owning the protocol.
> 
> Can you please differentiate in your question between the aspects below
> (my assumption in [ ]?
> a) informational concept for the DS handling [netmod]
> b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to
> enable the usage of DS [protocol WGs, e.g. I2RS]
> c) generic extensions to YANG language usable by many protocols [netmod]
> d) any specific YANG modules necessary for the use of DS [protocols WGs]
> 
> BR,
> Mehmet
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Susan
> Hares
> > Sent: Tuesday, March 7, 2017 4:30 PM
> > To: 'Kent Watsen' ; netmod@ietf.org
> > Cc: netmod-cha...@ietf.org
> > Subject: Re: [netmod] draft netmod charter update proposal
> >
> > Kent and Lou:
> >
> > Clarifying questions:
> >
> > Does c) and d) include additions to include I2RS ephemeral state as
> > part
> of
> > an I2RS control plane protocol?  If not, which WG works on the I2RS
> > ephemeral additions to Yang for control plane data stores?
> >
> > Sue
> >
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent
> Watsen
> > Sent: Wednesday, February 22, 2017 7:25 PM
> > To: netmod@ietf.org
> > Cc: netmod-cha...@ietf.org
> > Subject: [netmod] draft netmod charter update proposal
> >
> >
> > Hi NETMOD WG,
> >
> > Please find below the draft charter update which we provided to our AD
> > 

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Sue,

AFAICS your question kind of mixes between "I2RS control plane protocol" and
"ephemeral additions to Yang".
I believe different WGs are responsible for the part they own.
E.g. protocol-specific part should be done in the WG owning the protocol.

Can you please differentiate in your question between the aspects below (my
assumption in [ ]?
a) informational concept for the DS handling [netmod]
b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to
enable the usage of DS [protocol WGs, e.g. I2RS]
c) generic extensions to YANG language usable by many protocols [netmod]
d) any specific YANG modules necessary for the use of DS [protocols WGs]

BR,
Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Susan Hares
> Sent: Tuesday, March 7, 2017 4:30 PM
> To: 'Kent Watsen' ; netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Kent and Lou:
> 
> Clarifying questions:
> 
> Does c) and d) include additions to include I2RS ephemeral state as part
of
> an I2RS control plane protocol?  If not, which WG works on the I2RS
> ephemeral additions to Yang for control plane data stores?
> 
> Sue
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Wednesday, February 22, 2017 7:25 PM
> To: netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: [netmod] draft netmod charter update proposal
> 
> 
> Hi NETMOD WG,
> 
> Please find below the draft charter update which we provided to our AD for
> review.  Comments are welcomed.  Authors, please note the milestone
> dates.
> 
> Kent (and Lou)
> 
> 
> 
> 
> Network Modeling (NETMOD)
> -
> 
> Charter
> 
> Current Status: Active
> 
> Chairs:
>Lou Berger 
>Kent Watsen 
> 
> Operations and Management Area Directors:
>Benoit Claise 
>Joel Jaeggli 
> 
> Operations and Management Area Advisor:
>Benoit Claise 
> 
> Secretary:
>Zitao (Michael) Wang 
> 
> Mailing Lists:
>General Discussion: netmod@ietf.org
>To Subscribe:   https://www.ietf.org/mailman/listinfo/netmod
>Archive:https://mailarchive.ietf.org/arch/browse/netmod/
> 
> Description of Working Group:
> 
>The Network Modeling (NETMOD) working group is responsible for the
> YANG
>data modeling language, and guidelines for developing YANG models.  The
>NETMOD working group addresses general topics related to the use of the
>YANG language and YANG models, for example, the mapping of YANG
> modeled
>data into various encodings.  Finally, the NETMOD working group also
>defines core YANG models used as basic YANG building blocks, and YANG
>models that do not otherwise fall under the charter of any other IETF
>working group.
> 
> The NETMOD WG is responsible for:
> 
>a) Maintaining the data modeling language YANG.  This effort entails
>   periodically updating the specification to address new requirements
>   as they arise.
> 
>b) Maintaining the guidelines for developing YANG models.  This effort
>   is primarily driven by updates made to the YANG specification.
> 
>c) Maintaining a conceptual framework in which YANG models are used.
>   This effort entails describing the context that network management
>   protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and
>   how certain YANG statements interact in that context.
> 
>d) Maintaining encodings for YANG modeled data.  This effort entails
>   updating encodings already defined by the NETMOD working (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.
> 
>e) Maintaining YANG models used as basic YANG building blocks.  This
>   effort entails updating existing YANG models (ietf-yang-types and
>   ietf-inet-types) as needed, as well as defining additional core YANG
>   data models when necessary.
> 
>f) Defining and maintaining YANG models that do not fall under the
>   charter of any other active IETF working group.
> 
>The NETMOD working group consults with the NETCONF working group to
>ensure that new requirements are and understood and can be met by
>the protocols developed within that working group (e.g., NETCONF
>and RESTCONF).  The NETMOD working group coordinates with other
>working groups on possible extensions to YANG to address new modeling
>requirements and, when needed, which group will run the process on a
>specific model.
> 
>The NETMOD working group does not serve as a review team for YANG
>modules developed by other working groups. Instead, the YANG doctors,
>as organized by the OPS area director responsible for network
>management, will act as advisors for other working groups and provide
>YANG reviews f

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Kent,

I am missing two aspects in the charter.
One is the short description of planned WG items setting the target. 
The other point is the intended status of the WG items.
To me without such definition it looks kind of incomplete.

Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Friday, March 3, 2017 4:23 PM
> To: netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> 
> Hi NETMOD WG,
> 
> Please find below draft-3 having the following changes:
> 
>  - s/representation/encoding/g
>  - s/2016/2017/ in Milestones
>  - moved syslog from Mar to Apr
>  - moved entity from Mar to Apr
> 
> Any other comments?
> 
> Kent
> 
> 
> 
> 
> Network Modeling (NETMOD)
> -
> 
> Charter
> 
> Current Status: Active
> 
> Chairs:
>Lou Berger 
>Kent Watsen 
> 
> Operations and Management Area Directors:
>Benoit Claise 
>Joel Jaeggli 
> 
> Operations and Management Area Advisor:
>Benoit Claise 
> 
> Secretary:
>Zitao (Michael) Wang 
> 
> Mailing Lists:
>General Discussion: netmod@ietf.org
>To Subscribe:   https://www.ietf.org/mailman/listinfo/netmod
>Archive:https://mailarchive.ietf.org/arch/browse/netmod/
> 
> Description of Working Group:
> 
>The Network Modeling (NETMOD) working group is responsible for the
> YANG
>data modeling language, and guidelines for developing YANG models.  The
>NETMOD working group addresses general topics related to the use of the
>YANG language and YANG models, for example, the mapping of YANG
> modeled
>data into various encodings.  Finally, the NETMOD working group
>also defines core YANG models used as basic YANG building blocks, and
>YANG models that do not otherwise fall under the charter of any other
>IETF working group.
> 
> The NETMOD WG is responsible for:
> 
>a) Maintaining the data modeling language YANG.  This effort entails
>   periodically updating the specification to address new requirements
>   as they arise.
> 
>b) Maintaining the guidelines for developing YANG models.  This effort
>   is primarily driven by updates made to the YANG specification.
> 
>c) Maintaining a conceptual framework in which YANG models are used.
>   This effort entails describing the generic context that in YANG
>   exists and how certain YANG statements interact in that context.
>   An example of this is YANG's relationship with datastores.
> 
>d) Maintaining encodings for YANG modeled data.  This effort entails
>   updating encodings already defined by the NETMOD working (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.
> 
>e) Maintaining YANG models used as basic YANG building blocks.  This
>   effort entails updating existing YANG models (ietf-yang-types and
>   ietf-inet-types) as needed, as well as defining additional core YANG
>   data models when necessary.
> 
>f) Defining and maintaining YANG models that do not fall under the
>   charter of any other active IETF working group.
> 
>The NETMOD working group consults with the NETCONF working group to
>ensure that new requirements are and understood and can be met by
>the protocols developed within that working group (e.g., NETCONF
>and RESTCONF).  The NETMOD working group coordinates with other
>working groups on possible extensions to YANG to address new modeling
>requirements and, when needed, which group will run the process on a
>specific model.
> 
>The NETMOD working group does not serve as a review team for YANG
>modules developed by other working groups. Instead, the YANG doctors,
>as organized by the OPS area director responsible for network
>management, will act as advisors for other working groups and provide
>YANG reviews for the OPS area directors.
> 
> Milestones:
> 
>Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication
>Mar 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG
>   for publication
>Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for publication
>Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication
>Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for
publication
>Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for
publication
>Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for
>   publication
>Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for
>   publication
>Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for
>   publication
> 
> 
> 
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@

Re: [netmod] draft netmod charter update proposal

[Mehmet Ersue]

Hi Kent, Lou,

>   c) Maintaining a conceptual framework in which YANG models are used.
>  This effort entails describing the context that network management
>  protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and
>  how certain YANG statements interact in that context.

The point above sounds a bit vague and can be interpreted wrongly.
What exactly is meant by "the context that network management protocols
operate in"?

Actually since 2002, NETCONF WG is responsible to specify the configuration
protocols and the context and framework where they operate in.
I assume you rather mean bringing YANG and the protocols using it into
relation or showing how YANG is used together with a protocol, or?
To make it more clear please elaborate what exactly is in-scope and what is
out-of-scope.

We were discussing to specify the YANG language as generic as possible to be
used by many protocols and with this to remove NETCONF specific details.
If this is still the aim, we should add a statement on this.

I have to admit I found the old charter format, where current and planned WG
items are described, as very purposeful.
IOW I am missing a short target description of WG items and how they map to
the high-level descriptions in a)-f).
The draft titles in Milestones are unfortunately not very descriptive.

Thank you for your efforts,
Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Thursday, February 23, 2017 1:25 AM
> To: netmod@ietf.org
> Cc: netmod-cha...@ietf.org
> Subject: [netmod] draft netmod charter update proposal
> 
> 
> Hi NETMOD WG,
> 
> Please find below the draft charter update which we provided to our AD for
> review.  Comments are welcomed.  Authors, please note the milestone
> dates.
> 
> Kent (and Lou)
> 
> 
> 
> 
> Network Modeling (NETMOD)
> -
> 
> Charter
> 
> Current Status: Active
> 
> Chairs:
>Lou Berger 
>Kent Watsen 
> 
> Operations and Management Area Directors:
>Benoit Claise 
>Joel Jaeggli 
> 
> Operations and Management Area Advisor:
>Benoit Claise 
> 
> Secretary:
>Zitao (Michael) Wang 
> 
> Mailing Lists:
>General Discussion: netmod@ietf.org
>To Subscribe:   https://www.ietf.org/mailman/listinfo/netmod
>Archive:https://mailarchive.ietf.org/arch/browse/netmod/
> 
> Description of Working Group:
> 
>The Network Modeling (NETMOD) working group is responsible for the
> YANG
>data modeling language, and guidelines for developing YANG models.  The
>NETMOD working group addresses general topics related to the use of the
>YANG language and YANG models, for example, the mapping of YANG
> modeled
>data into various encodings.  Finally, the NETMOD working group also
>defines core YANG models used as basic YANG building blocks, and YANG
>models that do not otherwise fall under the charter of any other IETF
>working group.
> 
> The NETMOD WG is responsible for:
> 
>a) Maintaining the data modeling language YANG.  This effort entails
>   periodically updating the specification to address new requirements
>   as they arise.
> 
>b) Maintaining the guidelines for developing YANG models.  This effort
>   is primarily driven by updates made to the YANG specification.
> 
>c) Maintaining a conceptual framework in which YANG models are used.
>   This effort entails describing the context that network management
>   protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and
>   how certain YANG statements interact in that context.
> 
>d) Maintaining encodings for YANG modeled data.  This effort entails
>   updating encodings already defined by the NETMOD working (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.
> 
>e) Maintaining YANG models used as basic YANG building blocks.  This
>   effort entails updating existing YANG models (ietf-yang-types and
>   ietf-inet-types) as needed, as well as defining additional core YANG
>   data models when necessary.
> 
>f) Defining and maintaining YANG models that do not fall under the
>   charter of any other active IETF working group.
> 
>The NETMOD working group consults with the NETCONF working group to
>ensure that new requirements are and understood and can be met by
>the protocols developed within that working group (e.g., NETCONF
>and RESTCONF).  The NETMOD working group coordinates with other
>working groups on possible extensions to YANG to address new modeling
>requirements and, when needed, which group will run the process on a
>specific model.
> 
>The NETMOD working group does not serve as a review team for YANG
>modules developed by other working groups. Instead, the YANG doctors,
>as organized by th

Re: [netmod] netmod-revised-datastores: templates, interactions with RFC6243 'report-all'

[Mehmet Ersue]

> >> I cannot help myself: we need to remove all dependecies on protocols, 
> >> specific datastores and data representation (encoding) from the YANG 
> >> spec in order to make it generally applicable.
> > 
> > I made a similar comment recently here:
https://www.ietf.org/mail-archive/web/netconf/current/msg12356.html.  Read
the remainder of the thread to see the response there.
>
> Yes, this has been discussed several times, in fact I proposed it even
before work on YANG 1.1 had started (at IETF 87). Juergen wants to have an
architecture document first, but I think we could instead limit the 
> scope of YANG, make it into kind of schema language for hierarchical data,
and use as a building block that does validation.

I fully agree and strongly support making YANG generally applicable and
independent of protocols and datastores.
We also agreed to put out encoding rules for particular protocols out of
YANG specification.

Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> Lhotka
> Sent: Monday, February 20, 2017 4:49 PM
> To: Kent Watsen 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] netmod-revised-datastores: templates, interactions
> with RFC6243 'report-all'
> 
> 
> > On 20 Feb 2017, at 15:53, Kent Watsen  wrote:
> >
> >
> > Hi Lada,
> >
> >
> >>> Yes, the YANG would have to define schema for both the template and
> >>> expanded forms.
> >>
> >> Are you saying that running and intended (may) have different schemas?
> >> The draft indicates that only intended is subject to validation.
> >> Either way, it significantly changes the rules of the game because
> >> validation in RFC 7950 is bound to running.
> >
> > I've been assuming that there is only one configuration schema, but
> > that the template schema wouldn't apply in the intended datastore.
> > This might be an academic distinction if , or
> > RESTCONF's unified datastore, only act on the running datastore.  Yes,
> 
> I think my problem is rather the opposite: could running containing
templates
> be invalid? Of course, it depends on how templates work, which isn't clear
> from the document (yet).
> 
> >  we'd want to support read-only operations on 'intended', but I'm not
> entirely sure about read-write operations, including the  or even
the
>  operations.
> >
> > Regarding moving validation from running to intended, I think that
Section
> 6.3 might be just poorly worded.  At least, I took it to mean that
semantic
> validation conceptually takes place after the system has removed inactive
> data and flattened templates.  Not only does it seem intuitive, but it
also
> helps simplify must/when/etc. expressions, as they only need to target the
> expanded/flattened template paths.
> 
> OK, but RFC 7950 list a number of properties that must be true in "all
data
> trees". I suspect that running (or candidate) with unexpanded templates
> might break some of these properties.
> 
> >
> >
> >> I cannot help myself: we need to remove all dependecies on protocols,
> >> specific datastores and data representation (encoding) from the YANG
> >> spec in order to make it generally applicable.
> >
> > I made a similar comment recently here: https://www.ietf.org/mail-
> archive/web/netconf/current/msg12356.html.  Read the remainder of the
> thread to see the response there.
> 
> Yes, this has been discussed several times, in fact I proposed it even
before
> work on YANG 1.1 had started (at IETF 87). Juergen wants to have an
> architecture document first, but I think we could instead limit the scope
of
> YANG, make it into kind of schema language for hierarchical data, and use
as
> a building block that does validation.
> 
> Lada
> 
> >
> > That said, I definitely think that a 7950bis should remove all of the
XML and
> NETCONF encoding text in RFC7950.  A number of these kinds of changes are
> being tracked here: https://github.com/netmod-wg/yang-next/issues.
> >
> >
> > Kent  // as an author
> >
> >
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Generic DS concept WAS:RE: [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Mehmet Ersue]

Hi All,

I started this thread for a discussion on the Intended Status of the Revised
DS Draft.
I think the discussion on technical issues of the DS concept can be
discussed on one maillist.

I call the new thread "Generic DS concept".

Cheers,
Mehmet

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Wednesday, January 11, 2017 4:37 PM
To: Robert Wilton 
Cc: Netconf ; NetMod WG 
Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the
Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits


> On 11 Jan 2017, at 16:18, Robert Wilton  wrote:
> 
> 
> 
> On 11/01/2017 14:48, Ladislav Lhotka wrote:
>>> On 11 Jan 2017, at 15:18, Robert Wilton  wrote:
>>> 
>>> Hi,
>>> 
>>> On 11/01/2017 13:05, Ladislav Lhotka wrote:
> On 11 Jan 2017, at 13:53, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>>> 
>> Show me a single YANG data node definition that's duplicate in my 
>> concept above. But then maybe I didn't explain it properly.
> The interface's "type" leaf.  With the new operational-state 
> datastore, /interfaces/interface/type in operational-state and 
> /interfaces-state/interface/type are duplicate.
 As I said, ietf-interfaces-state state would consist of augments
containing extra state nodes (i.e. those that are not in configuration). So
"type" won't be there.
>>> I think that this effectively just achieves the same thing that the
"config: true|false" statement indicates in a combined config/state tree.
>>> 
>>> Personally, I think that a file of augmentations is probably going to be
harder to read than having the config and state schema in one tree in one
file.
>> Possibly we could also use schema mount. On the other hand, it doesn't
enforce the use of operational-state datastore. A simple device like a
WiFi-controlled electric socket could easily use just ietf-interfaces-config
(and ietf-ip-config), i.e. no state data.
>> 
>> Another example I am dealing with now is OpenWRT: with some effort, it
would be possible to translate our nice configuration data into UCI files
without touching the OpenWRT system itself. On the other hand, serving state
data according to our YANG modules is a non-starter.
> Isn't the proper answer here to generate deviations to remove the state
leaves that won't be implemented.

This is of course possible but deviations are generally frowned upon, so why
not use the modularity features for making it a little more flexible? I know
some people will now say that without state data it is no proper network
management but, speaking pragmatically, automated configuration would be a
big boon by itself.

> 
>> 
>>> The models may also be slightly more inconvenient to use because the
state tree leaves would presumably be in a different namespace from the
configuration?
>>> 
>> Yes, but I don't think it is a big problem - even for human readers.
> I'm not sure.  I think that you might end up with a variation of the
OpenConfig models, and based on experience I would say that those models are
hard to read if they haven't been compiled first to expand the groupings and
reveal the actual structure.

One thing that makes modules really hard to read are augments, and we
already have them all over the place. It's a trade-off between readability
and modularity.

Lada

> 
> Rob
> 
> 
>> 
>>> If you wanted this file level split then using submodules would allow
for separate config/state files but still be managed as a single combined
module.
>> But it means you have to implement both.
>> 
>> Lada
>> 
>>> Rob
>>> 
>>> 
>> Note also that you slightly misinterpreted my statement that you
>> cited:
>> 
>> I believe both the protocols and YANG can work with any set of 
>> datastores [...]
>> 
>> I didn't say that there cannot be *modules* that are somehow 
>> designed for a particular datastore model - I meant YANG the
language.
> Ok.  Yes, you're right, but then we'd probably need some new 
> statement in each module that tells which meta-model the YANG 
> module is written for.
 I would prefer to have it as state data, basically separate YANG
libraries for configuration datastores and operational-state.
>>> 
 Lada
 
> /martin
> 
> 
>> Lada
>> 
>>> /martin
>>> 
>>> 
 Am I completely misguided here? If not, then I don't see where 
 the new modules refer to any particular datastore model. Yes, 
 they do reflect that there is configuration and state data, but 
 we don't want to get rid of this distinction, right?
 
 Lada
 
> 
> /martin
 --
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: 0xB8F92B08A9F76C67
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
 --
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: 0xB8F92B08A9F76C67
 
 
 
 
 
 _

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Mehmet Ersue]

Hi Juergen,

I don't think it is duplicate work. One is as I understand the architecture and 
concept document you were asking for 
and the other draft is the standard DS framework RFC to be used as the basis 
for different documents.

Cheers,
Mehmet

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Friday, January 6, 2017 7:45 PM
To: Mehmet Ersue 
Cc: 'Netconf' ; 'NetMod WG' 
Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS Draft 
WAS:RE: :candidate, :writable-running and RESTCONF edits

On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote:
> 
> It is correct that we need a standard track document for the new DS framework 
> - to provide a basis for other RFCs to develope.  However the current DT 
> solution draft has not been prepared as a standard track document nor it has 
> standard relevant content. Such concept description is usually prepared as an 
> architecture document (see example in  <https://tools.ietf.org/html/rfc6244> 
> RFC 6244).
> 
> As I stated earlier I believe “a new protocol- and language-independent 
> standard document” should be prepared defining the generic datastore 
> framework (based on and following the concept in the DT solution draft).
> 

To me, this sounds like duplicate work for no real technical value. If the 
existance of two WG results into actions like this, we should seriously 
consider the option to merge NETMOD and NETCONF into one WG.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: [Netconf] :candidate, :writable-running and RESTCONF edits

[Mehmet Ersue]

Hi All,

 

[NETMOD CCed as this is relevant to the revised DS draft]

 

> > > > I wrote it already several times: I support(ed) Mehmet's proposal to 
> > > > make the revised-datastores I-D informative. The document was adopted 
> > > > as a Standard Track WG item although I didn't see anything close to 
> > > > rough consensus during the adoption poll.
> > > >
> > > It appears to me that there is consensus to making this a standards track 
> > > solution.
> > >
> > Where is any evidence of this?
>
> I think there was approval in the room in Seoul, and it is being confirmed on 
> the mailing list.

It is correct that we agreed in Seoul to start a consensus call on both 
maillists for the adoption of the DT draft and executed such an adoption call.

However we did not have any decision on the intended draft status in Seoul and 
did not have any agreement during the adoption call. I explained my concerns on 
the currently indicated status being standard track and did not hear any other 
argument.

 

It is correct that we need a standard track document for the new DS framework - 
to provide a basis for other RFCs to develope.  However the current DT solution 
draft has not been prepared as a standard track document nor it has standard 
relevant content. Such concept description is usually prepared as an 
architecture document (see example in   
RFC 6244).

As I stated earlier I believe “a new protocol- and language-independent 
standard document” should be prepared defining the generic datastore framework 
(based on and following the concept in the DT solution draft).

 

IMO the intended status of the DS draft is still open and subject to decide.

 

Regards,

Mehmet

 

From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, December 28, 2016 6:37 PM
To: Ladislav Lhotka 
Cc: Netconf 
Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits

 

 

 

On Wed, Dec 28, 2016 at 1:06 AM, Ladislav Lhotka mailto:lho...@nic.cz> > wrote:


> On 27 Dec 2016, at 19:34, Andy Bierman   > wrote:
>
>
>
> On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka   > wrote:
>
> > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder 
> >  >  > wrote:
> >
> > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote:
> >>
> >>>
> >>> A remote API for management applications was our original target and
> >>> this is where YANG is doing well (and we apparently still have work to
> >>> do to improve things).
> >>
> >> By "management application" I mean a specific implementation with a fixed 
> >> set of datastores and precise semantics. I do argue that neither RFC 6241, 
> >> nor "revised-datastores" nor any other *specific* setup of datastores is 
> >> going to work for all use cases, yet the protocols and YANG can be pretty 
> >> universal.
> >>
> >> We have already seen YANG being used in areas that are, strictly speaking, 
> >> not supported by 6020/7950. Rather than tolerating such uses (which is a 
> >> slippery slope), I would prefer to make them - within reasonable limits - 
> >> officially supported.
> >>
> >
> > This is too abstract for me. What do you suggest to change in the
> > revised datastore architecture? I do believe that having a number of
> > well defined datastores with specific semantics is necessary for
> > having interoperability.
>
> I wrote it already several times: I support(ed) Mehmet's proposal to make the 
> revised-datastores I-D informative. The document was adopted as a Standard 
> Track WG item although I didn't see anything close to rough consensus during 
> the adoption poll.
>
>
>
> It appears to me that there is consensus to making this a standards track 
> solution.

Where is any evidence of this?

 

 

I think there was approval in the room in Seoul, and it is being confirmed on 
the mailing list.

 

 

>
> Datastores allow universal concepts about managed data to be standardized
> across multiple protocols.  In a protocol, the datastore name serves as
> an input parameter value.  It needs to be normative in order for a
> standards-track protocol to use it.

For the protocol, the RPC parameter needs to be normative, not a particular 
datastore name or semantics.

>
> Changing standards track status never addresses real technical problems.
> I do not understand your objections or alternate proposals.

I think this proposal will lead to rather significant changes to the protocols 
and YANG, and their extent IMO isn't clear yet. For one, the draft aims at 
moving validation from "running" to "intended". But if "intended" is optional 
to implement (sec. 6.1), I don't get how validation in YANG can be (re)defined 
to apply also to implementations that don't have "intended".

 

 

 

It should be possible to add new operations to NETCONF and

new query parameters to RESTCONF that support the operator requirements,

and 

Re: [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Mehmet Ersue]

Dear Lou,

as I stated earlier and some people agreed, I believe this document should be 
published as Informational RFC.

The reason I gave is below:
> I see the DT document as a datastore solution proposal. There are different 
> gaps and issues which still need to be addressed and the solution proposal 
> needs yet to be 
> discussed and finalized. The document is providing information on the 
> history, explaining the need for a generic solution as well as is discussing 
> different scenarios. 
> As such I believe the datastore solution proposal from the DT should be 
> published with the intended status Informational RFC.

I would like to recommend to change the intended status of the draft 
accordingly.

Thanks,
Mehmet

-Original Message-
From: Lou Berger [mailto:lber...@labn.net] 
Sent: Monday, December 19, 2016 2:34 PM
To: NetMod WG ; NetConf WG 
Cc: NetMod WG Chairs ; NetConf WG Chairs 

Subject: Re: WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

All,

This poll is closed and this document is adopted in the NETMOD WG.

There have been many good topics raised during the call adoption call that we 
will work through. Kent and I are already working on a draft of the updated 
charter.

Authors,

Please resubmit your draft with the new name
draft-nmdsdt-netmod-revised-datastores-00 and with that and the date being the 
only change.

Please consider how you want to track and resolve the topics/issues raised 
during the adoption call.  WG trac and github issue tracker are available to 
you.  Please also set a topic-specific Subject line in any list followup. 

-- Draft specific discussion can now be limited to just the netmod list.

Thank you!
Lou

On 12/2/2016 4:26 PM, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-nmdsdt-netmod-revised-datastores-00 a NetMod working group 
> document.  This document is unusual in that WG last call will be 
> jointly held in both the NetConf and NetMod WGs, while adoption and 
> day-to-day processing will take place in NetMod.
>
> Please send email to the list indicating "yes/support" or "no/do not 
> support".  If indicating no, please state your reservations with the 
> document.  If yes, please also feel free to provide comments you'd 
> like to see addressed once the document is a WG document.
>
> The poll ends December 16.
>
> Thank you,
> NetConf and NetMod WG Chairs
>
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Mehmet Ersue]

Technically spoken actually both options work for me: 

Keeping current concept in 6241 or having everything in one document.

I prefer the latter.

 

We actually don’t want to remove , only solve issues.

Any change to  is for sure subject to WG decision.

 

Mehmet

 

From: Andy Bierman [mailto:a...@yumaworks.com] 
Sent: Tuesday, December 13, 2016 10:52 PM
To: Mehmet Ersue 
Cc: Eric Voit (evoit) ; Ladislav Lhotka ; 
NetMod WG Chairs ; NetConf WG Chairs 
; NetMod WG ; Netconf 

Subject: Re: [netmod] [Netconf] WG adoption poll 
draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue mailto:mer...@gmail.com> > wrote:

Hi Andy,

 

> This architectural change needs to be implemented in various protocols.

> I am not sure a 6241bis is the best approach because it is not clear which

> servers really need to implement the revised datastores.  

 

I agree fully. This is the reason why I wrote in my mail:

 

>> - a new protocol- and language-independent standard document (RFC XYZ) 
>> defining the generic datastore concept and framework and describing its use 
>> (based on and following the DT solution draft),

>> - a RFC6241bis draft removing the current datasore concept specification, 
>> and getting rid of well-known issues e.g. with the  operation,

 

I do not agree with the text you wrote.

I do not want to remove candidate, running, and startup from RFC 6241.

IMO the new datastores can be defined in a new document that does not redefine 
the existing datastores.

 

I also do not want to get rid of ,  It works as intended.

It is not a problem on small devices.  It is not a problem on large devices if

sufficient filtering is used.  It does not differentiate between intended and 
applied config

or understand different types of config=false nodes.  Use a new operation to

add these features.

 

 

 

 

 

Mehmet

 

 

Andy

 

 

 

From: Andy Bierman [mailto:a...@yumaworks.com <mailto:a...@yumaworks.com> ] 
Sent: Dienstag, 13. Dezember 2016 18:38
To: Eric Voit (evoit) mailto:ev...@cisco.com> >
Cc: Ladislav Lhotka mailto:lho...@nic.cz> >; MehmetErsue 
mailto:mer...@gmail.com> >; NetMod WG Chairs 
mailto:netmod-cha...@ietf.org> >; NetConf WG Chairs 
mailto:netconf-cha...@ietf.org> >; NetMod WG 
mailto:netmod@ietf.org> >; Netconf mailto:netc...@ietf.org> >
Subject: Re: [netmod] [Netconf] WG adoption poll 
draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) mailto:ev...@cisco.com> > wrote:

I support adoption, and like Mehmet's thinking as well.

Also worth focusing on is transport protocol independent yang filtering.  So 
along with how to frame get operations against one of the datastores, how do 
you know which subtrees/nodes should be included/excluded.

 

 

This architectural change needs to be implemented in various protocols.

I am not sure a 6241bis is the best approach because it is not clear which

servers really need to implement the revised datastores.  Since RD is purely 
optional

to implement, it should not obsolete 6241 in any way.  It should be possible

to add new operations and/or new parameters to existing operations without

needing to redefine what is already there.

 

The new protocol features need to explain how to include/exclude subtrees.

IMO we should only support YANG defined data.  This allows the solutions

to be generalized and reusable across protocols (e.g., using YANG extensions).

 

 

Eric

 

 

Andy

 


> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Mehmet,
>
> I think I could just sign your text at the bottom.
>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsue  > <mailto:mer...@gmail.com> > wrote:
> >
> > Hi All,
> >
> > I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt 
> > and
> finalize the DT draft in NETMOD WG, which I still support.
> >
> > I believe the bigger issue is to agree on a plan concerning the related work
> and the re-organization of existing standards. As a matter of fact this plan 
> will
> lead to updating the charter of two WGs and the work we are going to start.
> >
> > I see the DT document as a datastore solution proposal. There are different
> gaps and issues which still need to be addressed and the solution proposal
> needs yet to be discussed and finalized. The document is providing information
> on the history, explaining the need for a generic solution as well as is 
> discussing
> different scenarios. As such I believe the datastore solution proposal from 
> the
> DT should be published with the intended status Informational RFC.
> >
> > Based on the finalized and agreed datastore solution we should do different
> updates to existing documents in NETCONF and

Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Mehmet Ersue]

Hi Andy,

 

> This architectural change needs to be implemented in various protocols.

> I am not sure a 6241bis is the best approach because it is not clear which

> servers really need to implement the revised datastores.  

 

I agree fully. This is the reason why I wrote in my mail:

 

>> - a new protocol- and language-independent standard document (RFC XYZ) 
>> defining the generic datastore concept and framework and describing its use 
>> (based on and following the DT solution draft),

>> - a RFC6241bis draft removing the current datasore concept specification, 
>> and getting rid of well-known issues e.g. with the  operation,



Mehmet

 

From: Andy Bierman [mailto:a...@yumaworks.com] 
Sent: Dienstag, 13. Dezember 2016 18:38
To: Eric Voit (evoit) 
Cc: Ladislav Lhotka ; MehmetErsue ; NetMod WG 
Chairs ; NetConf WG Chairs ; 
NetMod WG ; Netconf 
Subject: Re: [netmod] [Netconf] WG adoption poll 
draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) mailto:ev...@cisco.com> > wrote:

I support adoption, and like Mehmet's thinking as well.

Also worth focusing on is transport protocol independent yang filtering.  So 
along with how to frame get operations against one of the datastores, how do 
you know which subtrees/nodes should be included/excluded.

 

 

This architectural change needs to be implemented in various protocols.

I am not sure a 6241bis is the best approach because it is not clear which

servers really need to implement the revised datastores.  Since RD is purely 
optional

to implement, it should not obsolete 6241 in any way.  It should be possible

to add new operations and/or new parameters to existing operations without

needing to redefine what is already there.

 

The new protocol features need to explain how to include/exclude subtrees.

IMO we should only support YANG defined data.  This allows the solutions

to be generalized and reusable across protocols (e.g., using YANG extensions).

 

 

Eric

 

 

Andy

 


> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Mehmet,
>
> I think I could just sign your text at the bottom.
>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsue  >  > wrote:
> >
> > Hi All,
> >
> > I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt 
> > and
> finalize the DT draft in NETMOD WG, which I still support.
> >
> > I believe the bigger issue is to agree on a plan concerning the related work
> and the re-organization of existing standards. As a matter of fact this plan 
> will
> lead to updating the charter of two WGs and the work we are going to start.
> >
> > I see the DT document as a datastore solution proposal. There are different
> gaps and issues which still need to be addressed and the solution proposal
> needs yet to be discussed and finalized. The document is providing information
> on the history, explaining the need for a generic solution as well as is 
> discussing
> different scenarios. As such I believe the datastore solution proposal from 
> the
> DT should be published with the intended status Informational RFC.
> >
> > Based on the finalized and agreed datastore solution we should do different
> updates to existing documents in NETCONF and NETMOD WGs. With this
> action we can also fix well-known issues.
> >
> > Concerning the NETCONF WG I would see it as valuable if we develop:
> > - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the
> >  operation,
> > - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing
> > its use (based on and following the DT solution draft),
> > - adding potential extensions to RFC6241bis (following the DT draft
> > and with a normative reference to RFC XYZ),
> > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > draft and with a normative reference to RFC XYZ),
> >
> > Concerning the NETMOD WG I would see it as valuable if we develop:
> > - RFC7950bis deleting protocol-dependent details and specifying the
> > datastore usage with YANG on a generic level (with a normative
> > reference to RFC XYZ),
> > - adding potential extensions to RFC7950bis, e.g. concerning the
> > proposed  element,
> > - possibly an RFC 6244bis to describe architectural aspects. However RFC6244
> is Informational and a RFC6244bis would be still Informational. I'm not sure
> whether this is really necessary. The DT proposal does already describe such a
> solution and can be seen as an update to RFC 6244.
> > - RFC6087bis giving guidelines on how to use YANG with the new datastore
> concept.
> >
> > Referring to Lada's proposal concerning the spin off document from
> > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> provided in the corresponding protocol RFCs, i.e.
> > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and