Re: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

[Loa Andersson <[e-mail]>]

WG,

I support this early allocation, we should not leave implementation
efforts hanging.

/Loa

On 03/01/2020 18:21, Mach Chen wrote:
> Hi,
> 
> Given there are more and more on-going implementations and interoperate 
> testing, I think it’s better to allocate the necessary code points 
>   asap. Hence, I support the Early Allocation request.
> 
> Best regards,
> 
> Mach
> 
> *From:*spring [mailto:[e-mail]] *On Behalf Of 
> *[e-mail]
> *Sent:* Friday, December 20, 2019 12:54 AM
> *To:* SPRING WG <[e-mail]>
> *Subject:* [spring] draft-ietf-spring-srv6-network-programming - 2 week 
> Early Allocation Call
> 
> Hi SPRING WG,
> 
> This begins a 2 week Early Allocation call for a “Ethernet” value from 
> the "Protocol Numbers" registry..
> 
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1
> 
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3
> 
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
> 
> In parallel of the Working Group Last Call which is currently running, 
> the authors are requesting for early code point allocation from IANA as 
> implementations are under way.
> 
> The criteria for early allocation are:
> 
>     a.  The code points must be from a space designated as "RFC
> 
>         Required", "IETF Review", or "Standards Action".  Additionally,
> 
>         requests for early assignment of code points from a
> 
>         "Specification Required" registry are allowed if the
> 
>         specification will be published as an RFC.
> 
>     b.  The format, semantics, processing, and other rules related to
> 
>         handling the protocol entities defined by the code points
> 
>         (henceforth called "specifications") must be adequately described
> 
>         in an Internet-Draft.
> 
>     c.  The specifications of these code points must be stable; i.e., if
> 
>         there is a change, implementations based on the earlier and later
> 
>         specifications must be seamlessly interoperable.
> 
>     d.  The Working Group chairs and Area Directors (ADs) judge that
> 
>         there is sufficient interest in the community for early (pre-RFC)
> 
>         implementation and deployment, or that failure to make an early
> 
>         allocation might lead to contention for the code point in the
> 
>         field.
> 
> https://tools.ietf.org/html/rfc7120#section-2
> 
> I believe the above conditions are met. (minus the AD judgement which is 
> further down in the process)
> 
> As a reminder, this topic has mainly been discussed following IETF 105 
> (Montréal) both during the meeting and on the mailing list.
> 
> During IETF 106 it has been discussed in the IntArea WG. 
> https://datatracker.ietf.org/meeting/106/proceedings#intarea
> 
> Note that this code point is not to be specific to SRv6. Depending on AD 
> guidance, this specific code point even be moved from 
> draft-ietf-spring-srv6-network-programming into a specific 1 page draft.
> 
> If you support early adoption,  please include “support” along with any 
> comments about the draft’s technical solution.
> 
> If you do not support early allocation, please include “no support” in 
> your email and indicate why.
> 
> Thank you,
> 
> --Bruno
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]