Re: [netmod] Unknown bits - backwards compatibility

[Jason Sterne (Nokia)]

I’m not sure how the concerns about non-backwards-compatibility are addressed 
by YANG library. Both Rob and I were proposing that one potential solution is 
to always send all the bits in the 2nd leaf (even after they become “known 
bits” in the first leaf).

From: Kent Watsen 
Sent: Wednesday, June 28, 2023 4:25 PM
To: Jeffrey Haas 
Cc: Rob Wilton (rwilton) ; Italo Busi 
; 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.


Hi Jeff,

I’ve been hoping you would reply to some of the comments here before kicking 
off the WGLC.  Specifically, I’m wondering if it makes sense to add a new 
section to provide guidance to implementors?   I’m unsure myself, as the 
concerns raised seem to be addressed by YANG Library, in that clients should 
use it to detect if the server is using a newer revision of modules than the 
client groks.

One new comment: the "unknown-bits” typedef's description statement seems 
unclear in terms of the expected reconciliation process.


Current:



  "Typedef describing 64 bits worth of unknown bits.  This can be

   used to model operational state that would normally be modeled

   using the YANG 'bits' type, but no registered bit has been

   created.”;



Proposed:



  "Typedef describing 64 bits worth of unknown bits.  This can be

   used to model operational state that would normally be modeled

   using the YANG 'bits' type, but no registered bit has been

   defined in the YANG module implemented by the server.”;



Thoughts?


K.




On May 23, 2023, at 11:59 AM, Rob Wilton (rwilton) 
mailto:rwilton=40cisco@dmarc.ietf.org>> 
wrote:

I was looking at this draft again, and since I had read the -02 version of the 
draft I thought that I would send the comments here.


My no hats view here (looking at the latest draft) is:

  *   documenting something here is probably helpful because this is an issue 
that folks are experiencing and providing written guidance on how to handle it 
helpful to the YANG modelling community.
  *   having such a document update RFC 8407 would probably be helpful (to help 
YANG authors find it),
  *   but I’m concerned that the proposed solution is not backwards compatible 
at the instance data level.  E.g., an old client talking to a new server would 
still hit a problem if the server changed from sending an unknown "bit-" to 
a known bit (defined in a backards-compatible module update), and if the old 
client doesn't know/understand the now known bit (because they are still coded 
against the older module version), then the client may break.  This makes me 
think that there is going to be some subtleties around when it is safe to not 
send an unknown bit, hence my suggestion was to call it just “bits” (which is 
already in -02) and *always sending* this leaf may be a more backwards 
compatible choice.  It isn’t clear to me, for the “all bits” leaf, whether 
sending this as a raw uint8 – uint64, or binary, and doing the decode on the 
client side (if required) might be a better choice than sending them as a 
generic bits type.


Regards,
Rob

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Italo Busi
Sent: 14 April 2023 09:05
To: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>; Jeffrey Haas 
mailto:jh...@pfrc.org>>; netmod@ietf.org
Subject: Re: [netmod] Unknown bits - backwards compatibility

Jason, Jeffrey,

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

Trailing zeros can be added when the protocol field is not an integer number of 
octets

In this way there will be no backward compatibility issues when unknown bits 
are assigned and becomes known

My 2 cents

Italo

From: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>
Sent: mercoledì 12 aprile 2023 23:26
To: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>; Jeffrey Haas 
mailto:jh...@pfrc.org>>; netmod@ietf.org
Subject: Re: [netmod] Unknown bits - backwards compatibility

It just occurred to me that to avoid the NBC change we could also consider just 
calling this new typedef “raw-bits” and always outputting all the bits in the 
second leaf (whether they are known or not)?  I suspect this was already 
considered though…

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Jason Sterne (Nokia)
Sent: Wednesday, April 12, 2023 5:24 PM
To: Jeffrey Haas mailto:jh...@pfrc.org>>; 
netmod@ietf.org
Subject: [netmod] Unknown bits - backwards compatibility

Hi Jeff,

One topic that came up during the IETF 116 

Re: [netmod] Unknown bits - backwards compatibility

[Kent Watsen]

Hi Jeff,

