Re: [netmod] tree diagram guidelines

[Juergen Schoenwaelder]

I agree. Fragile pointers to pages that can change anytime are
problematic in static documents.

/js

On Thu, Dec 07, 2017 at 08:04:52PM -0500, Joel M. Halpern wrote:
> I have been watching this discussion of referencing the wiki page from
> the RFC-to-be about tree diagrams.  I must admit that I am confused as to
> why we would want to do so.
> 
> For anyone writing a document with a YANG tree, what they are required
> to do is what is in this RFC.  While the wiki page may be interesting, it is
> not normative.
> For anyone reading an RFC that uses a Tree diagram (a significantly
> larger number of people), what they need to know is in the RFC.  Reading the
> wiki not only is not normative, it may well have content that was not even
> present when the RFC that they are reading was written.  In fact, the
> content of the wiki may contradict what is in the RFC they are reading,
> without indicating any errors having been made.  Which I fear may be
> confusing to the reader.
> 
> I understand and support wanting to make it easy for readers to find the
> wiki of ongoing discussions of YANG tree diagrams (and other issues.)  But
> it seems like this is the wrong way to achieve the goal.
> 
> Yours,
> Joel
> 
> On 12/7/17 6:38 PM, Lou Berger wrote:
> > Hi,
> > 
> > Following up on this discussion (and hoping to wrap it up):
> > 
> > I have created two  wikis off of
> > https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis
> > content and the other for section 3 of tree diagrams.  I also propose
> > the following changes to the tree-diagrams draft:
> > 
> > To section 3 intro, add:
> >      For the most current quidelines being developed, please see the IETF
> > NetMod Working
> >     Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart
> > 
> > Add :
> >    3.2.  Groupings
> > 
> >     If the YANG module is comprised of groupings only, then the tree
> >     diagram should contain the groupings.  The 'pyang' compiler can be
> >     used to produce a tree diagram with groupings using the "-f tree --
> >     tree-print-groupings" command line parameters.
> > 
> > And to section 3.3, start with:
> > 
> >     Tree diagrams can be split into sections to correspond to document
> >     structure.
> > 
> > For 6087 bis, I think section 3.4 gets replaced with something like.
> > 
> >      YANG tree diagrams provide a concise representation of a YANG module,
> >     and SHOULD be included to help readers understand YANG module
> >      structure.  Guidelines on tree diagrams can be found in Section 3 of
> >      [I-D.ietf-netmod-yang-tree-diagrams].
> > 
> > These changes can be found at:
> > https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c285758eb5aaaf02cf980269afff
> > 
> > This leaves the intended status as the key open issue on the draft.
> > 
> > Lou
> > 
> > 
> > On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:
> > > I am confused. I think there was some consensus to
> > > 
> > > - include all tree related guidelines in the tree document, remove all 
> > > tree
> > >related guidelines from 6087bis and have 6087bis point to the tree 
> > > document
> > >(which it already does)
> > > 
> > > The rest is pointless since AFAIK there is no wiki guidelines pages to
> > > point to and there is AFAIK nobody in place to actually maintain such
> > > a wiki page. Perhaps a wiki is the future but until future has
> > > arrived, we should not point to it.
> > > 
> > > The other proposal I heard was to have a landing page that points to
> > > the current guideline work which points to the relevant documents. A
> > > wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not
> > > affect the documents.
> > > 
> > > /js
> > > 
> > > PS: I am happy to add pointers to guidelines as a section to the
> > >  wikipedia page.
> > > 
> > > On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
> > > > To circle back to this.  My sense of this discussion (as contributor) is
> > > > (a) the tree diagrams draft should be updated to point to a "guidelines"
> > > > wiki page for "the most current guidelines"
> > > > (b) the tree diagrams draft should be updated to include a full set of 
> > > > the
> > > > current tree related guidelines
> > > > (c) 6087bis should be updated to point to a "guidelines" wiki page for 
> > > > "the
> > > > most current guidelines"
> > > > (d) 6087bis should have it's tree guidelines point to the tree diagrams
> > > > document -- in addition to pointing to the wiki
> > > > 
> > > > Does this sound right?
> > > > 
> > > > Lou
> > > > (as tree co-author)
> > > > 
> > > > On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
> > > > > The Wiki is useful as a starting point providing a collection of 
> > > > > pointers to guideline RFCs and the bis-revisions in development.
> > > > > 
> > > > > Cheers,
> > > > > Mehmet
> > > > > 
> > > > > > -Original Message-
> > > > > > From: netmod [mailto:netmod-boun...@ietf.org] On 

