Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Acee Lindem]

> On Sep 5, 2023, at 16:25, Jeffrey Haas  wrote:
> 
> Acee,
> 
> 
>> On Sep 5, 2023, at 12:42 PM, Acee Lindem  wrote:
>> 
>> What I’d thought about for this requirement is an optional read-only leaf 
>> containing the hex representation of only the unknown bits. This would be 
>> simpler to model and would be fully backward compatible. 
>> 
>> For example:
>> 
>>   leaf unknown-flags {
>>type yang:hex-string; 
>>description
>>  "When a bit is exchanged in the Graceful Restart Flags
>>   field that is unknown to this module, the hexadecimal
>>   representation of flags field is returned with the unknown 
>> bit(s).";
>>reference
>>  "RFC 4724: Graceful Restart Mechanism for BGP, Section
>>   3.";
>>  }
> 
> I'm not sure why this variant is particularly nicer than a set of bits in a 
> bit vector that themselves do not have any backward-incompatible changes.
> 
> If I have, e.g. "unknown-3" and "unknown-4" as the options in the unknown 
> field, and then next rev comes along and defines 3 and the "known" bit gets 
> defined, deprecating unknown-3 is clear signaling that it's gone away.
> 
> Part of the complaint in this thread is bit-3's contents "move" around.  The 
> same would be true for the contents of a unknown field in a different non-bit 
> format: e.g. hex, uint, or binary.

The advantage is that the initial modeling is simpler (especially with lots of 
reserved bits) and an augmentation adding a definition of a bit that was 
previously defined doesn’t need to deprecate anything. 

Acee



> 
> -- Jeff
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jeffrey Haas]

Acee,


> On Sep 5, 2023, at 12:42 PM, Acee Lindem  wrote:
> 
> What I’d thought about for this requirement is an optional read-only leaf 
> containing the hex representation of only the unknown bits. This would be 
> simpler to model and would be fully backward compatible. 
> 
> For example:
> 
>leaf unknown-flags {
> type yang:hex-string; 
> description
>   "When a bit is exchanged in the Graceful Restart Flags
>field that is unknown to this module, the hexadecimal
>representation of flags field is returned with the unknown 
> bit(s).";
> reference
>   "RFC 4724: Graceful Restart Mechanism for BGP, Section
>3.";
>   }

I'm not sure why this variant is particularly nicer than a set of bits in a bit 
vector that themselves do not have any backward-incompatible changes.

If I have, e.g. "unknown-3" and "unknown-4" as the options in the unknown 
field, and then next rev comes along and defines 3 and the "known" bit gets 
defined, deprecating unknown-3 is clear signaling that it's gone away.

Part of the complaint in this thread is bit-3's contents "move" around.  The 
same would be true for the contents of a unknown field in a different non-bit 
format: e.g. hex, uint, or binary.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Acee Lindem]

What I’d thought about for this requirement is an optional read-only leaf 
containing the hex representation of only the unknown bits. This would be 
simpler to model and would be fully backward compatible. 

For example:

leaf unknown-flags {
 type yang:hex-string; 
 description
   "When a bit is exchanged in the Graceful Restart Flags
field that is unknown to this module, the hexadecimal
representation of flags field is returned with the unknown 
bit(s).";
 reference
   "RFC 4724: Graceful Restart Mechanism for BGP, Section
3.";
   }
Or some variant. 
Thanks,
Acee


> On Sep 5, 2023, at 10:54, Jeffrey Haas  wrote:
> 
> Italo,
> 
> 
>> On Sep 5, 2023, at 10:28 AM, Italo Busi  wrote:
>> Thinking further, you are right that hex-dumping a field works well only 
>> when the "the semantics of the field were always clear: bits, but some are 
>> unassigned/reserved"
>> 
>> IMHO, if you are interested to diagnose also RESERVED fields with no clear 
>> semantic, the best option would be to hex-dump the whole packet/message
> 
> IMNSHO, end users will be cursing models that require you to tcpdump the YANG 
> for many years to come.
> 
> I have some small hope that we'll eventually end up with a mechanism that 
> permits such diagnostic nodes to be easily excluded from default views.  
> We're not there yet.
> 
>> In order to keep the semantics, it is possible to prefix the name of the 
>> YANG leaf carrying the hex-dump of the reserved field with the RFC number 
>> where the reserved field is defined (e.g., rfcxxx-foo).
> 
> I think this is a reasonable proposal.
> 
> -- Jeff
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jürgen Schönwälder]

