Subject: Re: [netmod] draft netmod charter update proposal

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Mar 2017 09:06:26 +0100

On Tue, Feb 28, 2017 at 11:41:35PM +0000, Kent Watsen wrote:
> 
> Hi NETMOD WG,
> 
> Please find below draft-2 having the following changes:
>  - clarified responsibility 'c'
>  - s/encoding/representation/g
>  - moved intf-ext-yang from Oct to Dec
>

So are we going through all NETMOD/NETCONF documents now to replace
'encoding' with 'representation', which also includes changing
document titles? I am not necessarily against that change but I think
it is good to understand the implications that go well beyond some
charter text. (I did do my own analysis how frequently we have used
encoding in our documents, I assume others have done this as well.)

/js

PS: RFC 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. August 2016.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 1 Mar 2017 09:32:37 +0100

> On 1 Mar 2017, at 09:06, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I don't think it is necessary to immediately update old RFCs with this new term. I do think though it is important to stop using "encoding". People have to realize that

- different representations of conceptual data/resources cannot be automatically translated to each other as the term "encoding" might suggest

- it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools).

This terminology will also help app folks understand what we are dealing with in NETCONF/NETMOD.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Mar 2017 10:46:29 +0100

> - different representations of conceptual data/resources cannot be automatically translated to each other as the term "encoding" might suggest

I do not think that encoding implies that encoding A can be converted
to encoding B nor do I think representation does not imply that
representation A can be converted into representation B.

> - it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools).

The same has always been true before as well.

> This terminology will also help app folks understand what we are dealing with in NETCONF/NETMOD.

I am not against changing terminology but I think we should make sure
that there is agreement, ideally in NETMOD and NETCONF, to adopt this
new terminology. The worst result would be if documents end up being
inconsistent in their terminology for a long period of time. So it is
also useful to consider how long the transition to a new terminology
is realistically going to be, i.e., how many documents are affected
and how much and when it is likely that they can move to a new
terminology.

In other words, if we make this change, we may consider to have this
explicitly mentioned in both charters.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 1 Mar 2017 11:45:13 +0100

> On 1 Mar 2017, at 10:46, Juergen Schoenwaelder <[email-masked]> wrote:
> 

But, if my memory serves me well, you have always insisted on being able to do the roundtrip conversion between XML and JSON (without using the data model, or in anydata). 

> The same has always been true before as well.

At one point, it looked like XML will be the mandatory "encoding" for RESTCONF, despite my fierce opposition, as if it was the the same as requiring everybody to support UTF-8. Fortunately this was eventually overturned.

> and how much and when it is likely that they can move to a new

Yes, "representation" should be one of the terms newly defined in 7950bis, and it can also be mentioned that "encoding" was used informally in the past. As far as I know, "encoding" has never been defined before in this context, so IMO no complicated transition is otherwise needed. And the fact that the term "representation" is used in this sense in related areas can only help.

> explicitly mentioned in both charters.

I don't mind although I don't think it is *that* important.

Lada

---

From: t.petch <[email-masked]>
Date: Wed, 1 Mar 2017 10:53:10 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Wednesday, March 01, 2017 9:46 AM

> > I don't think it is necessary to immediately update old RFCs with
this new term. I do think though it is important to stop using
"encoding". People have to realize that
> >
> > - different representations of conceptual data/resources cannot be
automatically translated to each other as the term "encoding" might
suggest
> representation A can be converted into representation B.

I agree.

I think that the real difference is between those working with networks
and those operating at a higher level.  Just because the terminology is
suitable for HTTP, URI and such like does not make it appropriate for
network configuration.

I would stay with encoding.

Tom Petch

> > - it is important to think about what representation to use for a
given use case (this may influence the choice of protocols and/or
tools).

---

From: Robert Wilton <[email-masked]>
Date: Wed, 1 Mar 2017 11:15:52 +0000

Hi Lada,

> Yes, "representation" should be one of the terms newly defined in 7950bis, and it can also be mentioned that "encoding" was used informally in the past. As far as I know, "encoding" has never been…
I'm not sure that I see that 'encoding' as the bad word for 
XML/JSON/CBOR etc.  Possibly 'representation' might be better, but I 
think that saying that something is 'encoded in XML' is likely to be 
well understood.

As I understand it, encoding doesn't just apply to characters, but is 
widely used in other places, such as audio, video, Ethernet (e.g. 64b/66b).

Perhaps, where appropriate, the drafts should differentiate between the 
YANG encoding for a YANG datatree vs the underlying character encoding 
that is being used.

Rob

> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 1 Mar 2017 12:29:28 +0100

> On 1 Mar 2017, at 11:53, t.petch <[email-masked]> wrote:
> 

The resource/representation concepts come (I think) from Roy Fielding's dissertation where it is explicitly mentioned that they are not specific to HTTP. Also, in my view, NETCONF/RESTCONF is a higher level than HTTP.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Mar 2017 16:56:12 +0000

Hi Lada,

I understand your intention here, but I'm inclined to agree with others
that it's better to stick with the term we're using in the documents.
I'm open to the idea of changing the term used in our RFCs, and I believe
that such a change would likely have to begin with the YANG spec, from
which it could flow into other drafts.  With this in mind, I've added an
item to the yang-next tracker:

  https://github.com/netmod-wg/yang-next/issues/17

and I plan to revert this change in the charter text.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Mar 2017 21:39:26 +0100

> But, if my memory serves me well, you have always insisted on being able to do the roundtrip conversion between XML and JSON (without using the data model, or in anydata). 

