Hi Med,
I believe it is a misconception that text not written in capital letters
is not normative. I also believe we need _guidelines_ on the choice of
identifiers like prefixes and not hard rules.
Prefixes do not have to be unique. It is nice if they are for widely
used modules, but we are on a slippery path if we think of them as
something that should be unique. Then they get long or clumsy or both
(or worse we encourage a competition to allocate nice short prefixes).
Yes, the original language is vague, on purpose. I guess I miss which
problem is solved by requiring uniqueness that practically can't be
ensured and is technically also not necessary.
/js
On 05.03.24 09:58, [email protected] wrote:
Hi Jürgen,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : netmod <[email protected]> De la part de Jürgen Schönwälder
Envoyé : lundi 4 mars 2024 20:44
À : [email protected]
Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-
rfc8407bis
Hi,
the statement "should be selected carefully to be unique" is
impossible to implement given an open ended set of YANG modules.
[Med] Hmm, but there is no normative text in that sentence. What concretely
needs to be followed is indicated in the sentence right after (SHOULD NOT);
which is inherited from 8407.
Isn't "selected carefully to be unique" echoing the spirit of this text from
RFC7950?
Developers of YANG modules and submodules are RECOMMENDED to choose
names for their modules that will have a low probability of colliding
with standard or other enterprise modules, e.g., by using the
enterprise or organization name as a prefix for the module name.
Within a server, all module names MUST be unique.
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.
[Med] "SHOULD ...likely" is really ambiguous as a reco if the text does not
explain when it won't be
Perhaps it should be even further watered down to "likely to be unique
in a certain usage context".
[Med] What is a usage context? how that usage context is known? How a module is
concretely bound to it? Etc. IMO, this triggers more questions that it
clarifies the guidance.
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C02%7Cjschoenwae%40constructor.university%7C8d19bba074754de88af008dc3cf268cf%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638452259052898639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kMRfC9Cuik8lhqIMXHI6K4NCZRjHUF1mORjOdUUFAvs%3D&reserved=0.
ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
r%40orange.com%7C3b125a3e5a83426657e108dc3c8376a4%7C90c7a20af34b40bfbc
48b9253b6f5d20%7C0%7C0%7C638451782524628913%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
C%7C%7C&sdata=fkyIdrLqhqIkfdivCbWnetivTNNcpW07OepfdUat3mo%3D&reserved=
0
--
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C02%7Cjschoenwae%40constructor.university%7C8d19bba074754de88af008dc3cf268cf%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638452259052906113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HZTNCsEkHPGu9IYUwl%2BIYr91dPNDz32KGguybeo9wSg%3D&reserved=0.
ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C02%7Cmohamed.boucadai
r%40orange.com%7C3b125a3e5a83426657e108dc3c8376a4%7C90c7a20af34b40bfbc
48b9253b6f5d20%7C0%7C0%7C638451782524636700%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
C%7C%7C&sdata=AEiqw14B6zxw14njEnUOEkEEzKdTmOc9%2BOTO5l2u8o8%3D&reserve
d=0
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
--
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
