On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder
j.schoenwael...@jacobs-university.de wrote:
On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote:
The I2RS interim is schedule for Wednesdsay 5/27 10:00am – 11:30am. The
interim schedule opens 30 minutes early to allow speakers to
Jürgen,
> On Jan 13, 2022, at 5:49 AM, Jürgen Schönwälder
> wrote:
>
> As pointed out by others, this is what I proposed back in July '21:
>
> typedef ipv6-address-link-local {
> type ipv6-address;
> pattern '[fF][eE]80:.*';
> description
>"A link-local IPv6 address in the prefix
Mahesh suggested I send this suggestion here.
Several IPv6 routing protocols have circumstances where the only acceptable
address is an ipv6 link-local address.
The YANG type we have for ipv6 can accommodate ipv6 link local addresses,
however it's overly permissive for some use cases.
Has the
rg/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/>
>
>
>
>
> On Thursday, January 6, 2022, 04:54:22 PM EST, Jeffrey Haas
> wrote:
>
>
> Mahesh suggested I send this suggestion here.
>
> Several IPv6 routing protocols have circumstances where the only acceptable
> add
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
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:
>
>
uot;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 1
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
>
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
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
Lada,
> On Oct 5, 2022, at 7:03 AM, Ladislav Lhotka wrote:
>
> I would still be against setting a hard limit in YANG itself, primarily
> because it is not clear what this general limit should be. Module authors
> might of course consider restricting key length to something that is
>
[I had promised Mahesh that I'd take my comments here, but I realize that this
is a topic that likely will result in no short term solutions. It may also
result in no action whatsoever.]
YANG strings are bounded in length, theoretically, but that length limit
isn't small.
When strings are used
Acee,
> On Oct 5, 2022, at 10:27 AM, Acee Lindem (acee) wrote:
>
> I'm supremely uninterested in the color of the bike shed. :-) I find minor
> value is having the word "key" present to cover the use case, but certainly
> could see use cases where a leaf might also want to limit the content
Jürgen,
On Fri, Jan 27, 2023 at 09:18:32PM +0100, Jürgen Schönwälder wrote:
> Depending on context, I think it is 'modeling' when it is about
> choosing the type or 'rendering' / 'representing' when it is about how
> a type's value is rendered (in XML). Some proposals:
I've incorporated all of
Jürgen,
Thank you for your comments.
On Thu, Jan 26, 2023 at 11:40:33PM +0100, Jürgen Schönwälder wrote:
> On Thu, Jan 26, 2023 at 03:51:57PM -0500, Jeffrey Haas wrote:
> - I suggest to avoid talking about displaying data, the verb 'display'
> is never used in RFC 7950.
What is the
-netmod-unknown-bits
-- Jeff
- Forwarded message from internet-dra...@ietf.org -
Date: Thu, 26 Jan 2023 12:43:24 -0800
From: internet-dra...@ietf.org
To: Jeffrey Haas
Subject: New Version Notification for draft-haas-netmod-unknown-bits-00.txt
A new version of I-D, draft-haas-netmod-unknown
ernet-dra...@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>Title : Representing Unknown YANG bits in Operational State
>Author : Jeffrey Haas
> Filename: draft-haas-ne
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
>
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
, at 9:40 AM, Jason Sterne (Nokia)
> wrote:
>
> That could be one approach, but note that the final step (your last sentence)
> would still be NBC.
>
> From: Rob Wilton (rwilton)
> Sent: Monday, April 17, 2023 9:36 AM
> To: Jason Sterne (Nokia) ; Italo Busi
> ; Jeffrey Haas
Italo,
> On Apr 14, 2023, at 4:04 AM, Italo Busi wrote:
>
> If the need is to report the value of a received protocol field for
> debugging/troubleshooting purposes, I am wondering why not using a binary
> type instead of a bits type or, better, a YANG leaf of bits type for the
> known bits
Italo,
> On Apr 14, 2023, at 10:32 AM, Italo Busi wrote:
> I also agree with you concerns with hexdump, but parsing has some issues when
> something is unknown (these are the issues that have triggered your draft and
> this discussion), although I also agree with you that the unknown is for
>
> On Apr 14, 2023, at 10:55 AM, Jürgen Schönwälder
> wrote:
>
> On Fri, Apr 14, 2023 at 08:48:39AM -0400, Jeffrey Haas wrote:
>>
>> -- Jeff (who keeps expecting this conversation to devolve to a proposal for
>> netconf streaming tcpdump)
>>
>
>
quot;.
Please find the information for the updated draft pasted below my original
request for adoption.
Having given my presentation and seeing there seems to be interest in the work,
could we consider adoption?
-- Jeff
> On Feb 20, 2023, at 1:23 PM, Jeffrey Haas wrote:
>
> The curren
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
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
> 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
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
>
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.
> 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
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
Jason,
Thanks for your comments.
On Tue, Jan 31, 2023 at 09:50:49PM +, Jason Sterne (Nokia) wrote:
> One potential consideration that came to my mind is about the choice of using
> 'bits' at all (vs a set of Boolean leafs), and it is related to on-change
> telemetry.
>
> With a leaf of
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
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"
> 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
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
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
"No, I'm not aware of any IPR that applies to this draft"
-- Jeff (sole author)
> On Jun 5, 2023, at 7:03 PM, Kent Watsen wrote:
>
> [NOTE: A response is needed from all listed in this message's "To" line, the
> authors and contributors listed in the draft]
>
>
> Authors, Contributors, WG,
>
38 matches
Mail list logo