I still think this was/is desirable but it does not matter whether the
term is encoding or representation.

> At one point, it looked like XML will be the mandatory "encoding" for RESTCONF, despite my fierce opposition, as if it was the the same as requiring everybody to support UTF-8. Fortunately this was…

Again, whether something is mandatory or not does not depend on
whether it is called encoding or representation.

> I don't mind although I don't think it is *that* important.

For me, it is important that we have a plan to adopt a new terminology
everywhere. If we do not have such a plan, I am strongly in favour to
stick with terminology that so far we use consistently.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Mar 2017 21:40:08 +0100

> and I plan to revert this change in the charter text.

Kent,

there either is a decision and plan to change terminology everywhere
or this proposal is in my view a no go. Right now, we seem to use
consistent terminology everywhere - I do not want to loose this
property lightly.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 2 Mar 2017 14:47:36 +0100

> On 1 Mar 2017, at 21:40, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I agree. If nobody else wants this change, I can live with "encoding", too.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Fri, 3 Mar 2017 15:23:21 +0000

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 <[email-masked]>
   Kent Watsen <[email-masked]>

Operations and Management Area Directors:
   Benoit Claise <[email-masked]>
   Joel Jaeggli <[email-masked]>

Operations and Management Area Advisor:
   Benoit Claise <[email-masked]>

Secretary:
   Zitao (Michael) Wang <[email-masked]>

Mailing Lists:
   General Discussion: [email-masked]
   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

---

From: t.petch <[email-masked]>
Date: Mon, 6 Mar 2017 12:34:58 +0000

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

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

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

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

The sections such as

5.6.4.  Announcing Conformance Information in NETCONF

7.5.8.  NETCONF <edit-config> Operations

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

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

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

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 6 Mar 2017 15:35:18 +0100

> On 6 Mar 2017, at 13:34, t.petch <[email-masked]> wrote:
> 

Of course, examples of instance data are important but in most cases JSON would be significantly easier to read. 7950bis could also contain examples in both XML and JSON (as RFC 8040 does).

> use of whatever it is using..

7950bis should include a much more explicit definition of the conceptual data tree, and specifications for particular encodings of the data tree can be in separate documents. All these documents can IMO stay in NETMOD because they are protocol independent. Each protocol would then choose to support one or more of the encodings.

> 5.6.4.  Announcing Conformance Information in NETCONF

Yes, but I think we need a *data modelling* formalism for specifying a bundle of YANG modules (including schema mount). YANG has currently almost no support for this, so tools often use hello or yang-library data for this purpose. So I would like to have some standard metadata like this, detached from protocols and devices.

> discuss ordered-by user?  YANG is not a DDL that describes a static,

It simply means that the order of entries carries some semantics. In fact, such a property might also be useful in state data.

That said, some background context of CRUD and other operations can of course remain.

> operations are a part of the language.

As a matter of fact, almost all formal rules in YANG are about static data. Apart from "ordered-by", probably the only other exception is "config true/false", which could be generalized to the "RW/RO" property. 

> leave the encoding to a transporting protocol.

Yes, 7950bis can define appropriate error-app-tags.  

> always be performed by RPC?  Well, not necessarily!

The concept of operations/RPCs/actions and their signatures is sufficiently general, it should IMO stay in some form.

Lada

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 7 Mar 2017 15:33:47 +0100

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:[email-masked]] On Behalf Of Kent Watsen
> Sent: Friday, March 3, 2017 4:23 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 10:30:07 -0500

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:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, February 22, 2017 7:25 PM
To: [email-masked]
Cc: [email-masked]
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)

Charter

Current Status: Active

Chairs:

Secretary:

Mailing Lists:

   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.

   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.

      new encodings that are needed and yet do not fall under the charter

Milestones:
  
   Done     - Submit draft-ietf-netmod-rfc6087bis to IESG for publication
   Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG
              for publication
   Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for publication
   Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication
   Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication
   Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang 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-sub-intf-vlan-yang to IESG for
              publication

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 7 Mar 2017 18:21:27 +0100

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

> From: netmod [mailto:[email-masked]] On Behalf Of Susan Hares
> Sent: Tuesday, March 7, 2017 4:30 PM
> To: 'Kent Watsen' <[email-masked]>; [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 13:27:28 -0500

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:[email-masked]] 
Sent: Tuesday, March 7, 2017 12:21 PM
To: 'Susan Hares'; 'Kent Watsen'; [email-masked]
Cc: [email-masked]
Subject: RE: [netmod] draft netmod charter update proposal

Hi Sue,

BR,
Mehmet

> Does c) and d) include additions to include I2RS ephemeral state as 
> part
of
> 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)
> 
> 
> 
>

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 7 Mar 2017 21:26:46 +0100

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

> From: Susan Hares [mailto:[email-masked]]
> Sent: Tuesday, March 7, 2017 7:27 PM
> To: 'Mehmet Ersue' <[email-masked]>; 'Kent Watsen'
> <[email-masked]>; [email-masked]
draft-ietf-netmod-yang-
> model-classification [netmod]
datastores in
> which a module exists
prioritization
> config data store. [netmod]
the
> configuration data store.
> 
plane
> data store.
> AFAICS your question kind of mixes between "I2RS control plane protocol"
> and "ephemeral additions to Yang".
> Can you please differentiate in your question between the aspects below
> (my assumption in [ ]?

---

From: Kent Watsen <[email-masked]>
Date: Wed, 8 Mar 2017 00:51:25 +0000

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

Cheers,
Mehmet

draft-ietf-netmod-yang-
datastores in
prioritization
the
plane

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Mar 2017 10:27:05 -0500

Kent: 

Would it be possible to publish a version of this draft by Thursday so that the I2RS drafts with changes can align with this new version of the revised-datastores draft? 

Sue 

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 7:51 PM
To: Mehmet Ersue; 'Susan Hares'; [email-masked]
Cc: [email-masked]
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:

> 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

> 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]
> To provide precision on this point, I will give examples of work 
> related
to
draft-ietf-netmod-yang-
datastores in
prioritization
> 3) generic extensions to describe ephemeral state the I2RS control 
> plane datastore  [I2RS]
>      a) extensions can define validation specific to I2RS control 
> plane datastore.
the
plane
> Can you please differentiate in your question between the aspects 
> below (my assumption in [ ]?
> to enable the usage of DS [protocol WGs, e.g. I2RS]
> > 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)
> >
> >
> >
> >
> >    NETMOD working group addresses general topics related to the use 
> > of
> the
> >       ietf-inet-types) as needed, as well as defining additional 
> > core
YANG

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 8 Mar 2017 17:00:46 +0100

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

> Sent: Wednesday, March 8, 2017 1:51 AM
> To: Mehmet Ersue <[email-masked]>; 'Susan Hares'
> <[email-masked]>; [email-masked]
> 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
> 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).
> 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
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Mar 2017 11:03:11 -0500

Sounds like a great idea!

Sue 

-----Original Message-----
From: Mehmet Ersue [mailto:[email-masked]] 
Sent: Wednesday, March 8, 2017 11:01 AM
To: 'Kent Watsen'; 'Susan Hares'; [email-masked]
Cc: [email-masked]
Subject: RE: [netmod] draft netmod charter update proposal

Does this make sense?

Mehmet

> outlining the creation of an "ephemeral" datastore.  The idea is to 
> give the I2RS WG the ability to define
> datastore(s) as needed
> 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
> 
> 
> > (b) - related to protocol extension for I2RS for RESTCONF, NETCONF 
> > or
> CoAP.
> > I have removed that one.
> >
> > 2) generic extensions to Yang to describe control plane datastore 
> > yang modules - [netmod]
> > b) standard extensions to the protocol (e.g. I2RS or 
> > NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g. 
> > I2RS]
> > > as part
> > > 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)
> > >
> > >
> > >
> > >
> > >    NETMOD working group addresses general topics related to the 
> > > use of
> > the
> > >    defines core YANG models used as basic YANG building blocks, 
> > > and
> YANG
> > >       updating encodings already defined by the NETMOD working 
> > > (XML
> and
> > >    The NETMOD working group consults with the NETCONF working 
> > > group
> to

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Mar 2017 13:18:10 -0500

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 8 Mar 2017 18:44:35 +0000

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

Charter

Current Status: Active

Chairs:

Secretary:

Mailing Lists:

  

   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.

Milestones:

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 8 Mar 2017 22:25:00 +0100

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

> From: Lou Berger [mailto:[email-masked]]
> Sent: Wednesday, March 8, 2017 7:18 PM
> To: Mehmet Ersue <[email-masked]>; 'Kent Watsen'
> <[email-masked]>; 'Susan Hares' <[email-masked]>;
> [email-masked]
> 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
> 
> 
> > 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
> >
> >> (likely on Wed morning) that could be used to discuss I2RS some, and
> >> I also plan on attending the I2RS meeting Wed afternoon.
> >>
> >> Kent
> >>
> >>
> NETCONF/RESTCONF)
> >>>>    YANG language and YANG models, for example, the mapping of
> YANG
> >>>> modeled

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 8 Mar 2017 22:47:27 +0100

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

> Sent: Wednesday, March 8, 2017 7:45 PM
> To: [email-masked]
> 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?
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.

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Mar 2017 16:49:47 -0500

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

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 9 Mar 2017 19:33:30 +0100

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:[email-masked]] 
Sent: Wednesday, March 8, 2017 10:50 PM
To: Mehmet Ersue <[email-masked]>; 'Kent Watsen' <[email-masked]>; 'Susan Hares' <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Benoit Claise' <[email-masked]>; 'Mahesh Jethanandani' <[email-masked]>
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:
>> 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
>>
>>
>> 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"
>>>> 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
>>>> that it's too late to add such a session to the IETF Agenda at this point.
>>>> (likely on Wed morning) that could be used to discuss I2RS some, 
>>>> and I also plan on attending the I2RS meeting Wed afternoon.
>>>>
>>>> Kent
>>>>
>>>>
>>>>>    c) extension to describe the merged tree in applied datastore 
>>>>> and
>>>> opstate
>>>>> datastore  [netmod]
>>>>>>    b) Maintaining the guidelines for developing YANG models.  
>>>>>> This
>>>> effort
>>>>>>    requirements and, when needed, which group will run the 
>>>>>> process on
>> a
>>>>>>    specific model.
>>>>>>
>>>>>>    Mar 2016 - Submit draft-ietf-netmod-yang-model-classification 
>>>>>> to
>> IESG
>>>>>>               for publication

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 9 Mar 2017 19:36:08 +0100

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.

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

> Sent: Wednesday, March 8, 2017 11:28 PM
> 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
> I'm sorry, I don't understand this last sentence can you rephrase it?
> 
> > 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.
> 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
> >
> >> existing a),

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 15 Mar 2017 14:50:06 +0100

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

> From: Mehmet Ersue
> Sent: Thursday, March 9, 2017 7:36 PM
> To: Lou Berger <[email-masked]>; 'Kent Watsen' <[email-masked]>;
> [email-masked]
> Cc: 'Benoit Claise' <[email-masked]>; 'Mahesh Jethanandani'
> <[email-masked]>
> > The charters from the last couple of years don't have the intended
status --
> > 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.
> 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.
> 
> > 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:
> > 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
> > 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.
> >
> > 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:
> > >> 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),
> > >>    Archive:
https://mailarchive.ietf.org/arch/browse/netmod/

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Mar 2017 18:59:02 -0400

Mehmet,

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

> match to the high-level WG focus topics in a)-f). I was thinking my proposal
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?

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

> protocol WGs. 

okay.

> This is as I think also important to avoid an overlapping

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?

> maillist and therefor skip sending to both ML.

Great.

Thanks.
Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 07:44:19 +0100

> 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

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Mar 2017 07:27:34 -0400

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.

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 16 Mar 2017 19:24:15 +0100

Lou,

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

> >> To: Lou Berger <[email-masked]>; 'Kent Watsen'
> >>> sufficiently
> >>>> It would be good to bring the high-level topics in relation to the
> >>>> WG
> >> items.
> >> 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.
> >>
> >>> 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:
> >>>>> we understand that this is how NETCONF charters are structured,
> >>>>> but it is not our practice,
> >>>> It would be good to bring the high-level topics in relation to the
> >>>> WG
> >> items.
> >>>> I believe a WG charter should be self-sufficient covering the
> >>>> target definition and intended status of the WG items.
> >>> 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:
> >>>>> 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),
> >>>>>    data modeling language, and guidelines for developing YANG
> models.
> >>> The
> >>>>>    also defines core YANG models used as basic YANG building
> >>>>> blocks,
> >> and
> >>>>>       effort entails updating existing YANG models
> >>>>> (ietf-yang-types
> > and
> >>>>>    Mar 2017 - Submit draft-ietf-netmod-yang-model-classification
> >>>>> to
> > IESG
> >>>>>               for publication

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Mar 2017 17:51:59 -0400

Mehmet,
   see below.
> 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'm not sure whether your "okay" means the same as I meant.
it meant, "Okay, I heard you."  I've already responded to this comment
multiple times so didn't think it would add anything to say it again.

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

> standardize, which at the end would prescribe protocol WGs what they should

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.

> situation with protocol WG's goals and documents and cannot be adopted

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?

Thanks,

Lou

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 16 Mar 2017 23:58:44 +0100

> On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
. . . 
> > 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.
> 
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.
> 
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. 
 
> >> 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?
> > 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.
> 
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.
> 
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.

> >>>> mature, leads to process-focused arguments that detracts from
> >>>> making technical progress.  While once a document is mature and
> >>>>>> It would be good to bring the high-level topics in relation to
> >>>>>> the WG
> >>>> items.
> >>>> 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.
> >>>>
> >>>>> 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
> >>>>> While once a document is mature and core direction/content is
> >>>>> fixed, it is generally obvious what status is appropriate.
> >>>>>
> >>>>>
> >>>>>> I did not ask
> >>>>>> It would be good to bring the high-level topics in relation to
> >>>>>> the WG
> >>>> items.
> >>>>>> Otherwise one can change the target for a WG item by simply
> >>>>>> editing the draft abstract anytime.
> >>>>> 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
> >>>>>>> From: netmod [mailto:[email-masked]] On Behalf Of
> Kent
> >>>>>>> Watsen
> >>>>>>>    To Subscribe:
> >>>>>>>    YANG models that do not otherwise fall under the charter of
> >>>>>>> any
> >>> other
> >>>>>>>    IETF working group.
> >>>>>>>
> >>>>>>>    c) Maintaining a conceptual framework in which YANG models
> >>>>>>> are
> >>>> used.
> >>>>>>>       JSON) to accommodate changes to the YANG specification,
> >>>>>>> and
> >>>>> defining
> >>>>>>>       new encodings that are needed, and yet do not fall under
> >>>>>>> the
> >>> charter
> >>>>>>>    f) Defining and maintaining YANG models that do not fall
> >>>>>>> under
> > the
> >>>>>>>    group.  The NETMOD working group coordinates with other
> >>>>>>> working
> >>>>> groups
> >>>>>>>    Oct 2017 - Submit draft-ietf-netmod-revised-datastores to
> >>>>>>> IESG
> > for
> >>>>>>>               publication
> >>>>>>>    Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to
> >>>>>>> IESG
> > for
> >>>>>>>               publication
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>

---

From: "Mehmet Ersue" <[email-masked]>
Date: Fri, 17 Mar 2017 14:22:43 +0100

I think YANG identities should be standardized with 7950bis.

Mehmet

> Sent: Thursday, March 16, 2017 12:28 PM
> To: Juergen Schoenwaelder <[email-masked]>;
> Mehmet Ersue <[email-masked]>
> Cc: 'Kent Watsen' <[email-masked]>; [email-masked]
> an

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Mar 2017 15:02:19 +0100

> I think YANG identities should be standardized with 7950bis.

Why? These identities are not specific to the YANG language itself.

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 17 Mar 2017 14:04:26 +0000

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Mar 2017 15:32:10 +0100

> On 17 Mar 2017, at 15:04, Robert Wilton <[email-masked]> wrote:
> 
> Hi,
> 
> Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores?

