Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[t.petch]

- Original Message -
From: "Robert Wilton" 
Sent: Wednesday, January 17, 2018 10:44 AM

> Hi Tom,
>
>
> On 17/01/2018 09:52, t.petch wrote:
> > - Original Message -
> > From: "Alexander Clemm" 
> > Sent: Wednesday, January 17, 2018 2:20 AM
> >
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is
needed
> > here.  The purpose is to make this human-readable and provide
readers a
> > good sense of the overall structure.
> >
> > 
> >
> > That's what I thought until Benoit said, and Robert agreed, that
> >
> > 'In the end, the tree view should be browsed with tooling.'
> The text based YANG tree diagram (i.e. covered by this draft) doesn't
> need to be browsable by tooling. The purpose of these diagrams should
> be to go in text documents to help explain and illustrate (to human
> readers) the structure of a YANG model.
>
> By "In the end, the tree view should be browsed with tooling.", what I
> mean is that I think that tools like YANG catalog will be the long
term
> way of interacting with and browsing YANG modules. For example, the
> link below for the RIP module.
>
> https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
>
> This provides an interactive GUI "tree view" of a YANG model, which
> should be structurally equivalent as the text tree diagram, but
> otherwise the information may be represented in a more visual way.
This
> will become even more powerful when all of the standard YANG modules
are
> available together in a single browsable tree.
>
> Hopefully, that clarifies my previous comment.

Yes, thank you for the clarification,

Tom Petch





>
> Thanks,
> Rob
>
> >
> > i.e. the tree view should be machine readable after which something
is
> > produced for human consumption; not a view I share.
> >
> > Tom Petch
> >
> >
> > The authoritative specification is still the .yang itself.
Providing
> > some guidance for how to represent the tree is good but let's not
> > over-engineer this; I believe retaining some flexibility is good.
> >> --- Alex
> >>
> >>> -Original Message-
> >> ...
>  Does anyone else have an opinion on this?  I can see three
>  alternatives:
> 
>  1) allow any number of addtional spaces
>  2) allow any number of addtional spaces + define a suggested
> alignment algorithm
>  3) mandate the alignment algorithm
> >>> Definition of symbols should be precise/consistent, so that
readers
> > can
> >>> consistently interpret tree diagrams.
> >>>
> >>> I think that flexibility in layout should be OK, but the draft
> > should provide
> >>> guideline to ensure the output is readable, and likely to be
broadly
> > consistent
> >>> (since consistency aids readability).
> >>>
> >>> If the IETF data modeling group is trying to specify text output
> > precisely
> >>> enough that it can be screen scraped then we may want to consider
> > whether
> >>> we are focusing on the right solution ;-)
> >>>
> >>> In summary, (2) is my preference, followed by (1), followed by
(3).
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> 
>  /martin
> > .
> >
>

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Jeff Tantsura]

+1 to 2

Cheers,
Jeff

On 1/16/18, 07:41, "netmod on behalf of Martin Bjorklund" 
 wrote:

Vladimir Vassilev  wrote:
> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
> 
> > Vladimir Vassilev  wrote:

[...]

> >> There is also undocumented alignment space count function before
> >>  that pyang uses to align the  fields of child data leafs
> >> with common ancestor. If this is specified in the draft the tree
> >> output can be deterministic and for me this is an advantage. This is
> >> currently one of the few underspecified pieces of the tree format so I
> >> had to check pyang implementation in oder to generate same alignment
> >> space counts and binary identical tree output results.
> > I think that we at least should write that there may be more than one
> > space between  and :
> >
> >There may be any number of additional space characters between
> > and .
> For the sake of the argument (at least having this on the mailing list
> as reference):
> 
>should be aligned at a common offset for all sibling nodes
>   from the start of  by adding trailing spaces. The recommended
>   offset is 3 plus the length of the longest node name among all
> sibling nodes
>   including those siblings defined under choice and case nodes.
> 
> This is what pyang does now. It is not a perfect solution but it
> allows identical output down to the bit.

Does anyone else have an opinion on this?  I can see three
alternatives:

  1) allow any number of addtional spaces
  2) allow any number of addtional spaces + define a suggested
 alignment algorithm
  3) mandate the alignment algorithm


/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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Benoit Claise]

Hi Tom,

Hi Tom,


On 17/01/2018 09:52, t.petch wrote:

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM


+1 to (2) as preference, followed by (1).  I don't think (3) is needed

here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't 
need to be browsable by tooling.  The purpose of these diagrams should 
be to go in text documents to help explain and illustrate (to human 
readers) the structure of a YANG model.


By "In the end, the tree view should be browsed with tooling.", what I 
mean is that I think that tools like YANG catalog will be the long 
term way of interacting with and browsing YANG modules. For example, 
the link below for the RIP module.


https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip

This provides an interactive GUI "tree view" of a YANG model, which 
should be structurally equivalent as the text tree diagram, but 
otherwise the information may be represented in a more visual way. 
This will become even more powerful when all of the standard YANG 
modules are available together in a single browsable tree.



Exactly what I meant.
'In the end, the tree view should be browsed with tooling.' doesn't mean 
that the tree diagram, to be inserted in the RFC text,(according to 
draft-ietf-netmod-yang-tree-diagrams-04 
should 
be browsed with tooling.


Sorry if it was not clear.

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Juergen Schoenwaelder]

On Wed, Jan 17, 2018 at 09:52:27AM -, t.petch wrote:
> 
> That's what I thought until Benoit said, and Robert agreed, that
> 
> 'In the end, the tree view should be browsed with tooling.'
> 
> i.e. the tree view should be machine readable after which something is
> produced for human consumption; not a view I share.
>

I think they did not say that the tooling should rely on tree views
published in RFCs as input. We should discourage tools to read tree
rendings as input; tools should read YANG modules as input. I doubt
Benoit's tools read tree views as input.

/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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Robert Wilton]

Hi Tom,


On 17/01/2018 09:52, t.petch wrote:

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM


+1 to (2) as preference, followed by (1).  I don't think (3) is needed

here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't 
need to be browsable by tooling.  The purpose of these diagrams should 
be to go in text documents to help explain and illustrate (to human 
readers) the structure of a YANG model.


By "In the end, the tree view should be browsed with tooling.", what I 
mean is that I think that tools like YANG catalog will be the long term 
way of interacting with and browsing YANG modules.  For example, the 
link below for the RIP module.


https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip

This provides an interactive GUI "tree view" of a YANG model, which 
should be structurally equivalent as the text tree diagram, but 
otherwise the information may be represented in a more visual way. This 
will become even more powerful when all of the standard YANG modules are 
available together in a single browsable tree.


Hopefully, that clarifies my previous comment.

Thanks,
Rob



i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.

Tom Petch


The authoritative specification is still the .yang itself.  Providing
some guidance for how to represent the tree is good but let's not
over-engineer this; I believe retaining some flexibility is good.

--- Alex


-Original Message-

...

Does anyone else have an opinion on this?  I can see three
alternatives:

1) allow any number of addtional spaces
2) allow any number of addtional spaces + define a suggested
   alignment algorithm
3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers

can

consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft

should provide

guideline to ensure the output is readable, and likely to be broadly

consistent

(since consistency aids readability).

If the IETF data modeling group is trying to specify text output

precisely

enough that it can be screen scraped then we may want to consider

whether

we are focusing on the right solution ;-)

In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob



/martin

.



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Martin Bjorklund]

Hi,

Robert Wilton  wrote:
> On 17/01/2018 07:43, Martin Bjorklund wrote:
> > Alexander Clemm  wrote:
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> >> here.  The purpose is to make this human-readable and provide readers
> >> a good sense of the overall structure.  The authoritative
> >> specification is still the .yang itself.  Providing some guidance for
> >> how to represent the tree is good but let's not over-engineer this; I
> >> believe retaining some flexibility is good.
> > The last sentence summarizes my personal view.  I prefer (1), followed
> > by (2).
> OK, so the "Providing some guidance for how to represent the tree is
> good" is along the lines of what I was thinking for the "algorithm"
> would be for 2.
> 
> E.g. something along the lines of:
> "Arbitrary whitespace is allowed between any of the whitespace
> separated fields (e.g.  and ).  Additional whitespace may
> be used to column align fields (e.g. within a list or container) to
> improve readability".

This is fine with me.  It is something in between (1) and (2) which
people preferred.  I will add this text.

> But just saying implementations can use arbitrary whitespace is also
> fine with me.  I certainly err on the side of not being overly
> prescriptive on this ..
> 
> I'm not really a fan of the comparing tree output as a method of
> verifying a YANG parser idea.

This is getting off-topic, but if an implementor wants to do this in
order to verify his implementation, go for it!  It doesn't have to be
discussed on this ML.  Speaking from own experience of two different
implementations, I can tell you that it is a useful test to do ;-)


/martin

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[t.petch]

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM

> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'

i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.

Tom Petch


   The authoritative specification is still the .yang itself.  Providing
some guidance for how to represent the tree is good but let's not
over-engineer this; I believe retaining some flexibility is good.
>
> --- Alex
>
> > -Original Message-
> ...
> > > Does anyone else have an opinion on this?  I can see three
> > > alternatives:
> > >
> > >1) allow any number of addtional spaces
> > >2) allow any number of addtional spaces + define a suggested
> > >   alignment algorithm
> > >3) mandate the alignment algorithm
> >
> > Definition of symbols should be precise/consistent, so that readers
can
> > consistently interpret tree diagrams.
> >
> > I think that flexibility in layout should be OK, but the draft
should provide
> > guideline to ensure the output is readable, and likely to be broadly
consistent
> > (since consistency aids readability).
> >
> > If the IETF data modeling group is trying to specify text output
precisely
> > enough that it can be screen scraped then we may want to consider
whether
> > we are focusing on the right solution ;-)
> >
> > In summary, (2) is my preference, followed by (1), followed by (3).
> >
> > Thanks,
> > Rob
> >
> > >
> > >
> > > /martin

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Robert Wilton]

On 17/01/2018 07:43, Martin Bjorklund wrote:

Alexander Clemm  wrote:

+1 to (2) as preference, followed by (1).  I don't think (3) is needed
here.  The purpose is to make this human-readable and provide readers
a good sense of the overall structure.  The authoritative
specification is still the .yang itself.  Providing some guidance for
how to represent the tree is good but let's not over-engineer this; I
believe retaining some flexibility is good.

The last sentence summarizes my personal view.  I prefer (1), followed
by (2).
OK, so the "Providing some guidance for how to represent the tree is 
good" is along the lines of what I was thinking for the "algorithm" 
would be for 2.


E.g. something along the lines of:
"Arbitrary whitespace is allowed between any of the whitespace separated 
fields (e.g.  and ).  Additional whitespace may be used to 
column align fields (e.g. within a list or container) to improve 
readability".


But just saying implementations can use arbitrary whitespace is also 
fine with me.  I certainly err on the side of not being overly 
prescriptive on this ..


I'm not really a fan of the comparing tree output as a method of 
verifying a YANG parser idea.


Thanks,
Rob





/martin


--- Alex


-Original Message-

...

Does anyone else have an opinion on this?  I can see three
alternatives:

1) allow any number of addtional spaces
2) allow any number of addtional spaces + define a suggested
   alignment algorithm
3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers
can
consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft should
provide
guideline to ensure the output is readable, and likely to be broadly
consistent
(since consistency aids readability).

If the IETF data modeling group is trying to specify text output
precisely
enough that it can be screen scraped then we may want to consider
whether
we are focusing on the right solution ;-)

In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob



/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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Juergen Schoenwaelder]

On Wed, Jan 17, 2018 at 10:08:02AM +0100, Vladimir Vassilev wrote:
> 
> The advantage I see is that 'uses' and 'augments' are resolved in the tree
> output. For example one can not cach bug in the reolution of the configure
> flag in a uses expanded under case with "configure false;" by generating
> YANG with unresolved 'uses'.  Another example - one can not represent the
> result of multiple modules augmenting e.g. /interfaces with a YANG module.
> The only universal representation is the YANG tree.
>

But then the tree diagram leave out tons of other details. Anyway, if
you insist on using tree diagrams for testing, your test can simply
tolerate white space differences.

/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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/16/2018 09:06 PM, Juergen Schoenwaelder wrote:

On Tue, Jan 16, 2018 at 08:19:38PM +0100, Vladimir Vassilev wrote:

As for the automated validation of the tree diagrams as an added value to
the human readability I have the following thoughts. I would like to be able
to compare unlimited line length tree outputs generated by different YANG
compilers for equality. This is mainly a way to have some partial common
denominator output for validating YANG is correctly compiled which we did
not have until now. For example as soon as I have support for Schema mount I
would compare the tree output with another tool known to work and add some
testcases based on that. I do not see any automated alternative for doing
this except writing NETCONF chat scripts (also module specific), or writing
not only YANG module specific but also API specific test cases as 3rd
option. 1) does not compromise this automated validation option since space
sequences can be collapsed to single space. If the alignment algorithm was
creating a possibility for nontrivial output variation then I would have
supported strongly 3) but this is not the current case.


If you want to make sure a YANG compiler is correct, simply write a
backend that generates a serialized YANG module in canonical
form. They YANG modules should be the same. Determining YANG compiler
correctness by comparing tree diagrams does not seem to be a
convincing approach since tree diagrams by design leave many details
out.
The advantage I see is that 'uses' and 'augments' are resolved in the 
tree output. For example one can not cach bug in the reolution of the 
configure flag in a uses expanded under case with "configure false;" by 
generating YANG with unresolved 'uses'.  Another example - one can not 
represent the result of multiple modules augmenting e.g. /interfaces 
with a YANG module. The only universal representation is the YANG tree.


Vladimir

/js



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Juergen Schoenwaelder]

