Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis

[Jürgen Schönwälder <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany