Hi Adrian,
This makes it clear whether or not that assignment needs to be updated when this
draft is approved for publication as RFC:
[[[
I think that might be valuable. So the IANA section should read...
IANA has previously made an allocation from the "BGP Tunnel Encapsulation
Attribute Tunnel Types" registry that reads:
Value | Name | Reference
--------+---------------------------+-------------------------------
13 | MPLS in UDP Encapsulation | [draft-ietf-l3vpn-end-system]
IANA is requested to change the reference to point to the RFC number
of this document when it is published.
]]]
The current text "This document has no IANA actions." provides no
instructions and incorrectly tell people there is no actions requested.
Thanks
~pl
On Tue Dec 09 13:20:57 2014, [email protected] wrote:
> Hi,
>
> Replying to myself and keeping the same IANA tracking number.
>
> > > IESG/Authors/WG Chairs:
> > >
> > > IANA has reviewed draft-ietf-l3vpn-end-system-04. Authors should
> review
> > > the comments and/or questions below. Please report any
> inaccuracies and
> > > respond to any questions as soon as possible.
> > >
> > > IANA's reviewer has the following comments/questions:
> > >
> > > IANA has a question about the IANA Considerations section of this
> document.
> > >
> > > Previously, an early assignment has been made to support this
> draft. The
> > > original request for an assignment is below:
> > >
> > >> <begin request="">
> > >> Contact Name:
> > >> Thomas Morin
> > >>
> > >> Contact Email:
> > >> [email protected]
> > >>
> > >> Type of Assignment:
> > >> Assignement of a BGP parameter in a FCFS registry.
> > >>
> > >> Registry:
> > >> BGP Tunnel Encapsulation Attribute Tunnel Types
> > >>
> > >> See: https://www.iana.org/assignments/bgp-parameters
> > >>
> > >> Description:
> > >> Needed for draft-ietf-l3vpn-end-system, to allow the use of an
> > >> MPLS-over-UDP encapsulation as specified in draft-ietf-mpls-in-
> udp .
> > >>
> > >> No value has been proposed yet, next available value 13 would be
> fine.
> > >>
> > >> Additional Info:
> > >> draft-ietf-l3vpn-end-system
> > >> </end>
> > >
> > > IANA Question --> The IANA Considerations section said "This
> document has
> > > no IANA actions." and, as a result, the assignment made through
> the request
> > > above would not be made permanent. Is this the author's intent? If
> not,
> could
> > > the draft be revised to indicate that the assignment made based on
> the
> request
> > > above be changed from an initial assignment to a permanent
> assignment.
>
> How do you mean?
> The registry is FCFS for which *any* document is sufficient.
> The assignment has been made and is as permanent as any FCFS
> assignment ever is.
>
> > > Please note that IANA cannot reserve specific values. However,
> early
> > > allocation is available for some types of registrations. For more
> information,
> > > please see RFC 7120.
>
> Yes, but this is a FCFS registry to which 7120 does not apply, and nor
> does
> "reservation of values".
> With FCFS the value is assigned when requested and that's it.
>
> Now, it is a different question whether this document should ask for
> the
> registry to be updated to point to the consequent RFC instead of the
> I-D.
>
> I think that might be valuable. So the IANA section should read...
>
> IANA has previously made an allocation from the "BGP Tunnel
> Encapsulation
> Attribute Tunnel Types" registry that reads:
>
> Value | Name | Reference
> --------+---------------------------
> +-------------------------------
> 13 | MPLS in UDP Encapsulation | [draft-ietf-l3vpn-end-system]
>
> IANA is requested to change the reference to point to the RFC
> number
> of this document when it is published.
>
> Cheers,
> Adrian
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
