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

Jeff, > On Apr 13, 2023, at 15:36, Jeffrey Haas wrote: > > Acee, > > >> On Apr 13, 2023, at 9:57 AM, Acee Lindem wrote: >>> I unclear on the "ease of use" gained by using YANG bits to define bit >>> positions. >>> IMO is would be much easier to use a protocol-specific leaf if you want to

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

Andy, > On Apr 13, 2023, at 5:06 PM, Andy Bierman wrote: > > 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. I certainly wished it worked this way.

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

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

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

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

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

On Thu, Apr 13, 2023 at 1:27 PM Jeffrey Haas wrote: > > > On Apr 13, 2023, at 3:59 PM, Andy Bierman wrote: > It is somewhat strange to model "unknown-bits" as if it was a property of > the data model. > Protocols generally have version detection or rules (e.g. receiver MUST > ignore reserved

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

> On Apr 13, 2023, at 3:59 PM, Andy Bierman wrote: > It is somewhat strange to model "unknown-bits" as if it was a property of the > data model. > Protocols generally have version detection or rules (e.g. receiver MUST > ignore reserved bits). Repeating my question to Acee... did you read

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

On Thu, Apr 13, 2023 at 12:17 PM Jeffrey Haas wrote: > Andy, > > > > On Apr 12, 2023, at 1:27 PM, Andy Bierman wrote: > > I unclear on the "ease of use" gained by using YANG bits to define bit > positions. > > IMO is would be much easier to use a protocol-specific leaf if you want > to debug >

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

Acee, > On Apr 13, 2023, at 9:57 AM, Acee Lindem wrote: >> I unclear on the "ease of use" gained by using YANG bits to define bit >> positions. >> IMO is would be much easier to use a protocol-specific leaf if you want to >> debug >> a specific protocol. An operational leaf like

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

> On Apr 13, 2023, at 9:51 AM, Kent Watsen wrote: > > >> I agree. If we end up with "yang-next" as I've heard it called, this would >> be a useful case to resolve. >> >> If we ended up with such a thing, it'd be nice to simply deprecate the >> "unknown" leaves, upgrade the type from

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

Andy, > On Apr 12, 2023, at 1:27 PM, Andy Bierman wrote: > I unclear on the "ease of use" gained by using YANG bits to define bit > positions. > IMO is would be much easier to use a protocol-specific leaf if you want to > debug > a specific protocol. An operational leaf like "raw-foo-field"

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

Tom, I'm choosing to reply to this mail rather than your previous one since it covers the relevant point. > On Apr 13, 2023, at 6:05 AM, tom petch wrote: >> With bits, if bit position 3 is "foo", you always know that foo is >> bit-position 3. > > > No you do not. The protocol may define

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

> On Apr 12, 2023, at 13:27, Andy Bierman wrote: > > > > On Wed, Apr 12, 2023 at 10:04 AM Jeffrey Haas > wrote: >> Tom, >> >> >> > On Apr 12, 2023, at 12:44 PM, tom petch > > > wrote: >> >> The reason to disconsider it is that within the

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

> I agree. If we end up with "yang-next" as I've heard it called, this would > be a useful case to resolve. > > If we ended up with such a thing, it'd be nice to simply deprecate the > "unknown" leaves, upgrade the type from "bits" to "bits-with-unknown" (or > similar) and work from there. >

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

From: Jeffrey Haas Sent: 12 April 2023 18:04 Tom, > On Apr 12, 2023, at 12:44 PM, tom petch wrote: >> The reason to disconsider it is that within the same leaf, the value >> "changes meaning" once you end up with the new identity for the value when >> it's assigned and then end up with an

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

On Wed, Apr 12, 2023 at 10:04 AM Jeffrey Haas wrote: > Tom, > > > > On Apr 12, 2023, at 12:44 PM, tom petch wrote: > >> The reason to disconsider it is that within the same leaf, the value > "changes meaning" once you end up with the new identity for the value when > it's assigned and then end

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

Tom, > On Apr 12, 2023, at 12:44 PM, tom petch wrote: >> The reason to disconsider it is that within the same leaf, the value >> "changes meaning" once you end up with the new identity for the value when >> it's assigned and then end up with an orphaned identity. Implementations >> looking

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

From: netmod on behalf of Jeffrey Haas Sent: 12 April 2023 15:39 Acee, > On Apr 12, 2023, at 10:33 AM, Acee Lindem wrote: > 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

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

Acee, > On Apr 12, 2023, at 10:33 AM, Acee Lindem wrote: > 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 >

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

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

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

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

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

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