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 On Behalf Of Jason
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
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
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
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
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
>
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
