I agree with Dhruv about experimentation.

We don’t want to encourage “squatting” on code points even for experiments 
because that typically results in code being deployed and (if we’re lucky) late 
requests for assignment of code points.

The idea of a single experimental code point is that it encourages people to 
realise the line between an experiment and a standards track.

This does not stop an Experimental RFC from requesting a full assignment from 
the registry.

 

Cheers,

Adrian

 

From: alto <[email protected]> On Behalf Of Dhruv Dhody
Sent: 08 March 2022 07:09
To: [email protected]
Cc: [email protected]; Kai Gao <[email protected]>; alto <[email protected]>
Subject: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

 

Hi Med,

 

On Tue, Mar 8, 2022 at 11:53 AM <[email protected] 
<mailto:[email protected]> > wrote:

Hi Dhruv, 

 

Thank you for the comments. 

 

We will be adding a “description” in the next iteration, however the details 
about the structure/etc should not be echoed in the table but be available in 
the pointer provided under “Specification”. 

 

 

Dhruv: Maybe I was not clear. I meant to say the IANA sections in RFC 7285 
included a lot more text than what is there in this I-D. See 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.2 and 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.3. I was suggesting 
using a similar format and adding more text about this new registry as well. 

 

 

I’m not sure a specific prefix for private use is needed, but I may be 
mistaken. When running experiments, the owners can just pick any value which 
does not conflict with a value in the registry + provide the semantic/behavior 
to ALTO nodes that are involved in the experiment.  

 

 

Dhruv: Experiments sometimes leak into the wild and thus we discourage simply 
picking any value and opting for private use and experimental use values in the 
IANA registry. Further, consistency in the protocol extensions is a good thing 
to have, and thus using priv: makes sense to me! I was not in the room when RFC 
7285 was being developed. Maybe some of the OG participants from the WG could 
through some light on this as well :)

 

Thanks! 

Dhruv

 

 

Cheers,

Med

 

De : Dhruv Dhody <[email protected] <mailto:[email protected]> > 
Envoyé : mardi 8 mars 2022 06:52
À : Kai Gao <[email protected] <mailto:[email protected]> >
Cc : alto <[email protected] <mailto:[email protected]> >; [email protected] 
<mailto:[email protected]> 
Objet : Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

 

Hi Kai,

 

Support adoption! 

 

Should the IANA consideration section follow the format followed by RFC 7285 
which includes lot more details on the rationale, requested information, string 
format etc. 

 

That also made me wonder if there is some benefit to also mark priv: for 
private use as done for some of the other ALTO registries.  

 

Thanks! 

Dhruv

 

On Mon, Mar 7, 2022 at 4:58 PM <[email protected] <mailto:[email protected]> > 
wrote:

Dear all,

I have been appointed to run the Call for Adoption of 
draft-bw-alto-cost-mode-01.

Following up with what has been proposed and agreed during the IESG review on 
draft-ietf-alto-path-vector [1], we are starting a call for adoption of the 
ALTO cost mode [2] document as a charter deliverable. It both helps push 
forward existing WG document and fits in the protocol maintenance item in the 
current charter.

The Call for Adoption will close on March 21 (2 weeks after the IETF submission 
deadline). Please post to the mailing list if you support or appose the 
adoption, or have any comments or suggestions.

[1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-Z_I8t4/
[2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01

Thanks!

Best,
Kai
_______________________________________________
alto mailing list
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/alto

_________________________________________________________________________________________________________________________
 
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.

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to