Re: [Idr] Debate about IANA assignment policies for BGP-LS registries

[[e-mail]]

Hi Adrian,

First of all, I'm fine with whatever you write (in this document. let's not over commit;-) ).
(If one need arguments: the last called is passed, you know the subject, I trust you to do the right thing, better you doing the job than me)

Then you are raising potentially wide and interesting points.
I don't feel that I have a specific position nor specific knowledge to share. On other hand ignoring your email may actually be more impolite than wasting 5 minutes of your time.

As an operator, I'm very much interested in interoperability.
 
IMHO I would personally distinguish two things.
a) code points are here to avoid clashes in both syntax and semantic interpretations between the sender and the receiver. Ideally, the bigger the code point space, the better; in which case we should be happy to burn many codepoint if needed (i.e. any interop risk).
b) specifications are here for interop. They must be permanent, unchanged, public, complete. Ideally agreed upon, but this is a different subject.
 
Along this, a specification needs codepoints. A code point does not necessarily need a specification.
E.g. if implementer A says 'I burned code point X, I need another one' then we should probably trust him and give him another one to avoid clash. (cf point a).

Now, there is the question of:
- the size of the code point space: how much unlimited is it?
- the incentive for "fait accompli'. One implementer asks for a code point to do whatever it wants. And then go to the IETF to have it rubberstamped, unchanged. A là "I have running code, and reals customers asking for it. We/you can't change anything in the spec". That is not a theoretical risk.


Given this, I personally like the approach taken in RFC 8810  [1] with multiple sub-pools:
- one for experiment use. E.g. 5-10%. With which anyone can freely innovate in his lab.
- one for FCFS or DE. E.g. 50%.  With which anyone can ship its implementation. No red tape. Whether it's unlimited or not is under the responsibility of the community or popularity of the subject/protocol. Note that under the above opinion, for this pool a spec is "nice to have" but not mandated. Hence the discussion of its permanence is moot.
- one for IETF standard E.g. 45-50%. That pool is for real IETF standards.


I'm fully aware that this is not the questions that you asked for. But this is my answer ;-) [2]

Best regards,
Bruno

[1] https://www.rfc-editor.org/rfc/rfc8810.html#name-iana-considerations
[2] Private joke for French people of my generation.

> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, November 19, 2020 9:26 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries
> 
> Hi,
> 
> You may have noticed some recent debate about
> draft-ietf-idr-bgp-ls-registries on the IDR list.
> 
> It is possible that, notwithstanding WG last call, the draft doesn't
> correctly capture what the working group wanted.
> 
> Since I hold the pen for the draft and am one of the Designated Experts for
> the registry, I will try to set out my understanding of what we currently
> have, what the document says, and what questions the WG may need to
> address
> next.
> 
> [For the avoidance of doubt: I'm just trying to serve the WG and clarify the
> instructions to the DEs, I don't have much of an opinion about this.]
> 
> The registries were created by RFC 7752 and currently make assignments
> according to "Specification Required." RFC 8126 (which post-dated RFC 7752)
> defines these terms in section 4.6. "Specification Required" includes the
> requirement for:
> - review by a Designated Expert
> - documentation in a permanent and readily available public specification
> 
> Debate rages about the meaning of "permanent" in this context. Does an
> Internet-Draft count, does it expire, or is it archived by the tools page?
> Does an individual I-D count, or does it need to be adopted first? Does IANA
> track the I-D version, and if not what does it mean when a new version
> changes the meaning of a code point?
> 
> As Alvaro, our AD remarks, IDR is not the place to have this debate. It is
> probably an IETF-wide debate and anyone is welcome to take it up with IANA
> and the IESG.
> 
> What we need to do is decide what we want as our policy for these registries
> to be, and then work out how to achieve it. We can then set the DE guidance
> (see section 5.1 of RFC 7752) to achieve the right results.
> 
> It seems, from various discussions on the list, that the WG (or some of its
> more vocal participants) want to be able to assign code points based on I-Ds
> and without requiring to do early allocation (RFC 7120). There seem (to me)
> to be three ways to approach this:
> 
> 1. Leave the assignment policies and DE instructions in place per 7752 and
> state that they do what we want.
> 2. Leave the assignment policies in place per 7752, but change the DE
> instructions to give explicit advice about Internet-Drafts.
> 3. Change the assignment policies to be simply "Expert Review" and change
> the DE instructions to describe what the DE must do.
> 
> The current draft seeks to implement option 3.
> 
> I'd note that a secondary issue arises about requests for codepoints arising
> from outside the IETF. Suppose another SDO or a vendor wants a code point:
> Do they have to write an I-D? Does it have to gain adoption in the WG?
> 
> 
> 
> The chairs have a slide on this for the meeting on Friday. I'll leave it to
> them to decide whether there is time in the meeting to discuss the topic,
> but the agenda was previously full. Perhaps a discussion on this list would
> be better.
> 
> Best,
> Adrian
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.