On Wed, Jan 17, 2018 at 08:43:18AM +0100, Martin Bjorklund wrote:
> Alexander Clemm  wrote:
> > +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> > here.  The purpose is to make this human-readable and provide readers
> > a good sense of the overall structure.  The authoritative
> > specification is still the .yang itself.  Providing some guidance for
> > how to represent the tree is good but let's not over-engineer this; I
> > believe retaining some flexibility is good.
> 
> The last sentence summarizes my personal view.  I prefer (1), followed
> by (2).

+1

/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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Martin Bjorklund]

Alexander Clemm  wrote:
> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
> here.  The purpose is to make this human-readable and provide readers
> a good sense of the overall structure.  The authoritative
> specification is still the .yang itself.  Providing some guidance for
> how to represent the tree is good but let's not over-engineer this; I
> believe retaining some flexibility is good.

The last sentence summarizes my personal view.  I prefer (1), followed
by (2).


/martin

> --- Alex 
> 
> > -Original Message-
> ...
> > > Does anyone else have an opinion on this?  I can see three
> > > alternatives:
> > >
> > >1) allow any number of addtional spaces
> > >2) allow any number of addtional spaces + define a suggested
> > >   alignment algorithm
> > >3) mandate the alignment algorithm
> > 
> > Definition of symbols should be precise/consistent, so that readers
> > can
> > consistently interpret tree diagrams.
> > 
> > I think that flexibility in layout should be OK, but the draft should
> > provide
> > guideline to ensure the output is readable, and likely to be broadly
> > consistent
> > (since consistency aids readability).
> > 
> > If the IETF data modeling group is trying to specify text output
> > precisely
> > enough that it can be screen scraped then we may want to consider
> > whether
> > we are focusing on the right solution ;-)
> > 
> > In summary, (2) is my preference, followed by (1), followed by (3).
> > 
> > Thanks,
> > Rob
> > 
> > >
> > >
> > > /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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Alexander Clemm]

+1 to (2) as preference, followed by (1).  I don't think (3) is needed here.  
The purpose is to make this human-readable and provide readers a good sense of 
the overall structure.  The authoritative specification is still the .yang 
itself.  Providing some guidance for how to represent the tree is good but 
let's not over-engineer this; I believe retaining some flexibility is good. 

--- Alex 

> -Original Message-
...
> > Does anyone else have an opinion on this?  I can see three
> > alternatives:
> >
> >1) allow any number of addtional spaces
> >2) allow any number of addtional spaces + define a suggested
> >   alignment algorithm
> >3) mandate the alignment algorithm
> 
> Definition of symbols should be precise/consistent, so that readers can
> consistently interpret tree diagrams.
> 
> I think that flexibility in layout should be OK, but the draft should provide
> guideline to ensure the output is readable, and likely to be broadly 
> consistent
> (since consistency aids readability).
> 
> If the IETF data modeling group is trying to specify text output precisely
> enough that it can be screen scraped then we may want to consider whether
> we are focusing on the right solution ;-)
> 
> In summary, (2) is my preference, followed by (1), followed by (3).
> 
> Thanks,
> Rob
> 
> >
> >
> > /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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/16/2018 06:34 PM, joel jaeggli wrote:



On 1/16/18 8:01 AM, Robert Wilton wrote:


On 16/01/2018 15:40, Martin Bjorklund wrote:

Vladimir Vassilev  wrote:



Does anyone else have an opinion on this?  I can see three
alternatives:

    1) allow any number of addtional spaces
    2) allow any number of addtional spaces + define a suggested
   alignment algorithm
    3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers
can consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft should
provide guideline to ensure the output is readable, and likely to be
broadly consistent (since consistency aids readability).

If the IETF data modeling group is trying to specify text output
precisely enough that it can be screen scraped then we may want to
consider whether we are focusing on the right solution ;-)

I would hope that we are not, as the diagrams are programmatically
generated if you wanted to for example validate them one should do that
from the sources.

Approaches that result in the most easily human readable, followed by
consistency between tools is probably better for that. That said this is
almost the indentation wars so the proscriptive it gets the more dissent
you can probably find (e.g. 3).

To make it clear I think 1) works with the text proposed by Martin.

As said I posted the pyang alignment algorithm description in a sort of 
2) variant only for reference on the mailing list since I implemented 
that too. Starting indentation war was not my intention.


