Hi,
the statement "should be selected carefully to be unique" is
impossible to implement given an open ended set of YANG modules.
If this section only applies to IETF modules (I thought it is
more general) and IANA never makes a mistake and we accept
that prefixes get longer or cryptic over time, then this may
be possible to implement, but I am not sure this is actually
desirable.
The original wording "likely to be unique" was selected
carefully, it conveys the message that prefixes can't be
assumed to be unique. Perhaps it should be even further
watered down to "likely to be unique in a certain usage
context".
I believe the original wording was good enough and does not
need an update. Every update, even if well intended, carries
a risk to break something that works.
/js
On 04.03.24 19:39, Randy Presuhn wrote:
Hi -
On 2024-03-04 12:51 AM, [email protected] wrote:
Hi Jan,
I went so far with the following:
OLD:
Prefix values SHOULD be short but are also likely to be unique.
Prefix values SHOULD NOT conflict with known modules that have been
previously published.
NEW:
Prefix values should be selected carefully to be unique, and ideally
not too long. Specifically, prefix values SHOULD NOT conflict with
known modules that have been previously published.
I’m having troubles with the normative language here. If we maintain
the two sentences, the second SHOULD is sufficient for the uniqueness
IMO.
Also, as per RFC2119, we should clarify when the SHOULD NOT can be
safely ignored:
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
An obvious case is an updated version of a published version.
...
In dealing with SHOULD statements in RFCs, both as an implementor
and as a specification writer, I find it useful to re-phrase (at least
in my head) a "SHOULD NOT X" as "MUST be able to cope with others
doing X, even if it does not itself do X."
A "SHOULD NOT X" in a specification does NOT relieve implementations
of the duty to work correctly when X happens, because "SHOULD NOT X"
means that X is indeed permitted, even if discouraged. If X causes a
an implementation pair to violate protocol or miscommunicate (e.g.
referencing the wrong syntax or semantics) at some level, then it
really needs to be a "MUST NOT".
But this is an old, old argument, and gliding along with "likely
uniqueness" rather than uniqueness has been a longstanding
bug/feature of netmod. I'd just like to see a bit more guidance
for implementors so their products don't crash and burn when they
do encounter "duplicate" prefixes in the wild.
Randy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
