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] Unknown bits - backwards compatibility

Jason, > On Apr 13, 2023, at 5:25 PM, Jason Sterne (Nokia) > wrote: > In the Schema Comparison draft we’re also debating whether to add “per node” > compatibility tags (optional – use when needed, and this is a case where it > is useful to flag a particular *node* as having an NBC change in

Re: [netmod] YANG model for BGP extended communities

> On Apr 13, 2023, at 5:16 PM, Jason Sterne (Nokia) > wrote: > > Hi Jeff, > > I’m branching off a separate thread for the extended communities discussion. > Is this a good one from the draft for discussion? It is, thanks. Since this is an item we want significant scrutiny on in the

Re: [netmod] Unknown bits - backwards compatibility

On Thu, Apr 13, 2023 at 2:00 PM Jason Sterne (Nokia) wrote: > Hi Jeff, > > > > We avoided getting into subtleties about “severity” of an NBC change (hard > enough to just get agreement on basic rules). But I do think it is useful > to come up with changes and approaches that have lower impact on

Re: [netmod] Unknown bits - backwards compatibility

Hi Jeff, You are absolutely right that this is a tricky case for identifying the specific affected node. I should have mentioned how to do that. Basically in this case, the “description” field of the unknown-flags leaf should really change each time there are newly unreported bit-0, bit-1, etc

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] Unknown bits - backwards compatibility

Jason, > On Apr 13, 2023, at 5:00 PM, Jason Sterne (Nokia) > wrote: > > Hi Jeff, > > We avoided getting into subtleties about “severity” of an NBC change (hard > enough to just get agreement on basic rules). But I do think it is useful to > come up with changes and approaches that have

[netmod] YANG model for BGP extended communities

Hi Jeff, I’m branching off a separate thread for the extended communities discussion. Is this a good one from the draft for discussion? /* BGP Extended Community Types. */ typedef bgp-ext-community-type { type union { type string { pattern

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] Unknown bits - backwards compatibility

Hi Jeff, We avoided getting into subtleties about “severity” of an NBC change (hard enough to just get agreement on basic rules). But I do think it is useful to come up with changes and approaches that have lower impact on users/clients even if they are still marked as NBC. For the new

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] Unknown bits - backwards compatibility

Jason, > On Apr 13, 2023, at 4:29 PM, Jason Sterne (Nokia) > wrote: > [>>JTS:] Yeah – I see that perspective. But a client using the old > API/contract gets new/different behavior for the unknown-flags leaf from a > new server. Hence NBC – unless we decide in the end to somehow make this >

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] Unknown bits - backwards compatibility

Hi Jeff, Please see inline. Jason From: Jeffrey Haas Sent: Thursday, April 13, 2023 4:03 PM To: Jason Sterne (Nokia) Cc: netmod@ietf.org Subject: Re: Unknown bits - backwards compatibility CAUTION: This is an external email. Please be very careful when clicking links or opening attachments.

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] Unknown bits - backwards compatibility

Jason, > On Apr 12, 2023, at 5:26 PM, Jason Sterne (Nokia) > wrote: > > 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

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