On Tue, Sep 05, 2023 at 02:28:02PM +, Italo Busi wrote:
> 
> In order to keep the semantics, it is possible to prefix the name of the YANG 
> leaf carrying the hex-dump of the reserved field with the RFC number where 
> the reserved field is defined (e.g., rfcxxx-foo).
>

Several decades ago, people thought it was a clever idea to name data
models using RFC numbers. But over time, when RFCs get replaced and
obsoleted, this started to look really odd (and who outside the IETF
wants to be bothered with RFC numbers).

/js

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jeffrey Haas]

Italo,


> On Sep 5, 2023, at 10:28 AM, Italo Busi  wrote:
> Thinking further, you are right that hex-dumping a field works well only when 
> the "the semantics of the field were always clear: bits, but some are 
> unassigned/reserved"
> 
> IMHO, if you are interested to diagnose also RESERVED fields with no clear 
> semantic, the best option would be to hex-dump the whole packet/message

IMNSHO, end users will be cursing models that require you to tcpdump the YANG 
for many years to come.

I have some small hope that we'll eventually end up with a mechanism that 
permits such diagnostic nodes to be easily excluded from default views.  We're 
not there yet.

> In order to keep the semantics, it is possible to prefix the name of the YANG 
> leaf carrying the hex-dump of the reserved field with the RFC number where 
> the reserved field is defined (e.g., rfcxxx-foo).

I think this is a reasonable proposal.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Italo Busi]

Hi Jeff,

Good question indeed

Thinking further, you are right that hex-dumping a field works well only when 
the "the semantics of the field were always clear: bits, but some are 
unassigned/reserved"

IMHO, if you are interested to diagnose also RESERVED fields with no clear 
semantic, the best option would be to hex-dump the whole packet/message

An alternative BC option (not my preferred, but possible) would be a small 
refinement to your last proposal:

> - Leave it alone and you now have a field that no longer matches the
>   semantics of a protocol update but you forever carry the 2 octets of state
>   where the fields live in new leaves?

In order to keep the semantics, it is possible to prefix the name of the YANG 
leaf carrying the hex-dump of the reserved field with the RFC number where the 
reserved field is defined (e.g., rfcxxx-foo).

My 2 cents

Italo

> -Original Message-
> From: Jeffrey Haas 
> Sent: giovedì 31 agosto 2023 22:01
> To: Italo Busi 
> Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02
> 
> Italo,
> 
> On Tue, Aug 29, 2023 at 12:19:28PM +, Italo Busi wrote:
> > Hi Jeff,
> >
> > I think that the guidelines can define some conventions for addressing
> > the case where the field length is not octect-aligned
> >
> > IMHO, aligning to the left would make the translation simpler:
> >
> >  -> 0x00
> > 0001 -> 0x01
> >  -> 0x0F
> 
> The above looks like all of the bits are shifted to the least significant 
> bits (right
> shifted).
> 
> > It is also not fully clear to me the case you mention about the need for NBC
> change to the "raw" representation: could you please provide an example?
> 
> Consider a protocol that has a 2-octet RESERVED field that has no user-visible
> semantics.  As per usual IETF procedure, the specification has the usual
> wisdom of "MUST be set to zero on send, SHOULD be ignored on receipt".
> 
> (Note that this isn't the bits scenario I was originally trying to cover 
> where the
> semantics of the field were always clear: bits, but some are
> unassigned/reserved.)
> 
> As noted in the prior mail, you can pick any of a few methods to provide
> operational visibility in YANG to this field if you wanted to: uint16, 
> hex-string,
> binary.  You'd be covering 2-octets of state.  In the boring world where
> everyone is conformant to the specification and the field is the expected 
> zero,
> perhaps it is 00:00 in hexstring format.
> 
> Consider the case in the future where the second octet is assigned to new
> state, foo.  In such a case, you'd add a new leaf for foo:
> 
> leaf foo type uint8 description "comes from version 2 of document"...
> 
> So, what now becomes of the original reserved field?  There's now only one
> octet of reserved.  Do you:
> 
> - Update the leaf with the new semantics in a NBC way?  If it was binary,
>   maybe all that changes is the length.  If it's hex-string, that's not
>   length constrained, and this is technically backwards compatible, but you'd
>   only print the first octet now.  Consider the contrary example where the
>   first octet is changed instead.
> - Obsolete the original leaf, do new lear "reserved2"?
> - Leave it alone and you now have a field that no longer matches the
>   semantics of a protocol update but you forever carry the 2 octets of state
>   where the fields live in new leaves?
> 
> 
> -- Jeff
> 
> 
> 
> 
> >
> > Thanks, Italo
> >
> > From: Jeffrey Haas 
> > Sent: lunedì 21 agosto 2023 16:15
> > To: Rob Wilton (rwilton) 
> > Cc: Italo Busi ; netmod@ietf.org
> > Subject: Re: [netmod] Adoption poll for
> > draft-haas-netmod-unknown-bits-02
> >
> > Rob,
> >
> > Rewinding to the points raised in the original discussion thread:
> >
> >
> >
> > On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton)
> mailto:rwil...@cisco.com>> wrote:
> > Specifically, sometimes/always just reporting the raw hex value alongside
> the bits value seems like a simple, effective, and robust solution, and 
> perhaps
> we could recommend a standard name prefix or suffix for the name of the raw
> value leaf relative to the bits value leaf.
> >
> > Leaf name aside, the question is what do you do with the raw value,
> especially when it's not really octet-aligned?
> >
> > In the example that prompted this discussion, we have a nybble.  (See RFC
> 4724) In that case, the nybble occupied the high order bits.  The natural 
> value
> that it is part of is a uint16 that contains a 12 bit time valu

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jeffrey Haas]

Italo,

On Tue, Aug 29, 2023 at 12:19:28PM +, Italo Busi wrote:
> Hi Jeff,
> 
> I think that the guidelines can define some conventions for addressing the 
> case where the field length is not octect-aligned
> 
> IMHO, aligning to the left would make the translation simpler:
> 
>  -> 0x00
> 0001 -> 0x01
>  -> 0x0F

The above looks like all of the bits are shifted to the least significant
bits (right shifted).

> It is also not fully clear to me the case you mention about the need for NBC 
> change to the "raw" representation: could you please provide an example?

Consider a protocol that has a 2-octet RESERVED field that has no
user-visible semantics.  As per usual IETF procedure, the specification has
the usual wisdom of "MUST be set to zero on send, SHOULD be ignored on
receipt".

(Note that this isn't the bits scenario I was originally trying to cover
where the semantics of the field were always clear: bits, but some are
unassigned/reserved.)

As noted in the prior mail, you can pick any of a few methods to provide
operational visibility in YANG to this field if you wanted to: uint16,
hex-string, binary.  You'd be covering 2-octets of state.  In the boring
world where everyone is conformant to the specification and the field is the
expected zero, perhaps it is 00:00 in hexstring format.

Consider the case in the future where the second octet is assigned to new
state, foo.  In such a case, you'd add a new leaf for foo:

leaf foo type uint8 description "comes from version 2 of document"...

So, what now becomes of the original reserved field?  There's now only one
octet of reserved.  Do you:

- Update the leaf with the new semantics in a NBC way?  If it was binary,
  maybe all that changes is the length.  If it's hex-string, that's not
  length constrained, and this is technically backwards compatible, but you'd
  only print the first octet now.  Consider the contrary example where the
  first octet is changed instead.
- Obsolete the original leaf, do new lear "reserved2"?
- Leave it alone and you now have a field that no longer matches the
  semantics of a protocol update but you forever carry the 2 octets of state
  where the fields live in new leaves?


-- Jeff




