Kent,
> On Jun 28, 2023, at 4:25 PM, Kent Watsen <[email protected]> wrote: > I’ve been hoping you would reply to some of the comments here before kicking > off the WGLC. I hadn’t realized that your intent was to skip directly to WGLC, unless this was a typo. Most WG process I deal with goes through at least a thin adoption stage even if the intent is to move forward swiftly to last call. > 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. As Jason notes in his reply, I’m unclear what YANG library may do to help this situation. I’m certainly fine adding an additional section to the draft discussing that unknown bits may “disappear” during maintenance as previously unknown bits become defined. > > 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.”; > I’m fine making this change. — Jeff > Thoughts? > > K. > > > >> On May 23, 2023, at 11:59 AM, Rob Wilton (rwilton) >> <[email protected]> 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-<x>" >> 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 <[email protected]> On Behalf Of Italo Busi >> Sent: 14 April 2023 09:05 >> To: Jason Sterne (Nokia) <[email protected]>; Jeffrey Haas >> <[email protected]>; [email protected] >> 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) <[email protected]> >> Sent: mercoledì 12 aprile 2023 23:26 >> To: Jason Sterne (Nokia) <[email protected]>; Jeffrey Haas >> <[email protected]>; [email protected] >> 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 <[email protected]> On Behalf Of Jason Sterne (Nokia) >> Sent: Wednesday, April 12, 2023 5:24 PM >> To: Jeffrey Haas <[email protected]>; [email protected] >> 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 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 <[email protected]> On Behalf Of Jeffrey Haas >> Sent: Monday, April 10, 2023 2:48 PM >> To: [email protected] >> 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. Seehttp://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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
