Hi Jeff, 

So the way you offer backward compatibility is that each bit-encoded field 
would have two leaves, one for the known bits and one for the unknown. Then 
when a bit is defined and supported by a YANG model implementation,  the known 
flags could be augmented and the corresponding unknown bit would just no longer 
be returned by the implementation. Correct? 

Another way to do the same thing and avoid the duplication of the leaves would 
be to use identities with the bit position encoded in the identity identifier. 
Of course, this would require defining the identities for the unknown bits for 
each base identity corresponding to a bit encoded field.

In either case, it would be better to have a construct in the YANG syntax which 
allows changing the definition of a bit to be a backward-compatible change. 
Even more obvious, adding a new enum should be allowed as backward-compatible 
change but I digress and this wouldn’t help us for our current models. 

Thanks,
Acee

> On Apr 10, 2023, at 14:48, Jeffrey Haas <jh...@pfrc.org> wrote:
> 
> Netmod Working Group,
> 
> The presentation at IETF 116 on the YANG unknown bits typedef seemed to be 
> positively received.
> 
> I've updated the draft in version -02 to incorporate a hallway suggestion 
> (from Rob, I think?) to rename the bits from a pattern of "unknown-N" to 
> "bit-N".  Please find the information for the updated draft pasted below my 
> original request for adoption.
> 
> Having given my presentation and seeing there seems to be interest in the 
> work, could we consider adoption?
> 
> -- Jeff
> 
> 
> 
> 
>> On Feb 20, 2023, at 1:23 PM, Jeffrey Haas <jh...@pfrc.org 
>> <mailto:jh...@pfrc.org>> wrote:
>> 
>> The current version of this small draft has addressed the discussion points 
>> to date.
>> 
>> I'd like to request that the netmod WG consider adopting this draft.  
>> Alternatively, if it's thought useful but more appropriate to carry this 
>> work on elsewhere (e.g. rtgwg), I'd appreciate such feedback.
>> 
>> For the process folk, I am unaware of any applicable IPR covering this draft.
>> 
>> -- Jeff
>> 
> 
> Name:         draft-haas-netmod-unknown-bits
> Revision:     02
> Title:                Representing Unknown YANG bits in Operational State
> Document date:        2023-04-10
> Group:                Individual Submission
> Pages:                18
> URL:            
> https://www.ietf.org/archive/id/draft-haas-netmod-unknown-bits-02.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/
> Html:           
> https://www.ietf.org/archive/id/draft-haas-netmod-unknown-bits-02.html
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-haas-netmod-unknown-bits
> Diff:           
> https://author-tools.ietf.org/iddiff?url2=draft-haas-netmod-unknown-bits-02
> 
> Abstract:
>   Protocols frequently have fields where the contents are a series of
>   bits that have specific meaning.  When modeling operational state for
>   such protocols in YANG, the 'bits' YANG built-in type is a natural
>   method for modeling such fields.  The YANG 'bits' built-in type is
>   best suited when the meaning of a bit assignment is clear.
> 
>   When bits that are currently RESERVED or otherwise unassigned by the
>   protocol are received, being able to model them is necessary in YANG
>   operational models.  This cannot be done using the YANG 'bits' built-
>   in type without assigning them a name.  However, YANG versioning
>   rules do not permit renaming of named bits.
> 
>   This draft proposes a methodology to represent unknown bits in YANG
>   operational models and creates a YANG typedef to assist in uniformly
>   naming such unknown bits.
> _______________________________________________
> 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

Reply via email to