> 
> Thanks, Italo
> 
> From: Jeffrey Haas 
> Sent: lunedì 21 agosto 2023 16:15
> To: Rob Wilton (rwilton) 
> Cc: Italo Busi ; netmod@ietf.org
> Subject: Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02
> 
> Rob,
> 
> Rewinding to the points raised in the original discussion thread:
> 
> 
> 
> On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>> wrote:
> Specifically, sometimes/always just reporting the raw hex value alongside the 
> bits value seems like a simple, effective, and robust solution, and perhaps 
> we could recommend a standard name prefix or suffix for the name of the raw 
> value leaf relative to the bits value leaf.
> 
> Leaf name aside, the question is what do you do with the raw value, 
> especially when it's not really octet-aligned?
> 
> In the example that prompted this discussion, we have a nybble.  (See RFC 
> 4724) In that case, the nybble occupied the high order bits.  The natural 
> value that it is part of is a uint16 that contains a 12 bit time value.
> 
> The "raw" for the bits really shouldn't be the uint16.
> 
> The "raw" really shouldn't be a dump of the full capability.  I think it has 
> been a mistake in prior models to ship raw that devolves to "you need to 
> tcpdump the yang".
> 
> One practice may simply be to say "shift the bits to the right" (presuming 
> usual network byte order considerations in IETF), which would take this 
> nybble and put it in the low-order bits of the respective leaf.
> 
> Also, keep in mind that these practices are often needed for "RESERVED" 
> fields that later on are decomposed into further structured fields.  This 
> would mean a NBC change to the "raw" representation in such a case.  I can 
> provide a contrived example, if this is not clear.
> 
> Once the "what do you do with the bits" point is addressed, there's also the 
> matter of how you ship it.  I find it peculiar that we seem to preference the 
> human-readable forms for "raw" than the machine readable ones in most of our 
> discussions.
> 
> In addition, I think that if we wanted a more efficient solution that doesn’t 
> require modelling two leaves, then perhaps this could be considered as a 
> potential YANG Next issue.  I.e., is there is a small change or addition to a 
> future revision of the YANG language (or encodings) that could allow this to 
> be better handled.
&

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Italo Busi]

Hi Jeff,

I think that the guidelines can define some conventions for addressing the case 
where the field length is not octect-aligned

IMHO, aligning to the left would make the translation simpler:

 -> 0x00
0001 -> 0x01
 -> 0x0F

My 2 cents

It is also not fully clear to me the case you mention about the need for NBC 
change to the "raw" representation: could you please provide an example?

Thanks, Italo

From: Jeffrey Haas 
Sent: lunedì 21 agosto 2023 16:15
To: Rob Wilton (rwilton) 
Cc: Italo Busi ; netmod@ietf.org
Subject: Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

Rob,

Rewinding to the points raised in the original discussion thread:



On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Specifically, sometimes/always just reporting the raw hex value alongside the 
bits value seems like a simple, effective, and robust solution, and perhaps we 
could recommend a standard name prefix or suffix for the name of the raw value 
leaf relative to the bits value leaf.

Leaf name aside, the question is what do you do with the raw value, especially 
when it's not really octet-aligned?

In the example that prompted this discussion, we have a nybble.  (See RFC 4724) 
In that case, the nybble occupied the high order bits.  The natural value that 
it is part of is a uint16 that contains a 12 bit time value.

The "raw" for the bits really shouldn't be the uint16.

The "raw" really shouldn't be a dump of the full capability.  I think it has 
been a mistake in prior models to ship raw that devolves to "you need to 
tcpdump the yang".

One practice may simply be to say "shift the bits to the right" (presuming 
usual network byte order considerations in IETF), which would take this nybble 
and put it in the low-order bits of the respective leaf.

Also, keep in mind that these practices are often needed for "RESERVED" fields 
that later on are decomposed into further structured fields.  This would mean a 
NBC change to the "raw" representation in such a case.  I can provide a 
contrived example, if this is not clear.

Once the "what do you do with the bits" point is addressed, there's also the 
matter of how you ship it.  I find it peculiar that we seem to preference the 
human-readable forms for "raw" than the machine readable ones in most of our 
discussions.