Re: [netmod] tree diagram guidelines

[Juergen Schoenwaelder]

On Thu, Dec 07, 2017 at 06:38:14PM -0500, Lou Berger wrote:
> 
> This leaves the intended status as the key open issue on the draft.
>

Have the suggestions for including a collapsed view of uses been
included?

Related to the status, I do think that the reference to YANG [RFC7950]
should be normative - other BCP documents also have normative
references and frankly this document talks a lot about YANG constructs
and hence it really has more than in informative dependency on YANG.

Is someone tracking issues somewhere?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] tree diagram guidelines

[Susan Hares]

Joel:

Agreed.  If it is going to common usage, then a BCP is appropriate.  Otherwise, 
the reader and user gets confused. 

Sue 

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, December 7, 2017 8:05 PM
To: netmod@ietf.org
Subject: Re: [netmod] tree diagram guidelines

 I have been watching this discussion of referencing the wiki page from the 
RFC-to-be about tree diagrams.  I must admit that I am confused as to why we 
would want to do so.

 For anyone writing a document with a YANG tree, what they are required to 
do is what is in this RFC.  While the wiki page may be interesting, it is not 
normative.
 For anyone reading an RFC that uses a Tree diagram (a significantly larger 
number of people), what they need to know is in the RFC.  Reading the wiki not 
only is not normative, it may well have content that was not even present when 
the RFC that they are reading was written.  In fact, the content of the wiki 
may contradict what is in the RFC they are reading, without indicating any 
errors having been made.  Which I fear may be confusing to the reader.

 I understand and support wanting to make it easy for readers to find the 
wiki of ongoing discussions of YANG tree diagrams (and other
issues.)  But it seems like this is the wrong way to achieve the goal.

Yours,
Joel

On 12/7/17 6:38 PM, Lou Berger wrote:
> Hi,
> 
> Following up on this discussion (and hoping to wrap it up):
> 
> I have created two  wikis off of
> https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis 
> content and the other for section 3 of tree diagrams.  I also propose 
> the following changes to the tree-diagrams draft:
> 
> To section 3 intro, add:
>  For the most current quidelines being developed, please see the 
> IETF NetMod Working
> Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart
> 
> Add :
>3.2.  Groupings
> 
> If the YANG module is comprised of groupings only, then the tree
> diagram should contain the groupings.  The 'pyang' compiler can be
> used to produce a tree diagram with groupings using the "-f tree 
> --
> tree-print-groupings" command line parameters.
> 
> And to section 3.3, start with:
> 
> Tree diagrams can be split into sections to correspond to document
> structure.
> 
> For 6087 bis, I think section 3.4 gets replaced with something like.
> 
>  YANG tree diagrams provide a concise representation of a YANG 
> module,
> and SHOULD be included to help readers understand YANG module
>  structure.  Guidelines on tree diagrams can be found in Section 3 
> of
>  [I-D.ietf-netmod-yang-tree-diagrams].
> 
> These changes can be found at:
> https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c28
> 5758eb5aaaf02cf980269afff
> 
> This leaves the intended status as the key open issue on the draft.
> 
> Lou
> 
> 
> On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:
>> I am confused. I think there was some consensus to
>>
>> - include all tree related guidelines in the tree document, remove all tree
>>related guidelines from 6087bis and have 6087bis point to the tree 
>> document
>>(which it already does)
>>
>> The rest is pointless since AFAIK there is no wiki guidelines pages 
>> to point to and there is AFAIK nobody in place to actually maintain 
>> such a wiki page. Perhaps a wiki is the future but until future has 
>> arrived, we should not point to it.
>>
>> The other proposal I heard was to have a landing page that points to 
>> the current guideline work which points to the relevant documents. A 
>> wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does 
>> not affect the documents.
>>
>> /js
>>
>> PS: I am happy to add pointers to guidelines as a section to the
>>  wikipedia page.
>>
>> On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
>>> To circle back to this.  My sense of this discussion (as 
>>> contributor) is
>>> (a) the tree diagrams draft should be updated to point to a "guidelines"
>>> wiki page for "the most current guidelines"
>>> (b) the tree diagrams draft should be updated to include a full set 
>>> of the current tree related guidelines
>>> (c) 6087bis should be updated to point to a "guidelines" wiki page 
>>> for "the most current guidelines"
>>> (d) 6087bis should have it's tree guidelines point to the tree 
>>> diagrams document -- in addition to pointing to the wiki
>>>
>>> Does this sound right?
>>>
>>> Lou
>>> (as tree co-author)
>>>
>>> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
 The Wiki is useful as a starting point providing a collection of pointers 
 to guideline RFCs and the bis-revisions in development.

 Cheers,
 Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh 
