Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

[Kent Watsen]

Hi Italo,

> On Mar 4, 2024, at 1:38 PM, Italo Busi 
>  wrote:
> 
> I am wondering whether the issue of YANG tree too-long could be resolved by 
> updating the IETF tooling. For example, I have noted that the html-ized 
> version of the I-Ds is now working well with artwork exceeding the 72 
> characters limit …
>  
> Maybe the html or html-ized version of the I-D/RFC might include the jstree 
> pyang output instead of the tree pyang output

This is what I’ve been saying for awhile now.

Datatracker should unfold folded-artwork for formats like HTML that can provide 
horizontal scrollbars.

That said, the desire to break tree-diagrams into pieces won’t be resolved, as 
authors still need to support plain-text output…  grrr


Personally, I prefer whole-trees (if not folded), which are much easier to 
place into a document, but many in the WG push for tree-diagram snippets.   
Hope we can reach a consensus on this…

K


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

Re: [netmod] Deviating in circles

[Mahesh Jethanandani]

Hi Jan,

See inline

> On Mar 4, 2024, at 11:26 AM, Jan Lindblad (jlindbla) 
>  wrote:
> 
> Reshad,
> 
>> Does the same question arise with augments?
> 
> No, I don't think so. Augments cannot modify existing namespaces, only add 
> content in their own namespace, then graft that namespace onto some existing 
> module. If that existing module imports the augmenting module, I would 
> imagine all YANG compilers would catch the attempt to create an import loop.
> 
>> Inline.
> ...
>> Is the construct in module d legal? RFC 7950 is not very clear on the 
>> subject, but it does say:
>> 
>>After applying all deviations announced by a server, in any order,
>>the resulting data model MUST still be valid.
>> 
>> If "applying" means actually replacing the original module text with the 
>> deviated text, then I'm fairly sure module d would violate the rule against 
>> circular imports. If "applying" is something that happens on a more "global" 
>> or "logical" level, then maybe this should be allowed?
>> 
>>  I don't know what was the intention of the 7950 authors and not even 
>> sure what would be the "right thing". My guess would be it's more in the 
>> "logical" level.
>> 
>> By allowing deviations of this kind, we might create a temptation for people 
>> to use deviations for their own modules in order to create YANG structures 
>> otherwise not possible. I find this problematic, since I don't like 
>> deviations much. On the other hand, allowing deviations of this kind 
>> increases the freedom of expression in the YANG world. I think many would 
>> regard a moratorium as another YANG CLR (crappy little rule).
>> 
>> If we were to decide that this sort of deviation is allowed, wouldn't a 
>> logical conclusion be that we should drop the circular imports rule? 
>> Compilers could very well track which modules have already been imported 
>> (like in python), and not go into unbounded spin just because there is a 
>> circular reference loop.
>> 
>>  yang-next?
> 
> We could of course clarify this or change the rules in yang-next once we know 
> what we want (I'm split on this one), but I was interested in the opinion of 
> the list whether this is allowed today.
> 

Please continue to have the discussion here, but suggest you create a new issue 
here , so the issue can be 
tracked.

Cheers.


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


Mahesh Jethanandani
mjethanand...@gmail.com






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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-semver-14.txt

[Joe Clarke (jclarke)]

NETMOD WG,

In conjunction with Reshad’s email on module versioning, this updated YANG 
Semver draft covers a lot of ground and is complimentary with that work.  Many 
of these changes were raised on-list as part of our key issues.  They were also 
discussed at IETF 118.

NOTE: Due to some changes moving from module versioning to Semver, I left out 
IANA considerations in rev -13, so I recommend people view the diff from -12 to 
-14 to get the full scope of the work (see 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-yang-semver-12=draft-ietf-netmod-yang-semver-14=--html)

Summary of the changes:


  *   With the removal of the revision-label-scheme, YANG Semver introduces the 
concept of an artifact (i.e., module or package) version.
  *   This version is also augmented into ietf-yang-library (previously 
described in module versioning).
  *   A new recommended-min-version extension was added to facilitate import by 
YANG Semver (and multiple recommended-min-versions are permitted).
  *   The import rules have been simplified such that importing by 
recommended-min-version follows – hopefully intuitive – numeric rules.
  *   A figure has been added in both module versioning and early-on in YANG 
Semver to illustrate how YANG Semver works with branching.
  *   The namespace for YANG Semver has been renamed “ys”.  So the extension 
for version is ys:version.

Joe (on behalf of the authors and contributors)

From: netmod  on behalf of internet-dra...@ietf.org 

Date: Monday, March 4, 2024 at 14:47
To: i-d-annou...@ietf.org 
Cc: netmod@ietf.org 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-semver-14.txt
Internet-Draft draft-ietf-netmod-yang-semver-14.txt is now available. It is a
work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   YANG Semantic Versioning
   Authors: Joe Clarke
Robert Wilton
Reshad Rahman
Balazs Lengyel
Jason Sterne
Benoit Claise
   Name:draft-ietf-netmod-yang-semver-14.txt
   Pages:   34
   Dates:   2024-03-04

Abstract:

   This document specifies a YANG extension along with guidelines for
   applying an extended set of semantic versioning rules to revisions of
   YANG artifacts (e.g., modules and packages).  Additionally, this
   document defines a YANG extension for controlling module imports
   based on these modified semantic versioning rules.  This document
   updates RFCs 7950, 8407, and 8525.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-14.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-semver-14

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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] [core] WG Last Call on draft-ietf-core-comi-16

[Carsten Bormann]

Hi Tom,

thank you for this feedback, which I only now get to put into the next revision 
of the draft.
The changes marked here with a “commit” number are both in the repository ([1], 
see [2]) and in draft-ietf-core-comi-17.

[1]: https://github.com/core-wg/comi
[2]: https://github.com/core-wg/comi/commits/main/


> On 2023-09-06, at 18:22, tom petch  wrote:
> 
> […]
> 
> I was slightly surprised when I got to the IANA Considerations and found the 
> registration of a YANG module which I had yet to see.  

Did we miss any formal steps?

> One convention is that Appendices are Informative not Normative so I would 
> suggest moving the YANG module into the body of the document or adding a 
> statement to the Appendix that this is Normative and putting in  a forward 
> reference in the IANA Considerations to the module.

Added statement in c72d08c, forward references in 790e8e7

> 'This draft...' in several places

Oops: 78521d0

> YANG import lack references which need to be Normative.

commit: 7d5784f

> Simplified BSD license is OOD

commit: 5795b5a

> As is the copyright.

commit: d3c50b3

> YANG contact lacks WG details
> 
> The YANG module authors are not quite the same as the I-D authors while the 
> authors' addresses at the end are different yet again

There were indeed a few updates needed to author and contact information.
commit: 542f3c8

> 'create or list instance,'
> perhaps
> 'create a list instance,'

commit: 50b6a1b

Thank you again for this review!

Grüße, Carsten


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

Re: [netmod] [core] WG Last Call on draft-ietf-core-comi-16

[Carsten Bormann]

Hi Andy,

I never got around to answering your feedback in the context of an updated 
document.
The changes marked here with a “commit” number are both in the repository ([1], 
see [2], where also the issues were created) and in draft-ietf-core-comi-17.

[1]: https://github.com/core-wg/comi
[2]: https://github.com/core-wg/comi/commits/main/

On 2023-09-07, at 22:28, Andy Bierman  wrote:
> 
> Hi,
> 
> I have some minor comments about this draft.
> I did not find any major issues.  It is almost ready for publication.
> 
> 
> Andy
> 
> 
> # comments on draft-ietf-core-comi-16
> 
> ## sec 2.3
> 
> Examples of each media type would be helpful here

Indeed.  The current document doesn’t have those; captured as 
https://github.com/core-wg/comi/issues/14

> ## sec 2.4
> 
> It is not clear how any interoperability would be possible
> if the server used some other datastore design.
> Para 2 should be removed or there should be a complete
> specification how NMDA datastores work in CORECONF.

Indeed.
This is clarified now both in the definitions at the start of Section 2 and in 
Section 2.4 (commit b06f134).

> ## sec 3.1.3
> 
> For compactness, indexes of the list instance identifiers
> returned by the FETCH response SHOULD be elided, only the
> SID is provided.
> 
> If this encoding is used then the FETCH response will
> not conform to the application/yang-instances+cbor-seq
> media-type.

A SID is a valid instance-identifier, so the representation still conforms to 
the media type (which is a sequence of maps from instance-identifiers to 
instance values).

> It could be more clear that the client is responsible
> for remembering the instance information for each
> varbind in the request since no key values will be in
> the response.

Added a sentence to this effect (commit 1f48edf).

> ## FETCH design issues
> 
> The client must know all of the key values in advance
> before being able to use the SID of a data node
> in a FETCH request.  It is difficult and expensive
> to retrieve the entire datastore contents at once,
> just to discover the key values in use for the YANG list
> entries within the datastore.
> 
> RESTCONF has the 'depth' and 'fields' filter parameters
> to address this issue. NETCONF has subtree and XPath filtering.
> NETCONF servers can generally support selection of 1 value or all
> values, for each key.
> 
> Perhaps CORECONF will need the 'depth' filter parameter.

I captured this as https://github.com/core-wg/comi/issues/15

> ## sec 3.2.3
> 
> It is not clear if there are any server requirements
> for error handling.  What happens if some (but not all)
> of the edit varbinds succeed?  Is the datastore left
> in a state such that YANG validation does not pass?
> How Are partial edits reported to the client?
> 
> Most NETCONF and RESTCONF servers implement an all-or-none
> design so that error-option='rollback-on-error' is always done.
> Perhaps CORECONF needs a SHOULD apply all-or-none for iPATCH?

All-or-none is indeed the intention.
Error handling is described in Section 6, but that also seems to miss an 
indication that this is the correct outcome.

While all-or-none processing could be considered to be implicit in the design 
of CoAP, I added a sentence at the start making this explicit (commit 79f35e1).

> ## sec 3.5.1
> 
> IMO there should be a SID file 'item' list shown for
> the examples.  

I found the examples quite readable without such a list.

> IMO it is confusing that the SID assignments
> do not follow the standard algorithm.

There isn’t really a “standard” algorithm; I’m assuming you mean this 
consideration:

> Since the 'input' or 'output' SID is actually used in
> protocol messages,

Actually, the examples should show how we are eliding the input/output sids, 
which is the reason non-contiguous assignment is actually optimal.

> the delta values for the child nodes
> are not optimal unless the correct path strings are sorted.
> 
> There is a cur-and-paste error:
> 
> OLD:
> 
>  This example invokes the 'reboot' RPC (SID 61000), of the
>  server instance with name equal to "myserver".
> 
> NEW:
> 
>  This example invokes the 'reboot' RPC (SID 61000).

Indeed (commit a0a00cd)

> 
> ## sec 3.5.1
> 
> REQ:  POST 
>   (Content-Format: application/yang-instances+cbor-seq)
> 
> { 61000:
>   {
> 1 : 77
>   }
> }
> RES:  2.04 Changed
>   (Content-Format: application/yang-instances+cbor-seq)
> 
> { 61000:
>   null
> }
> 
> I am not sure 2.04 Changed the the correct status to match '200 OK'

RFC 7252 Section 5.8.2 is quite explicit about this.

> The example RPC does not define any 'output' section
> so the response should not have any payload at all.

It is not quite clear to me how this would work with a POST that addresses 
multiple nodes.  This is not visible from the example, which attempts to stay 
simple, but the elements of the CBOR map sequences used in requests and 
responses need to match 

[netmod] I-D Action: draft-ietf-netmod-yang-semver-14.txt

[internet-drafts]

Internet-Draft draft-ietf-netmod-yang-semver-14.txt is now available. It is a
work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   YANG Semantic Versioning
   Authors: Joe Clarke
Robert Wilton
Reshad Rahman
Balazs Lengyel
Jason Sterne
Benoit Claise
   Name:draft-ietf-netmod-yang-semver-14.txt
   Pages:   34
   Dates:   2024-03-04

Abstract:

   This document specifies a YANG extension along with guidelines for
   applying an extended set of semantic versioning rules to revisions of
   YANG artifacts (e.g., modules and packages).  Additionally, this
   document defines a YANG extension for controlling module imports
   based on these modified semantic versioning rules.  This document
   updates RFCs 7950, 8407, and 8525.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-14.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-semver-14

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

[Jürgen Schönwälder]

Hi,

the statement "should be selected carefully to be unique" is
impossible to implement given an open ended set of YANG modules.
If this section only applies to IETF modules (I thought it is
more general) and IANA never makes a mistake and we accept
that prefixes get longer or cryptic over time, then this may
be possible to implement, but I am not sure this is actually
desirable.

The original wording "likely to be unique" was selected
carefully, it conveys the message that prefixes can't be
assumed to be unique. Perhaps it should be even further
watered down to "likely to be unique in a certain usage
context".

I believe the original wording was good enough and does not
need an update. Every update, even if well intended, carries
a risk to break something that works.

/js

On 04.03.24 19:39, Randy Presuhn wrote:

Hi -

On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote:

Hi Jan,

I went so far with the following:

OLD:

    Prefix values SHOULD be short but are also likely to be unique.

    Prefix values SHOULD NOT conflict with known modules that have been

previously published.

NEW:

    Prefix values should be selected carefully to be unique, and ideally

    not too long.  Specifically, prefix values SHOULD NOT conflict with

    known modules that have been previously published.

I’m having troubles with the normative language here. If we maintain 
the two sentences, the second SHOULD is sufficient for the uniqueness 
IMO.


Also, as per RFC2119, we should clarify when the SHOULD NOT can be 
safely ignored:


    SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that

    there may exist valid reasons in particular circumstances when the

    particular behavior is acceptable or even useful, but the full

    implications should be understood and the case carefully weighed

    before implementing any behavior described with this label.

An obvious case is an updated version of a published version.

...

In dealing with SHOULD statements in RFCs, both as an implementor
and as a specification writer, I find it useful to re-phrase (at least
in my head) a "SHOULD NOT X" as "MUST be able to cope with others
doing X, even if it does not itself do X."

A "SHOULD NOT X" in a specification does NOT relieve implementations
of the duty to work correctly when X happens, because "SHOULD NOT X"
means that X is indeed permitted, even if discouraged.  If X causes a
an implementation pair to violate protocol or miscommunicate (e.g.
referencing the wrong syntax or semantics) at some level, then it
really needs to be a "MUST NOT".

But this is an old, old argument, and gliding along with "likely
uniqueness" rather than uniqueness has been a longstanding
bug/feature of netmod.  I'd just like to see a bit more guidance
for implementors so their products don't crash and burn when they
do encounter "duplicate" prefixes in the wild.

Randy

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


--
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany

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

Re: [netmod] Deviating in circles

[Jan Lindblad (jlindbla)]

Reshad,

Does the same question arise with augments?

No, I don't think so. Augments cannot modify existing namespaces, only add 
content in their own namespace, then graft that namespace onto some existing 
module. If that existing module imports the augmenting module, I would imagine 
all YANG compilers would catch the attempt to create an import loop.

Inline.
...
Is the construct in module d legal? RFC 7950 is not very clear on the subject, 
but it does say:

   After applying all deviations announced by a server, in any order,
   the resulting data model MUST still be valid.

If "applying" means actually replacing the original module text with the 
deviated text, then I'm fairly sure module d would violate the rule against 
circular imports. If "applying" is something that happens on a more "global" or 
"logical" level, then maybe this should be allowed?

 I don't know what was the intention of the 7950 authors and not even sure 
what would be the "right thing". My guess would be it's more in the "logical" 
level.

By allowing deviations of this kind, we might create a temptation for people to 
use deviations for their own modules in order to create YANG structures 
otherwise not possible. I find this problematic, since I don't like deviations 
much. On the other hand, allowing deviations of this kind increases the freedom 
of expression in the YANG world. I think many would regard a moratorium as 
another YANG CLR (crappy little rule).

If we were to decide that this sort of deviation is allowed, wouldn't a logical 
conclusion be that we should drop the circular imports rule? Compilers could 
very well track which modules have already been imported (like in python), and 
not go into unbounded spin just because there is a circular reference loop.

 yang-next?

We could of course clarify this or change the rules in yang-next once we know 
what we want (I'm split on this one), but I was interested in the opinion of 
the list whether this is allowed today.

Best Regards,
/jan

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

Re: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

[Italo Busi]

I support the adoption of this document as a WG draft

In this update, the technical concerns raised on the list have been addressed, 
making this draft a technically solid and common solution to address the 
different use cases where providing this information is needed

Italo

From: Kent Watsen 
Sent: giovedì 22 febbraio 2024 18:42
To: netmod@ietf.org
Subject: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

NETMOD WG,

This email begins a 2-week adoption poll for:

YANG Metadata Annotation for Immutable Flag

https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09

There is no known IPR on this draft:

https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/

Please voice your support or technical objections to adoption on the list by 
the end of the day Mar 7 (any time zone).

PS: This draft was discussed in our recent Interim, where a show-of-hands hands 
showed unanimous support for adoption.

Thank you,
Kent (as co-chair)

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

Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

[Randy Presuhn]

Hi -

On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote:

Hi Jan,

I went so far with the following:

OLD:

    Prefix values SHOULD be short but are also likely to be unique.

    Prefix values SHOULD NOT conflict with known modules that have been

previously published.

NEW:

    Prefix values should be selected carefully to be unique, and ideally

    not too long.  Specifically, prefix values SHOULD NOT conflict with

    known modules that have been previously published.

I’m having troubles with the normative language here. If we maintain the 
two sentences, the second SHOULD is sufficient for the uniqueness IMO.


Also, as per RFC2119, we should clarify when the SHOULD NOT can be 
safely ignored:


    SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that

    there may exist valid reasons in particular circumstances when the

    particular behavior is acceptable or even useful, but the full

    implications should be understood and the case carefully weighed

    before implementing any behavior described with this label.

An obvious case is an updated version of a published version.

...

In dealing with SHOULD statements in RFCs, both as an implementor
and as a specification writer, I find it useful to re-phrase (at least
in my head) a "SHOULD NOT X" as "MUST be able to cope with others
doing X, even if it does not itself do X."

A "SHOULD NOT X" in a specification does NOT relieve implementations
of the duty to work correctly when X happens, because "SHOULD NOT X"
means that X is indeed permitted, even if discouraged.  If X causes a
an implementation pair to violate protocol or miscommunicate (e.g.
referencing the wrong syntax or semantics) at some level, then it
really needs to be a "MUST NOT".

But this is an old, old argument, and gliding along with "likely
uniqueness" rather than uniqueness has been a longstanding
bug/feature of netmod.  I'd just like to see a bit more guidance
for implementors so their products don't crash and burn when they
do encounter "duplicate" prefixes in the wild.

Randy

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

Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

[Italo Busi]

Hi Med,

In my personal experience, I have found the YANG tree included in the IETF 
RFCs/I-Ds useful only when they are complete, even if they are too long

In RFC8795 you can find an example of a too-long YANG tree which I am using 
quite often

I have found YANG trees with unexpanded grouping almost impossible to use. In 
draft-ietf-teas-yang-te you can find an example of a YANG tree with unexpanded 
grouping which I am not using at all. In this case, I refer to the YANG catalog 
to get the complete tree

I have also found the YANG tree pieces almost useless (even if much better than 
the YANG trees with unexpanded grouping) without some overview. RFC8348 is an 
example of YANG tree pieces which I am using very rarely. In most of the cases, 
I refer to the YANG catalog to get the complete tree

I am wondering whether the issue of YANG tree too-long could be resolved by 
updating the IETF tooling. For example, I have noted that the html-ized version 
of the I-Ds is now working well with artwork exceeding the 72 characters limit …

Maybe the html or html-ized version of the I-D/RFC might include the jstree 
pyang output instead of the tree pyang output

My 2 cents

Italo

From: Qin Wu 
Sent: giovedì 29 febbraio 2024 02:51
To: Mahesh Jethanandani ; mohamed.boucad...@orange.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

+1,  a few thoughts to share.

I know this is tricky question related to tooling or artifact generation and 
representation.
I am wondering whether we can make YANG tree diagram in a "collapsed" state 
where all the Leaf nodes and only leaf nodes are hidden from view until its 
parent node is expanded, which can improve readability of the tree diagram,
In many cases can greatly reduce the size of YANG tree diagram, make it fit 
into one page.

Moving compete tree diagram or artifacts is another option we can pursue. Also 
generating YANG tree along with YANG file in 
https://github.com/YangModels/yang/tree/main/standard/ietf
Is another option we can take a look at.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Mahesh Jethanandani
发送时间: 2024年2月29日 7:02
收件人: mohamed.boucad...@orange.com
抄送: netmod@ietf.org
主题: Re: [netmod] Long trees RE: Next steps for draft-ietf-netmod-rfc8407bis

I would agree with Andy that it is not clear how long is “too long”.

BGP YANG model, which is perhaps one of the biggest models at 150 pages long, 
has multiple tree diagrams none of which are more than one page long.

If the complete tree diagram is too long, could it moved to the Appendix, 
instead of banishing it from the document completely? Sorry Jan, but I hope no 
one is cutting down trees to read the entire tree diagram. Sometimes, albeit 
rarely, it is helpful to have the complete tree diagram handy to reference 
where a particular node is in the tree.

Cheers.

On Feb 28, 2024, at 8:29 AM, 
mohamed.boucad...@orange.com wrote:

Hi Jan,

Thanks for the comments.

Here is a first attempt to address the long trees point while taking into 
account expanded/unexpanded uses:

NEW:
   YANG tree diagrams provide a concise representation of a YANG module
   and SHOULD be included to help readers understand YANG module
   structure.  If the complete tree diagram for a module becomes too
   long, the diagram SHOULD be split into several smaller diagrams.  If
   the complete tree diagram is too long even with groupings unexpanded
   (Section 2.2 of [RFC8340]), authors SHOULD NOT include it in the
   document.

   These guidelines take precedence over the generic guidance in
   Section 3 of [RFC8340].

For convenience a diff for the proposed change can be 
seenhttps://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt_2=https://boucadair.github.io/rfc8407bis/long-trees/draft-ietf-netmod-rfc8407bis.txt

Cheers,
Med

De : Jan Lindblad mailto:j...@tail-f.com>>
Envoyé : mercredi 28 février 2024 15:21
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : netmod@ietf.org
Objet : Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

Med, author team,

Thank you for taking the time to get this work done, and well done! This is one 
of those fundamental bricks that saves time and improves quality for the entire 
YANG community.

I read the -09 version and like what I see. I have a couple of minor 
suggestions you might consider.

+ In section 3.4 about tree diagrams, the section text is already advocating 
intermixing smaller tree snippets with explanations (which is great), but I 
wish we could say that
tree diagrams of entire modules SHOULD NOT be included. Just a waste of forest 
and attention span, imho.

+ In section 4.2 about choice of prefixes, it is said that "Prefix values 
SHOULD be short but are also likely to be unique." I used to say the same 

[netmod] FW: New Version Notification for draft-jouqui-netmod-yang-full-include-01.txt

[Jean Quilbeuf]

Hello NETMOD,
This new draft tries to define the inclusion of an existing YANG model into 
another YANG model, without using grouping or augment.

The driving use cases are to reuse device-level modules (i.e. where the root 
context is the device) into network-level YANG modules (i.e. where the root 
context is the network, and to access a device context one must follow a path 
such as /devices/device[id=deviceid]). One of these use cases is 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/ 

The difference with Schema Mount (RFC8528) is that we focus on a pure YANG 
solution (i.e. design-time), without the need to configure a server with the 
content of the mount-points.

Best,
Jean

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, March 4, 2024 2:48 PM
> To: Benoit Claise ; Jean Quilbeuf
> ; Thomas Joubert  partners.com>
> Subject: New Version Notification for draft-jouqui-netmod-yang-full-include-
> 01.txt
> 
> A new version of Internet-Draft draft-jouqui-netmod-yang-full-include-01.txt
> has been successfully submitted by Jean Quilbeuf and posted to the IETF
> repository.
> 
> Name: draft-jouqui-netmod-yang-full-include
> Revision: 01
> Title:YANG Full Embed
> Date: 2024-03-04
> Group:Individual Submission
> Pages:17
> URL:  
> https://www.ietf.org/archive/id/draft-jouqui-netmod-yang-full-include-01.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-jouqui-netmod-yang-full-include/
> HTML: 
> https://www.ietf.org/archive/id/draft-jouqui-netmod-yang-full-include-01.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-jouqui-netmod-yang-full-include
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-jouqui-netmod-yang-full-include-01
> 
> Abstract:
> 
>YANG lacks re-usability of models defined outside of the grouping and
>augmentation mechanisms.  For instance, it is almost impossible to
>reuse a model defined for a device in the context of the network, i.e
>by encapsulating it in a list indexed by device IDs.  [RFC8528]
>defines the YANG mount mechanism, partially solving the problem by
>allowing to mount an arbitrary set of schemas at an arbitrary point.
>However, YANG mount is only focusing on deploy or runtime.  This
>document aims to provide the same mechanism at design time.
> 
> 
> 
> The IETF Secretariat
> 

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

[netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

[mohamed . boucadair]

Hi Jan,

I went so far with the following:

OLD:
   Prefix values SHOULD be short but are also likely to be unique.
   Prefix values SHOULD NOT conflict with known modules that have been
   previously published.

NEW:

   Prefix values should be selected carefully to be unique, and ideally

   not too long.  Specifically, prefix values SHOULD NOT conflict with

   known modules that have been previously published.

I’m having troubles with the normative language here. If we maintain the two 
sentences, the second SHOULD is sufficient for the uniqueness IMO.

Also, as per RFC2119, we should clarify when the SHOULD NOT can be safely 
ignored:

   SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

An obvious case is an updated version of a published version.

Cheers,
Med

De : Jan Lindblad 
Envoyé : mercredi 28 février 2024 15:21
À : BOUCADAIR Mohamed INNOV/NET 
Cc : netmod@ietf.org
Objet : Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

Med, author team,

Thank you for taking the time to get this work done, and well done! This is one 
of those fundamental bricks that saves time and improves quality for the entire 
YANG community.

I read the -09 version and like what I see. I have a couple of minor 
suggestions you might consider.

+ In section 3.4 about tree diagrams, the section text is already advocating 
intermixing smaller tree snippets with explanations (which is great), but I 
wish we could say that
tree diagrams of entire modules SHOULD NOT be included. Just a waste of forest 
and attention span, imho.

+ In section 4.2 about choice of prefixes, it is said that "Prefix values 
SHOULD be short but are also likely to be unique." I used to say the same 
thing. In recent years, however, I have started to stress the importance of 
uniqueness much more. I'd say something like "Prefix values SHOULD be selected 
carefully to be unique, and ideally not too long." The reason for my change is 
I have met several engineers who have been deeply confused (to the point of 
costing real money) when the same prefix has shown up in multiple places. It's 
just an unnecessary part of the learning curve associated with YANG.

In fact, I have started to recommend people to set the prefix to equal the 
module name. This also solves another problem, which is that the "prefixes" you 
see in RESTCONF are module names, and the confusion of what to use where is 
sometimes suffocating. I understand if many think I'm going overboard here, but 
when we pretend that modules don't have prefixes, only module names, there is a 
lot less friction in learning the ropes.

+ In section 4.6.2 regarding useless (in YANG Context) functions in the XPath 
function library, it is said that the "YANG compiler" should return false, etc. 
Better wording might be that the XPath execution environment (or something) 
should return false, etc. The YANG compiler is not even running when the calls 
to those functions are happening.

+ In section 4.11.5 regarding booleans, it is said that booleans can take 
values true and false. This is true in mathematics :-) but in YANG a boolean 
leaf can additionally take the "value" of "not set". Actually, "not set" is a 
possibility for leafs in general, unless it is declared mandatory true, or has 
a default. In my experience, one of the most common YANG modeling issues is 
when people model a leaf foo, which isn't mandatory, has no default and the 
description statement does not say what happens if the leaf is not set. In many 
cases, there is a sort of natural meaning, but with booleans leafs in 
particular, the absence of the leaf is typically highly ambiguous. I think this 
hole merits a recommendation clause in the I-D.

Best Regards,
/jan




On 28 Feb 2024, at 10:51, 
mohamed.boucad...@orange.com wrote:

Hi all,

I think that this version is ready for the WGLC.

The document fully covers the items promised when requesting adoption [1]. As 
listed in the ACK section, we also solicited and integrated feedback from many 
yangdoctors, solicited SAAG WG to review the security text, etc. Refer to 1.1 
for a comprehensive list of the changes.

Cheers,
Med

[1] Slide#7 of 
https://datatracker.ietf.org/meeting/117/materials/slides-117-netmod-7-guidelines-for-authors-and-reviewers-of-documents-containing-yang-data-models-00


-Message d'origine-
De : I-D-Announce 
mailto:i-d-announce-boun...@ietf.org>> De la 
part de
internet-dra...@ietf.org
Envoyé : mercredi 28 février 2024 10:01
À : i-d-annou...@ietf.org
Cc : netmod@ietf.org
Objet : I-D Action: draft-ietf-netmod-rfc8407bis-09.txt