In addition, I think that if we wanted a more efficient solution that doesn’t 
require modelling two leaves, then perhaps this could be considered as a 
potential YANG Next issue.  I.e., is there is a small change or addition to a 
future revision of the YANG language (or encodings) that could allow this to be 
better handled.

IMO, permitting bit field aliasing where multiple names can refer to the same 
bit position would address this issue.  Good for YANG-next.

That said, I'm targeting the narrow use case of a small number of bits.  Such 
"raw" considerations break down under larger examples.  See above for such an 
example.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Kent Watsen]

Thank you everyone that participated in the poll.
Based on the results, there isn’t sufficient support to adopt the draft at this 
time.

Kent and Lou


> On Aug 3, 2023, at 2:02 PM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02
> 
> There is no known IPR on this draft (IPR call 
> ).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here 
> ) 
> before starting this poll, but he is going on PTO shortly and wouldn’t be 
> able to get to it for awhile, though he’s happy to do so upon returning.
> 
> Thank you,
> Kent (as Co-chair)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jeffrey Haas]

Jan,


> On Aug 22, 2023, at 4:07 AM, Jan Lindblad  wrote:
> The recommendation I would give for modeling bit fields with reserved bits is 
> to not model them as the YANG bits type.

I think I've unfortunately caused this thread to fork in a non-productive 
fashion. The unknown-bits proposal discusses primarily what to do about 
unassigned bits in flags fields.

Similar considerations in terms of NBC modeling for the contents of RESERVED 
fields similarly apply.  I'm going to reply to the remainder of this message 
solely from that context.


> Even if, on the protocol level of whatever it is that we are managing, some 
> uint16 is divided up into three well defined bit fields and have another few 
> bits reserved for future use, that is no strong reason for selecting the bits 
> type in the YANG representation of this functionality.

I would not make that recommendation.  Unless you know the underlying contents 
are a given type, something that handles representing that state opaquely is 
the best you can do.

> YANG works best when those three currently defined bit fields are defined as 
> three separate YANG leafs. Logically, that is what they are. Three separate 
> quantities. Later, when some of the reserved bits are taken to good use, 
> another YANG leaf that declares the new functionality can be easily added to 
> the next version of the YANG in a backwards compatible way. The new leaf 
> could even have an if-feature statement, so that clients can identify server 
> support up front. Or use the YANG choice statement to describe how various 
> fields exist on condition that certain other leafs have some specific value.

This is fine.  As you slice off portions of reserved for new state, you add new 
leaves that model that new state appropriately.

What remains unanswered is what you'd do if you wanted to model the contents of 
that RESERVED field over the transition process.  Let's do a single theoretical 
iteration:

Our mythical protocol has a 16-bit RESERVED field that is octet-aligned in the 
PDU, just to make this easy.

If the model author wanted to represent the contents of that field at all for 
state purposes, how best to model that?  Some options:
1. We know it's 16 bits, so just make it a uint16.
2. We don't like 1 because uint16 implies that it has a type, so we model it as 
a bounded hex-string.
3. We don't like the IETF hex-string format because the consumer of this thing 
is a machine rather than a human, so we make it a bounded binary.

All three of these are fine.

An update to the protocol then slices off the lower octet for a new field 
that's a uint8 type.  We can model that as a new leaf fine.

What then of the "reserved" leaf?  Some impacted properties:
1. It's no longer describing 16 bits of data.  At best, it describes the 16 
bits of data that now includes the new leaf.  You have overlapping noise in the 
model.
2. You shouldn't shrink the existing leaf as that's NBC.
3. It's arguable you don't want to mask out the new field from the reserved 
field as that's exactly as NBC as the bits conversation we're having.

Other options?
1. Obsolete the existing leaf, create a new one.  reserved2, reserved-20230813, 
reserved-iana-foo...
1a. pray that you don't have the options to have forking features.  If so, you 
might end up in combinatoric if-feature hell if you wanted to capture the 
various options.
2. Leave it alone.  It's historical noise, even though the property impacts 
above are relevant.
2a. When all of the reserved space is finally allocated, obsolete the leaf.

Thus, we have similar considerations for non-bit RESERVED fields if we have any 
interest in modeling them.