> Jethanandani
> Sent: Thursday, November 16, 2017 7:39 AM
> To: Robert Wilton 

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

[Susan Hares]

Kent:

A common way to express tree-diagrams in Yang documents provides a common
and clear to describe the models.  This would be really helpful to those
using these yang models.  Seems like a standard or a BCP to me.  

Sue Hares 
 

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, December 7, 2017 7:06 PM
To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder
Subject: Re: [netmod] intended status of the tree diagram document


BCP for tree-diagrams?   This doesn't seem like an appropriate application
of that designation.  I don't view the format for tree diagrams to be a
"practice", whereas it definitely seems "informational".

Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does not
represent an Internet community consensus or recommendation" could be cause
for objection, since this draft is obviously going through a WG (NETMOD) and
therefore does, in fact, represent some form of consensus, but I'm willing
to gloss over that line as, clearly, many Informational RFCs are published
by WGs, which wouldn't be possible if that line were taken literally.
Perhaps we should file Errata against it?

Kent // co-chair


= original message =

Hi Juergen,

Sorry for the slow response, I missed this message.

Circling back to this discussion made me go revisit RFC2026.  Based on all
the factors/discussions I agree  that standards track isn't quite right for
this document, but I also think informational isn't quite right either.  I
do think BCP would as described in RFC2026 fits.  This said, I think it
would be good to hear from at least Kent (as Chair) and Benoit (as AD) if
they agree/disagree with publishing as a BCP.

Kent, Benoit?

Thanks,

Lou

On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:
> Lou,
>
> right now, the document says standards track, Martin's proposal was to 
> move to informational. So how do I parse "I think you are correct.  We 
> should leave as is."?
>
> /js
>
> On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:
>> Martin,
>>  I think you are correct.  We should leave as is.
>>
>> I'm sure Kent/the document Shepherd makes sure whatever we do is 
>> right before publication in any case.
>>
>> Lou (as contributor)
>>
>> On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status 
>>> Standards Track.  I think I heard during the meeting today that it 
>>> ought to be Informational.  I think this makes sense.  It would then 
>>> imply that other standards track documents will have the tree 
>>> diagram document as an informative reference.
>>>
>>> Should we make this change?
>>>
>>>
>>> /martin
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
>>> ilman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voD
>>> TXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvoumTA
>>> -4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsko
>>> noVDeyYcQE=
>>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTX
>> cWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvoumTA-4y
>> jD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVD
>> eyYcQE=



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

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

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

[Lou Berger]

Umm, bcp covers process and consensus agreement while informational 
typically does not*.  I also don't see how 6087bis would be a more suited 
to be a bcp than this document.


Lou


On December 7, 2017 7:06:35 PM Kent Watsen  wrote:



BCP for tree-diagrams?   This doesn't seem like an appropriate application 
of that designation.  I don't view the format for tree diagrams to be a 
"practice", whereas it definitely seems "informational".


Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does 
not represent an Internet community consensus or recommendation" could be 
cause for objection, since this draft is obviously going through a WG 
(NETMOD) and therefore does, in fact, represent some form of consensus, but 
I'm willing to gloss over that line as, clearly, many Informational RFCs 
are published by WGs, which wouldn't be possible if that line were taken 
literally.  Perhaps we should file Errata against it?


Kent // co-chair


= original message =

Hi Juergen,

Sorry for the slow response, I missed this message.

Circling back to this discussion made me go revisit RFC2026.  Based on
all the factors/discussions I agree  that standards track isn't quite
right for this document, but I also think informational isn't quite
right either.  I do think BCP would as described in RFC2026 fits.  This
said, I think it would be good to hear from at least Kent (as Chair) and
Benoit (as AD) if they agree/disagree with publishing as a BCP.

Kent, Benoit?

Thanks,

Lou

On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:

Lou,

right now, the document says standards track, Martin's proposal was to
move to informational. So how do I parse "I think you are correct.  We
should leave as is."?

/js

On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:

Martin,
I think you are correct.  We should leave as is.

I'm sure Kent/the document Shepherd makes sure whatever we do is right
before publication in any case.

Lou (as contributor)

On 11/15/2017 8:58 PM, Martin Bjorklund wrote:

Hi,

Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
Standards Track.  I think I heard during the meeting today that it
ought to be Informational.  I think this makes sense.  It would then
imply that other standards track documents will have the tree diagram
document as an informative reference.

Should we make this change?


/martin

___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvoumTA-4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVDeyYcQE=


___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvoumTA-4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVDeyYcQE=







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

Re: [netmod] tree diagram guidelines

[Joel M. Halpern]

I have been watching this discussion of referencing the wiki page 
from the RFC-to-be about tree diagrams.  I must admit that I am confused 
as to why we would want to do so.


For anyone writing a document with a YANG tree, what they are 
required to do is what is in this RFC.  While the wiki page may be 
interesting, it is not normative.
For anyone reading an RFC that uses a Tree diagram (a significantly 
larger number of people), what they need to know is in the RFC.  Reading 
the wiki not only is not normative, it may well have content that was 
not even present when the RFC that they are reading was written.  In 
fact, the content of the wiki may contradict what is in the RFC they are 
reading, without indicating any errors having been made.  Which I fear 
may be confusing to the reader.


I understand and support wanting to make it easy for readers to 
find the wiki of ongoing discussions of YANG tree diagrams (and other 
issues.)  But it seems like this is the wrong way to achieve the goal.


Yours,
Joel

On 12/7/17 6:38 PM, Lou Berger wrote:

Hi,

Following up on this discussion (and hoping to wrap it up):

I have created two  wikis off of
https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis
content and the other for section 3 of tree diagrams.  I also propose
the following changes to the tree-diagrams draft:

To section 3 intro, add:
     For the most current quidelines being developed, please see the IETF
NetMod Working
    Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart

Add :
   3.2.  Groupings

    If the YANG module is comprised of groupings only, then the tree
    diagram should contain the groupings.  The 'pyang' compiler can be
    used to produce a tree diagram with groupings using the "-f tree --
    tree-print-groupings" command line parameters.

And to section 3.3, start with:

    Tree diagrams can be split into sections to correspond to document
    structure.

For 6087 bis, I think section 3.4 gets replaced with something like.

     YANG tree diagrams provide a concise representation of a YANG module,
    and SHOULD be included to help readers understand YANG module
     structure.  Guidelines on tree diagrams can be found in Section 3 of
     [I-D.ietf-netmod-yang-tree-diagrams].

These changes can be found at:
https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c285758eb5aaaf02cf980269afff

This leaves the intended status as the key open issue on the draft.

Lou


On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:

I am confused. I think there was some consensus to

- include all tree related guidelines in the tree document, remove all tree
   related guidelines from 6087bis and have 6087bis point to the tree document
   (which it already does)

The rest is pointless since AFAIK there is no wiki guidelines pages to
point to and there is AFAIK nobody in place to actually maintain such
a wiki page. Perhaps a wiki is the future but until future has
arrived, we should not point to it.

