H Jeff,
> I hadn’t realized that your intent was to skip directly to WGLC, unless this
> was a typo. Most WG process I deal with goes through at least a thin
> adoption stage even if the intent is to move forward swiftly to last call.
I meant “adoption”. No process skipping here!
>> Specifically, I’m wondering if it makes sense to add a new section to
>> provide guidance to implementors? I’m unsure myself, as the concerns
>> raised seem to be addressed by YANG Library, in that clients should use it
>> to detect if the server is using a newer revision of modules than the client
>> groks.
>
> As Jason notes in his reply, I’m unclear what YANG library may do to help
> this situation.
As Martin points out, a revision of a module using this typedef is backwards
compatible (both the old and new modules define the same “unknown-flags” leaf
with the same meaning, and adding new bits to the “flags” leaf is allowed per
RFC 7950, Section 11. The concern isn’t that the module revision is NBC, but
that the data changed and that, a client coded to look-for/act-on the presence
of an unknown bit would break, which could be construed as NBC at the *data*
level. My point with regards to YL is that this is nothing new. New revisions
of modules can always come out with new nodes and clients always need to update
themselves to understand the module versions used by the server.
In this case, the debate is particularly shallow. Firstly, I think that it is
bad form for a client to be coded to look-for/act-on the “unknown bits”. So
the "NBC at the data level” case shouldn’t occur in practice. Next, as my edit
below alludes, when a bit goes from being unknown to known, a new revision of
the module will be defined and implemented by the server, meaning the server
will start sending the new bit in the, e.g., “flags” leaf. That the server
stopped sending the bit in the “unknown-flags” leaf is secondary to that
started sending it in the “flags” leaf. A client that “breaks" because an
unknown-bit isn’t sent will more surely break because a new known bit is sent.
Again, one purpose of YL is for clients to ensure they’re up to date wrt to
the servers it connects to.
> I’m certainly fine adding an additional section to the draft discussing that
> unknown bits may “disappear” during maintenance as previously unknown bits
> become defined.
Something that captures some of what I wrote above?
>> One new comment: the "unknown-bits” typedef's description statement seems
>> unclear in terms of the expected reconciliation process.
>>
>> Current:
>> "Typedef describing 64 bits worth of unknown bits. This can be
>> used to model operational state that would normally be modeled
>> using the YANG 'bits' type, but no registered bit has been
>> created.”;
>>
>> Proposed:
>>
>> "Typedef describing 64 bits worth of unknown bits. This can be
>> used to model operational state that would normally be modeled
>> using the YANG 'bits' type, but no registered bit has been
>> defined in the YANG module implemented by the server.”;
>>
>
> I’m fine making this change.
I refrained from expanding the description statement even more, but leave it to
you to consider. I was thinking to also add something like:
This typedef is intended to be used to model a “catch all” leaf for when, e.g.,
over-the-wire protocol data contains bits not representable by the module
implemented by the server. The “unknown-bits” data should be considered
short-lived, as the bits will be known as soon as the server updates to a
module revision defining them. Implementations should not look for or act on
the presence of unknown bits.
And then, for implementations that disregard that advice, they can always
update themselves:
OLD
if unknown-flags.bit-3:
foo
NEW
if unknown-flags.bit-3 or known-flags.my-foo-bit:
foo
I don’t see the reason to force servers to carry-forwards (forever) the
reporting of previously unknown bits.
> — Jeff
K.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