As for the automated validation of the tree diagrams as an added value 
to the human readability I have the following thoughts. I would like to 
be able to compare unlimited line length tree outputs generated by 
different YANG compilers for equality. This is mainly a way to have some 
partial common denominator output for validating YANG is correctly 
compiled which we did not have until now. For example as soon as I have 
support for Schema mount I would compare the tree output with another 
tool known to work and add some testcases based on that. I do not see 
any automated alternative for doing this except writing NETCONF chat 
scripts (also module specific), or writing not only YANG module specific 
but also API specific test cases as 3rd option. 1) does not compromise 
this automated validation option since space sequences can be collapsed 
to single space. If the alignment algorithm was creating a possibility 
for nontrivial output variation then I would have supported strongly 3) 
but this is not the current case.


Vladimir



In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob



/martin



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

On 1/16/18 8:01 AM, Robert Wilton wrote:
>
>
> On 16/01/2018 15:40, Martin Bjorklund wrote:
>> Vladimir Vassilev  wrote:

>> Does anyone else have an opinion on this?  I can see three
>> alternatives:
>>
>>    1) allow any number of addtional spaces
>>    2) allow any number of addtional spaces + define a suggested
>>   alignment algorithm
>>    3) mandate the alignment algorithm
>
> Definition of symbols should be precise/consistent, so that readers
> can consistently interpret tree diagrams.
>
> I think that flexibility in layout should be OK, but the draft should
> provide guideline to ensure the output is readable, and likely to be
> broadly consistent (since consistency aids readability).
>
> If the IETF data modeling group is trying to specify text output
> precisely enough that it can be screen scraped then we may want to
> consider whether we are focusing on the right solution ;-)
I would hope that we are not, as the diagrams are programmatically 
generated if you wanted to for example validate them one should do that
from the sources. 

Approaches that result in the most easily human readable, followed by
consistency between tools is probably better for that. That said this is
almost the indentation wars so the proscriptive it gets the more dissent
you can probably find (e.g. 3).

> In summary, (2) is my preference, followed by (1), followed by (3).
>
> Thanks,
> Rob
>
>>
>>
>> /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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Robert Wilton]

On 16/01/2018 15:40, Martin Bjorklund wrote:

Vladimir Vassilev  wrote:

On 01/16/2018 11:56 AM, Martin Bjorklund wrote:


Vladimir Vassilev  wrote:

[...]


There is also undocumented alignment space count function before
 that pyang uses to align the  fields of child data leafs
with common ancestor. If this is specified in the draft the tree
output can be deterministic and for me this is an advantage. This is
currently one of the few underspecified pieces of the tree format so I
had to check pyang implementation in oder to generate same alignment
space counts and binary identical tree output results.

I think that we at least should write that there may be more than one
space between  and :

There may be any number of additional space characters between
 and .

For the sake of the argument (at least having this on the mailing list
as reference):

    should be aligned at a common offset for all sibling nodes
   from the start of  by adding trailing spaces. The recommended
   offset is 3 plus the length of the longest node name among all
sibling nodes
   including those siblings defined under choice and case nodes.

This is what pyang does now. It is not a perfect solution but it
allows identical output down to the bit.

Does anyone else have an opinion on this?  I can see three
alternatives:

   1) allow any number of addtional spaces
   2) allow any number of addtional spaces + define a suggested
  alignment algorithm
   3) mandate the alignment algorithm


Definition of symbols should be precise/consistent, so that readers can 
consistently interpret tree diagrams.


I think that flexibility in layout should be OK, but the draft should 
provide guideline to ensure the output is readable, and likely to be 
broadly consistent (since consistency aids readability).


If the IETF data modeling group is trying to specify text output 
precisely enough that it can be screen scraped then we may want to 
consider whether we are focusing on the right solution ;-)


In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob




/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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Lou Berger]

On 1/16/2018 10:08 AM, Vladimir Vassilev wrote:

4. This bit I found confusing. I propose this change to unambiguously
describe the current pyang format.

OLD:
   *  for a leaf-list or list
   [] for a list's keys
NEW:
   *  for a leaf-list or list without keys
   * [] for a list with keys

Hmm, wouldn't it be better to use [] for a list w/o keys?

Yes I also agree this improves readability at the cost of slight
redundancy increase and modification to format of diagrams already used
in RFCs. Your call.

Vladimir


(as contributor) I agree with martin on this point.

Lou

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Martin Bjorklund]

Vladimir Vassilev  wrote:
> On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
> 
> > Vladimir Vassilev  wrote:

[...]

> >> There is also undocumented alignment space count function before
> >>  that pyang uses to align the  fields of child data leafs
> >> with common ancestor. If this is specified in the draft the tree
> >> output can be deterministic and for me this is an advantage. This is
> >> currently one of the few underspecified pieces of the tree format so I
> >> had to check pyang implementation in oder to generate same alignment
> >> space counts and binary identical tree output results.
> > I think that we at least should write that there may be more than one
> > space between  and :
> >
> >There may be any number of additional space characters between
> > and .
> For the sake of the argument (at least having this on the mailing list
> as reference):
> 
>    should be aligned at a common offset for all sibling nodes
>   from the start of  by adding trailing spaces. The recommended
>   offset is 3 plus the length of the longest node name among all
> sibling nodes
>   including those siblings defined under choice and case nodes.
> 
> This is what pyang does now. It is not a perfect solution but it
> allows identical output down to the bit.

Does anyone else have an opinion on this?  I can see three
alternatives:

  1) allow any number of addtional spaces
  2) allow any number of addtional spaces + define a suggested
 alignment algorithm
  3) mandate the alignment algorithm


/martin

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Robert Wilton]

On 16/01/2018 15:08, Vladimir Vassilev wrote:

On 01/16/2018 11:56 AM, Martin Bjorklund wrote:


Vladimir Vassilev  wrote:





4. This bit I found confusing. I propose this change to unambiguously
describe the current pyang format.

OLD:
  *  for a leaf-list or list
  [] for a list's keys
NEW:
  *  for a leaf-list or list without keys
  * [] for a list with keys

Hmm, wouldn't it be better to use [] for a list w/o keys?
Yes I also agree this improves readability at the cost of slight 
redundancy increase and modification to format of diagrams already 
used in RFCs. Your call.


I like the idea of using [] for a list without keys, to cleanly 
differentiate list vs leaf-list.


I presume that they don't turn up that much in practice, so presumably 
not many RFC's would be impacted.


Thanks,
Rob

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/16/2018 11:56 AM, Martin Bjorklund wrote:


Vladimir Vassilev  wrote:

Hi,

I have reviewed and implemented (apart from schema mount specific
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found
the following issues:

==sec 2.6.  Node Representation==

1. To correctly reflect the current pyang output one needs to add '--'
between  and .
OLD:
      
NEW:
     --

Ok.


There is also undocumented alignment space count function before
 that pyang uses to align the  fields of child data leafs
with common ancestor. If this is specified in the draft the tree
output can be deterministic and for me this is an advantage. This is
currently one of the few underspecified pieces of the tree format so I
had to check pyang implementation in oder to generate same alignment
space counts and binary identical tree output results.

I think that we at least should write that there may be more than one
space between  and :

   There may be any number of additional space characters between
and .
For the sake of the argument (at least having this on the mailing list 
as reference):


   should be aligned at a common offset for all sibling nodes
  from the start of  by adding trailing spaces. The recommended
  offset is 3 plus the length of the longest node name among all 
sibling nodes

  including those siblings defined under choice and case nodes.

This is what pyang does now. It is not a perfect solution but it allows 
identical output down to the bit.




I also just realized that we need to add text to the line wrapping
section about line breaks between  and :

OLD:

Internet Drafts and RFCs limit the number of characters that may in a
line of text to 72 characters.  When the tree representation of a
node results in line being longer than this limit the line should be
broken between  and .  The type should be indented so
that the new line starts below  with a white space offset of at
least two characters.

NEW:

Internet Drafts and RFCs limit the number of characters in a line
of text to 72 characters.  When the tree representation of a node
results in line being longer than this limit the line should be
broken between  and , or between  and
.  The new line should be indented so that it starts
below  with a white space offset of at least two characters.



2. It is unclear which  option should be used for rpc and
action input/output and child nodes and the notification child
nodes. pyang uses '-w' for input and input/* and 'ro' for output and
output/*:

     module: ietf-netconf-partial-lock
   rpcs:
     +---x partial-lock
     |  +---w input
     |  |  +---w select*   string
     ...

I'll do:

OLD:

 is one of:
  rw  for configuration data
  ro  for non-configuration data
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statment

NEW:

 is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statment

OK



pyang also uses '--' as  for augmentation data nodes for
actions input.

I think that this is a bug in pyang, which I have now fixed.

OK



     ...
   augment
/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
     + destination-address?   inet:ipv4-address
     ...


3. pyang is prefixing choice node names with the parent 
e.g. +--ro (next-hop-options) while case nodes are not prefixed. I
guess this is a bug in pyang since it is not specified in the draft
but choice nodes prefixed with parent  are  also present in the
sec 4 and 4.1 examples?

[ignoring based on latest email from Vladimir]


4. This bit I found confusing. I propose this change to unambiguously
describe the current pyang format.

OLD:
  *  for a leaf-list or list
  [] for a list's keys
NEW:
  *  for a leaf-list or list without keys
  * [] for a list with keys

Hmm, wouldn't it be better to use [] for a list w/o keys?
Yes I also agree this improves readability at the cost of slight 
redundancy increase and modification to format of diagrams already used 
in RFCs. Your call.


Vladimir



/martin




Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

   YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to 

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Martin Bjorklund]

Vladimir Vassilev  wrote:
> Hi,
> 
> I have reviewed and implemented (apart from schema mount specific
> functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found
> the following issues:
> 
> ==sec 2.6.  Node Representation==
> 
> 1. To correctly reflect the current pyang output one needs to add '--'
> between  and .
> OLD:
>      
> NEW:
>     --

Ok.

> There is also undocumented alignment space count function before
>  that pyang uses to align the  fields of child data leafs
> with common ancestor. If this is specified in the draft the tree
> output can be deterministic and for me this is an advantage. This is
> currently one of the few underspecified pieces of the tree format so I
> had to check pyang implementation in oder to generate same alignment
> space counts and binary identical tree output results.

I think that we at least should write that there may be more than one
space between  and :

  There may be any number of additional space characters between
   and .


I also just realized that we need to add text to the line wrapping
section about line breaks between  and :

OLD:

   Internet Drafts and RFCs limit the number of characters that may in a
   line of text to 72 characters.  When the tree representation of a
   node results in line being longer than this limit the line should be
   broken between  and .  The type should be indented so
   that the new line starts below  with a white space offset of at
   least two characters.

NEW:

   Internet Drafts and RFCs limit the number of characters in a line
   of text to 72 characters.  When the tree representation of a node
   results in line being longer than this limit the line should be
   broken between  and , or between  and
   .  The new line should be indented so that it starts
   below  with a white space offset of at least two characters.


> 2. It is unclear which  option should be used for rpc and
> action input/output and child nodes and the notification child
> nodes. pyang uses '-w' for input and input/* and 'ro' for output and
> output/*:
> 
>     module: ietf-netconf-partial-lock
>   rpcs:
>     +---x partial-lock
>     |  +---w input
>     |  |  +---w select*   string
>     ...

I'll do:

OLD:

is one of:
 rw  for configuration data
 ro  for non-configuration data
 -u  for uses of a grouping
 -x  for rpcs and actions
 -n  for notifications
 mp  for nodes containing a "mount-point" extension statment

NEW:

is one of:
 rw  for configuration data
 ro  for non-configuration data, output parameters to rpcs
 and actions, and notification parameters
 -w  for input parameters to rpcs and actions
 -u  for uses of a grouping
 -x  for rpcs and actions
 -n  for notifications
 mp  for nodes containing a "mount-point" extension statment

> pyang also uses '--' as  for augmentation data nodes for
> actions input.

I think that this is a bug in pyang, which I have now fixed.

>     ...
>   augment
> /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
>     + destination-address?   inet:ipv4-address
>     ...
> 
> 
> 3. pyang is prefixing choice node names with the parent 
> e.g. +--ro (next-hop-options) while case nodes are not prefixed. I
> guess this is a bug in pyang since it is not specified in the draft
> but choice nodes prefixed with parent  are  also present in the
> sec 4 and 4.1 examples?

[ignoring based on latest email from Vladimir]

> 4. This bit I found confusing. I propose this change to unambiguously
> describe the current pyang format.
> 
> OLD:
>  *  for a leaf-list or list
>  [] for a list's keys
> NEW:
>  *  for a leaf-list or list without keys
>  * [] for a list with keys

Hmm, wouldn't it be better to use [] for a list w/o keys?


/martin



> 
> Vladimir
> 
> On 01/01/2018 11:01 PM, joel jaeggli wrote:
> > Greetings,
> >
> > We hope  the new year is a time to make great progess on outstanding
> > documents before preparation for the  London IETF begins in earnest.
> >
> > This starts a two-week working group last call on:
> >
> >   YANG Tree Diagrams
> > draft-ietf-netmod-yang-tree-diagrams
> >
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
> >
> > Please send email to the list indicating your support or concerns.
> >
> > We are particularly interested in statements of the form:
> >
> >* I have reviewed this draft and found no issues.
> >* I have reviewed this draft and found the following issues: ...
> >
> >
> > Thank you,
> > NETMOD WG 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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/15/2018 09:41 PM, Vladimir Vassilev wrote:

Hi,

I have reviewed and implemented (apart from schema mount specific 
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found 
the following issues:


==sec 2.6.  Node Representation==

1. To correctly reflect the current pyang output one needs to add '--' 
between  and .

OLD:
     
NEW:
    --

There is also undocumented alignment space count function before 
 that pyang uses to align the  fields of child data leafs 
with common ancestor. If this is specified in the draft the tree 
output can be deterministic and for me this is an advantage. This is 
currently one of the few underspecified pieces of the tree format so I 
had to check pyang implementation in oder to generate same alignment 
space counts and binary identical tree output results.



2. It is unclear which  option should be used for rpc and 
action input/output and child nodes and the notification child nodes. 
pyang uses '-w' for input and input/* and 'ro' for output and output/*:


    module: ietf-netconf-partial-lock
  rpcs:
    +---x partial-lock
    |  +---w input
    |  |  +---w select*   string
    ...

pyang also uses '--' as  for augmentation data nodes for 
actions input.


    ...
  augment /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
    + destination-address?   inet:ipv4-address
    ...


3. pyang is prefixing choice node names with the parent  e.g. 
+--ro (next-hop-options) while case nodes are not prefixed. I guess 
this is a bug in pyang since it is not specified in the draft but 
choice nodes prefixed with parent  are  also present in the sec 
4 and 4.1 examples?
Ignore 3. choice had a config substatement which explains the presence 
of .


4. This bit I found confusing. I propose this change to unambiguously 
describe the current pyang format.


OLD:
 *  for a leaf-list or list
 [] for a list's keys
NEW:
 *  for a leaf-list or list without keys
 * [] for a list with keys

Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG 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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

Hi,

I have reviewed and implemented (apart from schema mount specific 
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found the 
following issues:


==sec 2.6.  Node Representation==

1. To correctly reflect the current pyang output one needs to add '--' 
between  and .

OLD:
     
NEW:
    --

There is also undocumented alignment space count function before  
that pyang uses to align the  fields of child data leafs with 
common ancestor. If this is specified in the draft the tree output can 
be deterministic and for me this is an advantage. This is currently one 
of the few underspecified pieces of the tree format so I had to check 
pyang implementation in oder to generate same alignment space counts and 
binary identical tree output results.



2. It is unclear which  option should be used for rpc and action 
input/output and child nodes and the notification child nodes. pyang 
uses '-w' for input and input/* and 'ro' for output and output/*:


    module: ietf-netconf-partial-lock
  rpcs:
    +---x partial-lock
    |  +---w input
    |  |  +---w select*   string
    ...

pyang also uses '--' as  for augmentation data nodes for actions 
input.


    ...
  augment /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
    + destination-address?   inet:ipv4-address
    ...


3. pyang is prefixing choice node names with the parent  e.g. 
+--ro (next-hop-options) while case nodes are not prefixed. I guess this 
is a bug in pyang since it is not specified in the draft but choice 
nodes prefixed with parent  are  also present in the sec 4 and 
4.1 examples?


4. This bit I found confusing. I propose this change to unambiguously 
describe the current pyang format.


OLD:
 *  for a leaf-list or list
 [] for a list's keys
NEW:
 *  for a leaf-list or list without keys
 * [] for a list with keys

Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs


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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Robert Wilton]

Hi,

I agree with all of Benoit's points below.

On 13/01/2018 14:08, Benoit Claise wrote:

Hi Tom,

IMO, the best to proceed is exactly like done in the RIP draft.
Some sections 2.* explains how the module was build, based one 
excerpts of the tree diagram.
Yes, smaller chunks of tree output can be very useful to explain parts 
of the model.




Then we have the full tree if someone wants to see the big structure.
Yes, personally, I think that it is probably useful to have the full 
tree output as a reference (probably even if it is 10 pages long). If it 
is particularly long then it would be better put into an appendix.




In the end, the tree view should be browsed with tooling.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
   => Yang catalog entry for ietf-...@2018-01-09.yang 

   => [Tree View for ietf-rip] Tree View 

+1, having a GUI interface into YANG modules (and the combined YANG tree 
with all standard YANG models augmented together) seems like it should 
be the future.





Regards, Benoit

I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.

I think its hard to judge whether a module is too flat or not.

I'm more concerned that YANG groupings make it easy to repeat large 
chunks of YANG in multiple places in a module tree, and I'm not 
convinced that this is always the right thing to do.  Sometimes it may 
be better to add a layer of indrection to avoid the need to reuse the 
same large chunk of YANG in multiple places in the tree. Of course, this 
is all highly subjective ...


Thanks,
Rob




Tom Petch

- Original Message -
From: "joel jaeggli"
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG 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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Benoit Claise]

Hi Tom,

IMO, the best to proceed is exactly like done in the RIP draft.
Some sections 2.* explains how the module was build, based one excerpts 
of the tree diagram.

Then we have the full tree if someone wants to see the big structure.

In the end, the tree view should be browsed with tooling.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
   => Yang catalog entry for ietf-...@2018-01-09.yang 

   => [Tree View for ietf-rip] Tree View 



Regards, Benoit

I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.

Tom Petch

- Original Message -
From: "joel jaeggli" 
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG 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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[t.petch]

I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.

Tom Petch

- Original Message -
From: "joel jaeggli" 
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG 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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[joel jaeggli]

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs






signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod