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 rules for state are fuzzy (theoretically they are defined by RFC7950 but it is clear those rules were focused on config, and the same goes for all our new versioning work). But I could imagine an implementation that was previously seeing bit-0 returned and suddenly stops seeing that bit-0 returned (which could cause different interpretation/behavior). So in some ways the semantics of the unknown-flags leaf has changed. It may be better to just flag this as an NBC change so a user would be drawn to look at it, and make a decision that they do or don't have to update their handling/use of it? The known flags leaf would only go through backwards compatible changes though (since we'd always be additive in adding bits) - assuming bit positions don't change in the protocol. It would probably help to show an example of what a YANG module looks like for step 1 and then step 2 (an unknown becomes known), and also what is returned in NETCONF in step 1 and step 2. You partially have that in section 3.2 although the YANG model isn't shown and it might be good to explicitly mention that <unknown-flags> isn't returned (note it may also be valid to return <unknown-flags></unknown-flags>). Jason From: netmod <netmod-boun...@ietf.org> On Behalf Of Jeffrey Haas Sent: Monday, April 10, 2023 2:48 PM To: netmod@ietf.org Subject: Re: [netmod] Request for WG adoption, draft-haas-netmod-unknown-bits-01.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext for additional information. 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