My idea is that 7950bis should be made independent of any particular set of datastores, so such a normative reference shouldn't be needed.

Lada

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 17 Mar 2017 14:46:42 +0000

> My idea is that 7950bis should be made independent of any particular set of datastores, so such a normative reference shouldn't be needed.
OK, if 70590bis was entirely datastore agnostic, then there would need 
to be a description of how YANG applies to a particular set of 
datastores (in particular the config: true|false statement), and which 
datastores are validated.  Would that go in the revised datastores 
architecture or somewhere else?  It wouldn't make sense to have to 
repeat this for every network configuration protocol.

Thanks,
Rob

---

From: "Mehmet Ersue" <[email-masked]>
Date: Fri, 17 Mar 2017 15:48:21 +0100

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

> From: Robert Wilton [mailto:[email-masked]]
> Sent: Friday, March 17, 2017 3:04 PM
> To: Mehmet Ersue <[email-masked]>; 'Lou Berger' <[email-masked]>;
> 'Juergen Schoenwaelder' <[email-masked]>
> Cc: [email-masked]
required to
> support the revised datastores draft) then does that mean we would also
> need to have a new version of YANG?
> 
mean
> for an implementation that is aware of the new datastores but is using a
mix
> of YANG modules with different versions?
> 
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.
> 
> >> 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.
> >>
> >>
> >>
> >>
> >>>> That said different people including Netconf WG co-chairs think the
> >>>> DS concept document is Informational in nature and should be
> >>>> published as
> >> an
> >>>> 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
> >>>
> >>> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Mar 2017 16:33:24 +0100

> On 17 Mar 2017, at 15:46, Robert Wilton <[email-masked]> wrote:
> 
> 
> 
> OK, if 70590bis was entirely datastore agnostic, then there would need to be a description of how YANG applies to a particular set of datastores (in particular the config: true|false statement), and which datastores are validated.  Would that go in the revised

I don't think that config true/false is necessarily tied to a particular set of datastores, it can be generalized to RW/RO.

>  datastores architecture or somewhere else?  It wouldn't make sense to have to repeat this for every network configuration protocol.

I think the structure of datastores and validation workflow could be supplied as extra info, see item #3 near the end of this message:

https://www.ietf.org/mail-archive/web/netmod/current/msg17673.html

Lada

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Mar 2017 15:40:07 +0000

Hi Lada,

I think some of what you're getting at is in these guidelines:

  https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01#section-5

But you're thinking about something more generalized?

Kent  // contributor

-----ORIGINAL MESSAGE-----

Lada

---

From: t.petch <[email-masked]>
Date: Fri, 17 Mar 2017 16:57:24 +0000

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Robert Wilton" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 17, 2017 2:32 PM
>
> My idea is that 7950bis should be made independent of any particular
set of datastores, so such a normative reference shouldn't be needed.

Lada

You say 'set of datastores' which I would agree with but I would propose
that the concept of a datastore, which could be a different term, just
semantically equivalent to that of 'datastore', is still needed for
validation.  The scope of validation is a closed set of data and the
current term for that is datastore (as opposed to module, model or any
other unit of data)..

Tom Petch

>
> Lada
>
> >
> > 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?
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.
> >>> Thank you for the input.  I think your point highlights how the
technical
> >>> PS as a reminder to all, intended status of documents is *not*
typically
> >>>>> protocol WGs. This is as I think also important to avoid an
overlapping
> >>>> The current datastore draft includes concrete YANG idenity
definitions

---

From: Robert Wilton <[email-masked]>
Date: Fri, 17 Mar 2017 17:19:40 +0000

> NETCONF uses a different datastore framework compared to RESTCONF.
Sure.  But there should still be *definitive* references of what those 
datastores mean.  Where should the definitive reference for the 
"intended" and "operational" datastores go?

> Such a concept providing the basis for many environments cannot be
Why not?

> conceptual model and standardize the usage of these DSs as part of the
OK.  But where is the definitive reference to those datastores. Having 
it is an "Informational" draft would seem to be a wrong.

Thanks,
Rob

---

From: t.petch <[email-masked]>
Date: Fri, 17 Mar 2017 17:24:59 +0000

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Friday, March 17, 2017 2:04 PM
> Informational RFC that defined the YANG datastores?

No but yes but ...

The rules say no but the exception is that the IESG can approve such a
downref (and other kinds of downref) after which it is listed as an
approved downref, on the IETF website, so the process need only be
performed once for a given target RFC for a given type of downref.

That said, I think that the rule is sound, and the question of why an
Informational RFC should be suitable for a Normative Reference should be
asked, at least once.  Originally it meant that there was no need to
reissue an historic RFC to upgrade its status to be what it probably
should have been in the first place but now the process is far more
widely used.

And I think that revised datastores should be Standards Track!  The
SNMPv3 Architecture is INTERNET STANDARD which is the kind of model that
I have in mind.

Tom Petch

on.
technical
typically
overlapping
definitions

---

From: "Mehmet Ersue" <[email-masked]>
Date: Fri, 17 Mar 2017 23:51:17 +0100

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<This work is planned to address with a 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<This 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<The
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 WG will finalize ongoing 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,
Mehmet

