Re: [netmod] comments on draft-jouqui-netmod-yang-full-include

[Andy Bierman]

On Thu, Mar 21, 2024 at 1:15 PM Jean Quilbeuf  wrote:

> Hi Andy,
>
>
>
> Many thanks for your comments, they make a lot of sense. We will work on
> it and propose a new version of the draft.
>
>
>
> Regarding point 5), can you elaborate on the problems caused by the
> anydata node. As I see it, it is inconvenient to have this extra node which
> does not have any real meaning. Is there any other issue with this anydata
> node?
>
>
>


Changing the root from container to anydata does not remove any extra nodes.
The anydata node is a named node in the schema tree.

The problem is that YANG 1.1 defines anydata as a terminal node.
Within a configuration datastore, there are no accessible nodes within an
anydata node.
There are many cases where RPC or action input parameters are anydata and
the contents are
converted to real nodes when added to a datastore.  This is not the same as
full-include.

This draft proposes changes to YANG that are too severe and too important
to the core language
to be an optional extension.  The WG seems to prefer an ad-hoc set of
optional YANG extensions
to a mandatory set of language statements that all tools must support.





> Best,
>
> Jean
>

Andy


>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Thursday, March 21, 2024 4:35 PM
> *To:* NetMod WG 
> *Subject:* [netmod] comments on draft-jouqui-netmod-yang-full-include
>
>
>
> Hi,
>
>
>
> The presentation yesterday helped me understand the motivation for this
> work.
>
> Seems simple enough, but rife with unintended consequences.
>
> RFC 8528 does a good job of dealing with most of these issues, but it is
> not a design-time
>
> modification like this draft is proposing.
>
>
>
> I would like to see this work as part of yang-next, but not thrown in with
> YANG 1.1.
>
>
>
> Just some of the major issues to solve:
>
>
>
> 1) XPath
>
> The issue of leafrefs was raised but of course this also applies to
> must/when statements.
>
>
>
> 2) Shared yanglib
>
> This draft shares the top yanglib.
>
> Schema Mount implementations allow completely separate YANG libraries
>
> that are decoupled from the top yanglib and other mount points.  This
> allows
>
> deviations, features, etc.
>
>
>
>
>
> 3) No way to include data nodes only at the mount point.
>
> To a YANG 1.1 tool, if a module is listed in the yanglib then all its
>
> implemented top-level objects are part of .
>
>
>
> 4) Not clear what is included and scoped at the mount point
>
> There are lots of top-level YANG statements that are not data-def-stmts.
>
> Are these ignored? What exactly is included?  What changes to identifier
> scope resolution
>
> are being made?
>
>
>
> 5) anydata as root
>
> This causes more problems than it is supposed to solve.
>
> IMO Schema Mount got this right, keeping it a container or list.
>
>
>
> 6) Recursion and Loops
>
> This adds significant complexity to the implementation.
>
>
>
> IMO this is an interesting topic for yang-next.
>
>
>
> Andy
>
>
>
>
>
>
> ___
> 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] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[mohamed . boucadair]

Hi all,

FWIW, the proposed changes to address the point mentioned by Mahesh [1] can be 
seen at: description text by boucadair · Pull Request #51 · 
boucadair/rfc8407bis 
(github.com)

For convenience, the changes can be tracked here: Diff: 
draft-ietf-netmod-rfc8407bis.txt - 
draft-ietf-netmod-rfc8407bis.txt

Only the template is updated because we do already have the following:

==
Concretely, the IANA Considerations Section SHALL at least
   provide the following information:

   *  ...

   *  An instruction about how to generate the "revision" statement.
==

Cheers,
Med

[1] refer to [yang-doctors] [IANA #1289473] Revision statements in 
IANA-maintained YANG modules 
(ietf.org)
 for more context.

De : Mahesh Jethanandani 
Envoyé : mercredi 13 mars 2024 03:51
À : BOUCADAIR Mohamed INNOV/NET 
Cc : netmod@ietf.org
Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

Hi Med,

Thanks for driving this effort on updating RFC 8407.

One additional change coming your way, is to address the question of how IANA 
is supposed to handle updates to IANA YANG modules. The YANG doctors are 
currently debating those changes. Once agreed, we will bring that discussion 
here, and will need to update rfc8407bis to provide guidance to authors who 
update an IANA module. Stay tuned.

Cheers.


On Mar 12, 2024, at 5:00 AM, 
mohamed.boucad...@orange.com wrote:

Hi all,


  *   A candidate -10 is ready to address 3 comments from Jan:

 *   Long trees
 *   Updated security template
 *   Minor tweaks to Section 3.8
 *   The changes circulated on the list can be seen here: Compare Editor's 
Copy to 
Datatracker

  *   Jan raised two other comments (short/uniqueness of prefixes + how to 
handle "not set") but no changes were made per the feedback received on the 
list.
  *   Next steps:

 *   Submit -10 right after IETF#119
 *   WGLC

Cheers,
Med



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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


Mahesh Jethanandani
mjethanand...@gmail.com






Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-jouqui-netmod-yang-full-include

[Jean Quilbeuf]

Hi Andy,

Many thanks for your comments, they make a lot of sense. We will work on it and 
propose a new version of the draft.

Regarding point 5), can you elaborate on the problems caused by the anydata 
node. As I see it, it is inconvenient to have this extra node which does not 
have any real meaning. Is there any other issue with this anydata node?

Best,
Jean

From: netmod  On Behalf Of Andy Bierman
Sent: Thursday, March 21, 2024 4:35 PM
To: NetMod WG 
Subject: [netmod] comments on draft-jouqui-netmod-yang-full-include

Hi,

The presentation yesterday helped me understand the motivation for this work.
Seems simple enough, but rife with unintended consequences.
RFC 8528 does a good job of dealing with most of these issues, but it is not a 
design-time
modification like this draft is proposing.

I would like to see this work as part of yang-next, but not thrown in with YANG 
1.1.

Just some of the major issues to solve:

1) XPath
The issue of leafrefs was raised but of course this also applies to must/when 
statements.

2) Shared yanglib
This draft shares the top yanglib.
Schema Mount implementations allow completely separate YANG libraries
that are decoupled from the top yanglib and other mount points.  This allows
deviations, features, etc.


3) No way to include data nodes only at the mount point.
To a YANG 1.1 tool, if a module is listed in the yanglib then all its
implemented top-level objects are part of .

4) Not clear what is included and scoped at the mount point
There are lots of top-level YANG statements that are not data-def-stmts.
Are these ignored? What exactly is included?  What changes to identifier scope 
resolution
are being made?

5) anydata as root
This causes more problems than it is supposed to solve.
IMO Schema Mount got this right, keeping it a container or list.

6) Recursion and Loops
This adds significant complexity to the implementation.

IMO this is an interesting topic for yang-next.

Andy



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

[netmod] comments on draft-jouqui-netmod-yang-full-include

[Andy Bierman]

Hi,

The presentation yesterday helped me understand the motivation for this
work.
Seems simple enough, but rife with unintended consequences.
RFC 8528 does a good job of dealing with most of these issues, but it is
not a design-time
modification like this draft is proposing.

I would like to see this work as part of yang-next, but not thrown in with
YANG 1.1.

Just some of the major issues to solve:

1) XPath
The issue of leafrefs was raised but of course this also applies to
must/when statements.

2) Shared yanglib
This draft shares the top yanglib.
Schema Mount implementations allow completely separate YANG libraries
that are decoupled from the top yanglib and other mount points.  This allows
deviations, features, etc.


3) No way to include data nodes only at the mount point.
To a YANG 1.1 tool, if a module is listed in the yanglib then all its
implemented top-level objects are part of .

4) Not clear what is included and scoped at the mount point
There are lots of top-level YANG statements that are not data-def-stmts.
Are these ignored? What exactly is included?  What changes to identifier
scope resolution
are being made?

5) anydata as root
This causes more problems than it is supposed to solve.
IMO Schema Mount got this right, keeping it a container or list.

6) Recursion and Loops
This adds significant complexity to the implementation.

IMO this is an interesting topic for yang-next.

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