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

[Robert Raszuk <[e-mail]>]

Support

On Thu, Dec 19, 2019 at 5:54 PM <[e-mail]> wrote:

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