> Sent: Thursday, March 16, 2017 11:59 PM
> > From: Lou Berger [mailto:[email-masked]] Mehmet,
> >    see below.
> > > 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.
> > 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.
> >
> > > Based on this the conceptual framework cannot be standardized as it
> > > is but the protocols using a consistent subset have to be
standardized.
> > 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.
in
> nature and is not relevant for standardization.
> 
> > >> 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.
over.
> > > competing situation with protocol WG's goals and documents and
> > > cannot be adopted successfully.
> >
> > 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?
> 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,
> >
> > Lou
> >
> > > Thanks,
> > > Mehmet
> > >
> > >>>>> 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
definition.
> > >>>>> 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:
> > >>>> I am actually raising this point since November meeting. There
> > >>>> are
> > >>> different
> > >>>>>>> we understand that this is how NETCONF charters are
> > >>>>>>> structured, but it is not our practice,
> > >>>>> 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
> > >>>>> 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:
> > >>>>>>> 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.
> > >>>>>>>    NETMOD working group addresses general topics related to
> > >>>>>>> the use of
> > >>>>> the
> > >>>>>>>    a) Maintaining the data modeling language YANG.  This
> > >>>>>>> effort
> > >>> entails
> > >>>>>>>       This effort entails describing the generic context that
> > >>>>>>> in
> > > YANG
> > >>>>>>>    d) Maintaining encodings for YANG modeled data.  This
> > >>>>>>> effort
> > >>> entails
> > >>>>>>>    e) Maintaining YANG models used as basic YANG building
> blocks.
> > >>> This
> > >>>>>>>       ietf-inet-types) as needed, as well as defining
> > >>>>>>> additional core
> > >>> YANG
> > >>>>>>>    ensure that new requirements are understood and can be met
> > >>>>>>> by
> > >> the
> > >>>>>>>    protocols (e.g., NETCONF and RESTCONF) developed within
> > >>>>>>> that
> > >>>> working
> > >>>>>>>    (e.g., I2RS, RTGWG) on possible extensions to YANG to
> > >>>>>>> address
> > new
> > >>>>>>>    modeling requirements and, when needed, which group will
> > >>>>>>> run
> > the
> > >>>>>>>    The NETMOD working group does not serve as a review team
> > >>>>>>> for
> > >>>> YANG
> > >>>>>>>    modules developed by other working groups. Instead, the
> > >>>>>>> YANG
> > >>>>> doctors,
> > >>>>>>>    management, will act as advisors for other working groups
> > >>>>>>> and
> > >>> provide
> > >>>>>>>    Mar 2017 - Submit
> > >>>>>>> draft-ietf-netmod-yang-model-classification
> > >>>>>>> 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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Mar 2017 12:05:33 +0100

> consistent terminology everywhere - I do not want to loose this
This consistency is an important feature of our documents set IMO.
And adding a sentence, somewhere, sometime, is easy: "the term encoding 
is also known as representation or serialization"

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Mar 2017 12:09:00 +0100

Lou,

In all my WGs, we consistently documented the intended status in the 
milestones, expressing the _intended _status at the time of the charter 
discussion

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Mar 2017 13:49:04 +0100

> But you're thinking about something more generalized?

Most likely yes - what I have in mind is something like datastore
modelling mini-language. To some extent, NETCONF already does this via
capabilities: server implementors can choose and advertize different variants of
running-candidate-startup organization.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Mar 2017 13:58:17 +0100

> current term for that is datastore (as opposed to module, model or any

Agreed, but I would suggest "data tree" as the subject of
validation. Something more general than datastore is probably needed
because already in RFC 7950 the tree that is validated sometimes
consists of multiple (two) datastores and/or payloads of operations or
notifications.

Lada

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Mar 2017 15:00:05 -0400

Kent and Lada: 
<individual contributor hat on> 

I agree that we need some parameters in yang.  I agree with version 1 of the
revised datastores.   

In my proposal regarding I2RS Yang, I tried to start suggesting some
parameters for control plane datastores, and ephemeral control plane
datastores.   In this I also suggest a "validation" key word that will
provide additional validation sequences for the control plane datastores.
There may be better ways to do this in Yang, but I hope it is a start. 

https://datatracker.ietf.org/doc/draft-hares-i2nsf-capability-yang/

If we start with this yang, I thought it made the capabilities easier to
define for NETCONF and RESTCONF.
https://datatracker.ietf.org/doc/draft-hares-netconf-i2rs-netconf/

I welcome any change or fixes.  I tried to make things concrete so it would
help the discussion. 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Friday, March 17, 2017 11:40 AM
To: Ladislav Lhotka; Robert Wilton
Cc: [email-masked]
Subject: Re: [netmod] draft netmod charter update proposal

Hi Lada,

https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01#section-
5

Kent  // contributor

-----ORIGINAL MESSAGE-----

>> My idea is that 7950bis should be made independent of any particular set
of datastores, so such a normative reference shouldn't be needed.
> datastores are validated.  Would that go in the revised

I don't think that config true/false is necessarily tied to a particular set
of datastores, it can be generalized to RW/RO.

>  datastores architecture or somewhere else?  It wouldn't make sense to
have to repeat this for every network configuration protocol.

I think the structure of datastores and validation workflow could be
supplied as extra info, see item #3 near the end of this message:

Lada

>>> 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.
document.
version.
>>>>>>> That said different people including Netconf WG co-chairs think 
>>>>>>> the DS concept document is Informational in nature and should be 
>>>>>>> published as
>>>>> an
>>>>>> definitions for datastores and origins and these definitions 
>>>>>> better be standards track.
>>>>>> 
>>>>>> /js
>>>>>> 
>>>>>> --

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 Mar 2017 22:44:57 -0400

Benoit,

Okay - we'll add the intended status to the milestones. 

Lou

On 3/20/2017 7:09 AM, Benoit Claise wrote:
> milestones, expressing the _intended _status at the time of the
> charter discussion
>
> Regards, Benoit
>> Juergen,
>>
>> typically included in charters and are not included in the
>> distributed version.
>>
>>
>>
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 09:04:23 +0100

> I don't think that config true/false is necessarily tied to a particular set of datastores, it can be generalized to RW/RO.

I do not agree that config true/false just means read write and I
certainly do not want semantics of statements to be changed. It is
easy to create new statements if needed.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Mar 2017 10:13:40 +0100

> On 21 Mar 2017, at 09:04, Juergen Schoenwaelder <[email-masked]> wrote:
> 

The revised-datastores draft changes the semantics of "configuration data" - for example, the definition from RFC 6241 clearly won't apply to the "running" datastore in the new datastore model. So a new definition of configuration data will probably be needed, and this implicitly changes the semantics of the "config" statement.

BTW, we use rw/ro in tree diagrams.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 10:43:13 +0100

On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote:
> 
> The revised-datastores draft changes the semantics of "configuration data" - for example, the definition from RFC 6241 clearly won't apply to the "running" datastore in the new datastore model.

Why would that be the case?

> So a new definition of configuration data will probably be needed, and this implicitly changes the semantics of the "config" statement.
>

YANG defines the config statement as follows:

   The "config" statement takes as an argument the string "true" or
   "false".  If "config" is "true", the definition represents
   configuration.  Data nodes representing configuration are part of
   configuration datastores.

I do not think it is the intend of the revised datastore model as
written down in the I-D to change this.

> BTW, we use rw/ro in tree diagrams.

Which is a mis-nomer (tree diagrams were inherited from the SNMP world
and somehow the rw/ro distinction was kept even though it is
technically wrong). There are more details here, I will start a
separate thread for this.

Note that the diagrams in the revised datastore ID make a clear
distinction between ct/cf and rw/ro. In particular, the ID notes that
ct object may be rw in one datastore but ro in a different datastore.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Mar 2017 10:59:11 +0100

> On 21 Mar 2017, at 10:43, Juergen Schoenwaelder <[email-masked]> wrote:
> 

RFC 6241:

   o  configuration data: The set of writable data that is required to
      transform a system from its initial default state into its current
      state.

If I understand revised-datastores correctly, this will no more be the case for "running" because it may contain intermediate data that require further processing (templates) and inactive data that are not used for changing the device state.

This may look like nit-picking but the fact is that we often use the term configuration in the sense "you know it when you see it". 

>   configuration datastores.

If the "config" statement really carried some protocol-specific semantics that isn't meaningful for all potential uses of YANG, it would be better to remove it from core YANG and define it as an extension that would be mandatory for configuration protocols that need it.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Mar 2017 11:00:39 +0100 (CET)

> certainly do not want semantics of statements to be changed.

+1

[...]

> technically wrong).

Correct.  Nowadays we are using ct vs. cf, so maybe we should use that
in the trees.  rw vs ro works better visually though - "t" and "f"
look fairly similar.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 21 Mar 2017 10:04:27 +0000

> in the trees.  rw vs ro works better visually though - "t" and "f"
Perhaps only mark the config false nodes?  I.e. if it isn't specified it 
is config true.

Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Mar 2017 11:09:12 +0100

> On 21 Mar 2017, at 11:04, Robert Wilton <[email-masked]> wrote:
> 
> 
> 
> Perhaps only mark the config false nodes?  I.e. if it isn't specified it is config true.

And what about operations and notifications? Tree diagrams show "ro" but config true/false doesn't really make sense for them.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Mar 2017 11:30:39 +0100

> If the "config" statement really carried some protocol-specific semantics that isn't meaningful for all potential uses of YANG, it would be better to remove it from core YANG and define it as an ex…

YANG exists because we wanted to describe and manage configurations. And
some people still want to do this. I understand that you want to turn YANG
into a general purpose data modeling language. But I am not sure this is
consensus. As of today, config true means what is defined in RFC 6020
and RFC 7950.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Mar 2017 11:44:15 +0100

> On 21 Mar 2017, at 11:30, Juergen Schoenwaelder <[email-masked]> wrote:
> 

... and operations and notifications where config true/false is already meaningless.

> into a general purpose data modeling language. But I am not sure this is

In reality, YANG has already been used as such quite a few times (not by me), mainly because it can define a schema of tree-like data in a representation-independent way, and there is no adequate substitute. Doing so in the current state of affairs means selectively ignoring some parts of RFC 7950, and creatively interpreting other parts. This is IMO not good.

Lada

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 09:33:18 -0400

Lada: 

As dynamic control plane datastores start-up, these will need to go from an
initial state to a "current state".   I2RS ephemeral dynamic control plane
datastores will have a model that comes up in a limited mode with the I2RS
agent's configuration.  The rest of the configuration will be update from a
client over the network.  You are correct that the RFC6241 definition does
not cover this state.  The I2RS concept does cover "Config=TRUE" being the
test of configuration.   I think this is the same test that applies because
configuration data can be updated even in the configuration datastore
(intended to applied). 

Good catch on the definition. 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Tuesday, March 21, 2017 5:59 AM
To: Jürgen Schönwälder
Cc: [email-masked]
Subject: Re: [netmod] draft netmod charter update proposal