The other proposal I heard was to have a landing page that points to
the current guideline work which points to the relevant documents. A
wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not
affect the documents.

/js

PS: I am happy to add pointers to guidelines as a section to the
 wikipedia page.

On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:

To circle back to this.  My sense of this discussion (as contributor) is
(a) the tree diagrams draft should be updated to point to a "guidelines"
wiki page for "the most current guidelines"
(b) the tree diagrams draft should be updated to include a full set of the
current tree related guidelines
(c) 6087bis should be updated to point to a "guidelines" wiki page for "the
most current guidelines"
(d) 6087bis should have it's tree guidelines point to the tree diagrams
document -- in addition to pointing to the wiki

Does this sound right?

Lou
(as tree co-author)

On 11/16/2017 11:04 AM, Mehmet Ersue wrote:

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

Cheers,
Mehmet


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh
Jethanandani
Sent: Thursday, November 16, 2017 7:39 AM
To: Robert Wilton 
Cc: netmod@ietf.org
Subject: Re: [netmod] tree diagram guidelines

Other SDOs can and follow the work in IETF through the RFCs we publish.
They do not follow wiki’s, unless the document itself says, “here are the
guidelines, but if you are looking for the latest, go to this wiki”. I therefore
would support the proposal outlined below. It gives the SDO a stable point of
reference with a document, which gets updated occasionally, but also allows
them to peak at what is coming down the pipeline.

Thanks.


On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:

I liked the suggestion from Chris Hopps:

I think that 

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

[Kent Watsen]

BCP for tree-diagrams?   This doesn't seem like an appropriate application of 
that designation.  I don't view the format for tree diagrams to be a 
"practice", whereas it definitely seems "informational".

Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does not 
represent an Internet community consensus or recommendation" could be cause for 
objection, since this draft is obviously going through a WG (NETMOD) and 
therefore does, in fact, represent some form of consensus, but I'm willing to 
gloss over that line as, clearly, many Informational RFCs are published by WGs, 
which wouldn't be possible if that line were taken literally.  Perhaps we 
should file Errata against it?

Kent // co-chair


= original message =

Hi Juergen,

Sorry for the slow response, I missed this message.

Circling back to this discussion made me go revisit RFC2026.  Based on
all the factors/discussions I agree  that standards track isn't quite
right for this document, but I also think informational isn't quite
right either.  I do think BCP would as described in RFC2026 fits.  This
said, I think it would be good to hear from at least Kent (as Chair) and
Benoit (as AD) if they agree/disagree with publishing as a BCP.

Kent, Benoit?

Thanks,

Lou

On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:
> Lou,
>
> right now, the document says standards track, Martin's proposal was to
> move to informational. So how do I parse "I think you are correct.  We
> should leave as is."?
>
> /js
>
> On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:
>> Martin,
>>  I think you are correct.  We should leave as is.
>>
>> I'm sure Kent/the document Shepherd makes sure whatever we do is right
>> before publication in any case.
>>
>> Lou (as contributor)
>>
>> On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
>>> Standards Track.  I think I heard during the meeting today that it
>>> ought to be Informational.  I think this makes sense.  It would then
>>> imply that other standards track documents will have the tree diagram
>>> document as an informative reference.
>>>
>>> Should we make this change?
>>>
>>>
>>> /martin
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvoumTA-4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVDeyYcQE=
>>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvoumTA-4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVDeyYcQE=



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

Re: [netmod] tree diagram guidelines

[Lou Berger]

Hi,

Following up on this discussion (and hoping to wrap it up):

I have created two  wikis off of
https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis
content and the other for section 3 of tree diagrams.  I also propose
the following changes to the tree-diagrams draft:

To section 3 intro, add:
    For the most current quidelines being developed, please see the IETF
NetMod Working
   Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart

Add :
  3.2.  Groupings

   If the YANG module is comprised of groupings only, then the tree
   diagram should contain the groupings.  The 'pyang' compiler can be
   used to produce a tree diagram with groupings using the "-f tree --
   tree-print-groupings" command line parameters.

And to section 3.3, start with:

   Tree diagrams can be split into sections to correspond to document
   structure.

For 6087 bis, I think section 3.4 gets replaced with something like.

    YANG tree diagrams provide a concise representation of a YANG module,
   and SHOULD be included to help readers understand YANG module
    structure.  Guidelines on tree diagrams can be found in Section 3 of
    [I-D.ietf-netmod-yang-tree-diagrams].

These changes can be found at:
https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c285758eb5aaaf02cf980269afff

This leaves the intended status as the key open issue on the draft.

Lou


On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:
> I am confused. I think there was some consensus to
>
> - include all tree related guidelines in the tree document, remove all tree
>   related guidelines from 6087bis and have 6087bis point to the tree document
>   (which it already does)
>
> The rest is pointless since AFAIK there is no wiki guidelines pages to
> point to and there is AFAIK nobody in place to actually maintain such
> a wiki page. Perhaps a wiki is the future but until future has
> arrived, we should not point to it.
>
> The other proposal I heard was to have a landing page that points to
> the current guideline work which points to the relevant documents. A
> wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not
> affect the documents.
>
> /js
>
> PS: I am happy to add pointers to guidelines as a section to the
> wikipedia page.
>
> On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
>> To circle back to this.  My sense of this discussion (as contributor) is
>> (a) the tree diagrams draft should be updated to point to a "guidelines"
>> wiki page for "the most current guidelines"
>> (b) the tree diagrams draft should be updated to include a full set of the
>> current tree related guidelines
>> (c) 6087bis should be updated to point to a "guidelines" wiki page for "the
>> most current guidelines"
>> (d) 6087bis should have it's tree guidelines point to the tree diagrams
>> document -- in addition to pointing to the wiki
>>
>> Does this sound right?
>>
>> Lou
>> (as tree co-author)
>>
>> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
>>> The Wiki is useful as a starting point providing a collection of pointers 
>>> to guideline RFCs and the bis-revisions in development.
>>>
>>> Cheers,
>>> Mehmet
>>>
 -Original Message-
 From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh
 Jethanandani
 Sent: Thursday, November 16, 2017 7:39 AM
 To: Robert Wilton 
 Cc: netmod@ietf.org
 Subject: Re: [netmod] tree diagram guidelines

 Other SDOs can and follow the work in IETF through the RFCs we publish.
 They do not follow wiki’s, unless the document itself says, “here are the
 guidelines, but if you are looking for the latest, go to this wiki”. I 
 therefore
 would support the proposal outlined below. It gives the SDO a stable point 
 of
 reference with a document, which gets updated occasionally, but also allows
 them to peak at what is coming down the pipeline.

 Thanks.

> On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:
>
> I liked the suggestion from Chris Hopps:
>
> I think that it was along the lines of ...
>
> The RFC contains a reference at the top that states that updates to the
 guidelines is available on a wiki at 
> Every few years the guidelines on the wiki can be folded into a latest
 version of the guidelines draft.
> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or 
> MEF be
 using the latest draft guidelines, or should then use the published RFC 
 until
 6087bis is actually republshed?
> Thanks,
> Rob
>
>
> On 15/11/2017 10:14, Martin Bjorklund wrote:
>> Hi,
>>
>> There was a proposal in the meeting today to have the guidelines for
>> tree diagrams in a wiki, instead of having them in 6087bis or in the
>> tree diagram document.
>>
>> Was the proposal really to have a wiki for just the tree guidelines,
>> or was 

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

[Lou Berger]

Hi Juergen,

    Sorry for the slow response, I missed this message.

Circling back to this discussion made me go revisit RFC2026.  Based on
all the factors/discussions I agree  that standards track isn't quite
right for this document, but I also think informational isn't quite
right either.  I do think BCP would as described in RFC2026 fits.  This
said, I think it would be good to hear from at least Kent (as Chair) and
Benoit (as AD) if they agree/disagree with publishing as a BCP.

Kent, Benoit?

Thanks,

Lou

On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:
> Lou,
>
> right now, the document says standards track, Martin's proposal was to
> move to informational. So how do I parse "I think you are correct.  We
> should leave as is."?
>
> /js
>
> On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:
>> Martin,
>>  I think you are correct.  We should leave as is.
>>
>> I'm sure Kent/the document Shepherd makes sure whatever we do is right
>> before publication in any case.
>>
>> Lou (as contributor)
>>
>> On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
>>> Standards Track.  I think I heard during the meeting today that it
>>> ought to be Informational.  I think this makes sense.  It would then
>>> imply that other standards track documents will have the tree diagram
>>> document as an informative reference.
>>>
>>> Should we make this change?
>>>
>>>
>>> /martin
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://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] referencing the tree-diagrams draft

[Lou Berger]

Kent,

On 12/7/2017 3:19 PM, Kent Watsen wrote:
> All,
>
> Looking at a few drafts going through last call currently, I notice that they 
> all define their own "Tree Diagrams" section rather than reference the 
> tree-diagrams draft:
>
>   https://tools.ietf.org/html/draft-ietf-netmod-entity-05#section-1.1.1
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-00#section-1.3
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00#section-1.3
>
> I realize that the tree-diagrams draft isn't published yet, but my 
> understanding is that its Last Call is imminent.  With that in mind, *should* 
> these three drafts (and, by extension, all drafts going forward) be updated 
> to reference the tree-diagrams draft?  - or are we currently in a grey area 
> where it's a "may" until the tree-diagrams draft is published, at which time 
> it becomes a "must"?
I think we're close enough to risk the MISREF state, ie.e., I think the
drafts should point to tree diagrams.

Lou
(Co-author and co-chair...)

> Kent  // co-chair
>
>
>
> ___
> 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] referencing the tree-diagrams draft

[Kent Watsen]

All,

Looking at a few drafts going through last call currently, I notice that they 
all define their own "Tree Diagrams" section rather than reference the 
tree-diagrams draft:

  https://tools.ietf.org/html/draft-ietf-netmod-entity-05#section-1.1.1
  https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-00#section-1.3
  https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00#section-1.3

I realize that the tree-diagrams draft isn't published yet, but my 
understanding is that its Last Call is imminent.  With that in mind, *should* 
these three drafts (and, by extension, all drafts going forward) be updated to 
reference the tree-diagrams draft?  - or are we currently in a grey area where 
it's a "may" until the tree-diagrams draft is published, at which time it 
becomes a "must"?

Kent  // co-chair



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

Re: [netmod] WG Last Call: draft-ietf-netmod-entity-05

[Kent Watsen]

All,

Picking up on Juergen's comment:

> If these deprecated objects are essential for BBF (please confirm),
> then it might be better to define them in a separate module...

I agree that the objects should be defined in a separate module.  The
request, as I understand it, is for there be an "ietf-hardware-state"
module defined in the Appendix of this draft.  I believe that doing
so is consistent with the NMDA guidelines:

   (b) Models that require immediate support for "in use" and "system
   created" information SHOULD be structured for NMDA.  A non-NMDA
   version of these models SHOULD exist, either an existing model or a
   model created either by hand or with suitable tools that mirror the
   current modeling strategies.  Both the NMDA and the non-NMDA modules
   SHOULD be published in the same document, with NMDA modules in the
   document main body and the non-NMDA modules in a non-normative
   appendix.  The use of the non-NMDA model will allow temporary
   bridging of the time period until NMDA implementations are available.

Of course, we should ask, for how long is it that the IETF (SDOs in 
general) should publish these -state modules?   During the discussion
at the beginning of the first session in Singapore, I said something
along the lines of "so long as there is market demand for it", which
seems a bit too open-ended for my taste.   I recommend that we set a 
date, perhaps a couple years out, after which we (the IETF) will no 
longer publish or maintain such foo-state modules.

Thoughts?

Kent  // as co-chair


= original message ==

Bart,

I think the reason for the difference is that the interfaces model was
published as an RFC before while the hardware model is new and hence
it seems to look a bit odd to define new deprecated objects.

If these deprecated objects are essential for BBF (please confirm),
then it might be better to define them in a separate module that then
can silently die while systems move to NMDA (and so we do not have the
deprecated objects with us in the hardware module forever - or at
least as long as we use YANG 1.1).

/js

On Tue, Dec 05, 2017 at 02:35:29PM +, Bogaert, Bart (Nokia - BE/Antwerp) 
wrote:
> Hello,
> 
> The latest draft does not contain an appendix with the deprecated state tree
> (to support the non-NMDA model as specified in RFC6087bis section 4.23.3),
> so if it is published in this way, there is an issue at the level of BBF
> TR-383.
> 
> Note that the draft-ietfnetmod-rfc7223bis does include the deprecated
> container interfaces-state.
> 
> Best regards,
> Bart Bogaert
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
> Sent: Wednesday, November 29, 2017 6:36 PM
> To: NetMod WG 
> Cc: NetMod WG Chairs 
> Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-entity-05.
> 
> The working group last call ends on December 13.
> Please send your comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Netmod Chairs
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chLVKwaAcdC6Llko8SagGTdtaLVTMJRVuFxx-MbXvQU=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqdIs=



> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chLVKwaAcdC6Llko8SagGTdtaLVTMJRVuFxx-MbXvQU=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqdIs=


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chLVKwaAcdC6Llko8SagGTdtaLVTMJRVuFxx-MbXvQU=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqdIs=


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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

[Martin Bjorklund]

Hi Eric,


"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> Several comments on the YANG model within rfc7223bis.
> 
> list interface {
> key "name";
> description
>   "The list of interfaces on the device.  The status of an interface
>   is available in this list in the
>operational state...
> 
> A few questions on this.
> (a) The description of the list defines behaviors of various list
> nodes which might or might not exist in different NMDA datastores.  It
> also suggests when certain elements should be populated in various
> datastores.  Is the precedence being set that datastore specific
> behaviors may be placed into descriptions?

I don't know; I guess it depends on what people think about this
style.  I think that when the mapping between config and operational
state is not 1-1 and obvious, it needs to be somehow explained in the
description - just like the old descriptions did, except that where
the old descriptions refered to different *nodes*, we now refer to
different *intantiations* of the same node.


> Is this type of
> documentation guidance something which explored in
> draft-dsdt-nmda-guidelines?

I don't think so.

> (b) Does status mean 'admin-status', 'oper-status' or both?  (I think
> 'oper-status'.)

No, it is intended to mean the status of the interface in general.

> (c) should quotes be used around status?

No, since it's not the name of a specific node.

> leaf name {,   leaf type { 
> There are NETCONF specific behaviors in the definition of these two
> leaves.  It would be great to have this transport agnostic.

One thing to note is that this also should apply to a RESTCONF
server.  But adding that doesn't really address your point :)
However, I don't know what the correct way of handling this would be.
We could be less specific and just write that the server MUST return
an "invalid-value" error, but less specific might also be more
confusing.

> I realize
> that such a transport segmentation dissociates transport error
> handling from the nodes being handled.
> 
> leaf admin-status {...
> incorrectly marked  as config false;

See the reply from Vladimir; this is corrcect.


/martin


> 
> Thanks,
> Eric
> 
> 
> > > -邮件原件-
> > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> > > 发送时间: 2017年11月29日 3:29
> > > 收件人: netmod@ietf.org
> > > 抄送: netmod-cha...@ietf.org
> > > 主题: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00
> > >
> > > All,
> > >
> > > This starts a two-week working group last call on draft-ietf-netmod-
> > rfc7223bis-00.
> > >
> > > Please recall that this update's intention is to modify the YANG
> > > module to
> > be in line with the NMDA guidelines [1].  Reviewing the diff between
> > the
> > two drafts [2] should reveal just this.
> > >
> > > The working group last call ends on December 12.
> > > Please send your comments to the netmod mailing list.
> > >
> > > Positive comments, e.g., "I've reviewed this document and believe it
> > > is
> > ready for publication", are welcome!
> > > This is useful and important, even from authors.
> > >
> > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
> > > [2]
> > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.tx
> > > t
> > >
> > > Thank you,
> > > Netmod Chairs
> > >
> > >
> > > ___
> > > 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod