[netmod] Re: [netconf] Re: Default statements on udp-client-server groupings

[Andy Bierman]

On Fri, Sep 20, 2024 at 9:08 AM Kent Watsen  wrote:

>
> Let me clarify, I’m trying to close the "default 0” statement on the
> "local-port” leafs issue.  Whether rfc8407bis is updated is a secondary
> concern.
>
> Andy (and others), do you believe this (to never set “default” or
> “mandatory”) to be a best-practice for reusable groupings?  Or more
> specifically and better for me, do you think the  "default 0” statement on
> the "local-port” leafs is okay or should be removed (in the
> tcl-client-server draft)?
>
>
In this case, default 0 meant use whatever port you want.
IMO that is a bad practice and should never be done.

In this case, the default is for an application well-known port assignment,
so the
groupings for the application should set the default port.

Kent
>
>
Andy


>
> > On Sep 20, 2024, at 11:14 AM, Andy Bierman  wrote:
> >
> > Hi,
> >
> > I do not think any new YANG guidelines need to be added to the already
> > completed rfc8407bis.
> > This is a design decision based on the intended reuse of the groupings.
> >
> > Here is a common sense guideline:  Document the grouping reuse
> limitations
> > in the description-stmt.
> >
> >
> > Andy
> >
> >
> >
> >
> > On Fri, Sep 20, 2024 at 8:02 AM Kent Watsen 
> wrote:
> >
> >>
> >> Can folks please chime in on this discussion to help bring it to a
> close?
> >>
> >> I rescinded my AUTH48 “approval” for the tcp-client-server draft pending
> >> the outcome of this discussion.
> >>
> >> PS: I see that Thomas CC-ed NETMOD, which makes sense given a potential
> >> update to rfc8407bis.
> >>
> >> Kent
> >>
> >>
> >> On Sep 18, 2024, at 2:52 AM, thomas.g...@swisscom.com wrote:
> >>
> >> Dear Kent, Andy and Alex,
> >>
> >> I think Alex statement
> >>
> https://mailarchive.ietf.org/arch/msg/netconf/5Yaiom0B0lDTeSPOvgNfPIEFvBw/
> ,
> >> Andy's feedback and guidelines in
> >> https://datatracker.ietf.org/doc/html/rfc8407#section-4.4 resp.
> >>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-15#section-4.4
> >> makes perfectly sense and I don't see why we should do else. As an
> >> author, I suggest to add in section 4 of draft-ietf-netmod-rfc8407bis
> based
> >> on the conclusion of this discussion guidelines on reusable YANG
> groupings.
> >>
> >> Best wishes
> >> Thomas
> >>
> >> *From:* Kent Watsen 
> >> *Sent:* Wednesday, September 18, 2024 3:12 AM
> >> *To:* Andy Bierman 
> >> *Cc:* netc...@ietf.org;
> >> draft-ietf-netconf-udp-client-server.auth...@ietf.org
> >> *Subject:* [netconf] Re: Default statements on udp-client-server
> groupings
> >>
> >> *Be aware:* This is an external email.
> >>
> >> Hi Andy,
> >>
> >>
> >> The main purpose for YANG defaults is ease of use.
> >> If there are less things to configure then the device is easier to use.
> >> Without a default port then this parameter becomes mandatory to
> configure
>
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: [netconf] Re: Default statements on udp-client-server groupings

[Andy Bierman]

Hi,

I do not think any new YANG guidelines need to be added to the already
completed rfc8407bis.
This is a design decision based on the intended reuse of the groupings.

Here is a common sense guideline:  Document the grouping reuse limitations
in the description-stmt.


Andy




On Fri, Sep 20, 2024 at 8:02 AM Kent Watsen  wrote:

>
> Can folks please chime in on this discussion to help bring it to a close?
>
> I rescinded my AUTH48 “approval” for the tcp-client-server draft pending
> the outcome of this discussion.
>
> PS: I see that Thomas CC-ed NETMOD, which makes sense given a potential
> update to rfc8407bis.
>
> Kent
>
>
> On Sep 18, 2024, at 2:52 AM, thomas.g...@swisscom.com wrote:
>
> Dear Kent, Andy and Alex,
>
> I think Alex statement
> https://mailarchive.ietf.org/arch/msg/netconf/5Yaiom0B0lDTeSPOvgNfPIEFvBw/,
> Andy's feedback and guidelines in
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.4 resp.
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-15#section-4.4
>  makes perfectly sense and I don't see why we should do else. As an
> author, I suggest to add in section 4 of draft-ietf-netmod-rfc8407bis based
> on the conclusion of this discussion guidelines on reusable YANG groupings.
>
> Best wishes
> Thomas
>
> *From:* Kent Watsen 
> *Sent:* Wednesday, September 18, 2024 3:12 AM
> *To:* Andy Bierman 
> *Cc:* netc...@ietf.org;
> draft-ietf-netconf-udp-client-server.auth...@ietf.org
> *Subject:* [netconf] Re: Default statements on udp-client-server groupings
>
> *Be aware:* This is an external email.
>
> Hi Andy,
>
>
> The main purpose for YANG defaults is ease of use.
> If there are less things to configure then the device is easier to use.
> Without a default port then this parameter becomes mandatory to configure.
>
>
> Alex is trying to maximize lazy binding.  That is, as a general statement,  
> unless
> 100% sure, groupings should never specify the “default” or “mandatory”
> statements, leaving it to terminal “uses” statements to specify.   His
> comment raises to the level of something that could be an addition to
> rfc8407bis.
>
> Thoughts?
>
> Kent
>
> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org
>
>
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Regarding RFC 7950 Mandatory validation

[Andy Bierman]

On Wed, Sep 18, 2024 at 4:10 AM parthasarath...@fujitsu.com <
parthasarath...@fujitsu.com> wrote:

> Hi Kent and Andy,
>
> Thanks again for your emails. I am kind of confused on Kent’s
> reply now.
>
>
>
> “The 'edit-config' RPC input parameters have some constraints like
> mandatory parameters.
>
> The 'config' payload constraints are not part of the RPC input parameter
> validation.
>
> Only constraints defined on the RPC input parameters are checked here.“
>
> Does it mean, whatever mentioned in 8.3.1 of RFC 7950 are only
> applicable to RPC input and not applicable for  payload? All the
> points apply to config payload as well, isn’t it? When we have the yang and
> the input payload (assuming a create edit-config request), we can directly
> check if mandatory attribute is missing and report error during the payload
> parsing itself, instead of doing that in ‘processing’ and ‘validation’. It
> is a fail-fast implementation. I was thinking, that as the reason, RFC
> lists down various validations as part of Payload Parsing.
>
>
>
> From Andy’s reply below:
>
> “Yes, the over-the-wire message must be valid XML but, beyond that, all
> implementations I’m aware of "validate the over-the-wire message" by 1)
> processing it to update a version of and 2) validating the
> resulting version of .“
>
> I understand, all current implementations are not failing
> fast, and they always check the constraints (including the leaf’s
> ‘mandatory’) during ‘processing’ and ‘validation’ and not during ‘payload
> parsing’. This dilutes the purpose of a separate ‘Payload Parsing’ section
> at all in RFC, when everything is going to be done on
> ‘processing’/’validation’
>
>
>
> In my humble opinion, we have to include a clause in ‘Payload
> Parsing’ section of RFC, mentioning, “If all mandatory leafs are not
> present, when the edit-config operation is ‘create’, then the server MUST
> reply with a "missing-element"  in the .”. This is
> only applicable for a create operation and not applicable for a merge or
> replace operation.
>


The Payload parsing refers to the RPC input parameters defined in the
edit-config operation.
There are 2 such constraints in this operation:

- mandatory choice config-target
- mandatory choice edit-content

The config parameter is not a representation of a datastore and not subject
to datastore validation
as part of the payload parsing.

Also, the  can be changed with many edit-config steps.
The combined result is only required to be valid when the  applies
the changes to .



>
>
> Regards,
>
> Partha.
>


Andy


>
>
> *From:* Kent Watsen 
> *Sent:* Wednesday, September 18, 2024 3:01 AM
> *To:* Andy Bierman 
> *Cc:* R, Parthasarathy ; netmod@ietf.org
> *Subject:* Re: [netmod] Regarding RFC 7950 Mandatory validation
>
>
>
> Hi Andy,
>
>
>
> IMO the RFCs are clear.
>
>
>
> The 'edit-config' RPC input parameters have some constraints like
> mandatory parameters.
>
> The 'config' payload constraints are not part of the RPC input parameter
> validation.
>
> Only constraints defined on the RPC input parameters are checked here.
>
>
>
> https://datatracker.ietf.org/doc/html/rfc6241#section-7.2
>
>
>
> The server applies the config to its internal datastore.
>
> At that point the config contents are part of a configuration data tree.
>
>
>
>
>
> https://datatracker.ietf.org/doc/html/rfc7950#section-8
>
>
>
>o  If the constraint is defined on configuration data, it MUST be
>
>   true in a valid configuration data tree.
>
> ...
>
>o  If the constraint is defined on RPC or action input parameters, it
>
>   MUST be true in an invocation of the RPC or action operation.
>
>
>
>
>
> You’re right.  Validation is context dependent.
>
>
>
> K.
>
>
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> K.
>
>
>
>
>
> Thanks & Regards,
>
> Partha.
>
>
>
> *From:* Kent Watsen 
> *Sent:* Tuesday, September 17, 2024 2:26 AM
> *To:* R, Parthasarathy 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] Regarding RFC 7950 Mandatory validation
>
>
>
> Hi Partha,
>
>
>
>
>
> On Sep 6, 2024, at 1:13 PM, parthasarath...@fujitsu.com<
> Parthasarathy.R=40fujitsu@dmarc.ietf.org> wrote:
>
>
>
> Hi,
>
> I am a Software Engineer working in Fujitsu’s NMS product
> supporting Netconf devices. I want a clarification in RFC 7950 on the
> behavior of constraint validation in an edit-config re

[netmod] Re: Regarding RFC 7950 Mandatory validation

[Andy Bierman]

On Tue, Sep 17, 2024 at 12:32 PM Kent Watsen  wrote:

> Hi Partha,
>
> On Sep 17, 2024, at 3:33 AM, parthasarath...@fujitsu.com wrote:
>
> Hi Andy and Kent,
> Thanks a lot for your emails. Great.
>
> One clarification:
> The RFC section 8.3.1 mentioning Payload Parsing is more of a validation
> over-the-wire, isn’t it?
>
> “When content arrives in RPC payloads, it MUST be well-formed XML,
> following the hierarchy and content rules defined by the set of
> models the server implements.
> o If a leaf data value does not match the type constraints for the
> leaf, including those defined in the type’s "range", "length", and
> "pattern" properties, the server MUST reply with an
> "invalid-value"  in the , and with the
> error-app-tag (Section 7.5.4.2) and error-message
> (Section 7.5.4.1) associated with the constraint, if any exist.”
>
>
> Try not to read this to mean that the over-the-wire message is
> fully-validated directly.  Yes, the over-the-wire message must be valid XML
> but, beyond that, all implementations I’m aware of "validate the
> over-the-wire message" by 1) processing it to update a version of
> and 2) validating the resulting version of .
>
>
>  On a quicker look, for a leaf, the length, range etc can be easily
> deduced from the Yang schema without involving Datastore. The same way, I
> interpreted ‘mandatory’ check too can be done just with Yang schema without
> involving Datastore.
>
>
> The check is mandatory, but it happens indirectly via checking the updated
>  or , if implementing NMDA (RFC8342).
>
>
>  Somehow, I feel, the thing, ‘mandatory is mandatory only for create
> request and it is not for merge request’ is not explicitly mentioned in RFC
> based on operation-type (be it create/merge).
>
>
> Yes, you make a point, such nodes exist in the request message 99% of the
> time, but it is possible that they may alternatively be set via 
> defined configuration, or via a template.
>
>


IMO the RFCs are clear.

The 'edit-config' RPC input parameters have some constraints like mandatory
parameters.
The 'config' payload constraints are not part of the RPC input parameter
validation.
Only constraints defined on the RPC input parameters are checked here.

https://datatracker.ietf.org/doc/html/rfc6241#section-7.2

The server applies the config to its internal datastore.
At that point the config contents are part of a configuration data tree.


https://datatracker.ietf.org/doc/html/rfc7950#section-8

   o  If the constraint is defined on configuration data, it MUST be
  true in a valid configuration data tree.
...
   o  If the constraint is defined on RPC or action input parameters, it
  MUST be true in an invocation of the RPC or action operation.


Andy



K.
>
>
> Thanks & Regards,
> Partha.
>
> *From:* Kent Watsen 
> *Sent:* Tuesday, September 17, 2024 2:26 AM
> *To:* R, Parthasarathy 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] Regarding RFC 7950 Mandatory validation
>
> Hi Partha,
>
>
>
> On Sep 6, 2024, at 1:13 PM, parthasarath...@fujitsu.com<
> Parthasarathy.R=40fujitsu@dmarc.ietf.org> wrote:
>
> Hi,
> I am a Software Engineer working in Fujitsu’s NMS product
> supporting Netconf devices. I want a clarification in RFC 7950 on the
> behavior of constraint validation in an edit-config request enforced by
> ‘mandatory’ statement. I referred to section 8 in RFC 7950 regarding this
> and from what I see, all edit-config requests should include the
> mandatory leafs. There is no special behavior mentioned on edit-config’s
> operation type as ‘create’ or ‘merge’ or ‘delete’ in the validation section
> of RFC.
>
> This ends up in two different interpretations:
>
> 1.  All edit-config requests must always include the mandatory
> attributes irrespective of the operation type is create/merge
>
> 2.  Edit-config requests must include the mandatory attributes only
> if operation type is create and it can choose to skip if the attribute is
> already present in Datastore due to previous edit-configs.
>
> Kindly confirm which interpretation holds good. Also, I would like to
> understand, if, ‘mandatory’ check applies to the payload during Payload
> Parsing stage (mentioned in section 8.3.1 of RFC 7950) for every edit
> config and that all edit config operations must include the mandatory
> attributes into the payload, even if the operation is merge and the
> mandatory attribute exists in the candidate store.
>
>
>
> It’s more the latter, but please note that YANG doesn’t validate what is
> in a message over-the-wire, so much as the contents of the 
> datastore (as Andy mentioned) after the over-the-wire message has been
> processed.
>
> PS: If using NMDA (RFC8342), then it’s the  datastore that is
> subject to validation.
>
> K.
>
>
>
>
> Kindly help to clarify.
>
> Thanks & Regards,
> Partha.
> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le.

[netmod] Re: Regarding RFC 7950 Mandatory validation

[Andy Bierman]

On Mon, Sep 16, 2024 at 10:26 AM parthasarath...@fujitsu.com
 wrote:

> Hi,
>
> I am a Software Engineer working in Fujitsu’s NMS product
> supporting Netconf devices. I want a clarification in RFC 7950 on the
> behavior of constraint validation in an edit-config request enforced by
> ‘mandatory’ statement. I referred to section 8 in RFC 7950 regarding this
> and from what I see, all edit-config requests should include the
> mandatory leafs. There is no special behavior mentioned on edit-config’s
> operation type as ‘create’ or ‘merge’ or ‘delete’ in the validation section
> of RFC.
>
>
>
> This ends up in two different interpretations:
>
>1. All edit-config requests must always include the mandatory
>attributes irrespective of the operation type is create/merge
>2. Edit-config requests must include the mandatory attributes only if
>operation type is create and it can choose to skip if the attribute is
>already present in Datastore due to previous edit-configs.
>
>
>
> Kindly confirm which interpretation holds good. Also, I would like to
> understand, if, ‘mandatory’ check applies to the payload during Payload
> Parsing stage (mentioned in section 8.3.1 of RFC 7950) for every edit
> config and that all edit config operations must include the mandatory
> attributes into the payload, even if the operation is merge and the
> mandatory attribute exists in the candidate store.
>
>
>
> Kindly help to clarify.
>
>
>

I do not think this is correct.
The 'mandatory' validation applies to a datastore.
The YANG validation done on the edit-config request ignores the 'config'
contents.
This rpc input parameter is anyxml.
The contents are applied to a datastore in an implementation-specific
manner.



Thanks & Regards,
>
> Partha.
>

Andy


> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: comments on system-config-08 draft

[Andy Bierman]

On Thu, Aug 22, 2024 at 8:09 PM maqiufang (A)  wrote:

> Hi, Andy,
>
>
>
>
>
> Changing the running config so it is split into 2 datastores makes
> operations more complicated.
>
> It doesn't actually work since YANG is hierarchical and has
> cross-references.
>
>
>
> IMO the only improvement needed is to add metadata to  so a
> client can
>
> better understand the system config and make edit requests that will not
> fail.
>
>
>
> Most deployment (90%?) is non-NMDA and it will probably stay that way.
>
> The developer focus is on data model deployment, not redoing the
> foundation. IMO people want YANG to
>
> be simpler and faster. I don't see how splitting config up into 2
> datastores helps.
>
>
>
> I am not sure I agree this draft is “changing the running config so it is
> split into 2 datastores”.
>
>
>
> I think it is already the case that NMDA never puts system configuration
> into , it’s only in . So has NMDA already made NBC
> changes to the behavior of non-NMDA servers? If you know any existing
> standards that say system configuration is defined in , I would
> appreciate that if you could help navigate, as I’ve always thought putting
> system configuration into  is just one of the existing various
> proprietary implementations, our implementation used to be this way, but
> not now, after some customers complained that they don’t want to see some
> system config magically appeared when they write some config into 
> and then read back, and there are other reasons like performance.
>
>
>

There is no such thing as "system config" defined in YANG.
It was never mentioned as an operator requirement in RFC 3535 (but separate
config and state is a requirement).

The "split config" is a result of suppressing system config (whatever that
is) when  is retrieved.

IMO this is no different than "with-defaults".  A client can retrieve
 with the defaults or without them.
A similar filter for "with-system" or "with-unused-system" would be simpler
than adding a new datastore to NMDA.
The complex interactions between datastores and operations on datastores
(like copy-config) are non-trivial.



>
> Best Regards,
>
> Qiufang
>
>
>
>
>

Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: 2nd WGLC on system-config-08

[Andy Bierman]

On Tue, Aug 20, 2024 at 5:54 AM Jürgen Schönwälder
 wrote:

> On Tue, Aug 20, 2024 at 12:20:55PM +, Jan Lindblad (jlindbla) wrote:
> >
> > PS: And with a well designed merge operation, one might in the future
> > even move towards breaking the monolithic  into pieces,
> > like we do for the  singleton today.
> >
> > [janl] Could you expand on that last PS? I’m not following your train of
> thought here.
> >
>
> If you take the configuration of a web server, then it is common
> practice to organize the configuration of different sites a server is
> serving into separate files. (I am talking about modularity of config
> instance data, not modularity of the underlying data models.) The
> server then loads the configs of all active sites and merges the
> settings somehow to derive all the internal settings necessary to
> provide the configured services.
>
>
The  datastore is not a functional partition, like virtual WEB
servers .
The split between system and client is somewhat arbitrary and quite
implementation-specific.
It does not provide modularity at all.

 as a datastore is conceptually monolithic, but required to be
that way in implementation.
Certainly the protocol operations are not required to operate on the entire
config at once.

I do not see any significant difference between system-created config and
traditional client-created config.  In modern distributed systems, the
system config
could actually be (at least partially) client config, even using the exact
same operations as a "real" client.
The distinction between system and client-created data is no longer
relevant.
The immutable flag addresses the relevant issues.


Andy


In the NC/RC world, we have a single monolithic  and hence
> all the busy merging needs to happen on the client side or you hope
> that clients respect each other instead of stepping onto each others
> toes when they make changes. I can see possible advantages of
> splitting our monolithic  into multiple s that are
> then merged on the server side into the grand unified . This
> gives us modularity, possibly easier to manage access controls,
> perhaps execution gains if it is possible to localize validations that
> do not always have to generate and revalidate the grand unified
> .
>
> I understand that this may sound far reaching since the IETF tends to
> move slwly and to be rightfully conservative about more radical
> proposals. On the other hand, having a plan where to go with a
> technology may help to guide current work and to avoid getting stuck
> with point solutions that at the end make it impossible to evolve
> beyond a certain stage.
>
> /js
>
> --
> 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
> To unsubscribe send an email to netmod-le...@ietf.org
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: comments on system-config-08 draft

[Andy Bierman]

On Thu, Aug 22, 2024 at 8:12 AM Kent Watsen  wrote:

> Hi Andy,
>
> > So you are planning new protocol versions with NBC changes as well?
>
> Yes.  The NETCONF WG already kicked-off (sort of) the NETCONF-next and
> RESTCONF-next efforts.  The “plan” is to first publish a BC (backwards
> compatible) version of the protocols to address low-hanging items, and then
> an NBC versions to align with YANG-next.
>
> The question is if telling the client that it “running alone MAY be valid”
> (was “MUST") can be in the BC update.  Technically, there is no change to
> the protocol on the wire, it’s only a change in how the client processing,
> so maybe okay for NC1.2 / RC1.1?
>
>
Changing the running config so it is split into 2 datastores makes
operations more complicated.
It doesn't actually work since YANG is hierarchical and has
cross-references.

IMO the only improvement needed is to add metadata to  so a client
can
better understand the system config and make edit requests that will not
fail.

Most deployment (90%?) is non-NMDA and it will probably stay that way.
The developer focus is on data model deployment, not redoing the
foundation. IMO people want YANG to
be simpler and faster. I don't see how splitting config up into 2
datastores helps.



> Kent // as a contributor
>
>
Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: comments on system-config-08 draft

[Andy Bierman]

On Wed, Aug 21, 2024 at 9:28 AM Kent Watsen  wrote:

> Hi Andy,
>
> The example in the appendix shows a device that would boot without any
> interfaces in .
> They would only be in .  If this is the case, then all non-NMDA
> clients and all current NMDA clients need to be rewritten to know about the
>  config.   IMO breaking all existing clients would be a bad idea.
>
>
> This is why there was so much effort before to copy system-defines nodes
> (the so called “shared objects”) into , i.e., so legacy clients
> wouldn’t break.  This is my #1 case in the other thread.
>
> The other approach is to version the protocols with a mandate that clients
> grok  and no longer “running alone must be valid”.
>
> No one is talking about changing the existing NC/1.1 and RC/1.0 contracts.
>
>

So you are planning new protocol versions with NBC changes as well?


> I am confused, because I was told the reason  is needed is so
> leafref and XPath in 
> can reference the system config (i.e. nodes in  require nodes
> from  to be part of the data tree.)
>
>
> This is not true.  XPaths are only resolved in the datastore that is the
> context.  E.g., if validating , running is the context.  If
> validating , intended is the context.
>
>

So what is the point of the system datastore?
If all references in  must be to other nodes in  ,
then the 'immutable' flag or other metadata is good enough.

I do not understand why metadata is OK for so many other properties, but a
special datastore
is needed for system-created="true".  Not just a special datastore, but
also breaking how 
has worked in routers from Day One.


I don’t think it is possible to validate .  I also don’t recall the
> draft saying one way of the other.  It might be good for the draft to say...
>
>

I don't understand how removing the system config from 
makes it easier for clients to configure a server.  Checking one datastore
so you can
create parent nodes and other referenced nodes in another datastore is
complicated.
IMO the current approach (plus immutable flag) is simpler to use.



>
> Obviously, an old client is unaware of the new  datastore and will
> never provide the 'resolve-system' leaf.
>
>
> I think that the current plan is to remove the ‘resolve-system’
> parameter.  Perhaps pending more responses from the WG…
>
>
So resolve-system means "figure out which missing system nodes to magically
add, or the edit will fail".?
Seems like setting this to 'false' is a bad idea.


> I do not understand how config can be changed, e.g. an address is assigned
> to an interface,
> if the parent interface is not in .
>
>
> It cannot, the parent nodes need to be in  as well.   This is my
> #3 case in the other thread.
>
>
> Kent // contributor
>
>
Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: comments on system-config-08 draft

[Andy Bierman]

On Wed, Aug 21, 2024 at 1:05 AM maqiufang (A)  wrote:

> Hi, Andy,
>
>
>
> Thanks for the comments, please see reply inline…
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Wednesday, August 21, 2024 12:34 AM
> *To:* NetMod WG 
> *Subject:* [netmod] comments on system-config-08 draft
>
>
>
> Hi,
>
>
>
> I do not think this draft is ready.
>
>
>
> 1) Behavior changes to conventional datastores
>
>
>
> There seem to be NBC changes being made to the
>
> behavior of the conventional non-NMDA datastores, particularly .
>
>
>
> I disagree that it is a problem that  contains some system
> configuration
>
> mixed in with the client configuration.  The only problem is that the data
> is not
>
> editable by clients.  The "immutable" flag draft provides clients
>
> with enough information to avoid 'access-denied' errors when editing
> system config.
>
> Changing the behavior of  seems to break old non-NMDA clients
>
> that expect the combined config.
>
> There are various implementations about system configuration, and some do
> put system configuration into , but the vision has always been to
> give the client full control over , right? System configuration
> comes and goes, which is beyond the control of operators, while I think
>  should be controlled with more predictability.
>
>
>


No, I do not agree that system config "comes and goes" and therefore no
system config can be in .
Metadata can be used to identify system data vs. client data.

The example in the appendix shows a device that would boot without any
interfaces in .
They would only be in .  If this is the case, then all non-NMDA
clients and all current NMDA clients
need to be rewritten to know about the  config.   IMO breaking all
existing clients would be a bad idea.



> 2) NBC Changes to XPath
>
>
>
> Changing the XPath evaluation procedures is an NBC change.
>
> In this case, also quite complicated to implement XPath across
>
> multiple datastores.
>
>
>
> System config could be visible in  using the immutable flag.
>
> Leafrefs and XPath are allowed to point at config=true in the same data
> tree.
>
> This does not require any changes to XPath processing.
>
>
>
> Referencing a special read-only datastore is no different than simply
>
> allowing the XPath to reference config=false.  It is the same NBC change.
>
> I am confused by this comment, as no one has ever proposed to change the
> XPath evaluation procedures.
>
> If the intention is to make  alone valid, the proposed approach
> is to either copy the referenced system nodes into  or use the
> “resolve-system” parameter to allow the server do the copy thing.
>
> If  alone doesn’t have to be valid and only  is subject
> to validation, then simply merge  with  to be
> referentially complete for .
>
> Neither case has proposed a direct cross-datastore reference.
>


I am confused, because I was told the reason  is needed is so
leafref and XPath in 
can reference the system config (i.e. nodes in  require nodes from
 to be part of the data tree.)
This violates the XPath context rules in RFC 7950.
This prevents offline validation of 
This violates the MUST requirement in RFC 7950 that  MUST be valid.



> 3) resolve-system
>
>
>
> I am confused why a client would not resolve the system, since
>
> the  datastore needs these nodes so the client nodes can exist.
>
> Of course the client can resolve the reference and explicitly copy the
> missing parts from  into  (see sec 5.2), “resolve-system”
> is just an alternative for the clients that don’t wish a manual copy. It is
> optional to implement and clients **may** use.
>
>
>

Obviously, an old client is unaware of the new  datastore and will
never provide the 'resolve-system' leaf.
I do not understand how config can be changed, e.g. an address is assigned
to an interface,
if the parent interface is not in .




>
>
> Andy
>
> Best Regards,
>
> Qiufang
>


Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] comments on system-config-08 draft

[Andy Bierman]

Hi,

I do not think this draft is ready.

1) Behavior changes to conventional datastores

There seem to be NBC changes being made to the
behavior of the conventional non-NMDA datastores, particularly .

I disagree that it is a problem that  contains some system
configuration
mixed in with the client configuration.  The only problem is that the data
is not
editable by clients.  The "immutable" flag draft provides clients
with enough information to avoid 'access-denied' errors when editing system
config.

Changing the behavior of  seems to break old non-NMDA clients
that expect the combined config.

2) NBC Changes to XPath

Changing the XPath evaluation procedures is an NBC change.
In this case, also quite complicated to implement XPath across
multiple datastores.

System config could be visible in  using the immutable flag.
Leafrefs and XPath are allowed to point at config=true in the same data
tree.
This does not require any changes to XPath processing.

Referencing a special read-only datastore is no different than simply
allowing the XPath to reference config=false.  It is the same NBC change.

3) resolve-system

I am confused why a client would not resolve the system, since
the  datastore needs these nodes so the client nodes can exist.



Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions

[Andy Bierman]

On Fri, Aug 2, 2024 at 8:15 AM Rob Wilton (rwilton)  wrote:

> I think that there is a balance to how much groupings are used.  E.g., I
> would regard the OpenConfig models as an example of where groupings are
> overly used resulting in YANG models where it is impossible to glean the
> structure.
>
> I’m also not sure whether groupings really help here – e.g., if you put
> the top level of the module under a grouping, then another module may just
> want to reuse a subtree.
>
> I’m also slightly concerned about whether this can really be achieved in
> an extension (which tooling is allowed to ignore).
>
> I.e., it feels like this really need a new (probably major) version of the
> YANG language – and possible would need a more radical rethink about how to
> manage and reuse parts of YANG schema.
>
>
I agree with all your concerns.

I reject the basic premise of this 'design time' text in RFC 8528

 In principle, the mounted schema can be specified at three different
   phases of the data model life cycle:

   1.  Design time: The mounted schema is defined along with the mount
   point in the parent YANG module.  In this case, the mounted
   schema has to be the same for every implementation of the parent
   module.

   2.  Implementation time: The mounted schema is defined by a server
   implementor and is as stable as the YANG library information of
   the server.

   3.  Run time: The mounted schema is defined by instance data that is
   part of the mounted data model.  If there are multiple instances
   of the same mount point (e.g., in multiple entries of a list),
   the mounted data model may be different for each instance.



YANG is modular by design.
The design-time schema mount option was never thought out or explored.

   The schema mount mechanism defined in this document provides support
   only for the latter two cases.  Design-time mounts are outside the
   scope of this document and could be possibly dealt with in a future
   revision of the YANG data modeling language.


If the contents of a mount-point are hard-wired, then no augmentations are
possible
without rewriting the module with the mount-point.  This is not consistent
with the intent or design
of YANG augments.  It is too brittle for real deployment.




Regards,
> Rob
>


Andy


