Re: [netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

[maqiufang (A)]

Hi, chair, all

No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Qiufang

From: Kent Watsen [mailto:kent+i...@watsen.net]
Sent: Tuesday, August 22, 2023 9:47 PM
To: maqiufang (A) ; Qin Wu ; Balazs 
Lengyel ; Hongwei Li 
Cc: netmod@ietf.org
Subject: Regarding IPR on draft-ma-netmod-immutable-flag-08

Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.
Kent (as co-chair)


https://www.ietf.org/mailman/listinfo/netconf
___
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] Regarding IPR on draft-ma-netmod-immutable-flag-08

[Hongwei Li]

No, I'm not aware of any IPR that applies to this draft

Hongwei Li

On Tue, Aug 22, 2023 at 8:46 AM Kent Watsen  wrote:

> Authors, Contributors, WG,
>
> As a prerequisite for the adoption on this document:
>
> Are you aware of any IPR that applies to draft identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft”
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules”
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
>
> Also please send the response to the list above, and not unicast it.
>
> Thanks.
> Kent (as co-chair)
>
>
> https://www.ietf.org/mailman/listinfo/netconf
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

[Kent Watsen]

Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft”
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules”
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.
Kent (as co-chair)


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

[netmod] netmod - New Meeting Session Request for IETF 118

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Lou Berger, a Chair
of the NETMOD Working Group.


-
Working Group Name: Network Modeling
Area Name: Operations and Management Area
Session Requester: Lou Berger


Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 Chair conflict: netconf teas detnet
 Key participant conflict: manet tvr

   


Participants who must be present:
  Jason Sterne

Resources Requested:

Special Requests:
  
-


___
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