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

[Kent Watsen]

I think that there might be a paragraph or two in the nmda-guidelines draft 
that could be
used as source material, but by and large, I'm imagine new text being needed.  
If none of
my co-authors step forward, I'll pen up some proposal text for Section 6.23 
myself, but it
may be awhile, with IETF-week coming on strong now (I'm sure you relate).

Don't worry about timing. The urgency to get 6087bis out with 7950 has 
subsided.  But
we do need to ensure that 6087bis dovetails nicely with the NMDA.

Kent  // shepherd


On 7/11/17, 4:44 PM, "Andy Bierman" 
> wrote:

Hi,

Do you have text from your that that should be pasted into section 6.23?

I think there were other issues, such as changing the terminology to reference 
RD.
There were comments opposing that idea because the definition for 
'configuration'
including everything that could possibly change the behavior of the device.


Andy


On Tue, Jul 11, 2017 at 1:31 PM, Kent Watsen 
> wrote:
Hi Andy,

I confirmed with Lou and Benoit that we want 6.23 to have the normative text 
within it,
as we're both unsure about if the nmda-guidelines draft will progress and also 
believe
that the text could be written more helpfully for the 6087bis audience.

Would it help if one of the nmda-guidelines authors wrote the section for you?

Thanks,
Kent   // co-chair


On 6/20/17, 11:27 AM, "Andy Bierman" 
> wrote:

Hi,

I rewrote 6.23 and it points at the NMDA guidelines.
The drafts will get published together so the references will
be to RFCs, not I-Ds.  That is usually what is meant by the comment below I 
think




> I don't expect the guidelines doc is going to progress independently.

Agreed.

Andy

On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen 
> wrote:


Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can 
just state what people should do, without providing a formula for transitioning.

I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.


 I thought that this was settled before (maybe not): 
https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q






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

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

[Andy Bierman]

Hi,

Do you have text from your that that should be pasted into section 6.23?

I think there were other issues, such as changing the terminology to
reference RD.
There were comments opposing that idea because the definition for
'configuration'
including everything that could possibly change the behavior of the device.


Andy


On Tue, Jul 11, 2017 at 1:31 PM, Kent Watsen  wrote:

> Hi Andy,
>
>
>
> I confirmed with Lou and Benoit that we want 6.23 to have the normative
> text within it,
>
> as we're both unsure about if the nmda-guidelines draft will progress and
> also believe
>
> that the text could be written more helpfully for the 6087bis audience.
>
>
>
> Would it help if one of the nmda-guidelines authors wrote the section for
> you?
>
>
>
> Thanks,
>
> Kent   // co-chair
>
>
>
>
>
> On 6/20/17, 11:27 AM, "Andy Bierman"  wrote:
>
>
>
> Hi,
>
>
>
> I rewrote 6.23 and it points at the NMDA guidelines.
>
> The drafts will get published together so the references will
>
> be to RFCs, not I-Ds.  That is usually what is meant by the comment below
> I think
>
>
>
>
>
> > I don't expect the guidelines doc is going to progress independently.
>
> Agreed.
>
>
>
> Andy
>
>
>
> On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen  wrote:
>
>
>
>
>
> Regarding the suggestion to add this text:
>
> > Guidelines for
> >  moving existing data modules to the NMDA are defined in
> >  [I-D.dsdt-nmda-guidelines].
>
> I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis
> can just state what people should do, without providing a formula for
> transitioning.
>
>
>
> I thought 6087bis is supposed to point people to the NMDA guidelines.
> That is why 6087bis has been held back for so long, even though it was
>
> supposed to be published with YANG 1.1.
>
>
>
> We waste a lot of time refactoring drafts and re-reviewing them.
>
> IMO the RD guidelines should be in the RD draft.
>
>
>
>
>
>  I thought that this was settled before (maybe not):
> https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q
>
>
>
>
>
>
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Hi Andy,

I confirmed with Lou and Benoit that we want 6.23 to have the normative text 
within it,
as we're both unsure about if the nmda-guidelines draft will progress and also 
believe
that the text could be written more helpfully for the 6087bis audience.

Would it help if one of the nmda-guidelines authors wrote the section for you?

Thanks,
Kent   // co-chair


On 6/20/17, 11:27 AM, "Andy Bierman" 
> wrote:

Hi,

I rewrote 6.23 and it points at the NMDA guidelines.
The drafts will get published together so the references will
be to RFCs, not I-Ds.  That is usually what is meant by the comment below I 
think




> I don't expect the guidelines doc is going to progress independently.

Agreed.

Andy

On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen 
> wrote:


Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can 
just state what people should do, without providing a formula for transitioning.

I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.


 I thought that this was settled before (maybe not): 
https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q





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

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

[Andy Bierman]

Hi,

I rewrote 6.23 and it points at the NMDA guidelines.
The drafts will get published together so the references will
be to RFCs, not I-Ds.  That is usually what is meant by the comment below I
think



> I don't expect the guidelines doc is going to progress independently.
Agreed.


Andy

On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen  wrote:

>
>
>
>
> Regarding the suggestion to add this text:
>
> > Guidelines for
> >  moving existing data modules to the NMDA are defined in
> >  [I-D.dsdt-nmda-guidelines].
>
> I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis
> can just state what people should do, without providing a formula for
> transitioning.
>
>
>
> I thought 6087bis is supposed to point people to the NMDA guidelines.
> That is why 6087bis has been held back for so long, even though it was
>
> supposed to be published with YANG 1.1.
>
>
>
> We waste a lot of time refactoring drafts and re-reviewing them.
>
> IMO the RD guidelines should be in the RD draft.
>
>
>
>
>
>  I thought that this was settled before (maybe not):
> https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q
>
>
>
>
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can 
just state what people should do, without providing a formula for transitioning.

I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.


 I thought that this was settled before (maybe not): 
https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q




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

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

[Andy Bierman]

On Tue, Jun 20, 2017 at 4:32 AM, Kent Watsen  wrote:

>
> Regarding the suggestion to add this text:
>
> > Guidelines for
> >  moving existing data modules to the NMDA are defined in
> >  [I-D.dsdt-nmda-guidelines].
>
> I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis
> can just state what people should do, without providing a formula for
> transitioning.
>
>
I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.




> Kent (any hat)


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

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

[Robert Wilton]

Hi Tom,

On 20/06/2017 12:39, t.petch wrote:

--- Original Message -
From: "Phil Shafer" 
To: "Andy Bierman" 
Cc: 
Sent: Tuesday, June 20, 2017 7:05 AM


Andy Bierman writes:

This draft addresses all remaining open issues, include the rewrite

of the

opstate section.

In YANG, any data that has a "config" statement value of "false"
could be considered operational data.  The relationship between
configuration (i.e., "config" statement has a value of "true") and
operational data can be complex.

The NMDA draft includes the following in its terminology section:

   - configuration: Data that determines how a device behaves.  This
 data is modeled in YANG using "config true" nodes.  Configuration
 can originate from different sources.

   - operational state: The combination of applied configuration and
 system state.

It would be nice to use matching terms, either by importing the
NMDA terms directly, or by mimicing them in this draft.  If your
"operational data" means "config false" and NMDA's "operational state"
means both config true and config false, readers will be confused.

Phil

Well, it would if the definitions in NMDA brought clarity but I think
the opposite.

'Data that determines how a device behaves' seems clear until you read
on and find that this excludes data learnt from the system or data
learnt from routing protocols.
Please can you clarify.  The text that you are quoting above is from the 
NMDA definition of "configuration".


Data learned from the system or routing protocols (for YANG config true 
nodes) would be classified as "system configuration" or "learned 
configuration", which are sub categories of "configuration", and hence 
are not excluded from the more general definition of "configuration".


Thanks,
Rob




I find the idea that the behaviour of a device is not determined by
routing protocols or a hot-plugged card an odd one.

This definition is rather different to that in NETCONF and seems
unlikely to bring clarity so I think it would be a mistake to
incorporate it in rfc6087bis..

Tom Petch



Also you say "operational state and other data such as statistics"
which inconsisent.  Under either set of terms, statistics are
part of operational state.


The original set of datastores defined in NETCONF (i.e., candidate,
unning, and startup) are not sufficient to fully manage a device
ith multiple sources of configuration data.  In additional, a
separate datastore is needed to store operational state and other
data such as statistics.  Refer to
[I-D.ietf-netmod-revised-datastores] for details on this new

"revised

datastore" architecture.  Guidelines for usage of the new datastores
(including the operational datastore) is defined in
[I-D.dsdt-nmda-guidelines].

"not sufficient to fully manage" is too broad a claim.  Can I suggest
a more positive spin:

   The Network Management Datastore Architecture (NMDA) defines a
   new set of datastores that improve visibility into the device,
   both in terms of the "intended" configurations values and the
   true operationally "in use" values.  Refer to
   [I-D.ietf-netmod-revised-datastores] for details.  Guidelines for
   moving existing data modules to the NMDA are defined in
   [I-D.dsdt-nmda-guidelines].

Thanks,
  Phil

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

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



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

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

[t.petch]

--- Original Message -
From: "Phil Shafer" 
To: "Andy Bierman" 
Cc: 
Sent: Tuesday, June 20, 2017 7:05 AM

> Andy Bierman writes:
> >This draft addresses all remaining open issues, include the rewrite
of the
> >opstate section.
>
> >>In YANG, any data that has a "config" statement value of "false"
> >>could be considered operational data.  The relationship between
> >>configuration (i.e., "config" statement has a value of "true") and
> >>operational data can be complex.
>
> The NMDA draft includes the following in its terminology section:
>
>   - configuration: Data that determines how a device behaves.  This
> data is modeled in YANG using "config true" nodes.  Configuration
> can originate from different sources.
>
>   - operational state: The combination of applied configuration and
> system state.
>
> It would be nice to use matching terms, either by importing the
> NMDA terms directly, or by mimicing them in this draft.  If your
> "operational data" means "config false" and NMDA's "operational state"
> means both config true and config false, readers will be confused.

Phil

Well, it would if the definitions in NMDA brought clarity but I think
the opposite.

'Data that determines how a device behaves' seems clear until you read
on and find that this excludes data learnt from the system or data
learnt from routing protocols.

I find the idea that the behaviour of a device is not determined by
routing protocols or a hot-plugged card an odd one.

This definition is rather different to that in NETCONF and seems
unlikely to bring clarity so I think it would be a mistake to
incorporate it in rfc6087bis..

Tom Petch


> Also you say "operational state and other data such as statistics"
> which inconsisent.  Under either set of terms, statistics are
> part of operational state.
>
> >>The original set of datastores defined in NETCONF (i.e., candidate,
> >>unning, and startup) are not sufficient to fully manage a device
> >>ith multiple sources of configuration data.  In additional, a
> >>separate datastore is needed to store operational state and other
> >>data such as statistics.  Refer to
> >>[I-D.ietf-netmod-revised-datastores] for details on this new
"revised
> >>datastore" architecture.  Guidelines for usage of the new datastores
> >>(including the operational datastore) is defined in
> >>[I-D.dsdt-nmda-guidelines].
>
> "not sufficient to fully manage" is too broad a claim.  Can I suggest
> a more positive spin:
>
>   The Network Management Datastore Architecture (NMDA) defines a
>   new set of datastores that improve visibility into the device,
>   both in terms of the "intended" configurations values and the
>   true operationally "in use" values.  Refer to
>   [I-D.ietf-netmod-revised-datastores] for details.  Guidelines for
>   moving existing data modules to the NMDA are defined in
>   [I-D.dsdt-nmda-guidelines].
>
> Thanks,
>  Phil
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can 
just state what people should do, without providing a formula for 
transitioning. 

Kent (any hat)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

Hi,

This draft addresses all remaining open issues, include the rewrite of the
opstate section.
I think it is ready for another quick WGLC and then back to the IESG.


Andy


On Sun, Jun 18, 2017 at 9:54 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the NETCONF Data Modeling Language of the
> IETF.
>
> Title   : Guidelines for Authors and Reviewers of YANG
> Data Model Documents
> Author  : Andy Bierman
> Filename: draft-ietf-netmod-rfc6087bis-13.txt
> Pages   : 64
> Date: 2017-06-18
>
> Abstract:
>This memo provides guidelines for authors and reviewers of Standards
>Track specifications containing YANG data model modules.  Applicable
>portions may be used as a basis for reviews of other YANG data model
>documents.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG data model modules.  This document
>obsoletes RFC 6087.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : Guidelines for Authors and Reviewers of YANG Data 
Model Documents
Author  : Andy Bierman
Filename: draft-ietf-netmod-rfc6087bis-13.txt
Pages   : 64
Date: 2017-06-18

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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