I’ve been hoping you would reply to some of the comments here before kicking 
off the WGLC.  Specifically, I’m wondering if it makes sense to add a new 
section to provide guidance to implementors?   I’m unsure myself, as the 
concerns raised seem to be addressed by YANG Library, in that clients should 
use it to detect if the server is using a newer revision of modules than the 
client groks.

One new comment: the "unknown-bits” typedef's description statement seems 
unclear in terms of the expected reconciliation process.

Current:

  "Typedef describing 64 bits worth of unknown bits.  This can be
   used to model operational state that would normally be modeled
   using the YANG 'bits' type, but no registered bit has been
   created.”;

Proposed:

  "Typedef describing 64 bits worth of unknown bits.  This can be
   used to model operational state that would normally be modeled
   using the YANG 'bits' type, but no registered bit has been
   defined in the YANG module implemented by the server.”;

Thoughts?

K.



> On May 23, 2023, at 11:59 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> I was looking at this draft again, and since I had read the -02 version of 
> the draft I thought that I would send the comments here.
> 
> My no hats view here (looking at the latest draft) is:
> documenting something here is probably helpful because this is an issue that 
> folks are experiencing and providing written guidance on how to handle it 
> helpful to the YANG modelling community.
> having such a document update RFC 8407 would probably be helpful (to help 
> YANG authors find it),
> but I’m concerned that the proposed solution is not backwards compatible at 
> the instance data level.  E.g., an old client talking to a new server would 
> still hit a problem if the server changed from sending an unknown "bit-" 
> to a known bit (defined in a backards-compatible module update), and if the 
> old client doesn't know/understand the now known bit (because they are still 
> coded against the older module version), then the client may break.  This 
> makes me think that there is going to be some subtleties around when it is 
> safe to not send an unknown bit, hence my suggestion was to call it just 
> “bits” (which is already in -02) and *always sending* this leaf may be a more 
> backwards compatible choice.  It isn’t clear to me, for the “all bits” leaf, 
> whether sending this as a raw uint8 – uint64, or binary, and doing the decode 
> on the client side (if required) might be a better choice than sending them 
> as a generic bits type.
> 
> Regards,
> Rob
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Italo Busi
> Sent: 14 April 2023 09:05
> To: Jason Sterne (Nokia)  >; Jeffrey Haas  >; netmod@ietf.org 
> Subject: Re: [netmod] Unknown bits - backwards compatibility
>  
> Jason, Jeffrey,
>  
> 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
>  
> Trailing zeros can be added when the protocol field is not an integer number 
> of octets
>  
> In this way there will be no backward compatibility issues when unknown bits 
> are assigned and becomes known
>  
> My 2 cents
>  
> Italo
>  
> From: Jason Sterne (Nokia)  > 
> Sent: mercoledì 12 aprile 2023 23:26
> To: Jason Sterne (Nokia)  >; Jeffrey Haas  >; netmod@ietf.org 
> Subject: Re: [netmod] Unknown bits - backwards compatibility
>  
> It just occurred to me that to avoid the NBC change we could also consider 
> just calling this new typedef “raw-bits” and always outputting all the bits 
> in the second leaf (whether they are known or not)?  I suspect this was 
> already considered though…
>  
> Jason
>  
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Jason Sterne (Nokia)
> Sent: Wednesday, April 12, 2023 5:24 PM
> To: Jeffrey Haas mailto:jh...@pfrc.org>>; netmod@ietf.org 
> 
> Subject: [netmod] Unknown bits - backwards compatibility
>  
> Hi Jeff,
>  
> One topic that came up during the IETF 116 NETMOD meeting was backwards 
> compatibility.
>  
> From what I understand, a leaf (e.g. unknown-flags) that uses the 
> unknown-bits typedef would never change its definition in YANG. It would 
> always be defined as unknown-bits with all 64 bit definitions even as more 
> and more bits become “known”.  *But* the system would suddenly stop reporting 
> bit-0, then bit-1 in that unknown-flags leaf as those bits become known.
>  
> Strictly speaking, that should probably be considered an NBC change although 
> it is a bit of a grey zone - the NBC 

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

[Adrian Farrel]

Thanks Qin,

In line...

Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity
node-tag-type to capture the variants defined in the IANA registry shown in
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of
introducing
node-tag-type identities is to address Jurgen's comment and try to make the
node tag mechanism 
generic enough and allow future extension, we did provide an example in
Appendix A which allow you add additional Auxiliary Data Property in the
module extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA
registry, but 
node-tag-type identities will not be registered together with IETF YANG Data
Node Tags. Secondly, we did use tag as a string, we choose to use the same
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it
doesn't allow any future module extension.
2. we keep some of these identities for second level data node
classification, e.g., summary, counter, gauge, unknown, etc but remove
packet loss ,jitter ,delay identities from this draft since it seems to
 duplicate with what has already been defined in IANA registry, in addition,
we remove some of IETF yang data node tags including summary, counter, gauge
and unknown, which is redundant with identities
 for second level data node classification.

[AF] I support the motivation. I would like the node tag mechanism to be
extensible.
I didn't notice the purpose of Appendix A (perhaps it could use a little
more explanation?).
I think your option 1 would only work if we move the identities to a new
module (possibly under IANA control - my option 3)
Your option 2 looks worthy of consideration, but it is a big change at this
stage in the process - I don't want to cause disruption to the WG process as
I am not an implementer of this technology.
I wonder whether my options 1 and 2 wouldn't be simpler.

--

I think that Section 1, in introducing the concept of tags, should spend a
sentence describing YANG Module Tags [RFC8819] so that we can see how the
YANG tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1
as follows:
"
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
"

[AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just
wondered about a quick description of what it does.
But I don't insist on this change.

--

Apart from being able to deduce it from Section 4.3, it is not absolutely
clear from Section 4 that the colon has special meaning. That is that all
prefixes now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish
an non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg the question about separators in the
  prefixes and in the tag values
  - Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
  - Tag values (after the prefix) that contain colons may cause 
confusion so you should probably make this a RECOMMENDation, 
although 4.2 suggests the use of colons as further separators.

An alternative to all this is that you define the colon as the separator,
and change the tag names to not include colons.

But 9.1 makes it pretty clear that you expect all registered prefixes to end
with a colon.

[Qin Wu] That's really a good comment, so Tag = Tag prefix+ Tag Value,
Colon is part of Tag prefix if you expect all registered prefix to end with
a colon.
The question is whether we see colon as separator or portion of the tag
prefix.
Do we need to make tag prefix is mandatory to have for a tag?

[AF] I don't really mind.
The closest to what you have is...

[netmod] Call for IETF 117 Slot Requests

[Kent Watsen]

NETMOD WG,

The *draft* agenda for IETF117 has been posted
- https://datatracker.ietf.org/meeting/117/agenda

The NETMOD session information is scheduled to be held:

Wednesday, July 26, 2023
09:30-11:30 Tuesday Session I
Room: Continental 6
https://datatracker.ietf.org/meeting/117/sessions/netmod.ics

This will be an in-person meeting with remote participation access.

Please send slot requests to netmod-cha...@ietf.org 
 (CC-ed) before the end of the day Monday July 
10 (any TZ, but earlier is appreciated).  Please include draft names(s), 
presenter, desired slot length.  Also, please let us know if you think the 
topic would be better covered in a Virtual Interim to be held at a future date.

Thank you!

Kent (and Lou)



Important dates  (https://datatracker.ietf.org/meeting/important-dates):

2023-06-30  Fri Final agenda to be published.
2023-07-10  Mon Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D Submission 
Tool.
2023-07-12  Wed Draft Working Group agendas due by UTC 23:59. 
Upload using the Meeting Materials Management Tool.
2023-07-17  Mon Revised Working Group agendas due by UTC 23:59. 
Upload using the Meeting Materials Management Tool.

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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt

[Joe Clarke (jclarke)]

Tom, you’re arguing our case.  The requirements specifically state that modules 
do and need to be updated sometimes in NBC ways.  The idea of this work is not 
to make perfection the enemy of good.

Joe

From: tom petch 
Date: Wednesday, June 28, 2023 at 08:01
To: Joe Clarke (jclarke) , Benoit Claise 
, Joe Clarke (jclarke) 
, netmod@ietf.org 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
From: Joe Clarke (jclarke) 
Sent: 27 June 2023 14:19

Yes, I had pushed for this.  I think it would have help better frame this work 
given how long it is taking.


Yes but had the then I-D been put forward as WGLC, I would have opposed it.  I 
think that the I-D overstates the case.  Modules have been and do get updated 
and the idea of having perfection on day is like a frictionless surface, a 
useful theoretical concept but not one any engineer expects to create.

Tom Petch

Joe

From: netmod  on behalf of Benoit Claise 

Date: Monday, June 26, 2023 at 12:21
To: tom petch , Joe Clarke (jclarke) 
, netmod@ietf.org 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
Dear all,

I am generically not in favor of publishing requirement documents.
However, it might have proven beneficial in this particular case.

Regards, Benoit

On 6/26/2023 6:02 PM, tom petch wrote:
> From: netmod  on behalf of Joe Clarke (jclarke) 
> 
> Sent: 26 June 2023 16:53
>
> This revision is a resurrection of the expired I-D to help frame the LC 
> discussions around module versioning and YANG Semver.
>
> 
> Joe
>
> Thank you for that
>
> Tom Petch
>
>
> Joe
>
> From: netmod  on behalf of internet-dra...@ietf.org 
> 
> Date: Monday, June 26, 2023 at 11:49
> To: i-d-annou...@ietf.org 
> Cc: netmod@ietf.org 
> Subject: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Network Modeling
> (NETMOD) WG of the IETF.
>
> Title   : YANG Module Versioning Requirements
> Author  : Joe Clarke
> Filename: draft-ietf-netmod-yang-versioning-reqs-08.txt
> Pages   : 12
> Date: 2023-06-26
>
> Abstract:
> This document describes the problems that can arise because of the
> YANG language module update rules, that require all updates to YANG
> module preserve strict backwards compatibility.  It also defines the
> requirements on any solution designed to solve the stated problems.
> This document does not consider possible solutions, nor endorse any
> particular solution.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-08
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-versioning-reqs-08
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
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] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt

[tom petch]

From: Joe Clarke (jclarke) 
Sent: 27 June 2023 14:19

Yes, I had pushed for this.  I think it would have help better frame this work 
given how long it is taking.


Yes but had the then I-D been put forward as WGLC, I would have opposed it.  I 
think that the I-D overstates the case.  Modules have been and do get updated 
and the idea of having perfection on day is like a frictionless surface, a 
useful theoretical concept but not one any engineer expects to create.

Tom Petch

Joe

From: netmod  on behalf of Benoit Claise 

Date: Monday, June 26, 2023 at 12:21
To: tom petch , Joe Clarke (jclarke) 
, netmod@ietf.org 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
Dear all,

I am generically not in favor of publishing requirement documents.
However, it might have proven beneficial in this particular case.

Regards, Benoit

On 6/26/2023 6:02 PM, tom petch wrote:
> From: netmod  on behalf of Joe Clarke (jclarke) 
> 
> Sent: 26 June 2023 16:53
>
> This revision is a resurrection of the expired I-D to help frame the LC 
> discussions around module versioning and YANG Semver.
>
> 
> Joe
>
> Thank you for that
>
> Tom Petch
>
>
> Joe
>
> From: netmod  on behalf of internet-dra...@ietf.org 
> 
> Date: Monday, June 26, 2023 at 11:49
> To: i-d-annou...@ietf.org 
> Cc: netmod@ietf.org 
> Subject: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Network Modeling
> (NETMOD) WG of the IETF.
>
> Title   : YANG Module Versioning Requirements
> Author  : Joe Clarke
> Filename: draft-ietf-netmod-yang-versioning-reqs-08.txt
> Pages   : 12
> Date: 2023-06-26
>
> Abstract:
> This document describes the problems that can arise because of the
> YANG language module update rules, that require all updates to YANG
> module preserve strict backwards compatibility.  It also defines the
> requirements on any solution designed to solve the stated problems.
> This document does not consider possible solutions, nor endorse any
> particular solution.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-08
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-versioning-reqs-08
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
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