>
>
>
>
> *From: *Kent Watsen 
> *Date: *Friday, 2 August 2024 at 14:21
> *To: *Shiya Ashraf (Nokia) 
> *Cc: *Alexander L Clemm , Alexander L
> Clemm , Jean Quilbeuf ,
> BOUCADAIR Mohamed IMT/OLN , netmod@ietf.org
> , Rob Wilton (rwilton) 
> *Subject: *Re: [netmod] Defining groupings after the fact?
> draft-jouqui-netmod-yang-full-include and the reuse of definitions
>
> [CC-ing Med]
>
>
>
> I wonder if rfc8047bis should have a recommendation to use groupings
> extensively?
>
>
>
> FWIW, my "client-server” suite of drafts in NETCONF use groupings
> extensively.  In fact, whenever a data-node is needed, it is always just a
> container that uses a grouping.
>
>
>
> Kent
>
>
>
> On Aug 2, 2024, at 4:54 AM, Shiya Ashraf (Nokia)  40nokia@dmarc.ietf.org> wrote:
>
>
>
> Hello Alex,
>
> " However, even in that case, an update to the original model is still
> required - you cannot simply say "let me use these data definitions from
> that other models", they need to be defined as a grouping"
>  Oh sure, absolutely. As you pointed out in one of the earlier
> emails, if this could address 99+% of the cases, why not do it at least for
> the models which we think will have more chance of getting reused, say for
> instance, ietf-interfaces, ietf-hardware etc. And this we could do it today
> in YANG 1.1 and with no extra tools support - which is clearly an advantage
> over the new embed mechanisms for faster commercial deployments of the
> solutions.
> Isn't it?
>
> Thanks,
> Shiya
>
> -Original Message-
> From: Alexander L Clemm 
> Sent: Thursday, August 1, 2024 10:49 PM
> To: Shiya Ashraf (Nokia) ; Alexander L Clemm <
> lud...@clemm.org>; Jean Quilbeuf ;
> netmod@ietf.org
> Subject: Re: [netmod] Re: Defining groupings after the fact?
> draft-jouqui-netmod-yang-full-include and the reuse of definitions
>
> [You don't often get email from ludwig=40clemm@dmarc.ietf.org. Learn
> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> Hello Shiya,
>
> re your comment on the "Once models have been defined this way, they
> cannot be altered after the fact":  Well, I guess as William has pointed
> out, it is possible to update a model with another, equivalent model which
> pulls data node definitions into groupings and then uses those groupings.
> That would be a compatible change.  The same groupings will then also be
> free for other models to use.  However, even in that case, an update to the
> original model is still required - you cannot simpl

[netmod] yang-next

[Andy Bierman]

Hi,

I still support the formation of a design team to
review the yang-next issues

https://github.com/netmod-wg/yang-next/issues

I mean a team of YANG experts that is willing to
prepare for the meeting, not a conf-call with 20 people
where only 3 people have bothered to review any issues.

The 1.2 vs. 2.0 issue is a 2nd order problem.
If any compelling features are found that are worth breaking
backward compatibility with YANG 1.1, then maybe 2.0 is
worth it, but the goal is that 1.1 will convert automatically to 1.2.

None of the feature requests are that compelling, but IMO
the community is expecting incremental improvements,
and there are plenty of those to consider.

The WG should either make an informed decision about yang-next
or archive the repo and tell the community there will not be any
new version of YANG.

Andy
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

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

[Andy Bierman]

On Fri, Jul 5, 2024 at 6:42 AM Jean Quilbeuf 
wrote:

> Hi Andy,
>
> I just posted  a new version of the draft, diff is here:
> https://author-tools.ietf.org/iddiff?url2=draft-jouqui-netmod-yang-full-include-02
>
>
>
> I provide some answers in-line.
>
>
>


I don't really see any improvement over Schema Mount.

SM is complex to implement in a server because it creates a "nested" schema
tree, which is extremely
implementation-specific.

IMO it is not difficult to use in the client. It seems like it would be
harder to use if the
YANG library details were left out.

It is not clear to me why a mount point with a static yanglib specified at
design-time is needed.
How will the vendor augment it, set features, or apply deviations and
annotations?
Even if there is an important use-case, the yang-next work would be the
appropriate way to add it.


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.
>
>
>
> Yes, so the semantics is the same as for Schema Mount, what’s inside an
> embed cannot access the outside. All leafref, must, and XPath in general is
> as if the root / is the embedding point. Trying to ../../ your way out of
> the embedding point is not possible as the embedded module must be valid
> even if not embedded.
>
>
>
> 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.
>
>
>
> Here we are in the design-time, so we don’t have the requirements to have
> such a strong decoupling. We design the model to embed other existing model.
>
> That being said, I added a section about how to augment the YANG library
> to define the content of each embedding point.
>
>
>
> 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 .
>
>
>
> True, so we would list module that are embedded as imported in the
> YANG library. To a client unaware of the extension, there would be no
> expectation of finding data nodes of modules that are only embedded and not
> present at the root context.
>
>
>
> 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?
>
>
>
> Same as for schema mount, rpc become action and notification can be
> declared anywhere.
>
>
>
> 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.
>
>
>
> It seems that adding the simple rule “a module cannot embed itself” is
> sufficient to prevent a truly recursive schema. I added a
> pseudo-demonstration of that in the “Recursive embedding” section.
>
>
>
> IMO this is an interesting topic for yang-next.
>
>
>
> Andy
>
>
>
>
>
>
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Fwd: A short note / request…

[Andy Bierman]

On Sun, Jun 30, 2024 at 3:55 AM Kent Watsen  wrote:

> A message from one of the Ops Area ADs.   Good advice!
>
>
>

An interesting and very old topic.

It is directly relevant to the Versioning work.
Very specifically, how would the following paragraph be changed from MUST
to SHOULD

RFC 7950, sec 11:

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.


Andy

*From:* Warren Kumari 
> *Date:* June 30, 2024 at 6:14:51 AM EDT
> *To:* ops-chairs 
> *Subject:* *A short note / request…*
>
> 
> Hi there all,
>
> As you've probably all realized by now, the IESG goes through cycles of
> what it thinks is super important.
>
> We just had the annual IESG/IAB workshop, and what something that got a
> lots of attention is ensuring that when a document contains a SHOULD, it is
> clear about under what conditions the SHOULD does or does not apply.
>
> From RFC2119:
> "3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>may exist valid reasons in particular circumstances to ignore a
>particular item, but the full implications must be understood and
>carefully weighed before choosing a different course.
>
> 4. 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."
>
>
> So, if a document says something like:
> You SHOULD NOT stick a fork in an electrical outlet.
> it should instead say something like:
> Unless the fork is made out of non-conductive plastic, you SHOULD NOT
> stick it in an outlet.
>
> I figured I'd let you know this so you ensure that documents that come
> through your WG fit this to minimize the chance of DISCUSS ballots.
>
> W
>
> ___
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: YANG Versioning question - namespace version?

[Andy Bierman]

On Tue, Jun 18, 2024 at 1:53 AM Jürgen Schönwälder
 wrote:

> The YANG naming scheme is (module, path). The XML namespaces are an
> XML serialization artifact.
>
> By promising backwards compatibility, the (module, path) naming scheme
> was sufficient (non-backwards compatible changes require to change either
> the module, the path, or both).
>
> The versioning effort proposes to evolve the current naming scheme
> to (module, path, version). This requires that in _all_ places where
> YANG-defined data is stored and processed, the version context needs
> to be made available, which essentially implies availability of the
> YANG library of the originating server plus code to process the same
> at all places where YANG-defined data is stored or processed and where
> robustness matters.
>
>

Versioning the namespace may be appropriate for a monolithic WEB API,
but YANG is modular, with lots of cross-references.  While it may be
trivial to
support GET or POST for many versions of a single WEB page, this is not the
case
for an API composed of 100s of modules.


/js
>

Andy


>
> On 18.06.24 08:22, Jan Lindblad (jlindbla) wrote:
> >
> > Kent,
> >
> >
> > I was recently asked why YANG module namespaces aren’t versioned.  For
> > example, the “1.0” at the end of this URI
> > "urn:ietf:params:xml:ns:yang:ietf-crypto-types:1.0”. The stated
> > concern was "because without this, then management of backward
> > compatibility becomes a nightmare.”
> >
> > In the very early days of YANG, we actually had a brief while when the
> > NS strings were composed just like that, with a sort of version number
> > at the end.
> >
> > To know that something is a new/different version of something else
> > you need two information elements. Something that indicates “sameness”
> > and something that indicates “newness”.
> >
> > When tracking files in git, the “sameness” typically comes from
> > keeping the same filename (even if git can handle file renames if
> > registered properly). In YANG, we didn’t want to rely on the filename,
> > since the module filenames are not necessarily globally unique, as the
> > thinking went. So the NS string serves as the sameness factor, and
> > must therefore not change. Basically, modules with different NS
> > strings are (considered) completely unrelated.
> >
> > To indicate “newness”, we depend on the revision statement in YANG. In
> > the Versioning Design Team, we have also been toying around with a
> > checksum to indicate newness, but that has not taken root.
> >
> > Theoretically, it would of course be possible to indicate both things
> > in the NS string by appending a version number at the end, but then
> > all clients and servers would have to agree on the convention/rule
> > that the characters after the last colon in the NS string need to be
> > processed differently. That ship has probably crossed the ocean by
> > now, but we could bring it up for YANG next.
> >
> > But I fail to see why our non-choice of this particular solution would
> > necessarily drive us into a nightmare. The necessary information is
> > available in the modules, just not in the NS string alone.
> >
> > Best Regards,
> >
> > /jan
> >
> >
> >
> > This convention was established prior to my becoming active in the
> > IETF, but my guess is that the reason is because the YANG-module
> > update rules in RFC 7950 Section 11 ensure backwards compatibility,
> > and hence the versioning the namespace would have no value. That said,
> > the YANG Versioning effort introduces the possibility of NBC changes,
> > which makes me wonder if this is something that should be discussed.
> >
> > Thoughts?
> >
> > Kent
> >
> >
> >
> > ___
> > netmod mailing list -- netmod@ietf.org
> > To unsubscribe send an email to netmod-le...@ietf.org
> >
> >
> > ___
> > netmod mailing list -- netmod@ietf.org
> > To unsubscribe send an email to netmod-le...@ietf.org
>
> --
> 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
> To unsubscribe send an email to netmod-le...@ietf.org
>
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Andy Bierman]

On Fri, May 17, 2024 at 2:46 AM Qin Wu  wrote:

> *发件人:* Andy Bierman [mailto:a...@yumaworks.com]
> *发送时间:* 2024年5月14日 1:28
> *收件人:* Qin Wu 
> *抄送:* Kent Watsen ; netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
>
> .
>
>
>
> Andy
>
>
>
> [Qin Wu]I think it can also be used as standard feature, Taking ONUG
> project and use cases as an example, many cloud providers suffer
>
> from increased expenditure of human and capital resources to assess Cloud
> Security Notification. They are looking for common definition
>
> and syntax for Cloud security notification. ONUG is working on Common
> Cloud Security Notification Framework or CSCF, CSCF introduces the
>
> similar concept as node tag called decorator which can provide rich
> context information without need to define new data node or new object,
>
> for downstream tools, they can use decorator to integrate these context
> data easily into data lake to drive new dashboards usages, I think
>
> node tag can be designed for the same purpose even though I haven't
> envision how module tag or module tag extension can be used.
>
>
>
> See the introduction of ONUG decorator:
>
> https://onug.net/blog/multi-cloud-security-gets-a-decorator/
>
> "
>
> The  “decorator” is to provide a common set of definitions and syntax to:
>
>
>
> 1. Ease ingestion of CSP security notifications into security data lakes
> and other security plus observability tools
>
> 2.Provide CSPs translational services to understand common security
> notifications between and across CSPs
>
>  a. Mappings of NIST controls and MITRE ATT&CK into a  decorator are high
> priority to deliver cross CSP translational service
>
> 3. Extended log information field attributes are to be accommodated to
> better understand context, e.g., each CSP to provide a log plus type
>
> set of meta field
>
>   a.A method to tag or identify Cloud Consumer assets so as to prioritize
> response is high priority
>
> "
>

I do not see what this has to do with the new IETF Node Tags Registry

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11#name-ietf-yang-data-node-tags-re

The goal is for a generic application to easily identify data nodes that
are metrics, logs, traces, and info.
This requires the module author(s) to correctly tag all the nodes that fit
some classification.
This is an enormous amount of work, even if the classifications are clearly
defined, which they are not.


Andy







>
>
> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2024年2月21日 8:18
> *收件人:* Kent Watsen 
> *抄送:* netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
>
> On Tue, Feb 20, 2024 at 8:03 AM Kent Watsen  wrote:
>
> Juergen, Tom, Andy,
>
> Gentle reminder.
>
>
>
> I read draft-11.  It is an improvement. No objections.
>
> There are 4 IETF tags defined:  metrics, logs, traces, info
>
> I do not see much value in these standard tags, but more guidance and
> explanation would help.
>
>
>
> Since the IETF does not define any protocol usage of tags, there is little
>
> impact caused by this draft, except for the additional administrative
> overhead.
>
>
>
>
>
> Kent // shepherd
>
>
>
> Andy
>
>
>
> > On Nov 14, 2023, at 4:49 PM, Kent Watsen  wrote:
> >
> > Juergen, Tom, Andy,
> >
> > The previous WGLC for this draft didn’t succeed due to your comments.
> > Qin’s update (1) below removes all the (metric) specific node-tags.
> > All that is left now is the generic mechanism for tagging nodes.
> > Can you confirm that this update (-11) addresses your concerns?
> >
> > Thanks,
> > Kent
> >
> >
> >> On Oct 23, 2023, at 6:28 AM, Qin Wu  40huawei@dmarc.ietf.org> wrote:
> >>
> >> v-11 addresses comments during WGLC, the main changes include:
> >> 1. Remove all specific metrics from both terminology section and
> section 9.2 on IETF YANG Data Node Tags Registry based on WGLC discussion.
> >> 2. Align with Open Telemetry and Open Metrics open source
> implementation specification, introduce traces, log for data nodes
> classification.
> >> 3.Fix normative reference issues in section 9.2.
> >>
> >> -Qin
> >> -邮件原件-
> >> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> >> 发送时间: 2023年10月21日 17:56
> >> 收件人: i-d-annou...@ietf.org
> >> 抄送: netmod@ietf.org
> >> 主题: I-D Action: draft-ietf-

[netmod] Re: RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Andy Bierman]

On Sat, May 11, 2024 at 11:01 PM Qin Wu  wrote:

> *发件人:* Andy Bierman [mailto:a...@yumaworks.com]
> *发送时间:* 2024年5月11日 1:10
> *收件人:* Qin Wu 
> *抄送:* Kent Watsen ; netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
>
> On Thu, May 9, 2024 at 7:19 AM Qin Wu  wrote:
>
> Thank Andy for valuable comments, I have update introduction in the github
> to clarify the motivation and provide more guidance
>
> See diff:
>
>
> https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/billwuqin/draft-ietf-netmod-node-tags/main/draft-ietf-netmod-node-tags-12.txt
>
>
>
>
>
>
>
> I cannot find any evidence that the IETF module-tags are being used
> anywhere.
>
>
> https://www.rfc-editor.org/rfc/rfc8819.html#name-ietf-yang-module-tags-regis
>
>
>
> Why do we need to go through every leaf in every YANG module and decide if
> it is a metric, log, trace, or info?
>
> Wouldn't every leaf be tagged as 'info'?
>
>
>
> [Qin]:I think you don’t need to go through all leafs and in most cases,
> you just pick the leaf you are interested or you might just pick parent
> leaf (e.g., list, container, etc).
>
> Take user configured tag as an example,
>
> You as user or operators can use edit-data to label all instances of data 
> node and establish the mapping between the label and instance of data node 
> using ietf-node-tags,
>
> Which can be get accessed to other users for data analytics, or decide to 
> where to subscribe the data. These data can be seen as user intent in some 
> sense.
>
>
>
> IMO it makes sense (in some cases) to improve the granularity of the
> module-tag with per-node tagging.
>
> That means using the same tag registry defined in RFC 8819, not inventing
> a new classification system.
>
>
>
> [Qin]:note that what we proposed in this document is to extend module tag 
> module to establish the mapping between tag and leaf.
>
> Or you think we should add one parameter under module list of 
> ietf-module-tags to distinguish module name from node name such as:
>
> module: ietf-module-tags
>
>   +--rw module-tags
>
>  +--rw module* [name]
>
> +--rw name  yang:yang-identifier
>
> +--rw type //indicate whether it is module or node.
>
> +--rw tag*  tag
>
> +--rw masked-tag*   tag
>
> Or you just think we should not introduce yang extension for node-tag, just 
> reuse YANG extension for module-tag, I am open to this.
>
>
>


I cannot find any evidence that the module-tag extension is being used.
There are no standard protocol operations that use module tags.
YANG Doctors are not telling WGs to add module-tag extensions.

The tag mechanism has some value, although variables (i.e. RFC 7952
annotations)
would be much better than tags.

The IETF classifications should not be expanded since they are not even
being used now.
There is still some value in the vendor and user tags.

We have proprietary augments to get* operations and to NACM rules to use a
module-tag as a filter.
Node tags could be more useful. They could provide a simple way to use YANG
Push.
But maybe this makes more sense as a vendor or operator-configured feature.


-Qin
>
>
>
>
>
> Andy
>


Andy


>
>
> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2024年2月21日 8:18
> *收件人:* Kent Watsen 
> *抄送:* netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
>
> On Tue, Feb 20, 2024 at 8:03 AM Kent Watsen  wrote:
>
> Juergen, Tom, Andy,
>
> Gentle reminder.
>
>
>
> I read draft-11.  It is an improvement. No objections.
>
> There are 4 IETF tags defined:  metrics, logs, traces, info
>
> I do not see much value in these standard tags, but more guidance and
> explanation would help.
>
>
>
> Since the IETF does not define any protocol usage of tags, there is little
>
> impact caused by this draft, except for the additional administrative
> overhead.
>
>
>
>
>
> Kent // shepherd
>
>
>
> Andy
>
>
>
> > On Nov 14, 2023, at 4:49 PM, Kent Watsen  wrote:
> >
> > Juergen, Tom, Andy,
> >
> > The previous WGLC for this draft didn’t succeed due to your comments.
> > Qin’s update (1) below removes all the (metric) specific node-tags.
> > All that is left now is the generic mechanism for tagging nodes.
> > Can you confirm that this update (-11) addresses your concerns?
> >
> > Thanks,
> > Kent
> >
> >
> >> On Oct 23, 2023, at 6:2

[netmod] Re: RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Andy Bierman]

On Thu, May 9, 2024 at 7:19 AM Qin Wu  wrote:

> Thank Andy for valuable comments, I have update introduction in the github
> to clarify the motivation and provide more guidance
>
> See diff:
>
>
> https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/billwuqin/draft-ietf-netmod-node-tags/main/draft-ietf-netmod-node-tags-12.txt
>
>
>


I cannot find any evidence that the IETF module-tags are being used
anywhere.
https://www.rfc-editor.org/rfc/rfc8819.html#name-ietf-yang-module-tags-regis

Why do we need to go through every leaf in every YANG module and decide if
it is a metric, log, trace, or info?
Wouldn't every leaf be tagged as 'info'?

IMO it makes sense (in some cases) to improve the granularity of the
module-tag with per-node tagging.
That means using the same tag registry defined in RFC 8819, not inventing a
new classification system.



-Qin
>


Andy


> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2024年2月21日 8:18
> *收件人:* Kent Watsen 
> *抄送:* netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
>
> On Tue, Feb 20, 2024 at 8:03 AM Kent Watsen  wrote:
>
> Juergen, Tom, Andy,
>
> Gentle reminder.
>
>
>
> I read draft-11.  It is an improvement. No objections.
>
> There are 4 IETF tags defined:  metrics, logs, traces, info
>
> I do not see much value in these standard tags, but more guidance and
> explanation would help.
>
>
>
> Since the IETF does not define any protocol usage of tags, there is little
>
> impact caused by this draft, except for the additional administrative
> overhead.
>
>
>
>
>
> Kent // shepherd
>
>
>
> Andy
>
>
>
> > On Nov 14, 2023, at 4:49 PM, Kent Watsen  wrote:
> >
> > Juergen, Tom, Andy,
> >
> > The previous WGLC for this draft didn’t succeed due to your comments.
> > Qin’s update (1) below removes all the (metric) specific node-tags.
> > All that is left now is the generic mechanism for tagging nodes.
> > Can you confirm that this update (-11) addresses your concerns?
> >
> > Thanks,
> > Kent
> >
> >
> >> On Oct 23, 2023, at 6:28 AM, Qin Wu  40huawei@dmarc.ietf.org> wrote:
> >>
> >> v-11 addresses comments during WGLC, the main changes include:
> >> 1. Remove all specific metrics from both terminology section and
> section 9.2 on IETF YANG Data Node Tags Registry based on WGLC discussion.
> >> 2. Align with Open Telemetry and Open Metrics open source
> implementation specification, introduce traces, log for data nodes
> classification.
> >> 3.Fix normative reference issues in section 9.2.
> >>
> >> -Qin
> >> -邮件原件-
> >> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> >> 发送时间: 2023年10月21日 17:56
> >> 收件人: i-d-annou...@ietf.org
> >> 抄送: netmod@ietf.org
> >> 主题: I-D Action: draft-ietf-netmod-node-tags-11.txt
> >>
> >> Internet-Draft draft-ietf-netmod-node-tags-11.txt is now available. It
> is a work item of the Network Modeling (NETMOD) WG of the IETF.
> >>
> >>  Title:   Node Tags in YANG Modules
> >>  Authors:  Qin Wu
> >>   Benoit Claise
> >>   Mohamed Boucadair
> >>   Peng Liu
> >>   Zongpeng Du
> >>  Name:draft-ietf-netmod-node-tags-11.txt
> >>  Pages:   30
> >>  Dates:   2023-10-21
> >>
> >> Abstract:
> >>
> >>  This document defines a method to tag nodes that are associated with
> >>  the operation and management data in YANG modules.  This method for
> >>  tagging YANG nodes is meant to be used for classifying either data
> >>  nodes or instances of data nodes from different YANG modules and
> >>  identifying their characteristic data.  Tags may be registered as
> >>  well as assigned during the definition of the module, assigned by
> >>  implementations, or dynamically defined and set by users.
> >>
> >>  This document also provides guidance to future YANG data model
> >>  writers; as such, this document updates RFC 8407.
> >>
> >> The IETF datatracker status page for this Internet-Draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/
> >>
> >> There is also an HTMLized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11
> >>
> >> A diff from the previous version is available at:
> >>
> https://author-tools.iet

Re: [netmod] IPR on call on draft-ietf-netmod-rfc8407bis-11

[Andy Bierman]

Hi,

 "No, I'm not aware of any IPR that applies to this draft”

Andy


On Mon, Apr 29, 2024 at 3:05 PM Kent Watsen  wrote:

> Authors, Contributors, WG,
>
> As a prerequisite for the WGLC on this document:
>
> Guidelines for Authors and Reviewers of Documents Containing YANG
> Data Models
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11
>
> Are you aware of any IPR that applies to draft identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft”
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules”
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
>
> Also please send the response to the list above, and not unicast it.
>
> FWIW, currently, no IPR is filed for this draft:
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netmod-rfc8407bis
>
> Thanks.
>
> Lou and Kent  (WG Chairs)
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Tue, Apr 16, 2024 at 7:01 AM Benoit Claise 
wrote:

> Hi Andy,
>
>
> On 3/21/2024 5:35 PM, Andy Bierman wrote:
>
> 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.
>
> Yes, we could always push enhancement to YANG-Next.However, don't we have
> enough requests now, not only from the IETF (
> draft-ietf-opsawg-collected-data-manifest
> <https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/>)
> but also from the BBF (Scott Mansfield) and 3GPP (Balazs), as mentioned in 
> meeting
> minutes
> <https://datatracker.ietf.org/doc/minutes-119-netmod-202403210300/>?
> Let's keep in mind that
> I don't see YANG-Next being standardized any time soon.
>
>

I don't see how this type of Schema Mount can be achieved without
specifying which
modules are included at the mount point.  It looks like a special "import"
mechanism will be needed
so a YANG 1.1 tool does not think a module is being used at the top-level.

IMO it is a bad idea to reinvent parts of the YANG language as external
language statements.

Regards, Benoit
>
>
>

Andy


> 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Andy Bierman]

On Tue, Apr 9, 2024 at 7:01 AM Rob Wilton (rwilton) 
wrote:

> Hi Andy,
>
>
>
> For me, it seems likely that vendors using YANG Semver will want to use a
> filename that can contain the Semver label, and I still see some advantages
> for everyone to do it in a similar way.  E.g., it is very likely that
> internally we will just use this format, but will probably strip or convert
> it before publishing them.
>
> But I agree that we shouldn’t formally change the filename format in YANG
> 1.1, and that would be best left for YANG 2.0 (obviously if agreed at that
> time).
>
> My question is whether we can find some middle ground where we at least
> informally document the format in an appendix now (i.e., as non-normative
> text), so that if folks are starting to use a format, then they could
> choose this one, but not to change the extension representation/API when
> naming YANG modules.
>
> Such an appendix might start with something like:
>
> 
> “During this work it was discussed that having a filename format that
> allows for the Semver, rather than the revision-date to be expressed in the
> filename, would be beneficial.  It was concluded that making such a change
> would risk breaking existing tooling and hence would be better deferred to
> a further revision of the YANG language.  The proposed format is
> ‘informatively’ documented below, which might be adopted in a future
> revision of YANG.
>
> … 
>
> 
>
>
> Would such an approach potentially be acceptable to you?  Or are you
> strongly against saying anything at all?  Note the motivation for
> considering put this in is because a comment was raised during IETF 119
> about avoiding an undocumented de facto standard – I would like to get
> consensus on this draft so that we can get it published an move on.
>
>
I tried 3 YANG compilers on a filename with the extension and it caused a
warning in 2 of them and no problem at all in the other.
However, the '#' character is used in config files to mean 'comment to end
of line', so this syntax would be a problem.
The "module-name@revision-date" pattern is used by several tools already.

I don't think changing the file-naming convention for YANG 1.1 is a good
idea.
It should be in a separate Experimental RFC.


Regards,
> Rob
>

 Andy


>
>
>
> *From: *netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Wednesday, 3 April 2024 at 19:07
> *To: *Joe Clarke (jclarke) 
> *Cc: *Jason Sterne (Nokia) ,
> netmod@ietf.org 
> *Subject: *Re: [netmod] YANG Versioning: filename recommendations for
> YANG Semver
>
> Hi,
>
>
>
>
>
> On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) 
> wrote:
>
>
>
>
>
> *From: *Andy Bierman 
> *Date: *Tuesday, April 2, 2024 at 17:40
> *To: *Joe Clarke (jclarke) 
> *Cc: *Jason Sterne (Nokia) ,
> netmod@ietf.org 
> *Subject: *Re: [netmod] YANG Versioning: filename recommendations for
> YANG Semver
>
>
>
>
>
> On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) 
> wrote:
>
> Thanks, Andy.  See inline below.
>
>
>
> I do not agree with these recommendations to change the file names of YANG
> modules.
>
> The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
>
> Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
>
> Additional file naming that can be ignored by YANG 1.1 tools is OK.
>
>
>
> [JMC] We had this conversation on our call today.  I agree with you that
> tools can be unaware of YANG Semver and attempt to load a file named
> foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the
> module name defined within the module.
>
>
>
>
>
> This can never happen since the '#' char is not allowed in a YANG module
> name.
>
> YANG 1.1 tools look for MODNAME[@DATE].EXT.
>
> If the YANG module name is not in this format the tool will not find the
> module.
>
>
>
> [JMC] Of course.  We (authors on the call) were debating what a tool would
> do with the *filename* if it didn’t understand this YANG Semver naming.
>
>
>
> The issue is obviously not the 2 lines of code to parse "#" instead of "@".
>
> IMO this file name change is operationally disruptive and not really
> needed.
>
> How come OpenConfig modules do not use this naming scheme?
>
> Is it because they are following the RFC 7950 file naming rules?
>
>
>
> [JMC] This naming scheme hadn’t been introduced.  OpenConfig doesn’t use
> the @ convention, either.  They just have naked module names from what I
> can see (https://github.com/openconfig/public/tree/master/release/models).
> I know that at least one vendo

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Andy Bierman]

On Tue, Apr 9, 2024 at 7:01 AM Rob Wilton (rwilton) 
wrote:

> Hi Andy,
>
>
>
> For me, it seems likely that vendors using YANG Semver will want to use a
> filename that can contain the Semver label, and I still see some advantages
> for everyone to do it in a similar way.  E.g., it is very likely that
> internally we will just use this format, but will probably strip or convert
> it before publishing them.
>
> But I agree that we shouldn’t formally change the filename format in YANG
> 1.1, and that would be best left for YANG 2.0 (obviously if agreed at that
> time).
>
> My question is whether we can find some middle ground where we at least
> informally document the format in an appendix now (i.e., as non-normative
> text), so that if folks are starting to use a format, then they could
> choose this one, but not to change the extension representation/API when
> naming YANG modules.
>
> Such an appendix might start with something like:
>
> 
> “During this work it was discussed that having a filename format that
> allows for the Semver, rather than the revision-date to be expressed in the
> filename, would be beneficial.  It was concluded that making such a change
> would risk breaking existing tooling and hence would be better deferred to
> a further revision of the YANG language.  The proposed format is
> ‘informatively’ documented below, which might be adopted in a future
> revision of YANG.
>
> … 
>
> 
>
>
> Would such an approach potentially be acceptable to you?  Or are you
> strongly against saying anything at all?  Note the motivation for
> considering put this in is because a comment was raised during IETF 119
> about avoiding an undocumented de facto standard – I would like to get
> consensus on this draft so that we can get it published an move on.
>
>

I do not see the value of creating a new file naming scheme based on the
revision label.
The "import by revision" mechanisms are based on revision date, not label.

YANG extensions are different.
1) a YANG extension MUST NOT alter YANG 1.1 semantics
2) a YANG 1.1 tool MUST be capable of skipping past any extension

However the YANG 1.1 specification makes no such provision for a detail
like the file naming.
So it seems premature and inappropriate to define a file naming scheme for
YANG 2.0
since it does not exist and will probably never exist.




> Regards,
> Rob
>

Andy


>
>
>
>
> *From: *netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Wednesday, 3 April 2024 at 19:07
> *To: *Joe Clarke (jclarke) 
> *Cc: *Jason Sterne (Nokia) ,
> netmod@ietf.org 
> *Subject: *Re: [netmod] YANG Versioning: filename recommendations for
> YANG Semver
>
> Hi,
>
>
>
>
>
> On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) 
> wrote:
>
>
>
>
>
> *From: *Andy Bierman 
> *Date: *Tuesday, April 2, 2024 at 17:40
> *To: *Joe Clarke (jclarke) 
> *Cc: *Jason Sterne (Nokia) ,
> netmod@ietf.org 
> *Subject: *Re: [netmod] YANG Versioning: filename recommendations for
> YANG Semver
>
>
>
>
>
> On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) 
> wrote:
>
> Thanks, Andy.  See inline below.
>
>
>
> I do not agree with these recommendations to change the file names of YANG
> modules.
>
> The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
>
> Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
>
> Additional file naming that can be ignored by YANG 1.1 tools is OK.
>
>
>
> [JMC] We had this conversation on our call today.  I agree with you that
> tools can be unaware of YANG Semver and attempt to load a file named
> foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the
> module name defined within the module.
>
>
>
>
>
> This can never happen since the '#' char is not allowed in a YANG module
> name.
>
> YANG 1.1 tools look for MODNAME[@DATE].EXT.
>
> If the YANG module name is not in this format the tool will not find the
> module.
>
>
>
> [JMC] Of course.  We (authors on the call) were debating what a tool would
> do with the *filename* if it didn’t understand this YANG Semver naming.
>
>
>
> The issue is obviously not the 2 lines of code to parse "#" instead of "@".
>
> IMO this file name change is operationally disruptive and not really
> needed.
>
> How come OpenConfig modules do not use this naming scheme?
>
> Is it because they are following the RFC 7950 file naming rules?
>
>
>
> [JMC] This naming scheme hadn’t been introduced.  OpenConfig doesn’t use
> the @ convention, either.  They just have naked module names from what I
> can see (https://github.

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Andy Bierman]

Hi,


On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) 
wrote:

>
>
>
>
> *From: *Andy Bierman 
> *Date: *Tuesday, April 2, 2024 at 17:40
> *To: *Joe Clarke (jclarke) 
> *Cc: *Jason Sterne (Nokia) ,
> netmod@ietf.org 
> *Subject: *Re: [netmod] YANG Versioning: filename recommendations for
> YANG Semver
>
>
>
>
>
> On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) 
> wrote:
>
> Thanks, Andy.  See inline below.
>
>
>
> I do not agree with these recommendations to change the file names of YANG
> modules.
>
> The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
>
> Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
>
> Additional file naming that can be ignored by YANG 1.1 tools is OK.
>
>
>
> [JMC] We had this conversation on our call today.  I agree with you that
> tools can be unaware of YANG Semver and attempt to load a file named
> foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the
> module name defined within the module.
>
>
>
>
>
> This can never happen since the '#' char is not allowed in a YANG module
> name.
>
> YANG 1.1 tools look for MODNAME[@DATE].EXT.
>
> If the YANG module name is not in this format the tool will not find the
> module.
>
>
>
> [JMC] Of course.  We (authors on the call) were debating what a tool would
> do with the *filename* if it didn’t understand this YANG Semver naming.
>
>
>
> The issue is obviously not the 2 lines of code to parse "#" instead of "@".
>
> IMO this file name change is operationally disruptive and not really
> needed.
>
> How come OpenConfig modules do not use this naming scheme?
>
> Is it because they are following the RFC 7950 file naming rules?
>
>
>
> [JMC] This naming scheme hadn’t been introduced.  OpenConfig doesn’t use
> the @ convention, either.  They just have naked module names from what I
> can see (https://github.com/openconfig/public/tree/master/release/models).
> I know that at least one vendor is already using YANG Semver and the ‘#’
> notation for file naming.  I believe it is in part because of this the
> chairs wanted us to revisit the naming.
>
>
>
>
>
> So the revision-date is the only field that can be relied upon since the
> same SemVer (e.g. "1.0.0") could be released several times,
>
> each one containing different content.
>
>
>
> [JMC] Just as with revision-date, the YANG Semver identifier must be
> unique.  You cannot have multiple “1.0.0” identifiers for the same module
> with different content.  That 1.0.0 would be tied to a revision of a unique
> date.
>
>
>


I do not see any net value by changing the filename spec so it is different
than YANG 1.1.
Duplication of files is a bug, not a feature.

Tools usually rely on a proprietary search path configuration to find
modules.
Some clients rely on  and always use the modules from the
server.
This is stable and has been the practice since 2016.

IMO this is an NBC change to YANG 1.1, so it should not be done at all.
Adding YANG extensions is fine, and I support that part of this work.


Joe
>
>
>

Andy


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

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Andy Bierman]

On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) 
wrote:

> Thanks, Andy.  See inline below.
>
>
>
> I do not agree with these recommendations to change the file names of YANG
> modules.
>
> The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
>
> Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
>
> Additional file naming that can be ignored by YANG 1.1 tools is OK.
>
>
>
> [JMC] We had this conversation on our call today.  I agree with you that
> tools can be unaware of YANG Semver and attempt to load a file named
> foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the
> module name defined within the module.
>
>
>

This can never happen since the '#' char is not allowed in a YANG module
name.
YANG 1.1 tools look for MODNAME[@DATE].EXT.
If the YANG module name is not in this format the tool will not find the
module.

The issue is obviously not the 2 lines of code to parse "#" instead of "@".
IMO this file name change is operationally disruptive and not really needed.
How come OpenConfig modules do not use this naming scheme?
Is it because they are following the RFC 7950 file naming rules?



> [JMC] Therefore, I’d be more in favor of no strong language on
> recommendations for YANG Semver within filenames.  Instead, to avoid a de
> facto standard in the industry, I’d prefer language such as, “if you want
> to insert YANG Semver into the module filename, then the format MUST be
> MODULE_NAME#SEMVER.yang.”  Any recommendation would be to remain consistent
> to 7950 and additionally publish the file with @REVSION.
>
>
>
> I do not understand how a 1:1 deterministic mapping is achieved, based on
> the YANG SemVer spec:
>
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-15.html#name-yang-semver-pattern
>
>
>
>1.0.3
>
>1.0.3_compatible
>
>1.0.3_non_compatible
>
>
>
> [JMC] These three versions cannot happen for a given module.  Only one of
> them can exist based on the rules.  If 1.0.3 already exists, then the next
> version could only be 1.0.4_compatible or 1.0.4_non_compatible (assuming
> you want to do BC or NBC changes in the 1.0 MAJOR.MINOR branch).
>
>
>
> The SemVer draft is confusing.
>
>
>
>   YANG artifacts that employ semantic versioning as defined in this
> document MUST use a version identifier
>
>   that corresponds to the following pattern: 'X.Y.Z_COMPAT'.
>
>
>
> And also:
>
>
>
>   Additionally, [SemVer] defines two specific types of metadata that
> may be appended to a semantic version string.  
>
>
>
> Examples from sec 6:
>
>
>   1.0.0-alpha.1
>
>   1.0.0-alpha.3
>
>   2.1.0-beta.42
>
>   3.0.0-202007.rc.1
>
>
>
>
>
> How do these strings conform to the pattern specified in sec. 4.3?
>
>
>
> [JMC] This additional build metadata is ignored for the purposes of YANG
> Semver, but I get your point.  I think some text should be added to address
> this optional metadata.
>
>
>

So the revision-date is the only field that can be relied upon since the
same SemVer (e.g. "1.0.0") could be released several times,
each one containing different content.


Joe
>


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

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Andy Bierman]

Hi,

I do not agree with these recommendations to change the file names of YANG
modules.
The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
Additional file naming that can be ignored by YANG 1.1 tools is OK.

I do not understand how a 1:1 deterministic mapping is achieved, based on
the YANG SemVer spec:

https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-15.html#name-yang-semver-pattern

   1.0.3
   1.0.3_compatible
   1.0.3_non_compatible

The SemVer draft is confusing.

  YANG artifacts that employ semantic versioning as defined in this
document MUST use a version identifier
  that corresponds to the following pattern: 'X.Y.Z_COMPAT'.

And also:

  Additionally, [SemVer] defines two specific types of metadata that
may be appended to a semantic version string.  

Examples from sec 6:

  1.0.0-alpha.1

  1.0.0-alpha.3

  2.1.0-beta.42

  3.0.0-202007.rc.1


How do these strings conform to the pattern specified in sec. 4.3?

How is the revision label in the filename useful if the same string
actually identifies multiple revisions?


Andy



>
> At IETF 119, during the YANG Versioning discussions, there was a
> suggestion to raise the filename issue again as one last issue to resolve
> before going to last call.
>
>
>
> Version 10 of Module Versioning had the following content that was
> subsequently removed in version 11:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-10#name-file-names
>
>
>
> 3.4.1.  File names
>
>
>
>This section updates [RFC7950] section 5.2, [RFC6020] section 5.2 and
>
>[RFC8407] section 3.2
>
>
>
>If a revision has an associated revision label, then it is
>
>RECOMMENDED that the name of the file for that revision be of the
>
>form:
>
>
>
>  module-or-submodule-name ['#' revision-label] ( '.yang' / '.yin' )
>
>
>
>E.g., acme-router-module#2.0.3.yang
>
>
>
>YANG module (or submodule) files may be identified using either the
>
>revision-date (as per [RFC8407] section 3.2) or the revision label.
>
>
>
> At least one major implementation is already using YANG Semver in
> filenames, and the IETF 119 attendees raised the concern that if we don’t
> specify a desired filename format, then an de-facto standard will likely
> occur. Or perhaps we’ll end up with multiple competing approaches to having
> a YANG Semver in a filename.
>
>
>
> There are a number of advantages of having the key version identifier in
> the filename (hence why it is recommended in RFC 7950 and RFC 8407).
> Resolving the new ‘recommended-min’ extensions in Module Versioning and
> YANG Semver would also be easier if the YANG Semver is right in the
> filename.
>
>
>
> In the IETF 118 Hackathon, Per demonstrated that modifying pyang to handle
> the additional filename format was a fairly trivial change. But it still
> may take other tool authors time to update other tools.
>
>
>
> Some potential issues for us to consider & discuss as a WG:
>
>1. Should we mention anything about potential use of symlinks (e.g.
>instead of having 2 copies of a module with two different filenames, one
>with revision date, the other with YANG Semver, just have one of them
>symlink to the other?)
>2. The YANG Semver draft mandates that IETF YANG modules have a YANG
>Semver. Do we also need to recommend/mandate something specific about
>filenames for IETF YANG modules (e.g. in the CODE BEGINS line in RFCs)?
>3. Will most tools that haven’t been modified yet to recognize the new
>filename format simply interpret the #X.Y.Z as part of the module name?
>Will they complain that the filename doesn’t match the module name?
>4. Will some tools & processes fail because of the “#” (i.e. consider
>it a comment marker and chop off the chars that follow)?
>
>
>
> Another possible approach is something along these lines:
>
> **If** you are going to put a YANG Semver into a module filename, then
> you MUST use this format:   #.yang
>
>
>
> That doesn’t preclude having both a revision date format and a YANG Semver
> format, but doesn’t specifically suggest to use one or the other. Then
> perhaps YANG-NEXT could mandate the YANG Semver filename format?
>
>
>
> So the big questions are:
>
>- Whether to include this filename convention in the YANG Semver draft?
>- How strong a recommendation/mandate should it be?
>
>
>
> Jason (he/him)
>
>
> ___
> 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] 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

[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

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

[Andy Bierman]

Hi,

I looked at the diffs and all are OK.


On Mon, Mar 4, 2024 at 12:18 PM Carsten Bormann  wrote:

> 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
>
>

thanks -- implementors rely on correct examples



> > ## 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).
>


So there MUST be a response for every varbind (even ones that failed or no
data)
or the response message is malformed?  The position is critical since the
same SID
could be requested for different instances.



>
> > ## 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
>
>

SNMP has 'get-next' for instance discovery, which I would be horrified to
see in a new protocol.
NETCONF and RESTCONF have complex filtering but not really any specific
support at all.
The 'depth' parameter is actually complicated to implement correctly and
almost always includes
more data than is needed for this purpose.

I suggest a more direct approach like "keys-only": a boolean filter
parameter indicating that the
only key leafs (and required ancestor containers/lists) are returned.

This is an optimization. A client can get everything which will include the
keys.
It could be added later if an efficient solution is really needed.


> ## 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.
>
>

Good. Do not repeat the mistakes of NETCONF "error-option".



> While all-or-none processing could be considered 

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Andy Bierman]

On Sat, Mar 16, 2024 at 2:41 AM Christian Hopps  wrote:

>
>
> > On Mar 15, 2024, at 19:13, Per Andersson (perander) 
> wrote:
> >
> > Christian Hopps  on Friday, March 15, 2024 20:10:
> >>> On Mar 15, 2024, at 13:26, mohamed.boucad...@orange.com wrote:
> >>>
> >>> Re-,
> >>> I’m not sure to agree with your last statement, Andy.
> >>> The reality is that the OLD reco is inducing many cycles and waste of
> time for no obvious technical reason:  see an example herehttps://
> mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/
> >>> Let’s save the authors time with a clear guidance:
> >>>• Pick ietf- or iana- as a function of the module
> >>
> >> I disagree with this guidance.
> >
> > Can you explain your motivation?
>
> Well first, what has been state earlier in the thread. But basically they
> add almost no value and gratuitously extend what is supposed to be a short
> identifier.
>
>
I am sorry for bringing this up.

I just grep'ed through about 1000 YANG modules to do a guestimate of the
prefix usage,
looking for "meaningful" prefixes.

It is not that consistent across SDOs. IMO BBF is the best (by far).
The IETF has the most 2-letter prefixes.
DOTS and TE have structured prefixes (about 7 - 12 chars).
IMO these are good examples for new YANG modules.

The most important property is that the prefix is meaningful.


Thanks,
> Chris.
>
>
Andy


> >
> >
> > --
> > Per
>
>
> ___
> 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] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Andy Bierman]

On Fri, Mar 15, 2024 at 9:42 AM Jürgen Schönwälder
 wrote:

> Yes, for long XPath expressions, one likes to have short prefixes, the
> shorter the better. In other contexts, such as type definitions, one
> may want to use longer prefixes providing more context. It seems you
> can't have both at the same time. Given this inherent conflict, I am
> not sure that generally pushing for longer prefixes is a good thing.
>
> For modules with long XPath expressions, an author may consider to go
> for one character local prefixes even if they require to lookup their
> meaning in the imports (or people have modern editors that can
> dynamically show an expansion) because mutli-line XPath expressions
> with lots of repetitive substrings are pretty bad for human eyes.
>
>
Short is OK if the prefix is familiar to the reader. Like "if".
What if the writer wanted a, b, c, d, etc? Shortt but not meaningful.
It is a judgment call every time, too complex for a guideline.

The guideline only mentions short so the prefix will not conflict and
the import-stmt in
other modules will not need a different prefix.  This is only for reader
familiarity, since the
YANG compiler does not care which prefix is used.

The naming convention already established is that the SDO prefix (ietf or
iana) is not used.
It would not help readers to change it now.



/js
>

Andy


>
> On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote:
> > On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder
> >  wrote:
> >
> > > I wonder which problem we are solving with adding more little rules.
> > > Perhaps a future version of YANG will do away with prefixes but until
> > > this happens, I do not think we need to add more rules about how to
> > > choose prefixes. The original intend was that they are short to keep
> > > YANG snippets concise and easy to read.
> > >
> > >
> >
> > This is the IETF Coding Conventions document, not the YANG specification.
> > Naming conventions are CLRs but often with some benefits.
> >
> > What problems?
> >
> > 1) If there are multiple modules used in imports then the reader must be
> > able to
> > easily tell the prefixes apart.  If prefixes are too short and not
> > meaningful, this task
> > gets more difficult.  I find myself constantly going back to the imports
> to
> > make sure
> > I am matching the prefix to the correct module.
> >
> > 2) If there are complex XPath expressions then prefixes that are too long
> > make the
> > expression unreadable, especially as it is chopped into "string" +
> > "string"  format
> > to fit into 72 character lines. If prefixes are too short then back to
> > problem (1).
> >
> > 3)  It is becoming more common to have vendor modules import modules from
> > multiple SDOs.
> > Prefix naming conventions are already the BCP everywhere but the IETF.
> >
> > Is it too late to start for IETF? There are many modules already with no
> > naming consistency,
> > so this would only affect new modules. There will never be consistent
> > naming of prefixes
> > so it may not be worth the change now.
> >
> >
> >
> > /js
> > >
> >
> >
>
> --
> 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] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Andy Bierman]

On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder
 wrote:

> I wonder which problem we are solving with adding more little rules.
> Perhaps a future version of YANG will do away with prefixes but until
> this happens, I do not think we need to add more rules about how to
> choose prefixes. The original intend was that they are short to keep
> YANG snippets concise and easy to read.
>
>

This is the IETF Coding Conventions document, not the YANG specification.
Naming conventions are CLRs but often with some benefits.

What problems?

1) If there are multiple modules used in imports then the reader must be
able to
easily tell the prefixes apart.  If prefixes are too short and not
meaningful, this task
gets more difficult.  I find myself constantly going back to the imports to
make sure
I am matching the prefix to the correct module.

2) If there are complex XPath expressions then prefixes that are too long
make the
expression unreadable, especially as it is chopped into "string" +
"string"  format
to fit into 72 character lines. If prefixes are too short then back to
problem (1).

3)  It is becoming more common to have vendor modules import modules from
multiple SDOs.
Prefix naming conventions are already the BCP everywhere but the IETF.

Is it too late to start for IETF? There are many modules already with no
naming consistency,
so this would only affect new modules. There will never be consistent
naming of prefixes
so it may not be worth the change now.



/js
>


Andy


>
> On Fri, Mar 15, 2024 at 01:02:58PM +, mohamed.boucad...@orange.com
> wrote:
> > Hi Andy,
> >
> > (changing the subject to ease tracking this)
> >
> > The thread I was referring is:
> https://mailarchive.ietf.org/arch/msg/netmod/6VkSrroaxwXHSI19Jj0j-tbFCjA/
> >
> > I do personally think that it is a good guidance to prefix IETF modules
> with “ietf-“ and IANA-maintained ones with “iana-‘. This is consistent with
> the practice we followed recently for iana-maintained modules.
> >
> > If we recommend this prefix pattern, I’m afraid that we need to revisit
> the text about short prefixes, e.g.,
> >
> > 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 prefixed with “ietf-“ for IETF modules and
> >“iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
> >too long and SHOULD NOT conflict with known modules that have been
> >previously published.
> >
> > Cheers,
> > Med
> >
> > De : Andy Bierman 
> > Envoyé : jeudi 14 mars 2024 22:53
> > À : Mahesh Jethanandani 
> > Cc : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> > Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis
> >
> > Hi,
> >
> > I cannot find this email wrt/ short prefixes
> >
> >
> >   *   (short/uniqueness of prefixes
> >
> > Other SDOs are using a prefix in their prefixes (e.g. openconfig).
> > It is common for servers to have both "if:interfaces" and
> "oc-if:interfaces" subtrees.
> >
> > It might be a good idea to have a guideline that all IETF YANG modules
> SHOULD
> > use the "ietf-" string in the module prefix.  This should reduce the
> chance of name collisions
> > between SDOs and vendors, and helps identify the module as an IETF
> module.
> >
> >
> > Andy
> >
> >
> >
> > On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani <
> mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote:
> > 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 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<
> https://boucadair.github.io/rfc8407bis/#go.draft-iet

Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Andy Bierman]

Hi,

I cannot find this email wrt/ short prefixes


   - (short/uniqueness of prefixes


Other SDOs are using a prefix in their prefixes (e.g. openconfig).
It is common for servers to have both "if:interfaces" and
"oc-if:interfaces" subtrees.

It might be a good idea to have a guideline that all IETF YANG modules
SHOULD
use the "ietf-" string in the module prefix.  This should reduce the chance
of name collisions
between SDOs and vendors, and helps identify the module as an IETF module.


Andy



On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani <
mjethanand...@gmail.com> wrote:

> 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
>
>
>
>
>
>
> ___
> 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] Draft IETF 119 NETMOD Agenda posted

[Andy Bierman]

On Tue, Mar 12, 2024 at 9:15 AM Jan Lindblad (jlindbla)  wrote:

> Qiufang,
>
> I'm sorry to say I'm strongly against WGLC at this time because of point
> #2 below.
>
> One of the great contributions to network automation that YANG has brought
> is that clients now have a fair chance at computing a desired configuration
> change for a network element. Maybe we need to develop a more elaborate
> model for configuration consistency relative today's "The running
> configuration datastore MUST always be valid", but have I trouble with us
> stirring up multiple interpretations and then staying silent. That's not
> the way to build interoperability.
>
> IMO we need to sort out what the rules are before we come close to WGLC,
> or else the grief outweighs the gain.
>
>

The WG does not think NMDA is too complicated or too difficult for clients
to use. I disagree.
Adding more datastores and interactions between datastores will make NMDA
even worse.
Retrieval of multiple datastores so they can be compared for transient
differences is a very complex
way to convey this state information to the client.

NMDA is too server-centric already. Maximum flexibility for the server
developer means
minimum consistency for the client developer.


Best Regards,
> /jan
>

Andy


>
> On 12 Mar 2024, at 03:44, maqiufang (A)  40huawei@dmarc.ietf.org> wrote:
>
> Hi, chairs,
>
> For system-config draft (
> https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), the
> authors have submitted a new version to reflect the outcome of the interim,
> the main updates are following:
> 1.  Address the "origin" issue
> a.   The current document explicitly states that system configuration
> copied from  into  have its origin value being reported as
> "intended" and update the examples accordingly
> b.  Also, update the definition of "intended" origin identity in 8342
> to allow a subset of configuration in  to use "system" as origin
> value
> c.   The current document states data migration is out-of-scope
> except that gives a couple of implementation examples in section 4.2
> (please feel free to propose text if you have better suggestion)
> 2.  validity of  alone
> a.   The current document is silent on this point. Related statements
> which requires referenced system nodes must be copied into  are
> removed.
> 3.  Other updates
> a.   Usage examples refinement, e.g., fix validation errors, remove
> redundancy for conciseness
>
> There is currently no open issues, thus the authors believe this draft is
> ready for WGLC, but this might be worth a broad review on the mailing list.
>
> Best Regards,
> Qiufang
> *From:* netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Lou Berger
> *Sent:* Friday, March 8, 2024 9:44 PM
> *To:* NETMOD WG 
> *Cc:* netmod-cha...@ietf.org
> *Subject:* Re: [netmod] Draft IETF 119 NETMOD Agenda posted
>
>
> **IMPORTANT**
>
> Authors of WG documents,
>
> If your document has not yet been submitted to the IESG for publication
> *and* your draft is not on the agenda, please either:
> (a) request to present status or
> (b) send email to the list summarizing status by end of day (any TZ)
> Friday, March 15.
>
> In either case, please include recent changes, open issues, plan to
> resolve open issues/complete the document.
>
> Thank you!
>
> Lou (and Kent)
> On 3/7/2024 3:53 PM, Jason Sterne (Nokia) wrote:
>
> Hello NETMOD WG,
>
> A draft NETMOD agenda for IETF 119 has been published. Please review and
> let the chairs know if any changes are needed or additional topics should
> be covered.
>
> The agenda is pasted below, but here's the link to the always-current
> version:
> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
>
> Presenters: please provide slides to netmod-cha...@ietf.org no later than
> Sunday March 17 (any time zone).
>
> Thanks,
> Jason (+ chairs Kent and Lou)
>
> Draft Agenda for the NETMOD 119 WG Session
>
> https://datatracker.ietf.org/meeting/119/materials/agenda-119-netmod
> https://datatracker.ietf.org/meeting/119/session/netmod
> Session:
>
> Thursday, March 21, 2024
> 13:00-15:00 Brisbane (Australia - Eastern Time)
> 03:00-05:00 UTC
> 23:00-01:00 Wednesday March 20 America - Eastern Time
>
> https://www.timeanddate.com/worldclock/converter.html?iso=20240321T03&p1=47
>
> Room: M2 https://datatracker.ietf.org/meeting/119/floor-plan?room=m2
> WG Chairs:
>
> Lou Berger (lberger at labs dot net)
> Kent Watsen (kent plus ietf at watsen dot net)
> WG Secretary
>
> Jason Sterne (jason dot sterne at nokia dot com)
> Available During Session:
>
> MeetEcho: https://meetings.conf.meetecho.com/ietf119/?session=31987
> Onsite tool: https://meetings.conf.meetecho.com/onsite119/?session=31987
> Audio Only: https://mp3.conf.meetecho.com/ietf119/31987.m3u
> Available During and After Session:
>
> Notes: https://notes.ietf.org/notes-ietf-119-netmod?both
> Slides: https://datatracker.ietf.org/meeting/119/session/netmod
> Zulip (chat):
> https://

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

[Andy Bierman]

On Tue, Mar 12, 2024 at 7:28 AM Per Andersson (perander) 
wrote:

> Andy Bierman  on Tuesday, March 12, 2024 15:14:
> > On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad  j...@tail-f.com>> wrote:
> >> Then we have the other thing with RESTCONF where the module names are
> used instead, which also causes some (unnecessary) confusion. If NETCONF
> and RESTCONF could use the same "prefixes", things would be easier. In the
> early days of programming (I mean in the 60's), FORTRAN programmers were
> told to choose short function and variable names. This mindset has long
> since been abandoned. Why is this still a good practice in YANG prefixes?
> >
> > I disagree with any changes to module prefixes.
> > They are not confusing to anybody who bothers to learn a little about
> YANG.
> > Long prefixes make YANG harder to read, not easier.
>
> I disagree with this (hence agree with Jan).
>
> It was confusing to learn that RESTCONF and NETCONF
> use different prefixes.
>
> Short prefixes are nice when writing, longer descriptive prefixes
> are better when reading. Why would otherwise other identifiers
> have these long form names, and not have short identifiers too?
>
>

Module names need to be longer so they are unlikely to clash.
All other identifiers are scoped within a namespace, so no technical reason
to be longer.
I agree that using prefixes that are already assigned should be avoided.



>
> --
> Per


Andy
___
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

[Andy Bierman]

On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad  wrote:

> Jürgen,
>
> You have been in the YANG circles long enough to remember the basic
> tenets.
>
>YANG values the time and effort of the
>readers of models above those of modules writers and YANG tool-chain
>developers.
>
> In this spirit, it's obvious to me that choosing very short prefixes are
> making it much harder for newcomers to parse YANG modules. They see "snmp:"
> in one module and assumes it means the same as "snmp:" in another. Or
> "if:", "mpls:" and a bunch of other convenient, short prefixes that I have
> seen clashing in the real world. If we could foster the habit (best
> practice) of at least adding a few characters to distinguish the publishing
> organizations from each other, a lot would be won. "ietf-if:" and
> "vendor-if:" would be a lot clearer.
>
> Then we have the other thing with RESTCONF where the module names are used
> instead, which also causes some (unnecessary) confusion. If NETCONF and
> RESTCONF could use the same "prefixes", things would be easier. In the
> early days of programming (I mean in the 60's), FORTRAN programmers were
> told to choose short function and variable names. This mindset has long
> since been abandoned. Why is this still a good practice in YANG prefixes?
>
>

I disagree with any changes to module prefixes.
They are not confusing to anybody who bothers to learn a little about YANG.
Long prefixes make YANG harder to read, not easier.


Best Regards,
> /jan
>
>
>
Andy


>
> On 5 Mar 2024, at 10:38, Jürgen Schönwälder
>  wrote:
>
> Hi Med,
>
> I believe it is a misconception that text not written in capital letters
> is not normative. I also believe we need _guidelines_ on the choice of
> identifiers like prefixes and not hard rules.
>
> Prefixes do not have to be unique. It is nice if they are for widely
> used modules, but we are on a slippery path if we think of them as
> something that should be unique. Then they get long or clumsy or both
> (or worse we encourage a competition to allocate nice short prefixes).
> Yes, the original language is vague, on purpose. I guess I miss which
> problem is solved by requiring uniqueness that practically can't be
> ensured and is technically also not necessary.
>
> /js
>
> On 05.03.24 09:58, mohamed.boucad...@orange.com wrote:
>
> Hi Jürgen,
> Please see inline.
> Cheers,
> Med
>
> -Message d'origine-
> De : netmod  De la part de Jürgen Schönwälder
> Envoyé : lundi 4 mars 2024 20:44
> À : netmod@ietf.org
> Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-
> rfc8407bis
>
> Hi,
>
> the statement "should be selected carefully to be unique" is
> impossible to implement given an open ended set of YANG modules.
>
> [Med] Hmm, but there is no normative text in that sentence. What
> concretely needs to be followed is indicated in the sentence right after
> (SHOULD NOT); which is inherited from 8407.
> Isn't "selected carefully to be unique" echoing the spirit of this text
> from RFC7950?
>Developers of YANG modules and submodules are RECOMMENDED to choose
>names for their modules that will have a low probability of colliding
>with standard or other enterprise modules, e.g., by using the
>enterprise or organization name as a prefix for the module name.
>Within a server, all module names MUST be unique.
>
> 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.
>
> [Med] "SHOULD ...likely" is really ambiguous as a reco if the text does
> not explain when it won't be
>
> Perhaps it should be even further watered down to "likely to be unique
> in a certain usage context".
>
> [Med] What is a usage context? how that usage context is known? How a
> module is concretely bound to it? Etc. IMO, this triggers more questions
> that it clarifies the guidance.
>
>
> 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 t

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

[Andy Bierman]

On Thu, Feb 22, 2024 at 9:42 AM Kent Watsen  wrote:

> 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
>
>

I support the problem statement.
The solution has minor resolvable issues, so no objections to adoption.

There is a larger concern here, which is the ad-hoc approach to metadata in
YANG protocols.

1)   data nodes returned with attributes and use a parameter to opt-in to
the added metadata
 e.g.: with-defaults and with-origin

2) node-tags monitoring data representing data nodes with metadata

3) separate datastore containing data nodes and their presence and value is
supposed
to be a replacement for metadata.


I prefer approach (1), which is what is used in this draft.
It is the simplest to use.

It looks like the WG is headed in a direction where there will be some of
each approach,
and each bit of metadata will require yet another ad-hoc solution.


Andy



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
>
___
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

[Andy Bierman]

ent 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 seen
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/long-trees/draft-ietf-netmod-rfc8407bis.txt
>
>
>
> 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

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

[Andy Bierman]

On Tue, Mar 5, 2024 at 1:39 AM Jürgen Schönwälder
 wrote:

> Hi Med,
>
> I believe it is a misconception that text not written in capital letters
> is not normative. I also believe we need _guidelines_ on the choice of
> identifiers like prefixes and not hard rules.
>
> Prefixes do not have to be unique. It is nice if they are for widely
> used modules, but we are on a slippery path if we think of them as
> something that should be unique. Then they get long or clumsy or both
> (or worse we encourage a competition to allocate nice short prefixes).
> Yes, the original language is vague, on purpose. I guess I miss which
> problem is solved by requiring uniqueness that practically can't be
> ensured and is technically also not necessary.
>
>
+1

The prefixes are local to the module or submodule.
We should not pretend they are global identifiers like the module name.


> /js
>

Andy


>
> On 05.03.24 09:58, mohamed.boucad...@orange.com wrote:
> > Hi Jürgen,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : netmod  De la part de Jürgen Schönwälder
> >> Envoyé : lundi 4 mars 2024 20:44
> >> À : netmod@ietf.org
> >> Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-
> >> rfc8407bis
> >>
> >> Hi,
> >>
> >> the statement "should be selected carefully to be unique" is
> >> impossible to implement given an open ended set of YANG modules.
> >
> > [Med] Hmm, but there is no normative text in that sentence. What
> concretely needs to be followed is indicated in the sentence right after
> (SHOULD NOT); which is inherited from 8407.
> >
> > Isn't "selected carefully to be unique" echoing the spirit of this text
> from RFC7950?
> >
> > Developers of YANG modules and submodules are RECOMMENDED to choose
> > names for their modules that will have a low probability of colliding
> > with standard or other enterprise modules, e.g., by using the
> > enterprise or organization name as a prefix for the module name.
> > Within a server, all module names MUST be unique.
> >
> >> 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.
> >
> > [Med] "SHOULD ...likely" is really ambiguous as a reco if the text does
> not explain when it won't be
> >
> >> Perhaps it should be even further watered down to "likely to be unique
> >> in a certain usage context".
> >
> > [Med] What is a usage context? how that usage context is known? How a
> module is concretely bound to it? Etc. IMO, this triggers more questions
> that it clarifies the guidance.
> >
> >>
> >> 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 d

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

[Andy Bierman]

On Wed, Feb 28, 2024 at 6:30 PM Qin Wu 
wrote:

> + 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."
>
>
>
> *[Qin Wu] Fair statement, there is tradeoff between uniqueness of the
> prefix and prefix length. Sometimes these two factor contradict to each
> other.*
>
> 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.
>
>
>
> *[Qin Wu]:There are two challenges I see here:*
>
> *a.  **sometimes the module name length is too long, which will make
> prefix long as well.*
>
> *b.  **Prefix definition rule for JSON is different from Prefix
> definition rule for XML, see section 5 of RFC7951:*
>
> o  namespace-qualified - the data node identifier is prefixed with
>
> the name of the module in which the data node is defined,
>
> separated from the data node identifier by the colon character
>
> (":").
>
> *I remember there is on relevant discussion on mailing list:*
>
> *https://mailarchive.ietf.org/arch/msg/netmod/DmvrWxlm3RGgTnPGPiE2hM_TpR8/
> <https://mailarchive.ietf.org/arch/msg/netmod/DmvrWxlm3RGgTnPGPiE2hM_TpR8/>*
>
>
>
> + 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.
>
>
>



A missing leaf with no default means there is no instance in the data tree.
This impacts XPath evaluation and leafref / instance-identifier validation.
I think the RFC is clear on how to handle an empty node-set.

Andy

*[Qin Wu] Interesting, it seems you are talking about Qutrit Entanglement
> in quantum communication. Yes, I agree this worth adding guidance. What is
> your recommendation? Allow three states or add default in the description
> statement?*
>
> 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  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
>
> Internet-Draft draft-ietf-netmod-rfc8407bis-09.txt is now available.
> It is a work item of the Network Modeling (NETMOD) WG of the IETF.
>
>   Title:   Guidelines for Authors and Reviewers of Documents
> Containing YANG Data Models
>   Authors: Andy Bierman
>Mohamed Boucadair
>Qin Wu
>   Name:draft-ietf-netmod-rfc8407bis-09.txt
>   Pages:   84
>  

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

[Andy Bierman]

gt;
>
> 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  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
>
> Internet-Draft draft-ietf-netmod-rfc8407bis-09.txt is now available.
> It is a work item of the Network Modeling (NETMOD) WG of the IETF.
>
>   Title:   Guidelines for Authors and Reviewers of Documents
> Containing YANG Data Models
>   Authors: Andy Bierman
>Mohamed Boucadair
>Qin Wu
>   Name:draft-ietf-netmod-rfc8407bis-09.txt
>   Pages:   84
>   Dates:   2024-02-28
>
> Abstract:
>
>   This memo provides guidelines for authors and reviewers of
>   specifications containing YANG modules, including IANA-maintained
>   modules.  Recommendations and procedures are defined, which are
>   intended to increase interoperability and usability of Network
>   Configuration Protocol (NETCONF) and RESTCONF protocol
>   implementations that utilize YANG modules.  This document obsoletes
>   RFC 8407.
>
>   Also, this document updates RFC 8126 by providing additional
>   guidelines for writing the IANA considerations for RFCs that
> specify
>   IANA-maintained modules.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C51672231
> 30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl
> P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D&reserved=0
>
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943
> a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447
> 076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f
> hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0
>
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943a5a4c
> 608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671
> 6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR
> mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
>
> 
> 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] Rfc8407 - what does this text mean?

[Andy Bierman]

Hi,

I don't think the issue is whether a foo-state module is included in the
RFC or not.
There is an algorithm to produce the foo-state module for vendors to use.

IMO the NMDA guideline should indicate "need NMDA", and be present if it is
believed that the operational state can be
different than the config. In that case a  on  would
be useful.
If not, then the foo-state module is not even relevant.


Andy


On Tue, Feb 20, 2024 at 10:34 PM  wrote:

> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Andy Bierman 
> *Envoyé :* mardi 20 février 2024 18:19
> *À :* BOUCADAIR Mohamed INNOV/NET 
> *Cc :* Kent Watsen ; netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
>
>
>
>
> On Mon, Feb 19, 2024 at 11:39 PM  wrote:
>
> Hi all,
>
>
>
> I updated the PR to use a wording aligned with 4.23:
>
>
>
> NEW:
>
>If the document contains a temporary non-NMDA (Network Management
>
>Datastore Architecture) [RFC8342], then the Introduction section
>
>should mention this fact with the reasoning that motivated that
>
>design.  Refer to Section 4.23 for more NMDA-related guidance.
>
>
>
>
>
>
>
> Does this mean that the Transition to NMDA is completed, and it is now
> considered a bad idea
>
> to include a non-NMDA 'state' module?
>
> *[Med] We don’t actually change the core NMDA guidance (hence the pointer
> to 4.23). All we do here is, given the SHOULD NMDA-compliant reco in 4.23
> and the practice adopted for published modules since then, we encourage
> highlighting exceptions (MAY temporary thing in 4.23) in the Introduction
> rather than the SHOULD.*
>
>
>
>   Most deployments (90%?) are non-NMDA.
>
> The motivation will always be to allow this 90% to retrieve the
> operational values of specific configuration data.
>
>
>
> Cheers,
>
> Med
>
>
>
>
>
> Andy
>
>
>
> *De :* Andy Bierman 
> *Envoyé :* lundi 19 février 2024 19:58
> *À :* Kent Watsen 
> *Cc :* BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
>
>
>
>
> On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen  wrote:
>
> Hi Med,
>
>
>
> On Feb 19, 2024, at 3:29 AM, mohamed.boucad...@orange.com wrote:
>
>
>
> Hi Kent, all,
>
>
>
> I also think that highlighting the exceptions + motivate them makes sense
> here. A PR to fix that can be seen at [1].
>
>
>
> Thank you.
>
>
>
> I hope folks express objections now, before WGLC, as an expeditious
> resolution helps me close off an IESG review comment in NETCONF.
>
>
>
> Guidelines should be specific and clear.
>
> This inverse exception text seems better than the boilerplate text you
> want to replace.
>
>
>
> What exactly does it mean for a YANG module to be non-NMDA-compliant?
>
> Is the guideline forbidding config/state sibling containers, or just those
> that use a grouping or cut-and-paste
>
> to implement its non-NMDA-ness?
>
> Maybe NMDA experts can explain when this exception is needed and what it
> should say.
>
>
>
>
>
>
>
>
>
>
>
> FWIW, the OLD text was added draft-ietf-netmod-rfc6087bis-17 as per a
> comment in the AD review [2].
>
>
>
> That’s a great find!
>
>
>
>
>
> No wonder I didn't remember the WG discussing this during draft-8407.
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> K.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
>
>
>
> *De :* netmod  *De la part de* Kent Watsen
> *Envoyé :* vendredi 16 février 2024 21:55
> *À :* Andy Bierman 
> *Cc :* netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
> Hi Andy,
>
>
>
> Thanks for the speedy reply.
>
>
>
> This guidance seems inverted, at least within the IETF (where SHOULDs are
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407
> is read.  See the first paragraph of
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
>
>
> I doubt any module would get past the IETF-publication process now if it
> defined a non-NMDA compliant structure (i.e., CF nodes that p

Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Andy Bierman]

On Tue, Feb 20, 2024 at 8:03 AM Kent Watsen  wrote:

> Juergen, Tom, Andy,
>
> Gentle reminder.
>
>
I read draft-11.  It is an improvement. No objections.
There are 4 IETF tags defined:  metrics, logs, traces, info
I do not see much value in these standard tags, but more guidance and
explanation would help.

Since the IETF does not define any protocol usage of tags, there is little
impact caused by this draft, except for the additional administrative
overhead.


Kent // shepherd
>
>
>
Andy


> > On Nov 14, 2023, at 4:49 PM, Kent Watsen  wrote:
> >
> > Juergen, Tom, Andy,
> >
> > The previous WGLC for this draft didn’t succeed due to your comments.
> > Qin’s update (1) below removes all the (metric) specific node-tags.
> > All that is left now is the generic mechanism for tagging nodes.
> > Can you confirm that this update (-11) addresses your concerns?
> >
> > Thanks,
> > Kent
> >
> >
> >> On Oct 23, 2023, at 6:28 AM, Qin Wu  40huawei@dmarc.ietf.org> wrote:
> >>
> >> v-11 addresses comments during WGLC, the main changes include:
> >> 1. Remove all specific metrics from both terminology section and
> section 9.2 on IETF YANG Data Node Tags Registry based on WGLC discussion.
> >> 2. Align with Open Telemetry and Open Metrics open source
> implementation specification, introduce traces, log for data nodes
> classification.
> >> 3.Fix normative reference issues in section 9.2.
> >>
> >> -Qin
> >> -邮件原件-
> >> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> >> 发送时间: 2023年10月21日 17:56
> >> 收件人: i-d-annou...@ietf.org
> >> 抄送: netmod@ietf.org
> >> 主题: I-D Action: draft-ietf-netmod-node-tags-11.txt
> >>
> >> Internet-Draft draft-ietf-netmod-node-tags-11.txt is now available. It
> is a work item of the Network Modeling (NETMOD) WG of the IETF.
> >>
> >>  Title:   Node Tags in YANG Modules
> >>  Authors:  Qin Wu
> >>   Benoit Claise
> >>   Mohamed Boucadair
> >>   Peng Liu
> >>   Zongpeng Du
> >>  Name:draft-ietf-netmod-node-tags-11.txt
> >>  Pages:   30
> >>  Dates:   2023-10-21
> >>
> >> Abstract:
> >>
> >>  This document defines a method to tag nodes that are associated with
> >>  the operation and management data in YANG modules.  This method for
> >>  tagging YANG nodes is meant to be used for classifying either data
> >>  nodes or instances of data nodes from different YANG modules and
> >>  identifying their characteristic data.  Tags may be registered as
> >>  well as assigned during the definition of the module, assigned by
> >>  implementations, or dynamically defined and set by users.
> >>
> >>  This document also provides guidance to future YANG data model
> >>  writers; as such, this document updates RFC 8407.
> >>
> >> The IETF datatracker status page for this Internet-Draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/
> >>
> >> There is also an HTMLized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11
> >>
> >> A diff from the previous version is available at:
> >>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-node-tags-11
> >>
> >> Internet-Drafts are also available by rsync at:
> >> rsync.ietf.org::internet-drafts
> >>
> >>
> >> ___
> >> I-D-Announce mailing list
> >> i-d-annou...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>
> >> ___
> >> 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] Rfc8407 - what does this text mean?

