Re: [PWE3] [Technical Errata Reported] RFC5003 (3411)

[Brian Haberman <[e-mail]>]

I have no issues with marking this erratum as rejected.  Are there other 
opinions?

Regards,
Brian

On 11/15/12 9:28 PM, Luca Martini wrote:
> RFC Editor,
>
> I propose to reject this Errata.
> There is no technical merit in changing the example on how one might
> possibly choose the 32bit number.
> This is a NIT , and does not affect implementations, nor service
> provider policies.
> the text "Prefix = The 32-bit prefix is a value assigned by the provider
> " is the main definition of how this 32 bit value is to be assigned.
>
> Luca
>
>
> Is the main point of this
> On 11/15/2012 01:09 PM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5003,
>> "Attachment Individual Identifier (AII) Types for Aggregation".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5003&eid=3411
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Rajiv Asati <[e-mail]>
>>
>> Section: 3.2
>>
>> Original Text
>> -------------
>>
>>
>>       o Prefix = The 32-bit prefix is a value assigned by the provider or
>>
>>         it can be automatically derived from the PE's /32 IPv4 loopback
>>
>>         address.  Note that, for IP reachability, it is not required that
>>
>>         the 32-bit prefix have any association with the IPv4 address
>>
>>         space used in the provider's IGP or BGP.
>>
>>
>>
>> Corrected Text
>> --------------
>>
>>
>>       o Prefix = The 32-bit prefix is a value assigned by the provider or
>>
>>         it can be automatically derived from the PE's router-id i.e. LSR Id.
>>
>>         Note that it is not required that
>>
>>         the 32-bit prefix is IP routable or have any association with the
>>
>>         IPv4 address space used in the provider's IGP or BGP.
>>
>>
>>
>> Notes
>> -----
>> The intent of this RFC is to treat the 32bit prefix as a number that provides uniqueness in the network (within the ASN). While it can be derived from the IPv4 /32 Loopback address, it causes confusion when routers are configured with no IPv4. It is better to suggest using router-id used by LDP for calculating the LSR identifier. How is router-id calculated is outside the scope of this document.`
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5003 (draft-ietf-pwe3-aii-aggregate-02)
>> --------------------------------------
>> Title               : Attachment Individual Identifier (AII) Types for Aggregation
>> Publication Date    : September 2007
>> Author(s)           : C. Metz, L. Martini, F. Balus, J. Sugimoto
>> Category            : PROPOSED STANDARD
>> Source              : Pseudo Wire Emulation Edge to Edge INT
>> Area                : Internet
>> Stream              : IETF
>> Verifying Party     : IESG