> On 21 Mar 2017, at 10:43, Juergen Schoenwaelder
<[email-masked]> wrote:
>> The revised-datastores draft changes the semantics of "configuration
data" - for example, the definition from RFC 6241 clearly won't apply to the
"running" datastore in the new datastore model.

RFC 6241:

If I understand revised-datastores correctly, this will no more be the case
for "running" because it may contain intermediate data that require further
processing (templates) and inactive data that are not used for changing the
device state.

This may look like nit-picking but the fact is that we often use the term
configuration in the sense "you know it when you see it". 

> 
>> So a new definition of configuration data will probably be needed, and
this implicitly changes the semantics of the "config" statement.
>   configuration datastores.

If the "config" statement really carried some protocol-specific semantics
that isn't meaningful for all potential uses of YANG, it would be better to
remove it from core YANG and define it as an extension that would be
mandatory for configuration protocols that need it.

Lada

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 22 Mar 2017 21:22:07 +0100

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

> Sent: Friday, March 17, 2017 11:51 PM
>       as they arise. ADD<This work is planned to address with a revision
of RFC
> 7950./>
ADD<This
> continuous effort has been recently addressed with a revision of RFC
6087./>
> mechanism to combine YANG modules into the schema defined in other
> YANG modules./>
> 
> > > > If not, you can keep the high-level focus text but set
> > > > additionally the borders of the WG item with a few concrete words.
> > >
> > > 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
> > I think the wording depends on the time period is for which the
> > charter is prepared.
> > > > 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.
> > > 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
> > 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.
> >
> > > >> 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?
> > > > attempted to standardize, which at the end would prescribe
> > > > protocol WGs what they should be standardizing.
> > >
> > This is again an interesting discussion which SHOULD be discussed in a
> > joint session.
> > > 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?
> > 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,
> > >
> > > Lou
> > >
> > > > Thanks,
> > > > Mehmet
> > > >
> > > >>>>> intended
> > > >>>>> I actually feel pretty strongly about this (which of course
> > > >>>>> can be easily overruled by our AD).  It's my experience that
> > > >>>>>> 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".
> > > >>>>> 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:
> > > >>>>> I actually feel pretty strongly about this (which of course
> > > >>>>> can be easily overruled by our AD).  It's my experience that
> > > >>>>>> 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?
> > > >>>>> 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.
> > > >>>>> 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:
> > > >>>>>>>    YANG models that do not otherwise fall under the charter
> > > >>>>>>> of any
> > > >>> other
> > > >>>>>>>    IETF working group.
> > > >>>>>>>
> > > >>>>>>>    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.
> > > >>>>>>>       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
> > > >>>>>>>    ensure that new requirements are understood and can be
> > > >>>>>>> met by
> > > >> the

---

From: Kent Watsen <[email-masked]>
Date: Wed, 22 Mar 2017 20:48:05 +0000

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,

Mehmet

of RFC
ADD<This
6087./>
standardized.
rephrase
rephrase

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 23 Mar 2017 18:04:50 +0100

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

> Sent: Wednesday, March 22, 2017 9:48 PM
> 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
> 
> 
> 
> 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
> 
> > ADD<The revised datastore draft will provide a conceptual framework
> > for the
> handling
> >       data models when necessary. ADD<The WG will finalize ongoing
> > 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./>
> >
> > > > > 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.
> > > > 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
> > > > > 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.
> > > >
> > > > 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
> > > > >> 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?
> > > This is again an interesting discussion which SHOULD be discussed in
> > > a joint session.
> > > > > In such a case the conceptual framework would most likely cause
> > > > > a competing situation with protocol WG's goals and documents and
> > > > 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.
> > > > >>>> 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,
> > > > >>>> 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.
> > > > >>>>> 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:
> > > > >>>> I am actually raising this point since November meeting.
> > > > >>>> There are
> > > > >>> different
> > > > >>>>> While once a document is mature and core direction/content
> > > > >>>>> is fixed, it is generally obvious what status is appropriate.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> I did not ask
> > > > >>>>>> I believe a WG charter should be self-sufficient covering
> > > > >>>>>> the target definition and intended status of the WG items.
> > > > >>>>> 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.
> > > > >>>>> 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:
> > > > >>>>>>> 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
> > > > >>>>>>>    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.
> > > > >>>>>>>
> > > > >>>>>>>       periodically updating the specification to address
> > > > >>>>>>> new
> > > > >>> requirements
> > > > >>>>>>>       as they arise.
> > > > >>>>>>>
> > > > >>>>>>>    f) Defining and maintaining YANG models that do not
> > > > >>>>>>> fall under
> > > > > the
> > > > >>>>>>>    modeling requirements and, when needed, which group
> > > > >>>>>>> will run
> > > > the
> > > > >>>>>>>    The NETMOD working group does not serve as a review
> > > > >>>>>>> team for
> > > > >>>> YANG
> > > > >>>>>>>    management, will act as advisors for other working
> > > > >>>>>>> groups and
> > > > >>> provide
> > > > >>>>>>>    Mar 2017 - Submit draft-ietf-netmod-acl-model 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
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Mar 2017 20:44:25 -0500

Mehmet,

As long as the WG items are in the milestones, we're good.

Regards, Benoit
> joint

---

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Mar 2017 20:50:03 -0500

Dear all,
> As it is a high-priority topic needed at least by 2 WGs,
Agreed. This should be earlier.

Regards, Benoit
> we were saying that revised-datastores should be finalized within 4 months and NC/RC-bis will take another 4-5 months.
>
> Thanks,
> Mehmet
>