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

I agree with Luca that it is a nit, 
and the existing text doesn't say that one MUST use the loopback address if not configured.

On the other hand the text is there to provide guidance,
and as such should help implementers that don't want to statically assign.

I think the proper classification is "Hold for Document Update", since that is how nits of this sort are usually handled.
Luca - note that that the guidelines say that this merely means that 
"any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update".

Y(J)S

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Brian Haberman
Sent: Friday, November 16, 2012 15:16
To: Luca Martini
Cc: chmetz@cisco.com; florin.balus@alcatel-lucent.com; pwe3@ietf.org; rdroms.ietf@gmail.com; sugimoto@nortel.com; andrew.g.malis@verizon.com
Subject: Re: [PWE3] [Technical Errata Reported] RFC5003 (3411)

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 <rajiva@cisco.com>
>>
>> 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

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3