If the Working Group prefers to make that the actual issue rather than solely 
the bits scenario, that's perfectly reasonable.

> 
> If we are concerned about the efficiency of the management protocol, then 
> there are *significantly* greater savings to be had by taking a more holistic 
> approach, rather than focusing on the encoding details for esoteric leaf 
> types. Txid comes to mind :-)

I certainly don't need to be convinced of this point; see my comments about 
tcpdump and YANG.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jan Lindblad]

Jeff, WG,

The recommendation I would give for modeling bit fields with reserved bits is 
to not model them as the YANG bits type. Even if, on the protocol level of 
whatever it is that we are managing, some uint16 is divided up into three well 
defined bit fields and have another few bits reserved for future use, that is 
no strong reason for selecting the bits type in the YANG representation of this 
functionality.

YANG works best when those three currently defined bit fields are defined as 
three separate YANG leafs. Logically, that is what they are. Three separate 
quantities. Later, when some of the reserved bits are taken to good use, 
another YANG leaf that declares the new functionality can be easily added to 
the next version of the YANG in a backwards compatible way. The new leaf could 
even have an if-feature statement, so that clients can identify server support 
up front. Or use the YANG choice statement to describe how various fields exist 
on condition that certain other leafs have some specific value.

If we are concerned about the efficiency of the management protocol, then there 
are *significantly* greater savings to be had by taking a more holistic 
approach, rather than focusing on the encoding details for esoteric leaf types. 
Txid comes to mind :-)

Best Regards,
/jan



> On 21 Aug 2023, at 16:15, Jeffrey Haas  wrote:
> 
> Rob,
> 
> Rewinding to the points raised in the original discussion thread:
> 
> 
>> On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton) > > wrote:
>> Specifically, sometimes/always just reporting the raw hex value alongside 
>> the bits value seems like a simple, effective, and robust solution, and 
>> perhaps we could recommend a standard name prefix or suffix for the name of 
>> the raw value leaf relative to the bits value leaf.
> 
> Leaf name aside, the question is what do you do with the raw value, 
> especially when it's not really octet-aligned?
> 
> In the example that prompted this discussion, we have a nybble.  (See RFC 
> 4724) In that case, the nybble occupied the high order bits.  The natural 
> value that it is part of is a uint16 that contains a 12 bit time value.
> 
> The "raw" for the bits really shouldn't be the uint16.
> 
> The "raw" really shouldn't be a dump of the full capability.  I think it has 
> been a mistake in prior models to ship raw that devolves to "you need to 
> tcpdump the yang".
> 
> One practice may simply be to say "shift the bits to the right" (presuming 
> usual network byte order considerations in IETF), which would take this 
> nybble and put it in the low-order bits of the respective leaf.
> 
> Also, keep in mind that these practices are often needed for "RESERVED" 
> fields that later on are decomposed into further structured fields.  This 
> would mean a NBC change to the "raw" representation in such a case.  I can 
> provide a contrived example, if this is not clear.
> 
> Once the "what do you do with the bits" point is addressed, there's also the 
> matter of how you ship it.  I find it peculiar that we seem to preference the 
> human-readable forms for "raw" than the machine readable ones in most of our 
> discussions.
> 
>> In addition, I think that if we wanted a more efficient solution that 
>> doesn’t require modelling two leaves, then perhaps this could be considered 
>> as a potential YANG Next issue.  I.e., is there is a small change or 
>> addition to a future revision of the YANG language (or encodings) that could 
>> allow this to be better handled.
> 
> IMO, permitting bit field aliasing where multiple names can refer to the same 
> bit position would address this issue.  Good for YANG-next.
> 
> That said, I'm targeting the narrow use case of a small number of bits.  Such 
> "raw" considerations break down under larger examples.  See above for such an 
> example.
> 
> -- Jeff
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jeffrey Haas]

Rob,

Rewinding to the points raised in the original discussion thread:


> On Aug 21, 2023, at 9:40 AM, Rob Wilton (rwilton)  wrote:
> Specifically, sometimes/always just reporting the raw hex value alongside the 
> bits value seems like a simple, effective, and robust solution, and perhaps 
> we could recommend a standard name prefix or suffix for the name of the raw 
> value leaf relative to the bits value leaf.

Leaf name aside, the question is what do you do with the raw value, especially 
when it's not really octet-aligned?

In the example that prompted this discussion, we have a nybble.  (See RFC 4724) 
In that case, the nybble occupied the high order bits.  The natural value that 
it is part of is a uint16 that contains a 12 bit time value.

The "raw" for the bits really shouldn't be the uint16.

The "raw" really shouldn't be a dump of the full capability.  I think it has 
been a mistake in prior models to ship raw that devolves to "you need to 
tcpdump the yang".

One practice may simply be to say "shift the bits to the right" (presuming 
usual network byte order considerations in IETF), which would take this nybble 
and put it in the low-order bits of the respective leaf.

Also, keep in mind that these practices are often needed for "RESERVED" fields 
that later on are decomposed into further structured fields.  This would mean a 
NBC change to the "raw" representation in such a case.  I can provide a 
contrived example, if this is not clear.

Once the "what do you do with the bits" point is addressed, there's also the 
matter of how you ship it.  I find it peculiar that we seem to preference the 
human-readable forms for "raw" than the machine readable ones in most of our 
discussions.

> In addition, I think that if we wanted a more efficient solution that doesn’t 
> require modelling two leaves, then perhaps this could be considered as a 
> potential YANG Next issue.  I.e., is there is a small change or addition to a 
> future revision of the YANG language (or encodings) that could allow this to 
> be better handled.

IMO, permitting bit field aliasing where multiple names can refer to the same 
bit position would address this issue.  Good for YANG-next.

That said, I'm targeting the narrow use case of a small number of bits.  Such 
"raw" considerations break down under larger examples.  See above for such an 
example.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Rob Wilton (rwilton)]

As a contributor.

I think that Jeff has obviously found a modelling issue, and documenting some 
collective guidance on how to handle that is useful.  IIRC, an effort was 
recently started to do an RFC 8407 (YANG Author Guidelines) bis document and 
depending on what and how much needs to be written about this issue, then that 
might be a better home than a separate RFC.

However, I agree with others, that the approach documented in the ID is perhaps 
not the best solution.  Specifically, sometimes/always just reporting the raw 
hex value alongside the bits value seems like a simple, effective, and robust 
solution, and perhaps we could recommend a standard name prefix or suffix for 
the name of the raw value leaf relative to the bits value leaf.

In addition, I think that if we wanted a more efficient solution that doesn’t 
require modelling two leaves, then perhaps this could be considered as a 
potential YANG Next issue.  I.e., is there is a small change or addition to a 
future revision of the YANG language (or encodings) that could allow this to be 
better handled.

Regards,
Rob


From: netmod  On Behalf Of Jeffrey Haas
Sent: 17 August 2023 16:38
To: Italo Busi 
Cc: netmod@ietf.org
Subject: Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

Italo,



On Aug 8, 2023, at 8:14 PM, Italo Busi 
mailto:Italo.Busi=40huawei@dmarc.ietf.org>>
 wrote:

Hi Kent,

I am a bit struggling about how to reply to this poll …

I think that having some guidelines about how to deal with unknown bits when 
reporting information received from a protocol is quite useful. In other words, 
the I-D is addressing an issue that needs to be resolved

This draft was created because such guidance was lacking.  Minimally, I'm happy 
that it's created useful discussion on the matter.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Jeffrey Haas]

Italo,


> On Aug 8, 2023, at 8:14 PM, Italo Busi 
>  wrote:
> 
> Hi Kent,
>  
> I am a bit struggling about how to reply to this poll …
>  
> I think that having some guidelines about how to deal with unknown bits when 
> reporting information received from a protocol is quite useful. In other 
> words, the I-D is addressing an issue that needs to be resolved

This draft was created because such guidance was lacking.  Minimally, I'm happy 
that it's created useful discussion on the matter.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Italo Busi]

Hi Kent,

I am a bit struggling about how to reply to this poll …

I think that having some guidelines about how to deal with unknown bits when 
reporting information received from a protocol is quite useful. In other words, 
the I-D is addressing an issue that needs to be resolved

