Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[tom petch <[e-mail]>]

From: [e-mail] <[e-mail]>
Sent: 30 March 2021 11:47
To: tom petch
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Hi Tom,

What really matters for the IANA early allocation is that the behaviors
associated to the code points are clear and stable. Assuming the WG
agrees on moving to the "binding value" terminology all along the
document, then the technical specification wouldn't change (i.e. it
would clearly be backward compatible [1]) and we could update the phrase
in IANA entry accordingly at final allocation time.

<tp>
I understand what you are saying but I also believe in
Get it Right First Time
that is getting it wrong and then changing it leads to a greater cost, to confusion and to mistakes.  I see this  with YANG modules where some way through the development, someone has a good idea and changes the YANG prefix, except that they change it in some places and not in others.  There have been cases where this has been detected and fixed at the RFC Editor stage, there are others where it has not and a published RFC has two different values which contradicts the BCP on YANG Guidelines.

So good ideas, on such as an identifier, need to happen early one, before adoption of an I-D IMHO which is why you may find me opposing adoption of an individual submission because I see the consequences in the long term of a less than ideal choice of identifier.

Tom Petch.

Cheers,

Julien

--
[1] https://www.rfc-editor.org/rfc/rfc7120.html#section-3.2


On 27/03/2021 13:02, tom petch wrote:
> <tp>
> Adrian
>
> I share your comments about the terminology in this I-D which is not precise, failing to specify 'MPLS label' and failing to use 'MPLS label stack entry' but I think that the worst part is this 'binding/Label SID' which to me is a classic example of how not to choose an identifier.  The I-D does use 'binding value' in one place as what appears to be one of the many different terms for this concept and I think that term much better.
>
> Since this term, whatever it is, gets embedded in IANA, I said that the IANA early allocation should not proceed until this is resolved, but you may not take it that far.
>
> Tom Petch


_________________________________________________________________________________________________________________________

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.