[Andy Bierman]

On Mon, Feb 19, 2024 at 11:39 PM  wrote:

> Hi all,
>
>
>
> I updated the PR to use a wording aligned with 4.23:
>
>
>
> NEW:
>
>If the document contains a temporary non-NMDA (Network Management
>
>Datastore Architecture) [RFC8342], then the Introduction section
>
>should mention this fact with the reasoning that motivated that
>
>design.  Refer to Section 4.23 for more NMDA-related guidance.
>
>
>


Does this mean that the Transition to NMDA is completed, and it is now
considered a bad idea
to include a non-NMDA 'state' module?  Most deployments (90%?) are non-NMDA.
The motivation will always be to allow this 90% to retrieve the operational
values of specific configuration data.

Cheers,
>
> Med
>
>
>

Andy


> *De :* Andy Bierman 
> *Envoyé :* lundi 19 février 2024 19:58
> *À :* Kent Watsen 
> *Cc :* BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
>
>
>
>
> On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen  wrote:
>
> Hi Med,
>
>
>
> On Feb 19, 2024, at 3:29 AM, mohamed.boucad...@orange.com wrote:
>
>
>
> Hi Kent, all,
>
>
>
> I also think that highlighting the exceptions + motivate them makes sense
> here. A PR to fix that can be seen at [1].
>
>
>
> Thank you.
>
>
>
> I hope folks express objections now, before WGLC, as an expeditious
> resolution helps me close off an IESG review comment in NETCONF.
>
>
>
> Guidelines should be specific and clear.
>
> This inverse exception text seems better than the boilerplate text you
> want to replace.
>
>
>
> What exactly does it mean for a YANG module to be non-NMDA-compliant?
>
> Is the guideline forbidding config/state sibling containers, or just those
> that use a grouping or cut-and-paste
>
> to implement its non-NMDA-ness?
>
> Maybe NMDA experts can explain when this exception is needed and what it
> should say.
>
>
>
>
>
>
>
>
>
>
>
> FWIW, the OLD text was added draft-ietf-netmod-rfc6087bis-17 as per a
> comment in the AD review [2].
>
>
>
> That’s a great find!
>
>
>
>
>
> No wonder I didn't remember the WG discussing this during draft-8407.
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> K.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
>
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
>
>
>
> *De :* netmod  *De la part de* Kent Watsen
> *Envoyé :* vendredi 16 février 2024 21:55
> *À :* Andy Bierman 
> *Cc :* netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
>
>
> Hi Andy,
>
>
>
> Thanks for the speedy reply.
>
>
>
> This guidance seems inverted, at least within the IETF (where SHOULDs are
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407
> is read.  See the first paragraph of
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
>
>
> I doubt any module would get past the IETF-publication process now if it
> defined a non-NMDA compliant structure (i.e., CF nodes that provide the
> opstate value for CT nodes), unless it was a “temporary non-NMDA module” (
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).
>
>
>
> Since this, for awhile now, is the normal thing to do, the text
> highlighted in my OP seems to have little to no value.  That said, an
> “inverted” statement would have some value, that is, to explicitly
> highlight if the document defines any “temporary non-NMDA modules”.  This
> would be akin to highlighting when a document defines any IANA-maintained
> modules.
>
>
>
> I am proposing to update the text in rfc8407bis accordingly (to invert the
> guidance).  Thoughts?
>
>
>
> If there is agreement to update this text accordingly, I will delete the
> "Adherence to the NMDA” section in all my drafts, since none of them define
> a “temporary non-NMDA module”.
>
>
>
> PS: top-posting for simplicity
>
>
>
> K.
>
>
>
>
>
>
>
> On Feb 16, 2024, at 3:25 PM, Andy Bierman  wrote:
>
>
>
>
>
>
>
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  wrote:
>
> NETMOD,
>
>
>
> An IESG member reviewing one of my drafts flagged a section I had written
> to satisfy this text from
> https

Re: [netmod] Rfc8407 - what does this text mean?

[Andy Bierman]

On Mon, Feb 19, 2024 at 6:54 AM Kent Watsen  wrote:

> Hi Med,
>
> On Feb 19, 2024, at 3:29 AM, mohamed.boucad...@orange.com wrote:
>
> Hi Kent, all,
>
> I also think that highlighting the exceptions + motivate them makes sense
> here. A PR to fix that can be seen at [1].
>
>
> Thank you.
>
> I hope folks express objections now, before WGLC, as an expeditious
> resolution helps me close off an IESG review comment in NETCONF.
>

Guidelines should be specific and clear.
This inverse exception text seems better than the boilerplate text you want
to replace.

What exactly does it mean for a YANG module to be non-NMDA-compliant?
Is the guideline forbidding config/state sibling containers, or just those
that use a grouping or cut-and-paste
to implement its non-NMDA-ness?
Maybe NMDA experts can explain when this exception is needed and what it
should say.




>
> FWIW, the OLD text was added draft-ietf-netmod-rfc6087bis-17 as per a
> comment in the AD review [2].
>
>
> That’s a great find!
>
>
No wonder I didn't remember the WG discussing this during draft-8407.


> Cheers,
> Med
>
>
> K.
>
>

Andy


>
>
> [1]
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://boucadair.github.io/rfc8407bis/nmda-exceptions/draft-ietf-netmod-rfc8407bis.txt
>
> [2]
> https://mailarchive.ietf.org/arch/msg/netmod/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
> *De :* netmod  *De la part de* Kent Watsen
> *Envoyé :* vendredi 16 février 2024 21:55
> *À :* Andy Bierman 
> *Cc :* netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
> Hi Andy,
>
> Thanks for the speedy reply.
>
> This guidance seems inverted, at least within the IETF (where SHOULDs are
> interpreted as MUSTs), and likely outside the IETF also, assuming rfc8407
> is read.  See the first paragraph of
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
> I doubt any module would get past the IETF-publication process now if it
> defined a non-NMDA compliant structure (i.e., CF nodes that provide the
> opstate value for CT nodes), unless it was a “temporary non-NMDA module” (
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3.1).
>
> Since this, for awhile now, is the normal thing to do, the text
> highlighted in my OP seems to have little to no value.  That said, an
> “inverted” statement would have some value, that is, to explicitly
> highlight if the document defines any “temporary non-NMDA modules”.  This
> would be akin to highlighting when a document defines any IANA-maintained
> modules.
>
>
> I am proposing to update the text in rfc8407bis accordingly (to invert the
> guidance).  Thoughts?
>
>
> If there is agreement to update this text accordingly, I will delete the
> "Adherence to the NMDA” section in all my drafts, since none of them define
> a “temporary non-NMDA module”.
>
> PS: top-posting for simplicity
>
> K.
>
>
>
>
> On Feb 16, 2024, at 3:25 PM, Andy Bierman  wrote:
>
>
>
> On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  wrote:
>
> NETMOD,
>
> An IESG member reviewing one of my drafts flagged a section I had written
> to satisfy this text from
> https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
>
>If the document contains a YANG module(s) that is compliant with
> NMDA
>[RFC8342], then the Introduction section should mention this fact.
>
>Example:
>
>  The YANG data model in this document conforms to the Network
>  Management Datastore Architecture defined in  RFC 8342.
>
>
> What does "compliant with NMDA” actually mean?   Are not all modules
> “compliant”, even if they unnecessarily define some opstate nodes?
>
>
>
> I do not recall the discussions that led to that text.
>
>
> Does this sentence actually point to if the document publishes any so
> called “-state” modules, defined only to support legacy “non-NMDA” servers?
>
>
>
> I think the state modules are optional, so it is still unclear what NMDA
> conformance means for a YANG module.
>
>
>
> Does it make sense to clarify this text, since rfc8407bis is an open WG
> document at the moment?
>
>
> maybe it means to follow all the guidelines in 4.23.3
> https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3
>
> maybe remove this other text you cite.
>
>
>
>
> Thanks,
> Kent
>
>
>
> Andy
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> ___

Re: [netmod] Rfc8407 - what does this text mean?

[Andy Bierman]

On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen  wrote:

> NETMOD,
>
> An IESG member reviewing one of my drafts flagged a section I had written
> to satisfy this text from
> https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
>
>If the document contains a YANG module(s) that is compliant with
> NMDA
>[RFC8342], then the Introduction section should mention this fact.
>
>Example:
>
>  The YANG data model in this document conforms to the Network
>  Management Datastore Architecture defined in  RFC 8342.
>
>
> What does "compliant with NMDA” actually mean?   Are not all modules
> “compliant”, even if they unnecessarily define some opstate nodes?
>
>
I do not recall the discussions that led to that text.


> Does this sentence actually point to if the document publishes any so
> called “-state” modules, defined only to support legacy “non-NMDA” servers?
>
>
I think the state modules are optional, so it is still unclear what NMDA
conformance means for a YANG module.


Does it make sense to clarify this text, since rfc8407bis is an open WG
> document at the moment?
>

maybe it means to follow all the guidelines in 4.23.3
https://datatracker.ietf.org/doc/html/rfc8407#section-4.23.3

maybe remove this other text you cite.



> Thanks,
> Kent
>
>
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] Draft Minutes for Virtual Interim

[Andy Bierman]

On Tue, Jan 30, 2024 at 8:55 AM Jason Sterne (Nokia)  wrote:

> Hi WG,
>
> (and in particular to those who attended the interim).
>
>
>
> The summary below mostly matches my memory of the discussions, but I don’t
> really remember us concluding on this:
>
>
>
>  The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
>
>  clarification the  alone does not have to be valid.
>
>  E.g., clients may have to perform transforms to calculate
>
>  , which is subject to validation.
>
>
>


I do not have a problem with " SHOULD always be valid" (instead of
MUST).
IMO the lack of standards for the "magic" that converts  into
 should be fixed.
There was going to be metadata like an "enabled" flag on  data
nodes. This never happened.
Too bad, because this solution could support both NMDA and non-NMDA
deployments.

Andy


> (the rest of the minutes/summary below also seems to contradict that
> paragraph being a conclusion no?)
>
>
>
> I thought it was going to remain somewhat optional/indeterminate if
> running will be valid:
>
>- Servers may or may not enforce running to be valid (i.e. they may
>only validate intended as a proxy for validating running)
>- Clients can’t necessarily expect to be able to offline validate
>running, although it may work in circumstances where the operator doesn’t
>use templates or inactive config **or** the client reproduces the
>server logic for the running->intended transforms
>
>
>
> Jason
>
>
>
> *From:* netmod  *On Behalf Of *Kent Watsen
> *Sent:* Monday, January 29, 2024 7:21 PM
> *To:* netmod@ietf.org
> *Subject:* [netmod] Draft Minutes for Virtual Interim
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Link to minutes:
>
>
> https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/
>
>
>
> Reproduced below for convenience.
>
>
>
> Please report any updates needed here.
>
>
>
> Kent (and Lou)
>
>
>
>
>
>
>
> This virtual interim was soley focused on the "system-config" draft.
>
> Qiufang Ma presented.
>
>
>
> Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config
>
>
>
> In the course of two hours, there was a lot of discussion.  So much so
>
> that trying to capture all the points verbatim would take too long. A
>
> link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA.
>
>
>
> A high-level summary is:
>
>
>
>   Qiufang's presentation focused on two main questions?
>
>
>
>   1) The "origin" issue.
>
>
>
>  The WG agreed that  nodes copied into  should
>
>  have origin "intended".  The system-config draft will "update"
>
>  RFC 8342 (NMDA) to state this.
>
>
>
>  The WG agreed that data-migration is 1) not -specific
>
>  concern and 2) is out-of-scope for this draft.
>
>
>
>   2) Validity of  alone.
>
>
>
>  The WG agreed to let 7950-bis "update" 8342 (NMDA) with the
>
>  clarification the  alone does not have to be valid.
>
>  E.g., clients may have to perform transforms to calculate
>
>  , which is subject to validation.
>
>
>
>  The WG agreed on a new Option 4: this document doesn't say
>
>  anything at all about the validity of .  That is,
>
>  fully rely on existing 7950 and 8342 statements.
>
>
>
>  This leaves it up to interpretation.
>
>
>
>  Templates and inactive configuration are nice for humans, but
>
>  unnecessary for machine-to-machine interfaces.  That is, the
>
>  issues arounds such mechanisms are largely moot in environments
>
>  using a controller.
> ___
> 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] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)

[Andy Bierman]

Hi,

On Mon, Jan 22, 2024 at 8:42 AM Mahesh Jethanandani 
wrote:

> Hi Med,
>
> On Jan 21, 2024, at 11:44 PM, mohamed.boucad...@orange.com wrote:
>
> Hi Acee,
>
> > I think these points are worth addressing in RFC8407 BIS.
>
> We do already have the following in the bis, which I think covers your
> initial question about “mandatory true” data nodes for operational state”:
>
>Section 8.1 of [RFC7950] includes a provision for defining a
>constraint on state data and specifies that the constraint must be
>true in a valid state data.  However, Section 5.3 of [RFC8342]
>softens that behavior by allowing semantic constraints to be violated
>under some circumstances to help detecting anomalies.  Relaxing
>validation constraints on state data is meant to reveal deviations of
>the observed behavior vs. intended behavior of a managed entity and
>hopefully trigger corrective actions by a management system.  From
>that perspective, it is RECOMMENDED to avoid defining constraints on
>state data that would hinder the detection by a management system of
>abnormal behaviors of a managed entity.
>
>
> [mj] When I read this, it tells me that it is ok to put constraints on
> state data.
>
> What I am hearing on the mailing list, by Juergen and others, is
> questioning the use of constraints on state data. What I am interested in
> understanding is, would there be a problem in dropping/ignoring constraints
> on state data?
>
>
The text in question is in sec 8.1

https://datatracker.ietf.org/doc/html/rfc7950#section-8.1

What is a "valid state data tree"?
Any representation of  that is filtered in any way or
incomplete in any way
is not a valid state data tree, so this section does not apply.




   o  If the constraint is defined on state data, it MUST be true in a
  valid state data tree.




Andy

Thanks.
>
>
> No?
>
> Cheers,
> Med
>
> *De :* netmod  *De la part de* Acee Lindem
> *Envoyé :* vendredi 19 janvier 2024 18:47
> *À :* Andy Bierman 
> *Cc :* Jürgen Schönwälder ; YANG
> Doctors ; netmod@ietf.org;
> draft-ietf-netmod-rfc8407...@ietf.org
> *Objet :* Re: [netmod] [yang-doctors] Operational State usage of YANG
> choices and constraints (fix draft address)
>
> Hi Andy,
>
>
> On Jan 19, 2024, at 12:17, Andy Bierman  wrote:
>
>
>
> On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem  wrote:
>
> Along the same lines, what is the sentiment for “mandatory true” data
> nodes for operational state (i.e., “config false” nodes)? Does this make
> sense to identify data nodes the must be returned if the parent node is
> returned?
>
>
>
> What does "must be returned" mean?
>
> Obviously, it does not mean returning the data even if the filters do not
> select that node. (I hope)
> I used to think it meant conformance  (whether the server must implement
> or may implement).
> I was told years ago that is not the case. Use if-feature for that. No
> if-feature == mandatory-to-implement.
>
> If a client requests the parent subtree, then how would it know the
> difference between config=false
> nodes that are not present vs. the server just decided not to return them
> (even though conformance
> to the retrieval operation requires them)?
>
> IMO the mandatory-stmt for config=false nodes does not make any sense at
> all.
>
>
> I’m fine with that - we just need to make sure that this is reflected in
> our IETF models. I think these points are worth addressing in RFC8407 BIS.
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> Thanks
> Acee
>
>
> Andy
>
>
> > On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder <
> jschoenwaelder@constructor.university> wrote:
> >
> > On Fri, Dec 22, 2023 at 07:22:55PM +, Kent Watsen wrote:
> >> With limited experience wrt the impact on servers, as a client, it’s
> always best for the opstate data to be modeled as accurately as possible,
> for better processing and user experience.
> >>
> >
> > What is accurate?
> >
> > I think the answer is "it depends". There are states that a model
> > allows to represent and there are states it does not allow to
> > represent. If a device ends up in a state that the model can't
> > represent, then the device has a problem, From a debugging point of
> > view, the worst is a device in a state that can't be represented
> > propoerly reporting a valid state it is not in.
> >
> > So like everything else, it is a modeling decision, like picking types
> > and everything else. I am not sure that 'as accurate as possible" is a
> > helpful guideline; for operational state 

Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints

[Andy Bierman]

On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem  wrote:

> Along the same lines, what is the sentiment for “mandatory true” data
> nodes for operational state (i.e., “config false” nodes)? Does this make
> sense to identify data nodes the must be returned if the parent node is
> returned?
>
>

What does "must be returned" mean?

Obviously, it does not mean returning the data even if the filters do not
select that node. (I hope)
I used to think it meant conformance  (whether the server must implement or
may implement).
I was told years ago that is not the case. Use if-feature for that. No
if-feature == mandatory-to-implement.

If a client requests the parent subtree, then how would it know the
difference between config=false
nodes that are not present vs. the server just decided not to return them
(even though conformance
to the retrieval operation requires them)?

IMO the mandatory-stmt for config=false nodes does not make any sense at
all.



> Thanks
> Acee
>
>
Andy


> > On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder
>  wrote:
> >
> > On Fri, Dec 22, 2023 at 07:22:55PM +, Kent Watsen wrote:
> >> With limited experience wrt the impact on servers, as a client, it’s
> always best for the opstate data to be modeled as accurately as possible,
> for better processing and user experience.
> >>
> >
> > What is accurate?
> >
> > I think the answer is "it depends". There are states that a model
> > allows to represent and there are states it does not allow to
> > represent. If a device ends up in a state that the model can't
> > represent, then the device has a problem, From a debugging point of
> > view, the worst is a device in a state that can't be represented
> > propoerly reporting a valid state it is not in.
> >
> > So like everything else, it is a modeling decision, like picking types
> > and everything else. I am not sure that 'as accurate as possible" is a
> > helpful guideline; for operational state I prefer to see as much as
> > possible the device's true state. (But even picking data types for
> > leaves restricts what can be represented, so it is a judgement call.)
> >
> > /js
> >
> > --
> > Jürgen Schönwälder  Constructor University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
>
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Is changing the type with union a BC change?

[Andy Bierman]

On Fri, Jan 19, 2024 at 8:00 AM Jason Sterne (Nokia) 
wrote:

> A previous post about one of these cases is here:
>
> https://mailarchive.ietf.org/arch/msg/netmod/yQSrlqFnrMEibLwuzMkyWt63kXQ/
>
>
>
> *From:* netmod  *On Behalf Of *Jason Sterne
> (Nokia)
> *Sent:* Friday, January 19, 2024 9:16 AM
> *To:* Andy Bierman 
> *Cc:* netmod@ietf.org; Italo Busi 
> *Subject:* Re: [netmod] Is changing the type with union a BC change?
>
>
>
> You don't often get email from jason.sterne=40nokia@dmarc.ietf.org. Learn
> why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> Hi Andy,
>
>
>
> What you’re describing here is types of changes that could be less
> impactful in many cases than other types of changes. And I agree that many
> of the examples you show are likely low impact for clients, but most of
> them are still officially NBC by RFC7950 rules IMO.  Please see inline.
>
>
>


I am interested in the operational impact of NBC changes on NC/RC
deployments, not
the boolean result: "Is this change BC or NBC according to RFC 7950?"

If the YANG authors determine the "old way" is wrong and needs to be
replaced, then what is the best
way to do that?  Can the "old way" and "new way" co-exist, and at what
level of granularity?

The "old client <--> new server" problem has been around forever.
It's easy to clobber the model in a new revision such that "old client"
stops working.
This prevents a software upgrade on the devices that need the old client to
keep working.

The WG seems focused on the boolean BC vs. NBC issue, not the operational
issues.


Jason
>


Andy


>
>
> *From:* Andy Bierman 
> *Sent:* Thursday, January 18, 2024 4:43 PM
> *To:* Jason Sterne (Nokia) 
> *Cc:* Italo Busi ; Reshad Rahman ;
> Jan Lindblad ; netmod@ietf.org
> *Subject:* Re: [netmod] Is changing the type with union a BC change?
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi,
>
>
>
> On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia)  40nokia@dmarc.ietf.org> wrote:
>
> Hi Italo,
>
>
>
> IMO RFC7950 Section 11 makes the second case NBC (and I remember it being
> confirmed on this list in the past). It may not turn out to be impactful
> depending on the client design (and if only XML is used) but officially it
> is NBC. The type of the leaf is changing from whatever foo is, to type
> ‘union’.   (even changes from uint8 to uint16 are NBC).
>
>
>
>
>
>
>
> I think RFC 7950 addresses only XML encoding of YANG data.
>
> CBOR encoding of a union would cause an NBC change only for protocols
> using CBOR.
>
>
>
> I prefer to focus on the backward compatibility at run-time.
>
> There are "soft" NBC changes that may break compile-time definitions but
> probably not run-time,
>
> especially if old-client and new-client are not both changing the same
> configuration data structures.
>
>
>
>
> The following change is not legal:*[>>JTS:] Agree*
>
>
>
> V1:
>
>
>
>
>
>  container oldway {}
>
>
>
>
>
> V2:
>
>
>
>  choice wrapper {
>
> container oldway {}
>
>   }
>
>
>
>
>
> The following changes are legal:*[>>JTS:] Agree (although there will be
> subtleties in how oldway behaves once you add newway – if it magically
> changes values when someone writes to “newway” then it may not really be
> NBC)*
>
>
>
> V1:
>
>
>
>  choice wrapper {
>
>  container oldway {}
>
>   }
>
>
>
> V2:
>
>
>
>  choice wrapper {
>
> container oldway {}
>
> container newway {}
>
>  }
>
>
>
> This allows old clients and new clients to coexist (better than just
> removing 'oldway').
>
> But adding the choice wrapper changes the schema node path that may be
> used in augments or deviations.
>
> Creating the choice from the start would clutter YANG modules and add
> complexity.
>
> IMO this compile-time NBC change is worth it if enough deployment of
> 'oldway' exists.
>
>
>
> The same applies for a simple type changing to a union type.
>
> It is not always transparent.  In C the order of the member types is
> irrelevant, but not in YANG.
>
>
>
> Safe (except for CBOR):*[>>JTS:] It may often be low impact, but this is
> not allowed according to RFC7950.*
>
>
>
> V1:
>
>
>
> leaf foo { t

Re: [netmod] Is changing the type with union a BC change?

[Andy Bierman]

Hi,

On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia)  wrote:

> Hi Italo,
>
>
>
> IMO RFC7950 Section 11 makes the second case NBC (and I remember it being
> confirmed on this list in the past). It may not turn out to be impactful
> depending on the client design (and if only XML is used) but officially it
> is NBC. The type of the leaf is changing from whatever foo is, to type
> ‘union’.   (even changes from uint8 to uint16 are NBC).
>
>
>


I think RFC 7950 addresses only XML encoding of YANG data.
CBOR encoding of a union would cause an NBC change only for protocols using
CBOR.

I prefer to focus on the backward compatibility at run-time.
There are "soft" NBC changes that may break compile-time definitions but
probably not run-time,
especially if old-client and new-client are not both changing the same
configuration data structures.


The following change is not legal:

V1:


 container oldway {}


V2:

 choice wrapper {
container oldway {}
  }


The following changes are legal:

V1:

 choice wrapper {
 container oldway {}
  }

V2:

 choice wrapper {
container oldway {}
container newway {}
 }

This allows old clients and new clients to coexist (better than just
removing 'oldway').
But adding the choice wrapper changes the schema node path that may be used
in augments or deviations.
Creating the choice from the start would clutter YANG modules and add
complexity.
IMO this compile-time NBC change is worth it if enough deployment of
'oldway' exists.

The same applies for a simple type changing to a union type.
It is not always transparent.  In C the order of the member types is
irrelevant, but not in YANG.

Safe (except for CBOR):

V1:

leaf foo { type int8; }

V2:

   leaf foo {
  type union {
   type int8;
   type declimal64;
   type string;
   }
   }

Not safe since no member types after 'string' would ever match:

V1:

leaf foo { type string; }

V2:

   leaf foo {
  type union {
   type string;
   type declimal64;
   type binary;
   }
   }

IMO it should be OK to to place the original type anywhere in the member
types.
It may not be completely transparent within the implementation or the
message encoding.


V1:

leaf foo { type string; }

new V2:

   leaf foo {
  type union {
   type declimal64;
   type binary;
   type string;
   }
   }

If old-client reads new values set by new-client then it may cause a
problem,
but probably not if it only reads values set by old-client.


Some of those sections of 7950 are really focussed on XML encoding. But
> YANG is intended to work with other encodings (and some of those may not
> encode foo in and out of a union in the same way).
>
>
>

They only apply to XML.
Any extrapolation or new rules are post-7950.



> Jason
>

Andy


>
>
>
>
> *From:* Italo Busi 
> *Sent:* Thursday, January 18, 2024 3:19 PM
> *To:* Jason Sterne (Nokia) ; Reshad Rahman <
> res...@yahoo.com>; Jan Lindblad 
> *Cc:* netmod@ietf.org
> *Subject:* RE: [netmod] Is changing the type with union a BC change?
>
>
>
> Hi Reshad, Jason, Jan,
>
>
>
> Thanks for your replies
>
>
>
> I have found these pieces of text in sections 9.12 and 11 which might be
> interpreted as stating that the changes to the union are BC:
>
>
>
>When generating an XML encoding, a value is encoded according to the
>
>rules of the member type to which the value belongs.  When
>
>interpreting an XML encoding, a value is validated consecutively
>
>against each member type, in the order they are specified in the
>
>"type" statement, until a match is found.  The type that matched will
>
>be the type of the value for the node that was validated, and the
>
>encoding is interpreted according to the rules for that type.
>
>
>
> <…>
>
>
>
>The lexical representation of a union is a value that corresponds to
>
>the representation of any one of the member types.
>
>
>
> <…>
>
>
>
>The canonical form of a union value is the same as the canonical form
>
>of the member type of the value.
>
>
>
> <…>
>
>
>
>o  A "type" statement may be replaced with another "type" statement
>
>   that does not change the syntax or semantics of the type.  For
>
>   example, an inline type definition may be replaced with a typedef,
>
>   but an int8 type cannot be replaced by an int16, since the syntax
>
>   would change.
>
>
>
> Given these definitions I am wondering whether having a different encoding
> between the union and its member types is a valid encoding according to
> RFC7950
>
>
>
> If this is the case, my feeling is that both examples can be considered BC
> changes at least when the base types are the same (e.g., type foo, bar and
> baz are all strings)
>
>
>
> Italo
>
>
>
> *From:* Jason Sterne (Nokia) 
> *Sent:* giovedì 18 gennaio 2024 19:33
> *To:* Reshad Rahman ; Jan Lindblad ;
> Italo Busi 
> *Cc:* netmod@iet

Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

[Andy Bierman]

On Wed, Nov 15, 2023 at 11:37 PM Jürgen Schönwälder
 wrote:

> If compilers can pick different revisions and this results in
> different interpretations of YANG definitions then thigns are
> broken.
>
>
Yes and no.
This has been the situation from the very start.
Implementation-dependent module search procedures determine the modules
that will be used.
This sort of works (from a very server-centric POV).

The YANG conformance model is fundamentally broken, and the "NBC work"
breaks it even more.
Conformance and capabilities are two sides of the same coin.
  - Conformance is the "standard contract" embodied in the YANG modules.
  - Capabilities are the "server contract" embodied in the server YANG
library.

SMIv2 has an explicit conformance model.
The way source modules are combined into a conceptual model is limited, so
this
static approach can work. The standard contract is static.

YANG has an implicit conformance model. It is not static at all.
A conceptual model only exists by combining and expanding an arbitrary set
of source modules.
It is impossible to construct a "standard conceptual model".
It is impossible to construct a standard schema tree if
the imported groupings can change
or NBC changes can happen in new releases. (Something that impacts SID
files)

Over time, the number of modules with typedefs and groupings keeps growing
and changing.
The number of variants that a manager can encounter keeps growing.
This is not a big problem if there are no NBC changes in the server YANG
modules.

YANG Packages should provide a solution for the missing standard conceptual
model.
This recommended-min extension can help a little in the meantime.

/js
>
>
Andy


> On Wed, Nov 15, 2023 at 10:30:49PM +, Jason Sterne (Nokia) wrote:
> > Hi all,
> >
> > A poll at IETF118 was roughly split on recommended-min.
> >
> > We discussed this in the weekly YANG versioning call and feel we should:
> > 1) keep recommended-min-date in the Module Versioning draft
> > 2) add recommended-min-label (or similar name) in the YANG Semver draft.
> > They would be mutually exclusive inside a single import statement.
> >
> > As defined in Module Versioning, the recommended-min is informational
> only. Compilers/tools are not required to use the recommended-min as a
> constraint.
> >
> > We don't believe this causes any new incompatibility issues wrt RFC7950.
> >
> > RFC7950 section 5.1.1 says the following:
> >
> >If a module is not imported with a specific revision, it is undefined
> which revision is used.
> >
> > So clients, servers and tools can pick whatever revision they want. Two
> different tools may pick different revisions.
> >
> > In section 5.6.5 RFC7950 says the following:
> >
> >If a server lists a module C in the "/modules-state/module" list from
> >"ietf-yang-library" and there are other modules Ms listed that import
> >C without specifying the revision date of module C, the server MUST
> >use the definitions from the most recent revision of C listed for
> >modules Ms.
> >
> > Recommended-min does not affect conformance and is not mandatory. So a
> server, toolchain, etc can continue to select the "most recent revision"
> even if that revision is older than the recommended-min.
> >
> > Jason
> >
> >
> > > -Original Message-
> > > From: Jürgen Schönwälder 
> > > Sent: Thursday, October 26, 2023 4:23 AM
> > > To: Andy Bierman 
> > > Cc: Joe Clarke (jclarke) ; Jason
> Sterne
> > > (Nokia) ; netmod@ietf.org
> > > Subject: Re: [netmod] Updated Content of Module Versioning - T8
> > > (recommended-min for imports)
> > >
> > >
> > > CAUTION: This is an external email. Please be very careful when
> clicking links or
> > > opening attachments. See the URL nok.it/ext for additional
> information.
> > >
> > >
> > >
> > > Well, yes, import-by-revision is broken. However, changing the way how
> > > imports work changes the YANG language. So it is important to know
> > > which version of the YANG language tools implement. For this we have
> > > language version numbers.
> > >
> > > /js
> > >
> > > On Wed, Oct 25, 2023 at 02:44:26PM -0700, Andy Bierman wrote:
> > > > On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke)  > > > 40cisco@dmarc.ietf.org> wrote:
> > > >
> > > > > This is the reason that, for me, I’d want the extension to be
> outside the
> > > > > description in something that is machine

Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)

[Andy Bierman]

On Wed, Nov 15, 2023 at 1:35 PM Jason Sterne (Nokia) 
wrote:

> Hi all,
>
>
>
> We discussed this in the weekly YANG versioning call. There have been
> concerns expressed on the list about weakening the format specified as a
> SHOULD in RFC7950 and about the time it may take for the ecosystem of tools
> to be updated. There is not any clear consensus that we should keep the new
> label-based filename recommendation.
>
>
>
> So we’re proposing to remove this new filename convention from the Module
> Versioning draft. That means there would be no particular standardized way
> of putting a label (yang semver label) in the module filename. We’d stick
> with the RFC7950 my-mod...@2023-10-14.yang format for now (or of course
> the format without any label or date: my-module.yang).
>
>
>


thank you.
The recent simplifications in this work make it better (IMO).
Look forward to implementing the RFC.


> If anyone feels that you can’t live without the new filename format
> specified (e.g. my-mod...@3.0.1.yang) now is the time to speak up.
> Otherwise we’ll remove it from the next iteration of Module Versioning.
>
>
>
> Jason
>
>
Andy


>
>
> *From:* Andy Bierman 
> *Sent:* Wednesday, October 25, 2023 4:28 PM
> *To:* Jürgen Schönwälder ; Jason
> Sterne (Nokia) ; netmod@ietf.org
> *Subject:* Re: [netmod] Updated Content of Module Versioning - T7
> (Filename changes)
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Wed, Oct 25, 2023 at 11:49 AM Jürgen Schönwälder <
> jschoenwaelder@constructor.university> wrote:
>
> I strongly disagree. You can add additional file names, you can't
> soften the existing SHOULD to a conditional SHOULD.
>
>
>
> +1
>
>
>
> Getting tools to handle the file naming patterns defined in RFC 7950 took
> a long time.
>
> It would be disruptive to introduce yet another file-naming pattern.
>
> It would also be another NBC change forced on YANG 1.1 tools.
>
>
>
>
>
> /js
>
>
>
> Andy
>
>
>
> On Wed, Oct 25, 2023 at 06:45:31PM +, Jason Sterne (Nokia) wrote:
> > Sure - I'd be OK with adding some wording here that makes it clear the
> 7950 recommendation remains.
> >
> > i.e. you SHOULD use my-module@2023-01-06 as per 7950, but if you elect
> to not use that format, and want to use a label in the filename, then this
> format is RECOMMENDED:  my-module#3.0.2.yang.
> >
> > I can see that 'primary identifier' isn't great. Maybe something more
> like "to uniquely identify the version of the module" or similar.
> >
> > Jason
> >
> > > -Original Message-
> > > From: Jürgen Schönwälder 
> > > Sent: Wednesday, October 25, 2023 2:32 PM
> > > To: Jason Sterne (Nokia) 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Updated Content of Module Versioning - T7
> > > (Filename changes)
> > >
> > >
> > > CAUTION: This is an external email. Please be very careful when
> clicking
> > > links or opening attachments. See the URL nok.it/ext for additional
> > > information.
> > >
> > >
> > >
> > > It needs to be clear that the existing text in section 5.2 remains
> > > untouched.
> > >
> > >YANG modules and submodules are typically stored in files, one
> > >"module" or "submodule" statement per file.  The name of the file
> > >SHOULD be of the form:
> > >
> > >  module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
> > >
> > >"module-or-submodule-name" is the name of the module or submodule,
> > >and the optional "revision-date" is the latest revision of the
> module
> > >or submodule, as defined by the "revision" statement (Section
> 7.1.9).
> > >
> > > Words like 'primary identifier' confuse me.
> > >
> > > /js
> > >
> > > On Wed, Oct 25, 2023 at 06:22:57PM +, Jason Sterne (Nokia) wrote:
> > > > Hi all,
> > > >
> > > > Starting a dedicated thread for T7 Filename changes.
> > > >
> > > > These are my own personal opinions (not those of the
> > > authors/contributors).
> > > >
> > > > RFC7950 says that the filename format SHOULD be my-module@2023-01-
> > > 06.yang<mailto:my-mo

Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

[Andy Bierman]

On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke)  wrote:

> This is the reason that, for me, I’d want the extension to be outside the
> description in something that is machine-readable.  Tools that do
> understand this extension could make a better decision about which module
> revision to use.
>
>
>

+1

The YANG author should know if their module depends on imported definitions
from a specific revision.
IMO the min-revision is needed in this case, and SHOULD be present.
There is a big difference between "module will compile" and "module will
work as intended".

Tools that do not understand the extension will resolve the import as they
> normally would, which may lead to a failure at compile time (e.g., for a
> missing node).
>

This extension MUST be ignored if the 'revision-date' statement is present
in the import-stmt.


>
> Joe
>

Andy


>
>
> *From: *netmod  on behalf of Jürgen Schönwälder
> 
> *Date: *Wednesday, October 25, 2023 at 14:45
> *To: *Jason Sterne (Nokia) 
> *Cc: *netmod@ietf.org 
> *Subject: *Re: [netmod] Updated Content of Module Versioning - T8
> (recommended-min for imports)
>
> I am strongly against this. The import statement is used by tools.
> Adding a recommendation for humans that existing and conforming tools
> will not understand just causes confusion.
>
> /js
>
> On Wed, Oct 25, 2023 at 06:41:19PM +, Jason Sterne (Nokia) wrote:
> > Hi all,
> >
> > Starting a dedicated thread for T8 recommended-min for imports
> >
> > These are my own personal opinions (not those of the
> authors/contributors).
> >
> > It has been discussed before that import by a specific revision is
> somewhat broken (not recommended). It is mentioned in section 2.5 of the
> versioning requirements draft:
> https://www.ietf.org/archive/id/draft-ietf-netmod-yang-versioning-reqs-08.html#name-no-good-way-to-specify-whic
> >
> > Based on previous WG LC discussions, we already changed from a
> revision-or-derived extension (that did affect conformance & what a tool
> could/should use), to a weaker recommended-min in order to avoid further
> changes to the YANG language & conformance rules.  The recommended-min is
> pretty much purely a documentation tag that helps users of the modules
> understand what versions of imports might be best to use (e.g. when
> supporting multiple modules in a server, or constructing a "package" of
> modules that work together).
> >
> > We could instead just say to put this information into a description
> field in the module. But it is helpful if the field is broken out (i.e.
> structured data) and more easily machine readable.
> >
> > So I'd like to see this stay as part of Module Versioning but be renamed
> to recommended-min-date.  Then in YANG Semver we should add
> recommended-min-semver-label.
> >
> > Jason
> >
> >
> > From: netmod  On Behalf Of Jason Sterne (Nokia)
> > Sent: Tuesday, October 24, 2023 9:58 AM
> > To: netmod@ietf.org
> > Subject: [netmod] Updated Content of Module Versioning
> >
> > Hello NETMOD WG,
> >
> > The YANG versioning authors and weekly call group members have been
> discussing the next steps for the versioning drafts.
> >
> > We'd propose that the first step is to converge on what aspects of the
> current Module Versioning draft should be retained, and which parts should
> be removed. We can then work towards a final call on an updated version
> with this revised scope.
> >
> > Below is a summary of the main topics in the Module Versioning draft.
> We've divided the items T1-T10 into 2 groups:
> > A) Baseline content of Module Versioning
> > B) Items which need more WG discussion
> >
> > In addition to whatever discussions happen on this email list, we have
> also created a hedgedoc where you can register your preference for items
> T7-T10. It would be much appreciated if you can put your opinion in the
> hedgedoc here:
> > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both
> >
> >
> > GROUP A (Baseline content of Module Vesioning)
> > -
> > Based on resolution of WG LC comments and subsequent discussions, and
> some feedback to reduce complexity and content in the Module Versioning
> draft, here is a summary of items that will and won't be part of the next
> update of the Module Versioning draft (also referred to as "this draft"
> below).
> >
> > T1. The "ver:non-backwards-compatible" annotation (Sec 3.2):
> > Retained. This top level (module level) extension (which can be ignored
> by tools that don't understand it) is critical to include so that module
> readers and tools can know when NBC changes have occurred.
> >
> > T2. Updated rules of what is NBC: (Sect 3.1.1, 3.1.2)
> > Retained. These are updates/clarifications (i.e., changes) to the RFC
> 7950 rules that are appropriate and helpful:
> > (i) "status obsolete"
> >   - This draft changes RFC 7950 so that marking a data node as obsolete
> is an NBC change because it can break clients.
> > (ii) "extensions"
> >   - This draf

Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)

[Andy Bierman]

On Wed, Oct 25, 2023 at 11:49 AM Jürgen Schönwälder
 wrote:

> I strongly disagree. You can add additional file names, you can't
> soften the existing SHOULD to a conditional SHOULD.
>
>
+1

Getting tools to handle the file naming patterns defined in RFC 7950 took a
long time.
It would be disruptive to introduce yet another file-naming pattern.
It would also be another NBC change forced on YANG 1.1 tools.



> /js
>
>
Andy


> On Wed, Oct 25, 2023 at 06:45:31PM +, Jason Sterne (Nokia) wrote:
> > Sure - I'd be OK with adding some wording here that makes it clear the
> 7950 recommendation remains.
> >
> > i.e. you SHOULD use my-module@2023-01-06 as per 7950, but if you elect
> to not use that format, and want to use a label in the filename, then this
> format is RECOMMENDED:  my-module#3.0.2.yang.
> >
> > I can see that 'primary identifier' isn't great. Maybe something more
> like "to uniquely identify the version of the module" or similar.
> >
> > Jason
> >
> > > -Original Message-
> > > From: Jürgen Schönwälder 
> > > Sent: Wednesday, October 25, 2023 2:32 PM
> > > To: Jason Sterne (Nokia) 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Updated Content of Module Versioning - T7
> > > (Filename changes)
> > >
> > >
> > > CAUTION: This is an external email. Please be very careful when
> clicking
> > > links or opening attachments. See the URL nok.it/ext for additional
> > > information.
> > >
> > >
> > >
> > > It needs to be clear that the existing text in section 5.2 remains
> > > untouched.
> > >
> > >YANG modules and submodules are typically stored in files, one
> > >"module" or "submodule" statement per file.  The name of the file
> > >SHOULD be of the form:
> > >
> > >  module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
> > >
> > >"module-or-submodule-name" is the name of the module or submodule,
> > >and the optional "revision-date" is the latest revision of the
> module
> > >or submodule, as defined by the "revision" statement (Section
> 7.1.9).
> > >
> > > Words like 'primary identifier' confuse me.
> > >
> > > /js
> > >
> > > On Wed, Oct 25, 2023 at 06:22:57PM +, Jason Sterne (Nokia) wrote:
> > > > Hi all,
> > > >
> > > > Starting a dedicated thread for T7 Filename changes.
> > > >
> > > > These are my own personal opinions (not those of the
> > > authors/contributors).
> > > >
> > > > RFC7950 says that the filename format SHOULD be my-module@2023-01-
> > > 06.yang
> > > >
> > > > Module versioning currently says the following format is RECOMMENDED
> > > (if the file has a revision label):  my-module#3.1.2.yang
> > > >
> > > > I'd recommend we remove that from Module Versioning, but add it to
> the
> > > YANG Semver draft (where all revision label text will be located - it
> is all
> > > being removed from Module Versioning).
> > > >
> > > > We could potentially say it more like this:
> > > >
> > > >   If a revision has an associated yang-semver-label, and if the
> publisher
> > > >  wishes to use the label in the filename as the primary identifier
> for the
> > > >  version of the module instead of the revision date, then it is
> > > >   RECOMMENDED to put the yang-semver-label into the filename as
> > > follows:
> > > >
> > > >  module-or-submodule-name ['#' yang-semver-label] ( '.yang' /
> '.yin' )
> > > >
> > > >E.g., acme-router-module#2.0.3.yang
> > > >
> > > >   YANG module (or submodule) files may be identified using either the
> > > >   revision-date (as per [RFC8407] section 3.2) or the revision label.
> > > >
> > > > If we don't at least have a recommendation (*if* people really want
> to put
> > > the label in the filename), then we might have different organizations
> using
> > > different formats:
> > > >
> > > >   *   org #1:   my-mod...@2.0.3.yang
> > > >   *   org#2:my-module#2@2023-01-06.yang > > module#2@2023-01-06.yang>
> > > >   *   org#3:my-module%2.0.3.yang
> > > >   *   org#4:my-module(2.0.3).yang
> > > >
> > > > I'm trying to find wording that doesn't strongly mandate the my-
> > > module#2.0.3.yang filename format, but does highly recommend it *if*
> > > someone is going to put a label in the filename somewhere.
> > > >
> > > > Jason
> > > >
> > > >
> > > > From: netmod  On Behalf Of Jason Sterne
> > > (Nokia)
> > > > Sent: Tuesday, October 24, 2023 9:58 AM
> > > > To: netmod@ietf.org
> > > > Subject: [netmod] Updated Content of Module Versioning
> > > >
> > > > Hello NETMOD WG,
> > > >
> > > > The YANG versioning authors and weekly call group members have been
> > > discussing the next steps for the versioning drafts.
> > > >
> > > > We'd propose that the first step is to converge on what aspects of
> the
> > > current Module Versioning draft should be retained, and which parts
> should
> > > be removed. We can then work towards a final call on an updated version
> > > with this revised scope.
> > > >

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Thu, Sep 14, 2023 at 11:46 AM Jürgen Schönwälder
 wrote:

> If the poll does not say what you want it to say, then the poll is
> broken.
>
> Right now, I see the following solution proposals floating around:
>
> 1) We change a single sentence in RFC 7950 and put an end to a
>multi-year effort that causes the AD to block other work from
>moving forward.
>

OK.
It would be useful to identify the specific text in RFC 7950
that is causing all these problems for the IETF.

 IMO, nobody is objecting to the MUST or MUST NOT text in sec 11, para 2,
3, 4, and 7.

There is only 1 paragraph in the entire RFC that needs to change (sec 11,
para 6)

OLD:

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.


NEW:

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this SHOULD be achieved by a
   new definition with a new identifier.

My preferred solution path:

 1) Issue Errata for RFC 7950 and Hold for Update or Verify.
 Either way, allow IETF modules to use the NEW text
 2) Remove updates to RFC 7950 from the versioning draft
 3) fix the other issues raised with the versioning draft and publish it

Andy



> 2) We make changes to YANG but we pretend that they are not real
>changes to YANG and we leave it to developers and operators to
>figure out differences in implementation behaviour one can create.
>
> 3) We make some minimal changes to YANG and we create clarity which
>rules apply and what what implementations support by giving the
>result a new version number.
>
> Are there others? Lets talk about solutions and their properties, lets
> stop standing on our heads. Guess what my acceptable and non-acceptable
> solutions are.
>
> /js
>
> On Thu, Sep 14, 2023 at 03:42:43PM +, Jason Sterne (Nokia) wrote:
> > I think it has been mentioned, but maybe worth repeating: this poll is
> *NOT* about accepting the entire Module Versioning + YANG Semver content as
> it currently stands.
> >
> > We separated out the first of several key issues to try and make
> progress. This is just the basic fundamental decision of whether we will
> allow (as a "SHOULD NOT") NBC changes in in YANG 1.0/YANG1.1  (option 1),
> or we are going to mandate that can only happen in a YANG 1.2 (option 2).
> >
> > After this poll settles out (hoping we'll get rough concensus), then
> we'll get back to chipping away at the other key issues (e.g. see email
> "YANG Versioning: Key Issues #2 and #3 - revision labels" from back in
> July, but there will be several other such debates & discussions).
> >
> > Jason
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Jürgen Schönwälder
> > > Sent: Thursday, September 14, 2023 5:35 AM
> > > To: Rob Wilton (rwilton) 
> > > Cc: Jan Lindblad (jlindbla) ; netmod@ietf.org
> > > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> > >
> > >
> > > CAUTION: This is an external email. Please be very careful when
> clicking links or
> > > opening attachments. See the URL nok.it/ext for additional
> information.
> > >
> > >
> > >
> > > On Tue, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote:
> > > >
> > > > I think that for this first poll this is the question that we should
> initially focus on.
> > > I.e., at a starting point, do you agree to updating RFC 6020, RFC
> 7950, to allow
> > > changing the MUST to a SHOULD without a new YANG 1.2?
> > > >
> > >
> > > There are many options, one is to just change a single sentence. But
> > > the poll fails to sort the options out.
> > >
> > > > If we can get consensus on this part, then I think that we can try
> and tackle
> > > getting consensus on the other updates in
> draft-ietf-netmod-yang-module-
> > > versioning to decide whether to include those in a document that
> updates existing
> > > versions of YANG without a change in the YANG versioning number, or
> whether
> > > those changes should be deferred to a new version of YANG (which I
> hope that
> > > the WG starts after this versioning work completes - but I'll no
> longer be an AD at
> > > that stage).
> > >
> > > This work is going on for years, the WG has failed so far to enumerate
> > > the options and come to a conclusion.
> > >
> > > > > There are features in draft-ietf-netmod-yang-module-versioning that
> > > > > you can use only with new tools that implement the features. I am
> not
> > > > > sure why tools that support different variants of YANG 1 and YANG
> 1.1
> > > > > are any easier in practice than a tool that says clearly what it
> > > > > implements.
> > > > [Rob Wilton (rwilton)]
> > > >
> > > > I hear two concerns:
> > > > (1) Existing tooling handling YANG 1 and YANG 1.1 modules must
> handle NB

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Thu, Sep 14, 2023 at 10:09 AM Acee Lindem  wrote:

>
>
> On Sep 14, 2023, at 12:40, Andy Bierman  wrote:
>
>
>
> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem  wrote:
>
>>
>>
>> > On Sep 13, 2023, at 10:36, Ladislav Lhotka > 40nic...@dmarc.ietf.org> wrote:
>> >
>> >
>> >
>> > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
>> >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
>> >>> Jernej,
>> >>>
>> >>> Hat off for the tools (and tool vendors!) that assist authors to stay
>> true to YANG RFC sections 10 and 11 also. Well done. :-)
>> >>>
>> >>> I intentionally used "compiler" rather than "toolchain", "IDE" or
>> something more open ended, because a compiler is what I have and can speak
>> for.
>> >>>
>> >>> Even so, I have a hard time thinking the customers of even the best
>> YANG IDEs would be interested to pay the effort for distinguishing between
>> YANG 1.1 and YANG 1.2 solely on the proposed RFC wording difference. Since
>> a BC verification capability apparently already exists in some IDEs, I
>> think it would make sense for their vendors to turn the checks it into a
>> warnings (if they aren't already), regardless of which yang-version
>> statement is found in the module header.
>> >>>
>> >>> This might mean a non-zero implementation effort for a few YANG
>> toolchain implementors. While this is a good point, it does not really sway
>> my opinion about what the pragmatic choice for IETF is. Or Jernej, do you
>> think the users of those good IDEs would prefer a new YANG version? If so,
>> why?
>> >> If you are asking whether I'd like to see a new version of YANG for
>> the sole purpose of changing those MUST and MUST NOTs - no, I would not.
>> However, a change like this mandates a yang-version bump, IMHO.
>> >
>> > Right, so we have two ugly options, but bumping YANG version really
>> makes no sense, so breaking those few tools that check update rules looks
>> like a better choice to me.
>> >
>> > We have already seen cases that the update rules prevented fixing
>> problems in YANG modules in a straightforward way, and backward-compatible
>> fixes negatively affected module readability. This is inevitable until the
>> ecosystem of YANG modules stabilizes. That's why I think changing update
>> rules from MUST to SHOULD is appropriate - it should have been so from the
>> beginning.
>>
>> I wholeheartedly agree. We need to be able to fix YANG modules with NBC
>> changes. I know of at least one implementation that support NBC changes for
>> proprietary models with node-specific translation
>>
>>
> Some of us do not think a bugfix counts as an NBC change.
> If the YANG definition is wrong and has been wrong from the start, then BC
> is not important.
> Fixing the YANG module so the definitions match the intent of the authors
> is important.
>
> IMO this new draft is not really needed at all, since bugfix exceptions
> should be allowed
> and should have always been allowed.
>
>
> What about models that are not functionally broken but need to be fixed
> for other reasons? For example, to adhere to IETF inclusive language?
>
> Would you still require a years long publication process for deprecation
> followed by another years long cycle to remove the deprecated nodes? For
> example:
>
> https://datatracker.ietf.org/doc/draft-acee-rtgwg-vrrp-rfc8347bis/
>
>
Years long process is not written anywhere in RFC 7950.  ;-)

I am OK with treating NBC changes as SHOULD NOT.

  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.


I don't care about the details of each YANG object.
That is for reviewers to decide.



Thanks,
> Acee
>

Andy


>
>
>
>
> Thanks,
>> Acee
>>
>>
> Andy
>
>
>>
>>
>>
>> >
>> > Lada
>> >
>> >> Jernej
>> >>>
>> >>> Best Regards,
>> >>> /jan
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> On 13 Sep 2023, at 10:57, Jernej Tuljak 
>> wrote:
>> >>>>
>> >>>> On 12/0

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem  wrote:

>
>
> > On Sep 13, 2023, at 10:36, Ladislav Lhotka  40nic...@dmarc.ietf.org> wrote:
> >
> >
> >
> > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
> >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
> >>> Jernej,
> >>>
> >>> Hat off for the tools (and tool vendors!) that assist authors to stay
> true to YANG RFC sections 10 and 11 also. Well done. :-)
> >>>
> >>> I intentionally used "compiler" rather than "toolchain", "IDE" or
> something more open ended, because a compiler is what I have and can speak
> for.
> >>>
> >>> Even so, I have a hard time thinking the customers of even the best
> YANG IDEs would be interested to pay the effort for distinguishing between
> YANG 1.1 and YANG 1.2 solely on the proposed RFC wording difference. Since
> a BC verification capability apparently already exists in some IDEs, I
> think it would make sense for their vendors to turn the checks it into a
> warnings (if they aren't already), regardless of which yang-version
> statement is found in the module header.
> >>>
> >>> This might mean a non-zero implementation effort for a few YANG
> toolchain implementors. While this is a good point, it does not really sway
> my opinion about what the pragmatic choice for IETF is. Or Jernej, do you
> think the users of those good IDEs would prefer a new YANG version? If so,
> why?
> >> If you are asking whether I'd like to see a new version of YANG for the
> sole purpose of changing those MUST and MUST NOTs - no, I would not.
> However, a change like this mandates a yang-version bump, IMHO.
> >
> > Right, so we have two ugly options, but bumping YANG version really
> makes no sense, so breaking those few tools that check update rules looks
> like a better choice to me.
> >
> > We have already seen cases that the update rules prevented fixing
> problems in YANG modules in a straightforward way, and backward-compatible
> fixes negatively affected module readability. This is inevitable until the
> ecosystem of YANG modules stabilizes. That's why I think changing update
> rules from MUST to SHOULD is appropriate - it should have been so from the
> beginning.
>
> I wholeheartedly agree. We need to be able to fix YANG modules with NBC
> changes. I know of at least one implementation that support NBC changes for
> proprietary models with node-specific translation
>
>
Some of us do not think a bugfix counts as an NBC change.
If the YANG definition is wrong and has been wrong from the start, then BC
is not important.
Fixing the YANG module so the definitions match the intent of the authors
is important.

IMO this new draft is not really needed at all, since bugfix exceptions
should be allowed
and should have always been allowed.


Thanks,
> Acee
>
>
Andy


>
>
>
> >
> > Lada
> >
> >> Jernej
> >>>
> >>> Best Regards,
> >>> /jan
> >>>
> >>>
> >>>
> >>>
> >>>
>  On 13 Sep 2023, at 10:57, Jernej Tuljak 
> wrote:
> 
>  On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
> > Jürgen, all,
> >
> > I see the irony in changing the YANG RFC(s) without updating the
> YANG language version number, but digging a bit deeper, I think the
> question is not as clear-cut as it might seem at first.
> >
> > Altering the contents of the backwards-compatibility section of RFC
> 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module
> authors' behavior.
> >
> > Speaking as a YANG compiler implementor, however, I don't see any
> changes that have to made to the compiler because of this RFC change. There
> are no new keywords, none are removed. There is no change in the meaning of
> existing keywords. There is no difference in the output the compiler needs
> to generate.
> >
> > So while there are changes to the YANG *standard* (meaning RFCs)
> there is no actual change to the YANG *language*. If we require user's to
> mark their modules with version 1.2 (or 2.0), from the compiler's pov, that
> would just be an alias for YANG 1.1. It means a fair amount of trouble to
> update all the tools out there to accept "yang-version 1.2" but do nothing
> new. It also adds a burden to YANG module implementors, since they would
> have to go through all YANG 1.1 modules and mark them 1.2, for no change in
> meaning. For organizations with some modules still on YANG 1.0, the bar is
> even higher.
> >
> > I think the most pragmatic approach in this case would be to change
> the RFC text in the backwards-compatibility sections and not update the
> yang-version number as long as no change is required in the compilers. If
> anyone can point to actual things the compiler needs to do differently, I'd
> be interested to hear.
> 
>  You will first have to define what a YANG compiler is before you can
> make such assumptions. YANG code validation rules may be implemented in
> several ways, depending on what the tool that utilizes them is used for. I
> choose to call that a "validation engine" - "com

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Tue, Sep 12, 2023 at 4:09 PM Kent Watsen  wrote:

> [All, don’t forget to vote, discussion here doesn’t count!
> https://notes.ietf.org/netmod-2023-sept-poll]
>
>
> On Sep 12, 2023, at 12:06 PM, Andy Bierman  wrote:
>
> So there is choice between:
>
>   (A) YANG 1.1 and SHOULD NOT
>   (B) YANG 1.2 and SHOULD NOT
>
>
> Thanks Andy, this is a succinct way to frame it.
>
>
>
> (A) is acceptable.
> YANG 1.2 would create a false expectation in the user community that the
> IETF
> had improved the YANG language somehow.
>
>
> Agreed.
>
>
It would be a very disruptive and visible change to just 'bump the version'.
Someday, the WG should work on the yang-next list and produce a real YANG
1.2.



> Kent
>

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Tue, Sep 12, 2023 at 8:54 AM Reshad Rahman  wrote:

>
>
> On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman <
> a...@yumaworks.com> wrote:
>
>
>
>
> On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:
>
> WG,
>
> Please help the YANG-versioning effort move forward by participating in
> the following poll:
>
>   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
>
>
>
> The draft proposed to change many specific MUST and MUST NOT requirements
> to MAY ignore.
> It has been pointed out that the correct change would be SHOULD NOT and
> the use of MAY is inappropriate
> according to the definitions in RFC 2119.
>  I thought the authors had agreed on SHOULD NOT (instead of MAY), but
> I don't recall if this was just in the weekly calls or actually
> communicated to the wg alias.
>
>
So there is choice between:

  (A) YANG 1.1 and SHOULD NOT
  (B) YANG 1.2 and SHOULD NOT

(A) is acceptable.
YANG 1.2 would create a false expectation in the user community that the
IETF
had improved the YANG language somehow.


> Regards,
> Reshad.
>

Andy


>
> Yet the WG continues to propose that these rules in RFC 7950 are purely
> optional and can be ignored by
> any implementation that chooses to do so.
>
> Of course rules that affect backward compatibility and stability do not
> affect the code that compiles a module.
> They only affect the client code that attempts to use the unstable server
> code.
>
>
>
> Kent and Lou
>
>
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:

> WG,
>
> Please help the YANG-versioning effort move forward by participating in
> the following poll:
>
>   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
>
>

The draft proposed to change many specific MUST and MUST NOT requirements
to MAY ignore.
It has been pointed out that the correct change would be SHOULD NOT and the
use of MAY is inappropriate
according to the definitions in RFC 2119.

Yet the WG continues to propose that these rules in RFC 7950 are purely
optional and can be ignored by
any implementation that chooses to do so.

Of course rules that affect backward compatibility and stability do not
affect the code that compiles a module.
They only affect the client code that attempts to use the unstable server
code.



Kent and Lou
>

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] [core] WG Last Call on draft-ietf-core-sid-21

[Andy Bierman]

On Sun, Sep 10, 2023 at 11:59 AM Michael Richardson 
wrote:

>
> Andy Bierman  wrote:
> > I do not have time to do another full review of this draft.
> > These are high-level comments.
>
> > ## document scope is too large
>
> > The draft should be split into 2 or 3 drafts.
>
> > 1) SID File Definition
> > 2a) SID Management Procedures
> > 2b) Initial SID File Definitions
>
> It sounds like a good idea in principal, and if it were 2018, I'd say,
> sure.
> But I'm not really sure we are going make anything easier by splitting
> things
> up now.
>
> > ## document scope is not CORE-specific
>
> > Several WGs and SDOs want to use SID files.
> > The 13 modules listed in sec 6.4.4 are a small fraction of the IETF
> YANG
> > modules
> > that should have SID files.
>
> I don't understand why it matters where we publish the work, as long as we
> do.
>
>

I don't understand where the SID files are for the modules in the initial
registry (sec. 6.4.4).
Is that for another WG to create the SID files and publish them in an RFC?


> ## SID files are normative
>
> > - The algorithm is not stable enough yet (both specification and
> > implementation).
> > - Manual editing is allowed.
> > - There is no indication in the SID file that it is automatically
> generated
> > or manually edited.
> > - Only the authoritative SID file can be trusted to have the correct
> > assignments
>
> These seem like reasonable complaints, but I'm not sure we can get past
> this
> until we publish a documents.  It's a *PROPOSED STANDARD*
>

The standard is fairly dependent on availability and conformance to
authoritative SID files.


> > ## Initial SID files are missing
>
> > The normative SID files for all YANG modules listed in sec 6.4.4 are
> > missing.
> > The assignment range is insufficient for interoperability.
>
> I hadn't imagined that we'd have to do all that work before publishing, but
> rather that we couldn't do any of that work until we published.
>


IMO this draft should include the normative SID files for the initial
registry contents.



>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08

[Andy Bierman]

On Tue, Sep 5, 2023 at 5:42 AM Kent Watsen  wrote:

> NETMOD WG,
>
> This email begins a 2-week adoption poll for:
> https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08
>
> There is no known IPR on this draft (IPR call
> 
> ).
>
> Please voice your support or technical objections to adoption on the list
> by the end of the day (any time zone) Sep 19.
>
>

I do not support the adoption of this draft.
It does not appear there is WG consensus on a problem statement.

I reject the architecture that is built upon the premise that the
config=true nodes
must not include any data nodes provided by the server. It is already
backed into
the YANG models.

The 'type' leaf in RFC 8343 is a good example of the problem:

 "The type of the interface.

  When an interface entry is created, a server MAY
  initialize the type leaf with a valid value, e.g., if it
  is possible to derive the type from the name of the
  interface.

  If a client tries to set the type of an interface to a
  value that can never be used by the system, e.g., if the
  type is not supported or if the type does not match the
  name of the interface, the server MUST reject the request.
  A NETCONF server MUST reply with an rpc-error with the
  error-tag 'invalid-value' in this case.";

Use-Cases:
- dynamic defaults
- system-dependent values (like if:type)

In both cases, there is a subset of valid values that are not the same as
the entire type range.
The server can provide a correct value, or the client can guess a correct
value.
For simplicity, it is easier if the server provides a correct value.  It
would be really complex
to require clients to always provide a correct value.

Possible Problems:
- There is no standard machine-readable mechanism to identify a
configuration leaf with these properties
- There is no way (besides populating NACM data rules) to indicate that the
server implementation
   does not allow the client to know if write access to the leaf is
restricted

Issues with if:type:
  -  The server MAY create a mandatory leaf.
  This clearly applies to  and 
  -  How does the client know which server implementations will create the
 missing mandatory leaf, and which will not?
  -  The if:type text does not mention that the server MAY prohibit
modification of this leaf.
  - The mandatory=true property indicates whether the client or server can
delete the leaf.
There is no such indication for an optional leaf.

It seems some people are arguing that data nodes like if:type should be
read-only because the server MAY write it.
IMO the if:type design is correct. I.e. both the server and client can
provide config=true values.
I am not sure a 1-size-fits-all YANG extension can replace the
description-stmt for a leaf like if:type.


Thank you,
> Kent (as co-chair)
>

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] WG Last Call on draft-ietf-core-sid-21

[Andy Bierman]

Hi,

I do not have time to do another full review of this draft.
These are high-level comments.

## document scope is too large

The draft should be split into 2 or 3 drafts.

1) SID File Definition
2a) SID Management Procedures
2b) Initial SID File Definitions

## document scope is not CORE-specific

Several WGs and SDOs want to use SID files.
The 13 modules listed in sec 6.4.4 are a small fraction of the IETF YANG
modules
that should have SID files.

A separate document can better address the IETF-wide requirements.

## SID files are normative

- The algorithm is not stable enough yet (both specification and
implementation).
- Manual editing is allowed.
- There is no indication in the SID file that it is automatically generated
or manually edited.
- Only the authoritative SID file can be trusted to have the correct
assignments

## Initial SID files are missing

The normative SID files for all YANG modules listed in sec 6.4.4 are
missing.
The assignment range is insufficient for interoperability.


Andy


On Mon, Sep 4, 2023 at 1:22 PM Marco Tiloca  wrote:

> Dear all,
>
> This email starts a Working Group Last Call for the document:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-21
>
> (YANG Schema Item iDentifier (YANG SID))
>
>
> The document status can be found at:
>
> https://datatracker.ietf.org/doc/draft-ietf-core-sid/
>
>
> Please provide your comments and feedback by Friday, 2023-09-15.
>
> This WGLC is also copied to the NETMOD WG mailing list.
>
> Best,
> /Marco
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Phone: +46 (0)70 60 46 501
>
> RISE Research Institutes of Sweden AB
> Box 1263
> 164 29 Kista (Sweden)
>
> Division: Digital Systems
> Department: Computer Science
> Unit: Cybersecurity
> https://www.ri.se
>
> ___
> 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

[Andy Bierman]

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

## 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.

## 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.

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.

## 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.

## 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?

## sec 3.5.1

IMO there should be a SID file 'item' list shown for
the examples.  IMO it is confusing that the SID assignments
do not follow the standard algorithm.

Since the 'input' or 'output' SID is actually used in
protocol messages, 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).

## 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'

The example RPC does not define any 'output' section
so the response should not have any payload at all.
RESTCONF uses the 'input' and 'output' nodes in the
payloads. CORECONF is using the RPC method node instead.


## sec 3.5.2


IMO the extra layer in the encoding for '0' is wrong.
It should match the format used for RPC.

It should be clear that if an RPC or action does not
have any input parameters (either direct or augments),
then the payload will not have any input parameters.

Is this the correct encoding (should have examples in the draft)

RPC:

{ 61000:
  null
}

ACTION:

{ [60002, "myserver"]:
  null
}

It should be clear that order of YANG list and leaf-list data nodes
are significant if they have the ordered-by 'user' property.
Note that this applies only to the entries within a parameter.
The RPC or action input/output child nodes do not need to
be supplied in order. The text in RFC 7950 (e.g. 7.14.4)
applies only to NETCONF.

## Appendix A and B

There should be a sentence declaring each appendix to
be normative, or move to a numbered section instead.



On Mon, Sep 4, 2023 at 1:24 PM Marco Tiloca  wrote:

> Dear all,
>
> This email starts a Working Group Last Call for the document:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-16
>
> (CoAP Management Interface (CORECONF))
>
>
> The document status can be found at:
>
> https://datatracker.ietf.org/doc/draft-ietf-core-comi/
>
>
> Please provide your comments and feedback by Friday, 2023-09-15.
>
> This WGLC is also copied to the NETMOD WG mailing list.
>
> Best,
> /Marco
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Phone: +46 (0)70 60 46 501
>
> RISE Research Institutes of Sweden AB
> Box 1263
> 164 29 Kista (Sweden)
>
> Division: Digital Systems
> Department: Computer Science
> Unit: Cybersecurity
> https://www.ri.se
>
> ___
> core mailing list
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Andy Bierman]

On Mon, Jul 24, 2023 at 4:41 PM Christian Hopps  wrote:

>
> Balázs Lengyel  writes:
>
> > Hello Andy,
> >
> > I assume you are referring to the sentence “A new module revision MAY
> > contain NBC changes” from the versioning draft.
> >
> > IMHO the authors agree that NBC changes are bad. They should be
> > allowed but discouraged.
>
> That's what "SHOULD NOT" means.
>
>
Indeed.
https://datatracker.ietf.org/doc/html/rfc2119

It is clear that 'SHOULD NOT' is the correct term and 'MAY' does not even
apply here.


> Would a sentence like
> >
> > “A new module revision MAY but SHOULD NOT contain NBC changes … ”
> >
> > be OK ?
> >
> > I think the MAY part is also needed< because that is what we are
> > introducing as new compared to 7950.
>
> IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD
> NOT" allows a thing while discouraging it.
>


> Thanks,
> Chris.
>
>
 Andy


> >
> > be agreeable?
> >
> > Regards Balazs
> >
> >
> >
> > From: Andy Bierman 
> > Sent: Sunday, 23 July, 2023 17:26
> > To: Balázs Lengyel 
> > Cc: Martin Björklund ; netmod@ietf.org
> > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
> > changes in YANG 1.0 & YANG 1.1 or not?
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel <
> > balazs.leng...@ericsson.com> wrote:
> >
> > Hello Andy,
> >
> > In 3GPP we have endless debates about what is a bugfix. If the
> > functionality will not work it is a bugfix. If it works in a bad
> > way it is or maybe not a bugfix. If it works just in an ugly way
> > is it a bugfix?
> >
> > Conclusion: it is not possible to define clear criteria about
> > what is a bug and what is an improvement.
> >
> >
> >
> >
> >
> > It is easy to change MAY to SHOULD NOT in the versioning draft.
> >
> >
> >
> > IMO changing MUST NOT to MAY is unacceptable.
> >
> > The versioning draft is attempting to completely toss out all of the
> > YANG update rules.
> >
> > Changing the normative text to SHOULD NOT instead of MAY does not
> > require any specification of a bugfix.
> >
> >
> >
> >
> >
> > Regards Balazs
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > From: netmod  On Behalf Of Andy Bierman
> > Sent: Wednesday, 19 July, 2023 10:13
> > To: Martin Björklund 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
> > changes in YANG 1.0 & YANG 1.1 or not?
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <
> > mbj+i...@4668.se> wrote:
> >
> > What about Option 4 - Pragmatic Adherence to Current RFC7950
> > Rules
> >
> >
> >
> >
> >
> > This is the approach I also suggested on the mailing list.
> >
> >
> >
> > - As it works today; the IETF *has* published bugfixed
> > modules that break the
> >   rules.  (and many vendors do this as well)
> > - (Possibly) Introduce rev:non-backwards-compatible
> >
> > This would allow 6991bis to update date-and-time to follow
> > the updated
> > semantics for RFC3339 timestamps (which imo is the only
> > reasonable
> > thing to do - the consuequences of this change is handled by
> > SEDATE).
> >
> >
> >
> >
> >
> > The important thing in each case is to consider
> >
> > the expected impact on the real world and real deployments.
> >
> >
> >
> > IMO a bugfix should be OK, even if the rules in RFC 7950 say it
> > is an NBC change.
> >
> > But this is not the same thing as changing the rules in a new
> > document to shift the
> >
> > implementation burden to the client.
> >
> >
> >
> > This is only an IETF issue and the burden should be on a WG to
> > convince the IESG and IETF
> >
> > that making the NBC change is a bugfix and should be allowed as a
> > special case.
> >
> >
> >
> >
> >
> >
> > /martin
> >
> >
> 

Re: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels

[Andy Bierman]

On Sun, Jul 23, 2023 at 6:52 PM Balázs Lengyel  wrote:

> Hello,
>
> While  I fully agree with Jason’s comments, I would like to state both as
> an Ericsson guy and as a 3GPP delegate that for us Key issue 2 (multiple
> label schemes) is not important. The only important point is that it should
> be settled fast and thus not delay the acceptance of the versioning RFCs.
>

I would like this email answered about this issue.
https://mailarchive.ietf.org/arch/browse/netmod/?q=about%20revision%20label

There is no justification for more than 1 scheme and it does not work
either.


> Regards Balazs
>

Andy


>
>
> *From:* netmod  *On Behalf Of *Jason Sterne
> (Nokia)
> *Sent:* Wednesday, 19 July, 2023 14:19
> *To:* netmod@ietf.org
> *Subject:* [netmod] YANG Versioning: Key Issues #2 and #3 - revision
> labels
>
>
>
> Hi all,
>
>
>
> The weekly call group thought it would be good to provide an advance look
> at Key Issues #2 and #3 before the IETF117 NETMOD meeting.
>
>
>
> For now on the list let’s continue the focus on K1 but we’ll start in on
> K2 & K3 (if there is time) at IETF117.
>
>
>
> Key Issue #2: Single v/s multiple revision label schemes
>
> ---
>
> Recap of revision-label-scheme:
>
> -Extension defined in YANG module versioning document.
>
> -Takes a mandatory parameter defining the scheme used, it is an
> identity derived from revision-label-scheme-base
>
> -Extension MUST be used if there is a revision label statement in
> the (sub)module
>
> -The YANG Semver document defines the scheme yang-semver
>
> (note – the current YANG revision date is not considered a revision label
> / label scheme)
>
>
>
> -Example:
>
> rev:revision-label-scheme "yangver:yang-semver";
>
>
>
> Pros of revision-label-scheme:
>
> -YANG Semver deemed too restrictive by some
>
> -This provides flexibility to e.g. have vendor specific schemes
> which allow for infinite branching where the versions have no semantic
> meaning
>
> -Consistent framework for adding other schemes
>
>
>
> Cons of revision-label-scheme
>
> -Flexibility comes with cost of added complexity, e.g. what if a
> module changes from scheme A to scheme B
>
> -YANG Semver is sufficient for IETF and many vendors
>
> -If some entity wants their own scheme they could just do it
> using their own separate extension (outside of any “framework”)
>
>
>
> Impact of removing revision-label-scheme
>
> -We would rename revision-label e.g. to yangsemver-label
>
> -If a vendor wants a new versioning scheme, a proprietary
> extension would need to be added by that vendor (including augmentations of
> yang library, packages, etc)
>
> -The current IETF documents would be simpler
>
> -Cost/effort to make the changes to the documents
>
>
>
>
>
> Key Issue #3: Why do we need YANG Semver (vs. SemVer 2.0.0)?
>
> ---
>
> SemVer 2.0.0:
>
> -Linear (no branching)
>
> -Simpler in construction
>
> o   Major
>
> o   Minor
>
> o   Patch
>
> -1.0.0, 1.0.1, 1.1.0, 2.0.0, …
>
> o   If a new feature is needed in 1.0.1, a 1.2.0 would need to be minted
> that incorporates the features of 1.1.0
>
> -Widely liked by the industry, but only works well when updating
> at the head (fine for open source, not acceptable for operators)
>
>
>
> YANG Semver:
>
> -Support for limited branching (maintenance of released code)
>
> -Supports SemVer 2.0.0 rules
>
> -MAJOR.MINOR.PATCH_MODIFIER
>
> o   _compatible
>
> o   _non_compatible
>
>
>
> Example:
>
> 1.0.0
>
> |
>
> 1.0.1 -- 1.0.2_non_compatible
>
> |
>
> 1.1.0
>
> |
>
> 2.0.0
>
> A feature (or an NBC change can be backported)
>
>
>
> Why YANG Semver:
>
> -Given that module versioning allows branching, the labeling
> scheme must also support branching
>
> -YANG Semver is a compromise between power and simplicity
>
> o   Encourage “mostly” single track development with modifiers the
> exception
>
> o   Retains support for some updates to older versions
>
> -Sufficient for  SDOs and vendors
>
> -Industry is familiar with Semver – tried to stay close to it
>
>
>
> Jason (he/him)
>
>
> ___
> 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] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Andy Bierman]

Hi,

OLD:

 A new module revision MAY contain NBC changes, e.g., the semantics of
an existing data-node
 definition MAY be changed in an NBC manner without requiring a new
data-node definition with
 a new identifier.

NEW:

 A new module revision SHOULD NOT contain NBC changes, e.g., the
semantics of an existing data-node
 definition SHOULD NOT be changed in an NBC manner without requiring a
new data-node definition with
 a new identifier.


This allows Option 4 since SHOULD NOT will require an exception review to
get an RFC published.


Andy


On Sun, Jul 23, 2023 at 5:11 PM Balázs Lengyel 
wrote:

> Hello,
>
> I am writing this as
>
> - Balazs Lengyel one of the authors, but also as
>
> - an Ericsson guy and also as
>
> - a delegate of 3GPP, which requested a better versioning scheme in a
> reasonably
>
>  fast timeline.  3GPP represents both vendors and operators, so in this
> last
>
>  role I am sitting on both side of the fence.
>
>  I strongly support option 1 - modifying 7950 to allow NBC changes and
>
>  introducing something like Semver.
>
> - We need this soon and the other alternatives will take a longer time.
>
> - we need it for the current YANG models too, not just for YANG 1.2 or 2
> models
>
> - We are already today doing backwards incompatible updates. We would like
> to have
>
>  that aligned with IETF.
>
>  - as one of the authors I believe the work is ready and reasonably good
>
> - I believe adapting the tooling for a few new extensions is much less
> work
>
>  than adapting to a new YANG version
>
>  Option 2 will take a long time to specify, implement and roll out. During
> this time
>
>  other non-standard solutions will proliferate; messy solutions, like just
>
>  ignoring the current RFC7950 rules, will be used more and more.
>
>  Option 3 just ignores the real world.
>
>  NBC changes are happening. There are SDOs that value speed over final
> quality
>
>  and role out a new version of the modules every few months. These can not
>
>  live without some NBC changes.
>
>  A more fine grained versioning system is required.
>
>
>
> Regards Balazs
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Thursday, 20 July, 2023 18:52
> *To:* Jason Sterne (Nokia) 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes
> in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
>
>
> On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) <
> jason.ste...@nokia.com> wrote:
>
> We considered this approach as well in the weekly calls but in the end
> felt that was just dodging the problem. We have a set of “MUST” rules that
> we know need to occasionally be broken. Shouldn’t we officialize this so
> our behavior and documents match?  (i.e. SHOULD NOT instead of MUST)?
>
>
>
> It isn’t just an IETF issue. These same exceptions occur in vendor models,
> 3GPP, etc. There are times when making the NBC change is the reasonable way
> to go.
>
>
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with
>
>
>
> I do not support these changes in any version of YANG.
>
> The advice to the community is non-specific and obviously not backward
> compatible with RFC 7950.
>
> The new advice is that any change at all in a YANG module is now allowed.
>
> Instead of normative rules, RFC 7950 simply advises whether the optional
> 'non-backwards-compatible' extension could be applied or not.
>
> This is not a good change, especially on top of YANG 1.1.
>
>
>
> I could see if specific MUST NOT rules were changed to SHOULD NOT instead.
>
> A blank check using the current "MAY" (3.1, para 2)  is not a good idea.
>
>
>
>
>
> Jason
>
>
>
> Andy
>
>
>
>
>
> *From:* Andy Bierman 
> *Sent:* Wednesday, July 19, 2023 1:13 PM
> *To:* Martin Björklund 
> *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org
> *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes
> in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-688efc90f7cb3f03&q=1&e=d73d3aee-48a4-4fe9-b81b-56650cfeb8c6&u=http%3A%2F%2Fnok.it%2Fext>
> for additional information.
>
>
>
>
>
>
>
> On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund  wrote:
>
> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
>
>
&g

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Andy Bierman]

On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel 
wrote:

> Hello Andy,
>
> In 3GPP we have endless debates about what is a bugfix. If the
> functionality will not work it is a bugfix. If it works in a bad way it is
> or maybe not a bugfix. If it works just in an ugly way is it a bugfix?
>
> Conclusion: it is not possible to define clear criteria about what is a
> bug and what is an improvement.
>


It is easy to change MAY to SHOULD NOT in the versioning draft.

IMO changing MUST NOT to MAY is unacceptable.
The versioning draft is attempting to completely toss out all of the YANG
update rules.
Changing the normative text to SHOULD NOT instead of MAY does not require
any specification of a bugfix.


Regards Balazs
>


Andy


>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, 19 July, 2023 10:13
> *To:* Martin Björklund 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes
> in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
>
>
> On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund  wrote:
>
> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
>
>
>
>
>
> This is the approach I also suggested on the mailing list.
>
>
>
> - As it works today; the IETF *has* published bugfixed modules that break
> the
>   rules.  (and many vendors do this as well)
> - (Possibly) Introduce rev:non-backwards-compatible
>
> This would allow 6991bis to update date-and-time to follow the updated
> semantics for RFC3339 timestamps (which imo is the only reasonable
> thing to do - the consuequences of this change is handled by SEDATE).
>
>
>
>
>
> The important thing in each case is to consider
>
> the expected impact on the real world and real deployments.
>
>
>
> IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC
> change.
>
> But this is not the same thing as changing the rules in a new document to
> shift the
>
> implementation burden to the client.
>
>
>
> This is only an IETF issue and the burden should be on a WG to convince
> the IESG and IETF
>
> that making the NBC change is a bugfix and should be allowed as a special
> case.
>
>
>
>
>
>
> /martin
>
>
>
> Andy
>
>
>
>
> "Jason Sterne (Nokia)"  wrote:
> > Hi all,
> >
> > At the request of the NETMOD chairs, and on behalf of the YANG
> Versioning weekly call group, here's a summary of Key Issue #1 for the
> versioning work (i.e. for the Module Versioning and YANG Semver WGLC).
> >
> > We'd like to suggest that the WG has a strong focus on deciding on this
> specific issue first. Then we'll move on to tackle other key issues. The
> idea is to try and avoid getting tangled in a web of multiple intertwined
> issues.
> >
> > Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1
> or not?
> >
> > For now please avoid debating other issues in this thread (e.g. multiple
> vs single label schemes, whether YANG semver is a good scheme, etc). Let's
> focus on K1 and work towards a WG decision.
> >
> > ###
> > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> >
> > Option 1 - Update RFC7950 to Allow NBC Changes
> > ---
> > - Module Versioning modifies 7950 to allow NBC changes
> > - guidance that NBC changes SHOULD NOT be done (impact to user base)
> > - rev:non-backwards-compatible is a YANG extension
> > - introduction in published YANG does not impact current tooling
> (ignored until recognized)
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - allows gradual adoption in the industry. YANG authors can immeditately
> start publishing with the new extensions.
> > - move faster to produce modules in the IETF (accept some
> errors/iteration)
> > - address the liaison from external standards bodies in a reasonable
> timeframe
> > - authors believe work is ready
> > - broad vendor support
> > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> > CONS:
> > - perception that we're "cheating" by not bumping our own spec's version
> > - Not fundamentally mandatory for clients or servers using YANG
> (mandatory for YANG claiming conformance to Module Versioning).
> >
> > Option 2 - RFC7950-bis: Publish a new version of the YANG language to
> allow NBC changes
> > ---
> > - NBC changes onl

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Andy Bierman]

On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) 
wrote:

> We considered this approach as well in the weekly calls but in the end
> felt that was just dodging the problem. We have a set of “MUST” rules that
> we know need to occasionally be broken. Shouldn’t we officialize this so
> our behavior and documents match?  (i.e. SHOULD NOT instead of MUST)?
>
>
>
> It isn’t just an IETF issue. These same exceptions occur in vendor models,
> 3GPP, etc. There are times when making the NBC change is the reasonable way
> to go.
>
>
>

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with

I do not support these changes in any version of YANG.
The advice to the community is non-specific and obviously not backward
compatible with RFC 7950.
The new advice is that any change at all in a YANG module is now allowed.
Instead of normative rules, RFC 7950 simply advises whether the optional
'non-backwards-compatible' extension could be applied or not.
This is not a good change, especially on top of YANG 1.1.

I could see if specific MUST NOT rules were changed to SHOULD NOT instead.
A blank check using the current "MAY" (3.1, para 2)  is not a good idea.


Jason
>

Andy


>
>
> *From:* Andy Bierman 
> *Sent:* Wednesday, July 19, 2023 1:13 PM
> *To:* Martin Björklund 
> *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org
> *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes
> in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund  wrote:
>
> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
>
>
>
>
>
> This is the approach I also suggested on the mailing list.
>
>
>
> - As it works today; the IETF *has* published bugfixed modules that break
> the
>   rules.  (and many vendors do this as well)
> - (Possibly) Introduce rev:non-backwards-compatible
>
> This would allow 6991bis to update date-and-time to follow the updated
> semantics for RFC3339 timestamps (which imo is the only reasonable
> thing to do - the consuequences of this change is handled by SEDATE).
>
>
>
>
>
> The important thing in each case is to consider
>
> the expected impact on the real world and real deployments.
>
>
>
> IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC
> change.
>
> But this is not the same thing as changing the rules in a new document to
> shift the
>
> implementation burden to the client.
>
>
>
> This is only an IETF issue and the burden should be on a WG to convince
> the IESG and IETF
>
> that making the NBC change is a bugfix and should be allowed as a special
> case.
>
>
>
>
>
>
> /martin
>
>
>
> Andy
>
>
>
>
> "Jason Sterne (Nokia)"  wrote:
> > Hi all,
> >
> > At the request of the NETMOD chairs, and on behalf of the YANG
> Versioning weekly call group, here's a summary of Key Issue #1 for the
> versioning work (i.e. for the Module Versioning and YANG Semver WGLC).
> >
> > We'd like to suggest that the WG has a strong focus on deciding on this
> specific issue first. Then we'll move on to tackle other key issues. The
> idea is to try and avoid getting tangled in a web of multiple intertwined
> issues.
> >
> > Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1
> or not?
> >
> > For now please avoid debating other issues in this thread (e.g. multiple
> vs single label schemes, whether YANG semver is a good scheme, etc). Let's
> focus on K1 and work towards a WG decision.
> >
> > ###
> > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> >
> > Option 1 - Update RFC7950 to Allow NBC Changes
> > ---
> > - Module Versioning modifies 7950 to allow NBC changes
> > - guidance that NBC changes SHOULD NOT be done (impact to user base)
> > - rev:non-backwards-compatible is a YANG extension
> > - introduction in published YANG does not impact current tooling
> (ignored until recognized)
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - allows gradual adoption in the industry. YANG authors can immeditately
> start publishing with the new extensions.
> > - move faster to produce modules in the IETF (accept some
> errors/i

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Andy Bierman]

On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund  wrote:

> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
>
>

This is the approach I also suggested on the mailing list.


> - As it works today; the IETF *has* published bugfixed modules that break
> the
>   rules.  (and many vendors do this as well)
> - (Possibly) Introduce rev:non-backwards-compatible
>
> This would allow 6991bis to update date-and-time to follow the updated
> semantics for RFC3339 timestamps (which imo is the only reasonable
> thing to do - the consuequences of this change is handled by SEDATE).
>
>

The important thing in each case is to consider
the expected impact on the real world and real deployments.

IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC
change.
But this is not the same thing as changing the rules in a new document to
shift the
implementation burden to the client.

This is only an IETF issue and the burden should be on a WG to convince the
IESG and IETF
that making the NBC change is a bugfix and should be allowed as a special
case.



> /martin
>

Andy


>
> "Jason Sterne (Nokia)"  wrote:
> > Hi all,
> >
> > At the request of the NETMOD chairs, and on behalf of the YANG
> Versioning weekly call group, here's a summary of Key Issue #1 for the
> versioning work (i.e. for the Module Versioning and YANG Semver WGLC).
> >
> > We'd like to suggest that the WG has a strong focus on deciding on this
> specific issue first. Then we'll move on to tackle other key issues. The
> idea is to try and avoid getting tangled in a web of multiple intertwined
> issues.
> >
> > Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1
> or not?
> >
> > For now please avoid debating other issues in this thread (e.g. multiple
> vs single label schemes, whether YANG semver is a good scheme, etc). Let's
> focus on K1 and work towards a WG decision.
> >
> > ###
> > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> >
> > Option 1 - Update RFC7950 to Allow NBC Changes
> > ---
> > - Module Versioning modifies 7950 to allow NBC changes
> > - guidance that NBC changes SHOULD NOT be done (impact to user base)
> > - rev:non-backwards-compatible is a YANG extension
> > - introduction in published YANG does not impact current tooling
> (ignored until recognized)
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - allows gradual adoption in the industry. YANG authors can immeditately
> start publishing with the new extensions.
> > - move faster to produce modules in the IETF (accept some
> errors/iteration)
> > - address the liaison from external standards bodies in a reasonable
> timeframe
> > - authors believe work is ready
> > - broad vendor support
> > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> > CONS:
> > - perception that we're "cheating" by not bumping our own spec's version
> > - Not fundamentally mandatory for clients or servers using YANG
> (mandatory for YANG claiming conformance to Module Versioning).
> >
> > Option 2 - RFC7950-bis: Publish a new version of the YANG language to
> allow NBC changes
> > ---
> > - NBC changes only allowed in a new (future) version of YANG
> > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
> > - Content = Module Versioning + YANG Semver + very limited YANG NEXT
> items
> > - rev:non-backwards-compatible tag is a language keyword
> > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that
> hasn't been updated
> > - TBD how to handle small NBC changes in IETF in the short term (i.e.
> non conformance to 7950)?
> > - RFC6991 bis - change the use/meaning of ip-address (or change
> datetime)
> >   - YANG date-and-time (because of SEDATE date string
> changes)
> >
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - clear delineation of changes in the YANG language
> > - consistent with philosophy that version number changes for significant
> changes in a spec (avoids concern that YANG is changing without bumping the
> version of YANG)
> > - can do this with mandatory YANG keywords which helps increase
> conformance to the new rules
> > CONS:
> > - difficult to roll out in the industry. Tools need upgrading before
> they won't error on a YANG 1.2 module.
> > - Authors can't publish YANG 1.2 until their users have upgraded their
> tools. Everyone has to move at once.
> > - likely large delay in producing the work (unclear what would go into
> YANG 1.2, may not reach concensus easily on N items)
> > - delay in follow up work (Packages, Schema Comparison, Version
> Selection)
> > - continue dominating WG effort for longer (opportunity cost)
> >
> > Option 3 - Strict Adherence to Current RFC7950 Rules
> > -

Re: [netmod] WGLC on node-tags-09

[Andy Bierman]

On Mon, Jun 26, 2023 at 2:34 AM Qin Wu  wrote:

> Andy:
>
> Sorry for late followup, please see my reply inline below.
>
>
>
> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2023年4月20日 2:39
> *收件人:* Kent Watsen 
> *抄送:* netmod@ietf.org
> *主题:* Re: [netmod] WGLC on node-tags-09
>
>
>
>
>
>
>
> On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen  wrote:
>
> This email begins a two-week WGLC on:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>
> Please take time to review this draft and post comments by May 2nd.
> Favorable comments are especially welcomed.
>
>
>
> I have read the latest draft and IMO it needs more work.
>
>
>
> 1) metrics
>
>
>
> The identities to represent system tags are quite vague.
>
> There are no specific guidelines for selecting the correct tag.
>
> There are no references to other RFCs for the metric definitions.
>
> I would expect IPPM WG to define the classification system, not NETMOD WG.
>
>
>
> [Qin Wu]
>
> Good comment, the idea of introducing system tags is to classify the data
> nodes or data node instances and identify the characteristics
>
> data or metric data. The identity is associated with ‘type’ leaf for
> specific data node or instance of data node and provides a second
>
> level classification, e.g., we add a system tag for ‘in-octets’ leaf under
> interface list in ietf-interface.yang module, in addition,
>
> we can add a type leaf with the value as ‘summary’ for the same leaf to
> indicate the leaf value is average value.
>
> For packet loss, jitter, delay, similar to what ALTO performance metrics
> RFC (draft-ietf-alto-performance-metrics) is doing, we don’t
>
> define any new metrics and we just reuse the same metrics defined in IPPM,
> we can add similar RFCs to packet loss, jitter, delay described
>
> in this draft. Regarding summary, counter definition, I believe we should
> reference to openmetric draft described in
>
> (https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00)
> which has already been open sourced and well specified and validated.
>
> Regarding guidelines for selecting the correct tag, we did provide
> guideline for model writer to define system tags at the design time,
>
> but similar to what module tag is doing, we will leave freedom to the
> client to decide whether the correct tag is selected.
>
>
>
> One more thing I want to clarify is I think identity used to describe the
> type of data node should be limited to summary, counter, unknown,
>
> gauge, etc, the packet loss, delay identities can be removed.
>
>
>


YANG authors should not need to tag nodes with specific metrics at all.
I am not convinced that standard tags like "counter," or "loss," or "delay"
are useful.
IMO it would be better to keep standard tags in their own RFC(s),
especially something as complicated as metrics classification.




>
> 2) System tag procedures
>
>
>
> There are no procedures defined for YANG model developers.
>
>
>
> [Qin Wu] See section 8 for guidelines for YANG model developers.
>
>
>
> Are they supposed to add a node-tag extension to almost every leaf in the
> module?
>
> [Qin Wu] The answer is no, we only add node tag extension to
> characteristics data
>
> Related leaf, e.g., leaf used to describe the metric data, e.g., the
> number of inbound
>
> packets that contained errors.
>
>
>

This seems like a huge administrative burden with minimal guidance provided.



Andy



> The administration and maintenance of node-tags will be a huge burden.
>
> That was one reason they were not added to the module-tags module in the
> first place.
>
>
>
> The YANG extension itself is under-specified since it offers no guidance on
>
> which YANG statements are allowed to have this extension as a
> sub-statement.
>
>
>
> [Qin Wu] See last paragraph of section 9.2
>
> “
>
>A data node can contain one or multiple node tags.Data node to be
>
>tagged with the initial value in Table 2 can be one of 'container',
>
>'leaf-list', 'list', or 'leaf' data node.  All tag values described
>
>in Table 2 can be inherited down the containment hierarchy if Data
>
>nodes tagged with those tag values is one of 'container', 'leaf-
>
>list', 'list'.
>
>
>
> ”
>
> Note that we don’t allow add system tag to notification or action
> statement. We can make this clear in the updated text.
>
>
>
> IMO all the metrics (tag type identities) should 

[netmod] questions about revision-label-scheme extension

[Andy Bierman]

Hi,

It is not really clear how this extension works.
This extension is used to specify the format and semantics of the 'label'
and 'recommended-min'
argument string contents.

Q1) What specific requirements (if any) are being addressed by this
solution?
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-08#name-the-problem-statement

Q2) What happens if the revision-label-scheme value is changed in a new
revision of the module?  Are all of the existing label and scattered
recommended-min
statements changed to the new scheme?

Q3) How is it possible to use recommended-min without knowing the revision
scheme
for the imported module (or included submodule)?  This is defined in the
imported module.

IMO allowing every module or submodule to use a different versioning system
does not work. Each system will define its own extensions anyway.
E.g., a tool will look for the 'openconfig-version' extension if it
supports OpenConfig.

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, Jun 14, 2023 at 3:00 AM Martin Björklund  wrote:

> "Rob Wilton (rwilton)"  wrote:
> > Hi Martin,
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin Björklund
> > > Sent: 07 June 2023 08:22
> > > To: rwilton=40cisco@dmarc.ietf.org
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > > drafts
> > >
> > > Hi,
> > >
> > > But the two drafts go way beyond fixing the problem your three
> > > examples illustrate.
> > [Rob Wilton (rwilton)]
> >
> > The actual goals of this work (i.e., the set of drafts) is aiming to
> > address the requirements stated here:
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07
> .
> > Although never taken to RFC, I believe was effectively last called and
> > achieved WG consensus for the NETMOD WG.  Hopefully the chairs can
> > chime in and keep me honest if I'm wrong on this point.
> >
> > The shape/structure/content of the drafts is very similar to when
> > these documents were adopted in March 2020:
> >
> > Your comments on these document at adoption time are here
> > (
> https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/
> ).
> > From that email, it is clear that you didn't support the YANG Semver
> > scheme, but my reading is that you were broadly supportive of the YANG
> > module versioning draft.
> >
> > Here are your review comments of the YANG module versioning draft at
> > adoption time:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/
> >
> > Here is a thread where you are discussing supporting different
> > revision label schemes:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> >
> > I appreciate that everyone has the right to change their mind at any
> > point, but as stated previously, I don't think that the shape of the
> > solution has really changed substantially since they were adopted.
>
> I'm not sure that I have changed my mind on this topic (but if I have
> I view that as a good thing; it means I'm open to new technical
> arguments ;-)
>
> I don't think I have ever said that this is important work.  I can
> live with optional extension statements that indicate nbc changes, and
> even that another optional revision label scheme is used, but I do
> think it adds unnecessary complexity.  I do not like "modified
> semver", and I see no reason why the current revision-date based
> scheme doesn't work for IETF modules.
>
>
>
I supported the adoption of OpenConfig SemVer when this work started.
Now there are 2 SemVers.  Not impossible to support
both the openconfig-version and label extensions.
Except 'label' is not fixed to a single semantic version system.
It supposedly supports any syntax and its associated semantics.

  3.4.2. Revision label scheme extension statement

  The optional "rev:revision-label-scheme" extension statement is used
to indicate which revision label scheme a module or submodule uses.
  There MUST NOT be more than one revision label scheme in a module or
submodule. The mandatory argument to this extension statement:

rev:revision-label-scheme "yangver:yang-semver";



I do not support this revision-label-scheme "framework".
IMO it actually harms interoperability instead of improving it, by allowing
any and every vendor to create their own semantic versioning system.

New issue with the actual YANG definitions:

The contents of the 'label' are confusing.
The semver draft says the label will contain a string matching the
"version" typedef.


  identity yang-semver {
base rev:revision-label-scheme-base;
description
  "The revision-label scheme corresponds to the YANG Semver
   scheme which is defined by the pattern in the 'version'
   typedef below. The rules governing this revision-label
   scheme are defined in the reference for this identity.";



The 'label' extension says something else

   The format of the revision label argument MUST conform to the
   pattern defined for the revision label typedef in this module.


The 'revision-label' typedef and 'version' typedef are different.



> /martin
>


Andy


>
>
>
> >   If the goal is to indicate that non-backwards
> > > compatible changes have occured, a single new extension statement
> > > could solve that.  (As I probably have stated before, personally I
> > > don't think this is necessary).
> >
> > That is one goal.  Another is to acknowledge that
> > non-backwards-compatible changes will occur, potentially even on
> > branches.  Another is to align with the versioning scheme that is
> > being broadly used by the industry (but with extensions to support a
> > branched history).
> >
> > >
> > > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > > about the additional complexity the "pluggable" revision-label scheme
> > > brings.
> > [Rob Wilton (rwilton)]
> >
> > It feels like we are somewhat going in circles:
> >
> 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, Jun 13, 2023 at 10:31 AM Jason Sterne (Nokia) <
jason.ste...@nokia.com> wrote:

> Its too late. The industry is already ignoring parts of 7950 in cases
> where many people agree that is the most practical thing to do.
>
>
>
> This work gives a common format for an author to explicitly indicate “hey
> – look out, we made an NBC change – take a look and see how it impacts you”.
>
>
>

The parts of the drafts that provide this feature are not the problem.
Adding some YANG extensions to help manage NBC changes is fine.
The changes are still NBC in YANG 1.1.

Changing the rules for YANG Module Updates requires a new YANG version
number.
Breaking the rules for YANG Module Updates does not. I object to
changing the rules
without a new yang-version number.  The industry just needs the YANG
extensions
and everyone can keep on breaking the rules.

If YANG 1.2 is ever developed then the module update rules can officially
change.



Jason
>
>
>

Andy


> *From:* Andy Bierman 
> *Sent:* Tuesday, June 13, 2023 12:45 PM
> *To:* Jason Sterne (Nokia) 
> *Cc:* Martin Björklund ; rwilton=
> 40cisco@dmarc.ietf.org; netmod@ietf.org
> *Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> drafts
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Tue, Jun 13, 2023 at 9:00 AM Jason Sterne (Nokia) <
> jason.ste...@nokia.com> wrote:
>
> Hi all,
>
>
>
> I don’t think requiring a new YANG 1.2 (or 2.0) is a practical way to
> introduce this much-needed enhancement to YANG (indicating NBC changes and
> clearly alerting users of YANG modules to the fact that there is an NBC
> change). NBC changes are happening (IETF, vendors, other standard bodies)
> because sometimes they are the most pragmatic way to evolve a model in some
> cases.
>
>
>
>
>
>
>
> I do not agree that parts of RFC 7950 can be ignored.
>
> If the yang-version is "1.1" then RFC 7950 applies to the YANG module.
>
> The module update draft has no authority to rewrite YANG 1.1.
>
> All the text that updates RFC 7950 should be removed.
>
>
>
>
>
> Andy
>
>
>
>
>
> If a YANG authoring entity (IETF, vendor) suddenly marked their latest
> YANG modules as 1.2 and those modules contained some new language keywords,
> it would immediately impacts dozens/hundreds of users of those modules.
> Tool chains will break.
>
>
>
> Using extensions allows a smooth and gradual deployment of the
> rev:non-backwards-compatible functionality/indicator. It won’t break tool
> chains. It is useful additive metadata immediately available at minimum for
> human readers, and over time tools can be upgraded to recognize and act on
> the extension. In the meantime, no client/user is worse off than today.
>
>
>
> Many YANG authoring organizations haven’t even moved to YANG 1.1 yet.
> Pyang doesn’t yet support the full set of YANG 1.1 changes (e.g. submodule
> scoping changes). I think it would be a mistake to only put this new YANG
> versioning work into a YANG 1.2 (which would be cumulative of YANG 1.1 +
> additional changes). The extensions are useful to YANG 1.0 and YANG 1.1
> modules.
>
>
>
> I still feel the work is a good practical step forward for the YANG
> ecosystem.
>
>
>
> Jason
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, June 7, 2023 4:49 PM
> *To:* Martin Björklund 
> *Cc:* rwilton=40cisco@dmarc.ietf.org; netmod@ietf.org
> *Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> drafts
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund  wrote:
>
> Hi,
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).
>
>
>
> Problem 1)
>
>
>
> We started out with the "grouping drift" problem.
>
> That led to "import-by-revision" in YANG 1.1.
>
> These drafts attempt to fix that.
>
> The "min-revision" for an import is an improvement over "exact revision".
>
>
>
> Problem 2)
>
>
>
> Some

Re: [netmod] Module updates in imported modules

[Andy Bierman]

On Tue, Jun 13, 2023 at 8:48 AM Jason Sterne (Nokia) 
wrote:

> Hi Andy,
>
>
>
> From my read of 7950, adding a mandatory leaf to a grouping isn’t allowed.
> Section 11 lists every case of allowable changes. Can you point out what
> statement(s) you feel allow it?
>





   The "grouping" statement is not a data definition statement and, as
   such, does not define any nodes in the schema tree.



IMO the constraints in sec 11. apply to the schema tree (i.e., uses
expansion) but the text is not clear about that.
E.g., many constraints are ignored within an sx:structure. The context of
the uses-stmt matters.

The same grouping can be used for the first time in 1 module and not be an
update,
so the mandatory node rule does not apply.

So incrementing the grouping module major-version if any possible uses
expansion leads to NBC changes is required.



>
> If there is some ambiguity about that in RFC7950 personally I think any
> clarification would be to make it not-allowed (aka NBC). The module A that
> defines a grouping (or a typedef, or the name of a choice, etc, etc)
> doesn’t know how other modules will import module A, or augment module A.
>
>
>
> So a client/app (or developer of that client/app) that uses modules A, B
> and C in your original example would “trigger” on the fact that module A
> had an NBC change. The developers would then examine the changes to A and
> determine how those impact them (by seeing where that grouping is used,
> whether the client uses those nodes, etc).
>

Perhaps an example showing an NBC change to an imported module should be
added.


>
> Jason
>

Andy


>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Friday, June 9, 2023 2:30 PM
> *To:* Jan Lindblad 
> *Cc:* NetMod WG 
> *Subject:* Re: [netmod] Module updates in imported modules
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Fri, Jun 9, 2023 at 1:23 AM Jan Lindblad  wrote:
>
> Andy,
>
>
>
> I think you have a lot of good points in this discussion, but here is one
> I don't quite understand.
>
>
>
> You state that the addition of leaf three in the 1.1.0 version of grouping
> A would be BC. 7950 sec 11 lists things you are allowed to do and still
> call your module BC. By which rule in section 11 would you argue that the
> 1.1.0 change is BC? To me, this addition of a mandatory leaf in an existing
> grouping, appear not to be covered in any of the BC cases. It also breaks
> the architectural idea expressed in the first paragraph of sec 11:
>
>
>
>[...] changes to published modules are not allowed
>
>if they have any potential to cause interoperability problems between
>
>a client using an original specification and a server using an
>
>updated specification.
>
>
>
>
>
> I think this text applies to schema nodes (i.e., uses expansion, not
> groupings).
>
> Adding a mandatory leaf to a grouping is allowed.
>
>
>
> The NBC change occurs here because it is an augment using a mandatory
> NP-container.
>
> The same "uses" in a P-container or a list is not an NBC change.
>
>
>
> My point is that none of the protections in these drafts work because the
> module
>
> with the "uses" is not the module being changed.  Even when A(2.0.0) is
> used by a server,
>
> none of the protections work because module C never gets updated, just A.
>
>
>
>
>
> Also, if your comment about SIDs not being updated as imported modules
> change is true, that is indeed a major problem for the SID generation.
>
>
>
>
>
> The SID file for module C is created and uses A(1.1.0).
>
> Over time new revisions of A are published.
>
> A server can choose any revision of A in its implementation.
>
> A client hardwired to expect A(1.1.0) could still work with A(1.2.0).
>
> The node 'three' would be encoded as text and not a SID.
>
> A client hardwired to expect A(1.1.0) may not still work with A(2.0.0).
>
> The node 'two' would be encoded as a number and not a string anymore.
>
> However, this exact situation can occur if the server uses a deviation to
> replace the type for leaf 'two'.
>
>
>
> Every time a new revision of any imported module gets updated, a new SID
> file may be needed.
>
> E.g: 3 revisions of C.sid:
>
>
>
>  - module C using A(1.1.0)  == [default sid-file-version=0]
>
>  - module C using A(1.2.0)  == sid-file-version=1
>
>  - module C using A(2.0.0)  == sid-file-version=2
>
>
>
>

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, Jun 13, 2023 at 9:00 AM Jason Sterne (Nokia) 
wrote:

> Hi all,
>
>
>
> I don’t think requiring a new YANG 1.2 (or 2.0) is a practical way to
> introduce this much-needed enhancement to YANG (indicating NBC changes and
> clearly alerting users of YANG modules to the fact that there is an NBC
> change). NBC changes are happening (IETF, vendors, other standard bodies)
> because sometimes they are the most pragmatic way to evolve a model in some
> cases.
>
>
>


I do not agree that parts of RFC 7950 can be ignored.
If the yang-version is "1.1" then RFC 7950 applies to the YANG module.
The module update draft has no authority to rewrite YANG 1.1.
All the text that updates RFC 7950 should be removed.


Andy


If a YANG authoring entity (IETF, vendor) suddenly marked their latest YANG
> modules as 1.2 and those modules contained some new language keywords, it
> would immediately impacts dozens/hundreds of users of those modules. Tool
> chains will break.
>
>
>
> Using extensions allows a smooth and gradual deployment of the
> rev:non-backwards-compatible functionality/indicator. It won’t break tool
> chains. It is useful additive metadata immediately available at minimum for
> human readers, and over time tools can be upgraded to recognize and act on
> the extension. In the meantime, no client/user is worse off than today.
>
>
>
> Many YANG authoring organizations haven’t even moved to YANG 1.1 yet.
> Pyang doesn’t yet support the full set of YANG 1.1 changes (e.g. submodule
> scoping changes). I think it would be a mistake to only put this new YANG
> versioning work into a YANG 1.2 (which would be cumulative of YANG 1.1 +
> additional changes). The extensions are useful to YANG 1.0 and YANG 1.1
> modules.
>
>
>
> I still feel the work is a good practical step forward for the YANG
> ecosystem.
>
>
>
> Jason
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, June 7, 2023 4:49 PM
> *To:* Martin Björklund 
> *Cc:* rwilton=40cisco@dmarc.ietf.org; netmod@ietf.org
> *Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> drafts
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund  wrote:
>
> Hi,
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).
>
>
>
> Problem 1)
>
>
>
> We started out with the "grouping drift" problem.
>
> That led to "import-by-revision" in YANG 1.1.
>
> These drafts attempt to fix that.
>
> The "min-revision" for an import is an improvement over "exact revision".
>
>
>
> Problem 2)
>
>
>
> Sometimes, after considering all options, breaking YANG Update rules is
>
> the least bad option. The versioning draft attempts to fix that problem,
>
>
>
> Problem with Problem 1)
>
>
>
> Attempting to solve the "max revision" problem is much harder than
> "min-version".
>
> A revision-label for every identifier in every module would be impossible
> to manage or use.
>
> A single revision-label for the entire module is usually way too simple
> and not useful.
>
> Importing the latest release without incrementing the major-release number
>
> sounds like it helps, but most of the time, using the real 'latest' will
> work even better.
>
>
>
> IMO complex lifecycle issues require resource-level support (like HTTP has)
>
> built into the protocol. For starters, NETCONF needs to support warnings.
>
> This would allow the server to send deprecation (and other) warnings
>
> and other metadata at the resource level.
>
>
>
>
> Problem with Problem 2)
>
>
>
> RFC 7950 is quite clear that extensions MAY be ignored
>
> and the yang-version field determines which specification is used for the
> module.
>
> Any tool that supports YANG 1.1 is not expected
>
> to handle module changes that the RFC says MUST NOT be done.
>
>
>
> Updating the rules to say that the MUST NOT is replaced with MAY means
>
> that all YANG 1.1 tools MUST support NBC changes.  This is a big change
>
> that should require a new yang-version.
>
>
>
> IMO changing the official module update rule

Re: [netmod] Module updates in imported modules

[Andy Bierman]

On Fri, Jun 9, 2023 at 1:23 AM Jan Lindblad  wrote:

> Andy,
>
> I think you have a lot of good points in this discussion, but here is one
> I don't quite understand.
>
> You state that the addition of leaf three in the 1.1.0 version of grouping
> A would be BC. 7950 sec 11 lists things you are allowed to do and still
> call your module BC. By which rule in section 11 would you argue that the
> 1.1.0 change is BC? To me, this addition of a mandatory leaf in an existing
> grouping, appear not to be covered in any of the BC cases. It also breaks
> the architectural idea expressed in the first paragraph of sec 11:
>
>[...] changes to published modules are not allowed
>if they have any potential to cause interoperability problems between
>a client using an original specification and a server using an
>updated specification.
>


I think this text applies to schema nodes (i.e., uses expansion, not
groupings).
Adding a mandatory leaf to a grouping is allowed.

The NBC change occurs here because it is an augment using a mandatory
NP-container.
The same "uses" in a P-container or a list is not an NBC change.

My point is that none of the protections in these drafts work because the
module
with the "uses" is not the module being changed.  Even when A(2.0.0) is
used by a server,
none of the protections work because module C never gets updated, just A.


> Also, if your comment about SIDs not being updated as imported modules
> change is true, that is indeed a major problem for the SID generation.
>
>
The SID file for module C is created and uses A(1.1.0).
Over time new revisions of A are published.
A server can choose any revision of A in its implementation.
A client hardwired to expect A(1.1.0) could still work with A(1.2.0).
The node 'three' would be encoded as text and not a SID.
A client hardwired to expect A(1.1.0) may not still work with A(2.0.0).
The node 'two' would be encoded as a number and not a string anymore.
However, this exact situation can occur if the server uses a deviation to
replace the type for leaf 'two'.

Every time a new revision of any imported module gets updated, a new SID
file may be needed.
E.g: 3 revisions of C.sid:

 - module C using A(1.1.0)  == [default sid-file-version=0]
 - module C using A(1.2.0)  == sid-file-version=1
 - module C using A(2.0.0)  == sid-file-version=2

It is valid for a server to use any 1 of the 3 revisions of module A.
Of course, this is a "hello world" example. A "real world" example will be
much more complicated.
Allowing NBC changes to YANG makes the problem more complicated as well.


Best Regards,
> /jan
>
>
>
Andy


>
>
> On 8 Jun 2023, at 21:18, Andy Bierman  wrote:
>
> Hi,
>
> It is not clear how the new drafts work for changes in imported groupings.
> This is a very common design pattern.
>
>  module A {
>// version 1.0.0
> grouping A {
>leaf one { type string; }
>leaf two { type string; }
>}
> }
>
>  module A {
>// version 1.1.0
> grouping A {
>leaf one { type string; }
>leaf two { type string; }
>leaf three { type string; mandatory true; }
>}
> }
>
> module B {
>container top;
> }
>
> module C {
>import A { prefix A; }
>import B { prefix B; }
>
>   augment "/B:top" {
> container C {
>uses A:A;
> }
>  }
> }
>
> In this example, the server starts out with module A(1.0.0).
> Modules B and C are some versions (doesn't matter).
>
> In a new server release, ONLY module A has been updated to 1.1.0.
> This is a BC change to the grouping so no major version update.
> Modules B and C are byte-exact and not changed at all.
>
> However now there is an NBC change caused by module C
> from a BC change in module A. (augment a mandatory node)
>
>
>  module A {
>// version 2.0.0
> grouping A {
>leaf one { type string; }
>leaf two { type uint32; }
>leaf three { type string; mandatory true; }
>}
> }
>
> Even if there is an NBC change to a grouping module, it is only apparent
> from
> compiling a specific YANG library, not from the individual modules.
> There is only an NBC change if the server chooses A(2.0.0).
>
> (out of scope here)
> Since module C never changed, the SID file for module C may not be changed,
> especially if module A is a standard module. If A(1.1.0) or (2.0.0) is
> used by the server then
> the SID for /top/C/three is missing.
>
> The module update draft should mention NBC issues from groupings.
>
>
> 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

[netmod] Module updates in imported modules

[Andy Bierman]

Hi,

It is not clear how the new drafts work for changes in imported groupings.
This is a very common design pattern.

 module A {
   // version 1.0.0
grouping A {
   leaf one { type string; }
   leaf two { type string; }
   }
}

 module A {
   // version 1.1.0
grouping A {
   leaf one { type string; }
   leaf two { type string; }
   leaf three { type string; mandatory true; }
   }
}

module B {
   container top;
}

module C {
   import A { prefix A; }
   import B { prefix B; }

  augment "/B:top" {
container C {
   uses A:A;
}
 }
}

In this example, the server starts out with module A(1.0.0).
Modules B and C are some versions (doesn't matter).

In a new server release, ONLY module A has been updated to 1.1.0.
This is a BC change to the grouping so no major version update.
Modules B and C are byte-exact and not changed at all.

However now there is an NBC change caused by module C
from a BC change in module A. (augment a mandatory node)


 module A {
   // version 2.0.0
grouping A {
   leaf one { type string; }
   leaf two { type uint32; }
   leaf three { type string; mandatory true; }
   }
}

Even if there is an NBC change to a grouping module, it is only apparent
from
compiling a specific YANG library, not from the individual modules.
There is only an NBC change if the server chooses A(2.0.0).

(out of scope here)
Since module C never changed, the SID file for module C may not be changed,
especially if module A is a standard module. If A(1.1.0) or (2.0.0) is used
by the server then
the SID for /top/C/three is missing.

The module update draft should mention NBC issues from groupings.


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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund  wrote:

> Hi,
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).
>
>
Problem 1)

We started out with the "grouping drift" problem.
That led to "import-by-revision" in YANG 1.1.
These drafts attempt to fix that.
The "min-revision" for an import is an improvement over "exact revision".

Problem 2)

Sometimes, after considering all options, breaking YANG Update rules is
the least bad option. The versioning draft attempts to fix that problem,

Problem with Problem 1)

Attempting to solve the "max revision" problem is much harder than
"min-version".
A revision-label for every identifier in every module would be impossible
to manage or use.
A single revision-label for the entire module is usually way too simple and
not useful.
Importing the latest release without incrementing the major-release number
sounds like it helps, but most of the time, using the real 'latest' will
work even better.

IMO complex lifecycle issues require resource-level support (like HTTP has)
built into the protocol. For starters, NETCONF needs to support warnings.
This would allow the server to send deprecation (and other) warnings
and other metadata at the resource level.


Problem with Problem 2)

RFC 7950 is quite clear that extensions MAY be ignored
and the yang-version field determines which specification is used for the
module.
Any tool that supports YANG 1.1 is not expected
to handle module changes that the RFC says MUST NOT be done.

Updating the rules to say that the MUST NOT is replaced with MAY means
that all YANG 1.1 tools MUST support NBC changes.  This is a big change
that should require a new yang-version.

IMO changing the official module update rules is not really needed.
It should be OK for a WG to make an NBC change to a published module,
if the consensus is that this is the least bad solution and better than
starting over with a new identifier, then just document that and allow the
NBC change.

This would be an interim solution until YANG 1.2 is done in the future.



Apart from the updates to RFC 7950 section 11, I am mostly concerned
> about the additional complexity the "pluggable" revision-label scheme
> brings.
>


Agreed.  Why isn't YANG Semver good enough for now?



>
>
>
>
> /martin
>


Andy


>
>
>
>
> "Rob Wilton \(rwilton\)"  wrote:
> > I'm wondering whether we are in the realm of missing the bigger
> > picture here, or perfection being the enemy of good enough.
> >
> > My first example:
> >
> > The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has
> > recently been rechartered to respecify the meaning of the date string
> > in a non-backwards compatible way.  Yes, this same date string format
> > that is very widely implemented and deployed.  I originally had a
> > block on the new charter until it was pointed out that the IETF
> > specification was being updated because it was inconsistent with the
> > ISO time specification and inconsistent with how the date string was
> > actually being used by implementations.  I.e., the specification is
> > being updated to reflect reality.  I.e., fixing the specification in a
> > non-backwards compatible way ends up being pragmatically the right
> > thing to do (and this is entirely allowed by the IETF process).
> >
> > Ideally, the date-and-time typedef in YANG would also be updated to
> > match the update to the definition in RFC 3339 by SEDATE.  But this is
> > clearly not compliant with section 11 of RFC 7950 (because the value
> > space of allowed values is being narrowed).  The only available choice
> > would be to define a new date-and-time-2 typedef which modules could
> > then update to.  Of course, you cannot update the existing leaves to
> > use the new date-and-time-2 typedef because that also violates section
> > 11.  So, you end up with two datetime leaves everywhere the
> > date-and-time typedef is used, hopefully with one deprecated (and at
> > some point, obsoleted).  Of course, defining the new datetime version
> > leaves could also break any loosely related modules that may have
> > xpath expressions dependent on that date-time leaf (that the updating
> > module author may not even know about) which would need to be updated
> > to depend on either of the leaves.  I also don't think that RFC 7950
> > is clear about whether deprecated leaves must be implemented by all
> > implementations or not, so realistically clients will need to handle
> > setting either (or perhaps in some cases, both) of the datetime
> > leaves, depending on implementation, probably with a different mix
> > across modules (in vast stages of being updated).  What happens if
> > some instances of those datetime leaves are mandatory configuration
> > and become obsole

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Mon, Jun 5, 2023 at 5:32 AM Jürgen Schönwälder
 wrote:

> On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> >
> > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next
> design team, asked to produce a limited-scope I-D they think best.
> WG-objections of the form "my pet-issue isn't picked-up" should not be used
> to fail adoption (or, later, the WGLC).  Of course, objections to how the
> specific-issues picked-up were resolved are valid.  The goal being to most
> expediently (<1yr) forward the versioning work in a correct
> (contract-compliant) manner.  Support?
> >
>
> I believe the WG chairs should guide more actively here. Back in a
> day, the IETF used WG charters to define the scope of work items and a
> project to produce lets say YANG 1.2 would have been a WG charter
> update. For the charter update, the WG chairs would organize a
> discussion to agree on the scope of the work. While bureaucratic, I
> believe it was useful to work this way since it helped to get
> agreement on the scope of work.
>
> If the goal is to produce YANG 1.2 which (i) integrates semantic
> versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> does not add any other new features, then having agreement on such a
> statement will help to steer the process. Yes, we will still have to
> sort out what is a bug fix and what is a new feature, but this is
> easier if there is upfront guidance on the scope of the work.
>
> And the second incredient is a dedicated team to work on such a
> project, which ideally brings the major stakeholders together.
>
>
https://github.com/netmod-wg/yang-next/issues

There are 100 issues collected in this list.
Perhaps if people picked their top 3 issues, there might be a chance for
consensus
on some "must have bugfixes".  2 of my issues could actually be solved
without a new language version.
Maybe there are few if any critical bugfixes that require a new language
version to accomplish.

Another option is to drop the Module Updates draft for now and just publish
SemVer,
or just remove all the text that updates RFC 7950.



> /js
>

Andy


>
> --
> Jürgen Schönwälder  Constructor 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen  wrote:

> As an individual contributor and faithful YANG custodian, I cannot
> support work that changes YANG-semantics without versioning YANG itself.
> As Andy wrote before:
>
> The only correct way to remove MUST/MUST NOT from the "YANG contract"
> is to introduce a new YANG language version (1.2), and make a new
> contract.
>
> I want this work to move forward in the form of a quick (limited-scope)
> rfc7950-bis.  One idea would to support just this YANG-next issue
>  and then mark the
> versioning extension as "critical".  That said, I believe that an even
> better versioning-solution can be had if integrated into the YANG-language
> directly.
>


IMO the parsing of YANG files to produce a conceptual data model
is a critical component of the language itself.  Any statements that
affect this conversion step MUST be regular statements.
An extension is (by definition) an external statement that is not part of
the YANG language.
Critical extensions are not a good design choice.  Just add real statements
instead.

IMO most of the yang-next issues are not interesting or valuable,
so a long WG process to go through this entire list is a non-starter.

There are 3 critical changes that need to be made.
  - change "status" so deprecated and obsolete definitions are correct
  - introduce new instance-identifier data type based on RFC 7951 definition
  - introduce new identityref data type based on RFC 7951 definition




> Kent
>


Andy


>
>
> On May 22, 2023, at 6:20 PM, Kent Watsen  wrote:
>
> NETMOD WG,
>
> The chairs are extending this WGLC by two weeks (now ending June 5) in
> order to ensure adequate review, since this is important work, and a solid
> consensus is needed.
>
> Kent and Lou
>
>
>
> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
>
> Dear NETMOD WG,
>
> This message begins a joint two-week WGLC for
> draft-ietf-netmod-yang-semver-11 and
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the
> direct links to the HTML version for these drafts:
>
>  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>  -
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
>
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
>
> Thank you,
> Kent and Lou (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] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[Andy Bierman]

On Thu, Jun 1, 2023 at 1:55 PM Kent Watsen  wrote:

> Hi Quifang,
>
> The latest update looks very good to me - IMO, ready for adoption.
>
> Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been
> addressed?
>
>

IMO the problem statement and solution are still rough and unclear.
The different behavior for each type of node made it even more unclear.

There is a useful improvement to configuration automation here, but it
needs more work.
The problem is that sometimes the server does not allow certain edits to
config=true nodes.
This can cause automated (or manual) edit requests to be rejected by the
server, with no way
for the client to fix the edit request.

The edit operations 'add', 'modify', and 'delete' need more clarification.
There seem to be 3 usage modes that must be supported

-  The server provides the value, and the client does not provide it
-  The client provides a server-approved value that can not change
-  The client picks a value that cannot change

In the example in A.2, any of the 3 modes could apply to a client creating
a new interface entry.

In all cases it seems the intent is to allow the client to create an
immutable node,
but not modify it.  It can only be deleted if a mutable ancestor is being
deleted.

It is not clear how inherited immutable flag values work, especially in
conjunction with NACM.

YumaPro has supported the "user-write" extension for many years for this
purpose.
https://docs.yumaworks.com/en/latest/yangauto/builtin-yang-extensions.html#ncx-user-write
It supports all 3 usage modes above.  IMO the immutable attribute should
support all 3 modes.

I do not understand the purpose of the with-immutable parameter.
The client can just parse the YANG modules from the server and find the
nodes with an immutable field.


Thanks,
> Kent
>
>

Andy


>
>
> On May 25, 2023, at 8:16 AM, maqiufang (A)  40huawei@dmarc.ietf.org> wrote:
>
> Hi, all
> This version reflects the input we've received from the mailing list.
>
> Thank you everyone(Jan, Rob, Kent, Jürgen, Andy, Frank et al.) for your
> great comments and suggestions!
> Please see if the following updates are good for you:
>*  Use a Boolean type for the immutable value in YANG extension and
>   metadata annotation
>*  Define a "with-immutable" parameter and state that immutable
>   metadata annotation is not included in a response unless a client
>   explicitly requests them with a "with-immutable" parameter
>*  reword the abstract and related introduction section to highlight
>   immutable flag is descriptive
>*  Add a new section to define immutability of interior nodes, and
>   merge with "Inheritance of Immutable configuration" section
>*  Add a new section to define what the immutable flag means for each
>   YANG data node
>*  Define the "immutable flag" term.
>*  Add an item in the open issues tracking: Should the "immutable"
>   metadata annotation also be returned for nodes described as
>   immutable in the YANG schema so that there is a single source of
>   truth.
>
> Thanks a lot.
>
> Best Regards,
> Qiufang
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org
> ]
> Sent: Thursday, May 25, 2023 4:52 PM
> To: Balazs Lengyel ; Hongwei Li <
> flycool...@gmail.com>; Qin Wu ; Qin Wu <
> bill...@huawei.com>; maqiufang (A) 
> Subject: New Version Notification for draft-ma-netmod-immutable-flag-07.txt
>
>
> A new version of I-D, draft-ma-netmod-immutable-flag-07.txt
> has been successfully submitted by Qiufang Ma and posted to the IETF
> repository.
>
> Name:  draft-ma-netmod-immutable-flag
> Revision:  07
> Title:  YANG Extension and Metadata Annotation for
> Immutable Flag
> Document date:   2023-05-25
> Group:  Individual Submission
> Pages:   24
> URL:
> https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-ma-netmod-immutable-flag-07
>
> Abstract:
>This document defines a way to formally document existing behavior,
>implemented by servers in production, on the immutability of some
>configuration nodes, using a YANG "extension" and a YANG metadata
>annotation, both called "immutable", which are collectively used to
>flag which data nodes are immutable.
>
>Clients may use "immutable" statements in the YANG, and annotations
>provided by the server, to know beforehand when certain otherwise
>valid configuration requests will cause the server to return an
>error.
>
>The immutable flag is descriptive, documenting existing behavior, not
>proscriptive, dictating server behavior.
>
>
>
>
>
> The IETF Secretariat
>
>
>
> __

Re: [netmod] Query RFC-8348 hardware model

[Andy Bierman]

Hi,

No changes are needed.
The notification definition says each leaf will be set to a value that
matches an instance of the leafref path.

The 'current()' linkage in your example links the sibling 'ifname' leaf to
select a matching instance.
That is not relevant to this notification example.

Andy


On Thu, Jun 1, 2023 at 1:12 PM Kent Watsen  wrote:

> Forwarding to the authors of the RFC.
>
> K.
>
>
> On May 30, 2023, at 3:47 AM, Vanapatla Ramana (Nokia) <
> vanapatla.ram...@nokia.com> wrote:
>
> Hello Team,
>
>
>
> Gentle remainder on the below query.
>
>
>
> Regards,
>
> Ramana
>
>
>
> *From:* Vanapatla Ramana (Nokia)
> *Sent:* Friday, May 5, 2023 8:05 PM
> *To:* draft-ietf-netmod-ent...@ietf.org; netmod@ietf.org
> *Cc:* Bart Bogaert (Nokia) ; Ludwig Pauwels
> (Nokia) ; Yves Beauville (Nokia) <
> yves.beauvi...@nokia.com>
> *Subject:* Query RFC-8348 hardware model
>
>
>
> Hello
>
>
>
> notification ‘hardware-state-oper-enabled’, notification
> ‘hardware-state-oper-disabled’ contains leaf admin-state, alarm-state
>  referring to path "/hardware/component/state/admin-state" ,
> "/hardware/component/state/alarm-state" but not specifying instance of
> hardware component
>
> Should this be changed to "/hardware/component[name =
> current()/../name]/state/admin-state","/hardware/component[name =
> current()/../name]/state/alarm-state" so that it is in-line with the
> notation shown in  RFC7950 examples?
>
>
>
> RFC-8348   Example
>
> notification hardware-state-oper-disabled {
>
> leaf name {
>
> type leafref {
>
>   path "/hardware/component/name";
>
> }
>
> leaf admin-state {
>
> type leafref {
>
>   path "/hardware/component/state/admin-state";
>
> }
>
> leaf alarm-state {
>
> type leafref {
>
>   path "/hardware/component/state/alarm-state";
>
> }
>
> }
>
> RFC7950 indicates to refer instance in page 162, 160
>
> Page 162
>
> The following notification defines two leafrefs to refer to an existing
> admin-status:
>
>  notification link-failure {
>
>leaf if-name {
>
>  type leafref {
>
>path "/interface/name";
>
>  }
>
>}
>
>leaf admin-status {
>
>  type leafref {
>
>path "/interface[name = current()/../if-name]"
>
>   + "/admin-status";
>
>  }
>
>}
>
>
>
> Page 160
>
> The following leafrefs refer to an existing address of an interface:
>
> container default-address {
>
>leaf ifname {
>
>  type leafref {
>
>path "../../interface/name";
>
>  }
>
>}
>
>leaf address {
>
>  type leafref {
>
>path "../../interface[name = current()/../ifname]"
>
>   + "/address/ip";
>
>  }
>
>}
>
> }
>
>
>
> Regards,
>
> Ramana
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, May 31, 2023 at 3:12 AM Andy Bierman  wrote:

>
>
> On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder
>  wrote:
>
>> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
>> > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
>> > >It is unclear what "identical" means here. If two people extract a
>> > >module from an RFC, they may not end up with identical byte
>> > >sequences. So does white space matter when we talk about MUST be
>> > >identical? What about comments? The problem is that the IETF still
>> > >publishes YANG modules in RFCs instead of files.
>> >
>> > As for RFC vs. files, the mechanics of extracting of files from RFCs
>> seems
>> > to be well established, plus it is an IETF-owned cron job which updates
>> > https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I
>> would
>> > (and I actually do) assume that is the normative source of byte-exact
>> files.
>>
>> I have YANG modules that were extracted years ago using some version
>> of smistrip of the past. Do you believe my files extracted back then
>> are byte-by-byte equivalent to what some cron job produces on some
>> github repo somewhere today? Do you guarantee that the software behind
>> the cron job will never ever be updated causing it to produce
>> something where white space may differ?
>>
>>
> The rfcstrip tool has been adding extra '\n' characters to YANG modules
> for years.
> In fact, there is not even one YANG module on a repo somewhere that is a
> byte-exact copy of the RFC version.
>
>
I checked some recent YANG modules, and the extra newline problem has been
fixed.
I am finding a different issue where trailing whitespace in the author's
YANG file on github
is removed from the YangModels repo version.  E.g.
ietf-netconf-server@2023-04-17

This should be a normal non-issue, but the new proposal requires a new
revision date
every time a meaningless space is added or removed from the file. Not sure
what problem
that is trying to solve.


/js
>>
>>
> Andy
>
>
>
>> --
>> Jürgen Schönwälder  Constructor University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 <https://constructor.university/>
>>
>> ___
>> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder
 wrote:

> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> > >It is unclear what "identical" means here. If two people extract a
> > >module from an RFC, they may not end up with identical byte
> > >sequences. So does white space matter when we talk about MUST be
> > >identical? What about comments? The problem is that the IETF still
> > >publishes YANG modules in RFCs instead of files.
> >
> > As for RFC vs. files, the mechanics of extracting of files from RFCs
> seems
> > to be well established, plus it is an IETF-owned cron job which updates
> > https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I
> would
> > (and I actually do) assume that is the normative source of byte-exact
> files.
>
> I have YANG modules that were extracted years ago using some version
> of smistrip of the past. Do you believe my files extracted back then
> are byte-by-byte equivalent to what some cron job produces on some
> github repo somewhere today? Do you guarantee that the software behind
> the cron job will never ever be updated causing it to produce
> something where white space may differ?
>
>
The rfcstrip tool has been adding extra '\n' characters to YANG modules for
years.
In fact, there is not even one YANG module on a repo somewhere that is a
byte-exact copy of the RFC version.

/js
>
>
Andy



> --
> Jürgen Schönwälder  Constructor 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, May 30, 2023 at 5:13 PM Robert Varga  wrote:

> On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> >It is unclear what "identical" means here. If two people extract a
> >module from an RFC, they may not end up with identical byte
> >sequences. So does white space matter when we talk about MUST be
> >identical? What about comments? The problem is that the IETF still
> >publishes YANG modules in RFCs instead of files.
>
> As for RFC vs. files, the mechanics of extracting of files from RFCs
> seems to be well established, plus it is an IETF-owned cron job which
> updates https://github.com/YangModels/yang/tree/main/standard/ietf/RFC
> -- so I would (and I actually do) assume that is the normative source of
> byte-exact files.
>
> In my opinion "identical" leaves little room for interpretation: it is
> byte-exact, i.e. md5sum (and everything else of that kind) returning the
> same value.
>
> If we were to say "equivalent", now that would be a whole another kettle
> of fish.
>
> I stand to be corrected, but I do not believe there is a single
> normative statement about handling equivalent Unicode encodings. As a
> tool author, I believe having that is a hard prerequisite to be solved
> before we ever embark on pulling in YANG semantics into the conversation.
>
> I do have opinions around that, in particular the equivalence of
> - description "foo"
> - description 'foo'
> - description foo
> and the order of preference of those (which may contradict best current
> practice), but I certainly do not have the cycles to engage in that
> discussion to a reasonable depth :(
>
>

There are many ways to maintain semantic equivalence with vastly different
language syntax.
That is a separate issue I think.

As per [RFC7950 ] and [RFC6020
], all published revisions of a
module are given a new unique revision date. This applies even for module
revisions containing (in the module or included submodules) only changes to
any whitespace, formatting, comments or line endings (e.g., DOS vs UNIX).¶


I disagree with this proposed module update rule.
This includes insignificant whitespace that is ignored in the YANG
language.

Your example description-stmt should count as a change since each string
form has different rules.

Changing any characters, even changing the newline (dos2unix) or trimming
trailing whitespace on a line, requires a new module revision.

IMO this is a bad idea since it is too fragile.
E.g., tools might change the end-of-line chars so they are correct
for the operating system used to store the file. Module authors should not
need to
track insignificant whitespace changes that are ignored in YANG.



> Regards,
> Robert
>

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] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, May 16, 2023 at 11:10 AM Robert Varga  wrote:

> On 09/05/2023 00.49, Kent Watsen wrote:
> > Dear NETMOD WG,
> >
> > This message begins a joint two-week WGLC for
> draft-ietf-netmod-yang-semver-11 and
> draft-ietf-netmod-yang-module-versioning-09
> >   ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are
> the direct links to the HTML version for these drafts:
> >
> > -
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
> > -
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> >
> > Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
>
> Hello, I have reviewed the module-versioning draft and overall it looks
> fine (well, aside from the incoming pain :), but we'll cope with that in
> due time).
>
> One concern I have is with
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#name-file-names,
>
> which changes file naming.
>
> Previously the canonical file name included revision -- and now that
> information is lost. While I understand the desire for descriptive
> names, which are a boon for humans, the until the entire ecosystem
> adopts labels, this change is either-or -- and hence tools have to pick
> which metadata is more important: label or revision.
>
> Would it be possible to define a format which contains *both* the label
> and revision, so as not to pick favorites?
>
>

This is an example of an important detail that could be solved differently
if a new YANG language version was used.  In YANG 1.1 the revision-date is
optional.
In YANG 1.2, both the revision-date and label could be mandatory.

It is common practice to release YANG changes in multiple release trains
on the same day.  So the {date, label} is the unique identifier for the
YANG file,
not some combination of optional parts.  IMO the file name you suggest
should
be the mandatory-to-implement canonical file name format for YANG 1.2.

I understand it could be a bad idea to start over with the yang-next list
and "work on YANG 1.2".
IMO there are only a small number of must-haves on that list, and most
issues
could be deferred. YANG 1.2 could be derived from these 2 drafts + a small
number of yang-next issues.

In the current form, I do not agree that the YANG module revision update
rules
should be updated without changing the yang-version value.


Thanks,
> Robert
>


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] Comments on draft-ietf-netmod-yang-module-versioning-09

[Andy Bierman]

On Sat, May 13, 2023 at 12:15 PM Jason Sterne (Nokia) <
jason.ste...@nokia.com> wrote:

> Hi Andy,
>
>
>
> YANG modules are occasionally doing NBC changes today (in the IETF, in
> other standard bodies and in vendor modules). If an old tool/client doesn’t
> recognize the new rev:non-backwards-compatible extension it isn’t any worse
> off than today. But this extension allows YANG 1.1 modules to clearly
> communicate to tools/programmers/etc that an NBC has occurred.
>
>
>

I do not buy the argument that it is OK to change the YANG 1.1 standard
this way
because there are some examples of 7950 violations.  Some NBC changes are
much
more impactful than others and are all being lumped together.

All extensions are optional to implement in YANG 1.1.
A YANG 1.1 tool already deployed (all of them) does not know about these
extensions, even if it tried not to ignore extensions.

The only correct way to remove MUST/MUST NOT from the "YANG contract"
is to introduce a new YANG language version (1.2), and make a new contract.

The versioning, update rules, import/include handling, and lifecycle
features are too important
for interoperability to be left optional, and too important to be
extensions instead
of real statements.

Ironically, the WG seems to understand the importance of proper management
for NBC changes in YANG content, but not the YANG language itself.



Andy





About your last paragraph: The intent of the draft is not to encourage NBC
> changes. In section 3.1 it says the following:
>
> Note that NBC changes often create problems for clients, thus it is
> recommended to avoid making them.¶
>
> Section 7.1 says the following:
>
> NBC changes to YANG modules may cause problems to clients, who are
> consumers of YANG models, and hence YANG module authors SHOULD minimize NBC
> changes and keep changes BC whenever possible.
>
>
>
> When NBC changes are introduced, consideration should be given to the
> impact on clients and YANG module authors SHOULD try to mitigate that
> impact.
>
>
>
> But NBC changes are happening in the industry so at least this lets
> authors indicate it.
>
>
>
> I agree that doing a phased change is best. That’s what we recommend in
> section 7.1.1 (deprecate first, etc) and B.2.
>
>
>
> The module versioning draft also updates that the change from current or
> deprecated to obsolete is NBC. Going “obsolete” is an impact to a client.
>
>
>
> Jason
>
>
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, May 9, 2023 2:06 PM
> *To:* NetMod WG 
> *Subject:* [netmod] Comments on
> draft-ietf-netmod-yang-module-versioning-09
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi,
>
>
>
> Most of the document focuses on the administrative details that will
>
> be required to update a YANG module. (Lots of them).
>
>
>
> My concern is with YANG 1.1 Co-existence and deployment of this new RFC.
> (Sec 3.1)
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#section-3.1
>
>
>
> A client (or another tool) that is compliant with RFC 7950 is
>
> not required to be aware of the new YANG extensions, or expect
>
> NBC changes in new module revisions.  It is not a good idea to
>
> allow NBC changes in a YANG 1.1 module. IMO the new rules
>
> need to apply to a new YANG language version.  It is not reasonable
>
> to expect YANG 1.1 tools to work even if MUST requirements are removed.
>
>
>
> Since YANG 1.1 Co-existence is not possible, vendors will decide
>
> for themselves how much NBC they want in their implementations.
>
> Breaking a YANG 1.1 client tool is still a problem they will have to deal
> with.
>
>
>
> This new RFC could encourage instability and poor engineering practices in
> YANG APIs.
>
> IMO best practice is still to introduce a new identifier and phase out
>
> the old identifier with status=deprecated, then obsolete.
>
> This is how opensource usually works (for good reason).
>
>
>
>
>
> Andy
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Clarify the meaning of property in RFC7950

[Andy Bierman]

Hi,

On Sat, May 13, 2023 at 12:02 PM Jason Sterne (Nokia) <
jason.ste...@nokia.com> wrote:

> Hi Frank,
>
>
>
> The table just after the text has this:
>
>
>
> +--+--+-+
>
>| substatement | section  | cardinality |
>
>+--+--+-+
>
>| config   | 7.21.1   | 0..1|
>
>| default  | 7.6.4, 7.7.4 | 0..n|
>
>| mandatory| 7.6.5| 0..1|
>
>| max-elements | 7.7.6| 0..1|
>
>| min-elements | 7.7.5| 0..1|
>
>| must | 7.5.3| 0..n|
>
>| type | 7.4  | 0..1|
>
>| unique   | 7.8.3| 0..n|
>
>| units| 7.3.3| 0..1|
>
>+--+--+-+
>
>
>
> The deviate's Substatements
>
>
>
> That implies to me (since it says “deviate’s substatements”, not just
> “delete substatements”) that only those items can be added/changed/deleted.
> That table is the list of “properties”.
>
>
>
> But the other part of your question here isn’t so clear to me either.
> Every node does have a config true or false property associated with them
> (either explicitly, by default, or inherited from an ancestor). But does
> that mean it “exists” (from the ‘replace’ paragraph)? Does that mean it
> “matches a corresponding keyword in the targer node (from the ‘delete’
> paragraph)?
>
>
>


IMO libyang is correct.

Maybe the RFC text refers to the actual 'config' statement, and 'property'
is not precise terminology.
Every node has an effective config property so it would never be possible
to "add" a config-stmt, only "replace" it.



> In some ways maybe either add or replace should just work in this case
> since it isn’t really ambiguous what the result should be.
>
>
>

Agreed.
I just checked, and our compiler works this way.
It does the patch for add or replace, whether the node has an existing
config-stmt or not.  (oops),


Jason
>


Andy


>
>
> *From:* netmod  *On Behalf Of *Fengchong (frank)
> *Sent:* Monday, May 8, 2023 2:15 AM
> *To:* netmod@ietf.org
> *Subject:* [netmod] Clarify the meaning of property in RFC7950
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi all,
>
>
>
> In RFC7950 sec *7.20.3.2 
> :*
>
>
>
>The argument "add" adds properties to the target node.  The
>
>properties to add are identified by substatements to the "deviate"
>
>statement.  If a property can only appear once, the property MUST NOT
>
>exist in the target node.
>
>
>
>The argument "replace" replaces properties of the target node.  The
>
>properties to replace are identified by substatements to the
>
>"deviate" statement.  The properties to replace MUST exist in the
>
>target node.
>
>
>
>The argument "delete" deletes properties from the target node.  The
>
>properties to delete are identified by substatements to the "delete"
>
>statement.  The substatement's keyword MUST match a corresponding
>
>keyword in the target node, and the argument's string MUST be equal
>
>to the corresponding keyword's argument string in the target node.
>
>
>
> What’s the meaning of property? Is it a sub-statement?
>
>
>
> I see pyang and libyang have two different explanation. Pyang treat ‘config’ 
> property as always exist property, because ‘config’ statement has default 
> value (true or derived from parent).
>
> But libyang think if there is no ‘config’ sub-statement, then the ‘config’ 
> property will be not exist.
>
>
>
> So there is a conflict when using pyang/libyang to parse YANG module.
>
> For example,
>
> Module a {
>
> Container a {
>
>
>
>Leaf b {
>
>  Type string;
>
>}
>
> }
>
>
>
> }
>
>
>
> Module a-dev {
>
>Deviation  “/a:a/a:b” {
>
>  Deviate add {
>
>Config false;
>
> }
>
>}
>
> }
>
>
>
> This example, pyang will report error, because pyang think ‘config’ property 
> is always exist, so this propery should not be added. But libyang think it’s 
> valid.
>
>
>
> If we change the type of deviate from ‘add’ to ‘replace’.
>
>
>
> Module a-dev {
>
>Deviation  “/a:a/a:b” {
>
>  Deviate replace {
>
>Config false;
>
> }
>
>}
>
> }
>
>
>
> Pyang will think it’s valid. But libyang think it’s invalid.
>
>
>
> So I think WG should clarify what’s the meaning of property.
>
>
>
> Ref:
>
> Issue on pyang: https://github.com/mbj4668/pyang/issues/815
>
>
>
> Issue on libyang: https://github.com/CESNET/libyang/issues/2010
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> netmod mailing

[netmod] Comments on draft-ietf-netmod-yang-module-versioning-09

[Andy Bierman]

Hi,

Most of the document focuses on the administrative details that will
be required to update a YANG module. (Lots of them).

My concern is with YANG 1.1 Co-existence and deployment of this new RFC.
(Sec 3.1)

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#section-3.1

A client (or another tool) that is compliant with RFC 7950 is
not required to be aware of the new YANG extensions, or expect
NBC changes in new module revisions.  It is not a good idea to
allow NBC changes in a YANG 1.1 module. IMO the new rules
need to apply to a new YANG language version.  It is not reasonable
to expect YANG 1.1 tools to work even if MUST requirements are removed.

Since YANG 1.1 Co-existence is not possible, vendors will decide
for themselves how much NBC they want in their implementations.
Breaking a YANG 1.1 client tool is still a problem they will have to deal
with.

This new RFC could encourage instability and poor engineering practices in
YANG APIs.
IMO best practice is still to introduce a new identifier and phase out
the old identifier with status=deprecated, then obsolete.
This is how opensource usually works (for good reason).


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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Andy Bierman]

On Tue, Apr 25, 2023 at 6:15 AM Jürgen Schönwälder
 wrote:

> On Tue, Apr 25, 2023 at 12:46:05PM +, Kent Watsen wrote:
> >
> >
> > > Which merge fails?
> >
> >  +  = 
>
> So far this merge step does not exist (and it may be bad if it would
> exist). The WGs need to think very careful about introducing such a
> step and the consequences.
>
>
I have not seen much real interest in NMDA, except for the 
datastore.

  - retrieval of operational values of configuration data nodes
  - operational context for invoking YANG actions

These are real issues that NMDA solves, in a way that is quite compatible
with non-NMDA deployment.
The additional datastores (intended, system) seem less compatible and more
architectural than practical.

I hope the immutable flag will work with non-NMDA as well as the current
NMDA.

/js
>
>

Andy


> --
> Jürgen Schönwälder  Constructor 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] ietf-yang-types:date-and-time canonical value

[Andy Bierman]

On Mon, Apr 24, 2023 at 7:48 AM Carsten Bormann  wrote:

> On 2023-04-24, at 14:20, Michal Vasko  wrote:
> >
> > canonical
>
> Hi Michal,
>
> I don’t know what exactly “canonical” means here.
>

>From the date-and-time typedef:

  The canonical format for date-and-time values with a known time
  zone uses a numeric time zone offset that is calculated using
  the device's configured known offset to UTC time.  A change of
  the device's offset to UTC time will cause date-and-time values
  to change accordingly.  Such changes might happen periodically
  in case a server follows automatically daylight saving time
  (DST) time zone offset changes.  The canonical format for
  date-and-time values with an unknown time zone (usually
  referring to the notion of local time) uses the time-offset
  -00:00, i.e., date-and-time values must be reported in UTC.";





>
> As a general rule, timestamps used by machines should not use timezones,
> so you should use
>
> 2023-02-22T22:00:00Z
>


Yes -- this is what a NETCONF server is supposed to do I think.

I am not sure how the timezone would be known to the client or configured
on the server.
The server should always store and send date-and-time values in the 'Z'
format.
IMO, even if there is a "configured known offset to UTC time."

Andy



> If there is a use for indicating the timezone offset a particular system
> was in when the timestamp actually occurred, then you might indicate that
> with a timezone offset:
>
> 2023-02-23T11:00:00+13:00
>
> The point in time at which you formatted this datetime is never relevant.
>
> I’m having a hard time imagining when you want to supply this hint at an
> individual timestamp level — I would believe these all should be without
> timezone offsets, i.e., Z.
> Your system information might usefully have timezone information (see also
> below), if timezone is at all relevant to your system.
>
>
> Note that if you have additional information (“hints”) that you want to
> send with the actual timestamp, you probably want to know about SEDATE’s
> IXDTF:
>
> https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html
>
> I don’t know when YANG will pick this up; I don’t know how important these
> hints are in management information (and that my uncertainty applies to
> using the timezone offset defined by RFC 3339 in YANG as well).
>
> Grüße, Carsten
>
> ___
> 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 on node-tags-09

[Andy Bierman]

Hi,

Adding a couple missed comments inline...

On Wed, Apr 19, 2023 at 11:38 AM Andy Bierman  wrote:

>
>
> On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen  wrote:
>
>> This email begins a two-week WGLC on:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>>
>> Please take time to review this draft and post comments by May 2nd.
>> Favorable comments are especially welcomed.
>>
>>
> I have read the latest draft and IMO it needs more work.
>
> 1) metrics
>
> The identities to represent system tags are quite vague.
> There are no specific guidelines for selecting the correct tag.
> There are no references to other RFCs for the metric definitions.
> I would expect IPPM WG to define the classification system, not NETMOD WG.
>
> 2) System tag procedures
>
> There are no procedures defined for YANG model developers.
> Are they supposed to add a node-tag extension to almost every leaf in the
> module?
> The administration and maintenance of node-tags will be a huge burden.
> That was one reason they were not added to the module-tags module in the
> first place.
>
> The YANG extension itself is under-specified since it offers no guidance on
> which YANG statements are allowed to have this extension as a
> sub-statement.
>
>
There is no way to specify the 'type' property using this extension.
There is no way to report this value in  for system entries.
The "standard" tags (e.g. "ietf:loss" have no formal linkage to the
identity 'loss' in the module.
It is not clear what value the 'type' identityref leaf provides at all.

IMO all the metrics (tag type identities) should be removed from this
> document and moved to separate work
> that is properly defined using IPPM metrics.
>
> 3) YANG module issues
>
> - what module entry is used if the node is from a module that augments
> another one?
>I would assume the augmented module not the base module.  Specify which
> one
>
> -  nacm:node-instance-identifier as a list key is complex to implement
>- not sure a canonical representation is possible or required
>- syntax allows notification and action nodes to be tagged. Are these
> allowed in thislist?
>
>

There is no canonical form possible for an instance-identifier.
Yet this module MUST define the procedures for storing and comparing 2
instances of this key leaf.
The draft says RESTCONF is supported.  It should also say that JSON is not
supported
since the instance-identifier data type is used in a configuration data
node.

IMO the instance-identifier encoding in RFC 7951 is a much better choice.
E.g., make a NACM schema-node-identifier typedef based on 7951, not 7950.

BTW, the same problem also exists if a list key is type identityref.
The encoding in 7951 is a better choice here as well.

Sec 4.3:

Any tag with the prefix "user:" is a user tag. Furthermore, any tag
that does not contain a colon
(":", i.e., has no prefix) is also a user tag. Users are not required
to use the "user:" prefix; however,
doing so is RECOMMENDED.


How does this text impact the key leaf 'tag' in the YANG module?
Do the key leaf values "user:foo" and "foo" match or not?
If yes, there needs to be a canonical format . If no, then not a good
design.


Andy

-  it is possible for multiple 'tags' entries to represent the same data
> node instances.
>Figuring out precedence and enforcing masked-tag rules seems
> complicated.
>NACM has ordered by-user semantics.  This module has "all entries at
> once" semantics.
>Not that easy to implement or deploy.
>
> - What if a tag value appears in the masked-tag leaf-list that has the
> same value as the 'tag' key leaf?
>
> - the indentation in the YANG module is wrong for masked-tag
>
> - the list and key naming (tags/tag) is not consistent with other IETF
> modules .
>   Maybe should be list tag and key leaf id.
>
>
>
> Andy
>
>
>
>> This draft went through a WGLC a year ago.  The authors addressed the
>> comments received and have been were waiting for feedback.   In essence,
>> this draft is presumed to reflect WG consensus and thusly, if no objection
>> is received, the draft will move to the next step in the publication
>> process.
>>
>> Ref:
>> https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
>>
>> Kent  // co-chair
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on node-tags-09

[Andy Bierman]

On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen  wrote:

> This email begins a two-week WGLC on:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>
> Please take time to review this draft and post comments by May 2nd.
> Favorable comments are especially welcomed.
>
>
I have read the latest draft and IMO it needs more work.

1) metrics

The identities to represent system tags are quite vague.
There are no specific guidelines for selecting the correct tag.
There are no references to other RFCs for the metric definitions.
I would expect IPPM WG to define the classification system, not NETMOD WG.

2) System tag procedures

There are no procedures defined for YANG model developers.
Are they supposed to add a node-tag extension to almost every leaf in the
module?
The administration and maintenance of node-tags will be a huge burden.
That was one reason they were not added to the module-tags module in the
first place.

The YANG extension itself is under-specified since it offers no guidance on
which YANG statements are allowed to have this extension as a sub-statement.

IMO all the metrics (tag type identities) should be removed from this
document and moved to separate work
that is properly defined using IPPM metrics.

3) YANG module issues

- what module entry is used if the node is from a module that augments
another one?
   I would assume the augmented module not the base module.  Specify which
one

-  nacm:node-instance-identifier as a list key is complex to implement
   - not sure a canonical representation is possible or required
   - syntax allows notification and action nodes to be tagged. Are these
allowed in thislist?

-  it is possible for multiple 'tags' entries to represent the same data
node instances.
   Figuring out precedence and enforcing masked-tag rules seems complicated.
   NACM has ordered by-user semantics.  This module has "all entries at
once" semantics.
   Not that easy to implement or deploy.

- What if a tag value appears in the masked-tag leaf-list that has the same
value as the 'tag' key leaf?

- the indentation in the YANG module is wrong for masked-tag

- the list and key naming (tags/tag) is not consistent with other IETF
modules .
  Maybe should be list tag and key leaf id.



Andy



> This draft went through a WGLC a year ago.  The authors addressed the
> comments received and have been were waiting for feedback.   In essence,
> this draft is presumed to reflect WG consensus and thusly, if no objection
> is received, the draft will move to the next step in the publication
> process.
>
> Ref:
> https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
>
> Kent  // co-chair
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown bits - backwards compatibility

[Andy Bierman]

On Fri, Apr 14, 2023 at 11:45 AM Jürgen Schönwälder
 wrote:

> On Fri, Apr 14, 2023 at 03:23:03PM +, Jason Sterne (Nokia) wrote:
>
> > IETF and vendor models are already doing NBC changes. The versioning
> > work is mostly just adding a way to indicate that to users/clients
> > when it happens.
>
> An industry proposal to replace the versioning rules of a versioned
> data modeling language without bumping the version number of the data
> modeling language makes me wonder whether the industry is ready to
> take versioning rules serious.
>
>
:-)

Adding new requirements to YANG that the major version
number MUST be incremented when making NBC changes,
while making NBC changes to YANG without even bumping the version number.



> /js
>

Andy


> --
> Jürgen Schönwälder  Constructor 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] Unknown bits - backwards compatibility

[Andy Bierman]

On Fri, Apr 14, 2023 at 7:33 AM Italo Busi  wrote:

> Hi Jeff,
>
>
>
> I agree with you on the preference for hex-string versus binary in YANG
>
>
>
> I also agree with you concerns with hexdump, but parsing has some issues
> when something is unknown (these are the issues that have triggered your
> draft and this discussion), although I also agree with you that the unknown
> is for ‘exception cases’
>
>
>
> That’s why I would prefer:
>
>- A YANG leaf of type bits to report known bits (after parsing) which
>will cover “most circumstances”
>- Another YANG leaf of type hex-string for the ‘exception cases’ (or
>for those who really loves hexdump)
>
>
>


Maybe because hexdump is over 20X more efficient on the wire than the bits
proposal.
Or that a special custom typedef is not needed for every leaf to represent
the bit names.
Or that an extra bit-name to bit-position lookup is not required.

The bits type is intended for permanent bit assignments, where
there is semantics associated with each bit (other than an unknown bit N
set).
It is not meant for temporary assignments that change the identifier over
time.

It is possible to change the status of a bit to "obsolete", which seems to
be sufficient
for the unknown-bits use-case.


There is a similar issue when reporting a protocol field representing an
> enumeration. If the received value is known, it would be better to report a
> string/identity name associated with the recived value but when the value
> is unknown it is only possible to report the hexdump of the field
>
>
>
> Italo
>

Andy


>
>
> *From:* Jeffrey Haas 
> *Sent:* venerdì 14 aprile 2023 14:49
> *To:* Italo Busi 
> *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org
> *Subject:* Re: [netmod] Unknown bits - backwards compatibility
>
>
>
> Italo,
>
>
>
>
>
> On Apr 14, 2023, at 4:04 AM, Italo Busi  wrote:
>
>
>
> If the need is to report the value of a received protocol field for
> debugging/troubleshooting purposes, I am wondering why not using a binary
> type instead of a bits type or, better, a YANG leaf of bits type for the
> known bits and another YANG leaf of binary type for all known/unknown bits
>
>
>
> Type binary isn't generically helpful.  The implementation has to do
> something with the base64 stream it gets.  If it's just going to dump it in
> hex format, you might as well just say that and use hex-string.
>
>
>
> The use case here is most bits are known and these are exception cases.
> Ideally in most circumstances, the leaf containing the unknowns is absent.
>
>
>
> Perhaps a bit of personal context:
>
> "Hey, Jeff... why not just get a hexdump of the packet?"
>
> "I've spent 20+ years looking at different tools' dumps of bits of BGP PDU
> and I'm sick of it.  The code knows how to parse out fields, let it do that
> work."
>
>
>
> -- Jeff (who keeps expecting this conversation to devolve to a proposal
> for netconf streaming tcpdump)
>
>
> ___
> 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] Unknown bits - backwards compatibility

[Andy Bierman]

On Fri, Apr 14, 2023 at 8:23 AM Jason Sterne (Nokia) 
wrote:

> IETF and vendor models are already doing NBC changes. The versioning work
> is mostly just adding a way to indicate that to users/clients when it
> happens.
>


Yes. And all such changes are non-conforming.
It is one thing to make an NBC change to fix a mistake.
Quite another to use NBC changes are part of the data model design.


Jason
>

Andy


>
> > -Original Message-
> > From: Jürgen Schönwälder 
> > Sent: Friday, April 14, 2023 2:12 AM
> > To: Andy Bierman 
> > Cc: Jason Sterne (Nokia) ; netmod@ietf.org
> > Subject: Re: [netmod] Unknown bits - backwards compatibility
> >
> >
> > CAUTION: This is an external email. Please be very careful when clicking
> links or
> > opening attachments. See the URL nok.it/ext for additional information.
> >
> >
> >
> > On Thu, Apr 13, 2023 at 02:32:28PM -0700, Andy Bierman wrote:
> > >
> > > I do not see any way to interpret RFC 7950 such that a YANG
> > > extension can be added later to another document that overrides any
> > > normative behavior defined in RFC 7950.
> > >
> > > So as long as a vendor wants to claim conformance to YANG 1.1, no
> > > MUSTs in 7950 can be violated. Period.  That may be harsh, but MUST
> > > and MUST NOT work that way.
> >
> > +1 (even though we may be getting off topic here)
> >
> > /js
> >
> > --
> > Jürgen Schönwälder  Constructor University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 <https://constructor.university/>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown bits - backwards compatibility

[Andy Bierman]

On Thu, Apr 13, 2023 at 2:00 PM Jason Sterne (Nokia) 
wrote:

> Hi Jeff,
>
>
>
> We avoided getting into subtleties about “severity” of an NBC change (hard
> enough to just get agreement on basic rules). But I do think it is useful
> to come up with changes and approaches that have lower impact on
> users/clients even if they are still marked as NBC.
>
>
>
> For the new versioning marking, it would basically be the following. In
> the “revision” statement of the new module:
>
>1. Add "rev:non-backwards-compatible" as per 
> draft-ietf-netmod-yang-module-versioning-08
>- Updated YANG Module Revision Handling
>
> 
>2. Increment the major version of the YANG Semver (i.e. go from 1.0.0
>to 2.0.0) as per draft-ietf-netmod-yang-semver-11 - YANG Semantic
>Versioning
>
>
>
>

I do not see any way to interpret RFC 7950 such that a YANG extension can
be added
later to another document that overrides any normative behavior defined in
RFC 7950.

So as long as a vendor wants to claim conformance to YANG 1.1, no MUSTs in
7950 can
be violated. Period.  That may be harsh, but MUST and MUST NOT work that
way.


That may seem harsh, but we leaned towards being strict on flagging any NBC
> change in order to avoid false-negatives (i.e. false-positives aren’t as
> bad). Users can then diff the module versions, see that only the
> unknown-bits stuff has changed, and then decide if they need to update
> their client, etc.
>
>
>
> Jason
>
>
>


Andy


> *From:* Jeffrey Haas 
> *Sent:* Thursday, April 13, 2023 4:44 PM
> *To:* Jason Sterne (Nokia) 
> *Cc:* netmod@ietf.org
> *Subject:* Re: Unknown bits - backwards compatibility
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Jason,
>
>
>
>
>
> On Apr 13, 2023, at 4:29 PM, Jason Sterne (Nokia) 
> wrote:
>
> *[>>JTS:] Yeah – I see that perspective. But a client using the old
> API/contract gets new/different behavior for the unknown-flags leaf from a
> new server. Hence NBC – unless we decide in the end to somehow make this
> specific case/typedef an exception but I’m not sure about that yet. The
> typedef and behavior you are describing there may still be useful as-is
> even if we decide to still officially consider the change to unknown-flags
> behavior as NBC (i.e. in new the version of the module that changes a bit
> from unknown to known).*
>
>
>
> Understood.  True to form, I seldom seem to come to netmod with easy
> problems. :-)
>
>
>
> Not having read the current versioning material, this would seem to be a
> case where you could consider this NBC, but likely not-problematic.  I'm
> not sure if you have "severity" as a concept in the discussions thus far.
>
>
>
> If there's current verbiage about documenting NBC considerations, feel
> free to point me to the appropriate documents.  As a general purpose
> mechanism, the draft could simply describe that any time an update to the
> known leaf type is done that the unknown leaf type is flagged for NBC for
> the newly assigned bits.
>
>
>
>
>
> I wish to point you and others concerned on these points to the BGP YANG
> modeling for Extended Communities, which will have these problems in a
> different flavor: Known communities will render via the typedefs, unknown
> will render using the prefix 'raw'.  (See typedef bgp-ext-community-type.)
>  This headache is already a consideration in every BGP implementation that
> deals with extended communities in changing meaning.
>
> *[>>JTS:] Can you point me to a repository or RFC where I can see this?
> I’m not familiar with where this YANG work is being done.*
>
>
>
> Sorry for not including the URL.  This document went to WGLC for IDR a few
> days ago.  We'll be asking (yet yet yet again) for YANG doctor review.
>
> https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-16.html
>
>
>
> You'll find the typedef issue for extended communities in there, and also
> the field for unknown bits in the operational state that is the genesis for
> this conversation.
>
>
>
> Figure 4 in draft version -02 shows how the type gets modified to add the
> new bit. The model doesn't change between step 1/ step 2 beyond this.  
> *[>>JTS:]
> Sure – maybe just mention explicitly that the model for unknown-flags stays
> unchanged.*
>
>
>
> If you'd find it helpful, I could add to the text covering Figure 8 "after
> assignment, bit-1 is no longer returned in unknown-flags".  Is that what
> you're looking for?*[>>JTS:] Yes – that would probably help.*
>
>
>
> I'll try to roll in these changes soon. Thanks.
>
>
>
> -- Jeff
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
n

Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt

[Andy Bierman]

On Thu, Apr 13, 2023 at 1:48 PM Jeffrey Haas  wrote:

> Andy,
>
> On Apr 13, 2023, at 4:42 PM, Andy Bierman  wrote:
>
>>
>> Repeating my question to Acee... did you read the draft?  This isn't a
>> theoretical use case.
>>
>
> Seeing no response, I'll assume "no".
>
> And yet, here you are stating an opinion.
>>
>> My opinion on this matter stems from the use case being mostly known and
>> assigned bits and a small number of unknown bits and a desire to not to
>> have to make my model users go fishing for the exceptions.
>>
>
>
> The typedef provides no semantics other than which bits are set in a bit
> string.
>
>
> For the unknown case.  The semantic is implied by the leaf.
>


In all cases this is true.


>
> There are other ways to do that and all of them are valid usage of YANG.
> I do not see how either encoding above requires "fishing" any more than
> the other.
>
>
> And thus ceteris paribus... you have no objections to this mechanism?
>

I do not support adoption or oppose adoption.
Identification of arbitrary bits in a bit-string is a solved problem -- but
not using YANG bits type.
If people want that solution then they will be happy to have this new
typedef.




>
>> And yet, we're here because the current design of YANG doesn't handle
>> this unknown case well.
>>
>>
> Changing the identifier breaks XML and JSON encoding of bits, so that is
> why it says MUST NOT do this in RFC 7950.
>
>
> The known leaf and unknown leaf do not change names.
> The unknown leaf does not change type.
> The known leaf's type is maintained according to current YANG versioning
> rules.  No on the wire behaviors are broken.
>
> Whether the semantic of a previously displayed unknown bit switching to a
> known bit is a non-backward compatible change is a reasonable debate.  I
> suggest you offer an opinion in Jason's thread on that matter.
>
>
The identifier is used on the wire.
Changing it for a given leaf in a new module revision is not allowed.

I guess I misunderstood that the bit identifier would change once it is
known.
e.g.  bit-3 is changed to some other string.  If the bit identifiers never
change
then there is no problem.




> -- Jeff
>

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