However, as pointed out in your PS, there has been a lot of discussion on the 
mailing list and I fully agree with the concerns raised during that discussion 
as well as raised by some people opposing the adoption of this I-D against the 
NBC aspects of the solution proposed in the I-D. In other words, I do not 
support the solution described in the I-D

My 2 cents

Italo

From: Kent Watsen 
Sent: giovedì 3 agosto 2023 11:03
To: netmod@ietf.org
Subject: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

NETMOD WG,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02

There is no known IPR on this draft (IPR 
call<https://mailarchive.ietf.org/arch/msg/netmod/zJPEgqyi9yXzRqPO6NPJklQsBcU/>).

Please voice your support or technical objections to adoption on the list by 
the end of the day (any time zone) Aug 17.

PS: I was hoping that Jeff would update the draft to reflect comments received 
on-list (e.g., 
here<https://mailarchive.ietf.org/arch/msg/netmod/8vk2TU2yaT8kLc1N7sbxiVs27UY/>)
 before starting this poll, but he is going on PTO shortly and wouldn’t be able 
to get to it for awhile, though he’s happy to do so upon returning.

Thank you,
Kent (as Co-chair)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[tom petch]

From: netmod  on behalf of Kent Watsen 

Sent: 03 August 2023 19:02

NETMOD WG,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02

There is no known IPR on this draft (IPR 
call).

Please voice your support or technical objections to adoption on the list by 
the end of the day (any time zone) Aug 17.


Do not support
Complicated, lacks the simplicity, the obviousness, that tis the hallmark of 
good engineering.

Tom Petch


PS: I was hoping that Jeff would update the draft to reflect comments received 
on-list (e.g., 
here)
 before starting this poll, but he is going on PTO shortly and wouldn’t be able 
to get to it for awhile, though he’s happy to do so upon returning.

Thank you,
Kent (as Co-chair)


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Acee Lindem]

I don’t support adoption as I think this solution to the problem of receiving 
unknown bits is excessive and the fact that it is Non-Backward Compatible (NBC) 
change to remove the unknown bits once they are defined. Rather, just add an 
optional read-only unknown-foo-bits leaf of type yang:hex-string and return the 
hex representation if they’re any unknown bits in the field.

Thanks,
Acee


> On Aug 3, 2023, at 14:02, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02
> 
> There is no known IPR on this draft (IPR call 
> ).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here 
> ) 
> before starting this poll, but he is going on PTO shortly and wouldn’t be 
> able to get to it for awhile, though he’s happy to do so upon returning.
> 
> Thank you,
> Kent (as Co-chair)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Rahman]

I support adoption.

Sent from my iPhone

> On Aug 3, 2023, at 2:02 PM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02
> 
> There is no known IPR on this draft (IPR call).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here) before starting this poll, but he is going on 
> PTO shortly and wouldn’t be able to get to it for awhile, though he’s happy 
> to do so upon returning.
> 
> Thank you,
> Kent (as Co-chair)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Mahesh Jethanandani]

Support this work!

> On Aug 3, 2023, at 11:02 AM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> This email begins a 2-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02 
> 
> 
> There is no known IPR on this draft (IPR call 
> ).
> 
> Please voice your support or technical objections to adoption on the list by 
> the end of the day (any time zone) Aug 17.
> 
> PS: I was hoping that Jeff would update the draft to reflect comments 
> received on-list (e.g., here 
> ) 
> before starting this poll, but he is going on PTO shortly and wouldn’t be 
> able to get to it for awhile, though he’s happy to do so upon returning.
> 
> Thank you,
> Kent (as Co-chair)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

[Kent Watsen]

NETMOD WG,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits/02

There is no known IPR on this draft (IPR call 
).

Please voice your support or technical objections to adoption on the list by 
the end of the day (any time zone) Aug 17.

PS: I was hoping that Jeff would update the draft to reflect comments received 
on-list (e.g., here 
) 
before starting this poll, but he is going on PTO shortly and wouldn’t be able 
to get to it for awhile, though he’s happy to do so upon returning.

Thank you,
Kent (as Co-chair)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod