Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 May 2015 16:49:18 +0000

Loa,

I do not argue with the decision.

I would simply like to understand

(a) whether you think that this change should be considered if/when 5586bis is considered

(b) how to preserve this input if it has any value.

My gut feeling after reading your original email was that the change is worth considering. And I do not know the answer for (b).

Thumb typed on my LG,
Sasha

------ Original message ------
From: Loa Andersson
Date: 13/05/2015 18:43
To: Alexander Vainshtein;BRUNGARD, DEBORAH A;
Cc: [email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];
Subject:Re: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Sasha,

I think the rationale is that the wg chairs don't see this as an
errata, but rather as a change.

Not being an errata, it seems odd to use the errata system to maintain a
non-errata.

/Loa

On 2015-05-13 14:14, Alexander Vainshtein wrote:
> Deborah, Loa and all,
> I accept the decision to reject the errata, of course.
>
> Revisiting this issue if/when the document is updated is OK with me, even if must admit that  I do not understand the difference between this and the disposition of errata that says "take into account when the document is updated" (or something like this).
>
> I would just like to clarify that my interest in the issue was triggered by a question I've received from the field, when a person examining some capture as asked me:
> "Why is the TTL in the LSE containing GAL set to 2" Is this standard?"
>
> I have looked up RFC 5586, and I did not find a straightforward answer to this question.
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   [email-masked]
>
> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2015 2:58 PM
> To: Loa Andersson; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: Alexander Vainshtein; [email-masked]
> Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
>
> Will do -
> Thanks Loa-
> Deborah
>
>
> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2015 2:59 AM
> To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; BRUNGARD, DEBORAH A; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
>
> Folks,
>
> MPLS chairs have discussed the errata.
>
> We feel that it is a change to the document rather than an errata, on that ground it should be rejected.
>
> We think that the appropriate would be to revisit this if the document is updated.
>
> I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision.
>
> Deborah,
>
> Can you mark this a "rejected"?
>
>
> /Loa
>
> On 2015-05-12 16:14, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5586, "MPLS
>> Generic Associated Channel".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Alexander ("Sasha") Vainshtein
>> <[email-masked]>
>>
>> Section: 4.2.1
>>
>> Original Text
>> -------------
>>      The Time-To-Live (TTL) field of the LSE that contains the GAL follows
>>      the definition and processing rules specified in [RFC3443].
>>
>> Corrected Text
>> --------------
>> The value of the  Time-To-Live (TTL) field of the LSE that contains
>> the GAL follows is irrelevant as long as it exceeds 1. (Setting this
>> value to 0 or 1 SHOULD be avoided because it could result in trapping
>> the OAM packets in with wrong reason: "TTL expiration" instead of "GAL
>> encountered").
>>
>> Notes
>> -----
>> The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet.
>> As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable.
>>
>> Instructions:
>> -------------
>> This erratum 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.
>>
>> --------------------------------------
>> RFC5586 (draft-ietf-mpls-tp-gach-gal-06)
>> --------------------------------------
>> Title               : MPLS Generic Associated Channel
>> Publication Date    : June 2009
>> Author(s)           : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Multiprotocol Label Switching
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>

--

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 May 2015 11:26:57 +0200

Sasha,

> (a) whether you think that this change should be considered if/when

We have a a proposed changed, and it should certainly be considered
if/when we do a 5586bis.

> (b) how to preserve this input if it has any value.

The simple answer is that I don't know if the IETF have a method to do
this - other than the mail archives.

I've a set of notes with potential changes/updates/extensions to the
MPLS RFCs and the RFCs that I been involved in writing.

Sometimes the number of entries towards one item/issues gets such that
it makes sense to do something, but when a full bis is not motivated. 
What I've don in such cases is towrite a small ID to preserve the input.

If you want it is possible to turn the "errata" into a draft.
We would then get wg consensus and if published it is guaranteed to
be considered when we do the bis.

If not I think we need to trust that we keep our notes straight.

/Loa

>
> My gut feeling after reading your original email was that the change is
> worth considering. And I do not know the answer for (b).
>
> Thumb typed on my LG,
> Sasha
>
> *From: *Loa Andersson
> *Date: *13/05/2015 18:43
> *To: *Alexander Vainshtein;BRUNGARD, DEBORAH A;
> *Cc:
> [email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];
> *Subject:*Re: to be rejected - Re: [Technical Errata Reported] RFC5586
> (4364)
>
> Sasha,
>

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 May 2015 09:51:38 +0000

Loa,
Lots of thanks for a prompt and highly informative response.
I will consider writing a short ID addressing this issue with 5586.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, May 14, 2015 12:27 PM
To: Alexander Vainshtein; BRUNGARD, DEBORAH A
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Sasha,

> (a) whether you think that this change should be considered if/when 

We have a a proposed changed, and it should certainly be considered if/when we do a 5586bis.

> (b) how to preserve this input if it has any value.

The simple answer is that I don't know if the IETF have a method to do this - other than the mail archives.

I've a set of notes with potential changes/updates/extensions to the MPLS RFCs and the RFCs that I been involved in writing.

Sometimes the number of entries towards one item/issues gets such that it makes sense to do something, but when a full bis is not motivated. 
What I've don in such cases is towrite a small ID to preserve the input.

If you want it is possible to turn the "errata" into a draft.
We would then get wg consensus and if published it is guaranteed to be considered when we do the bis.

/Loa

>
> My gut feeling after reading your original email was that the change 
> is worth considering. And I do not know the answer for (b).
>
> Thumb typed on my LG,
> Sasha
>
> [email-masked];[email-masked];martin.vigoureux@alcat
> el-lucent.com;[email-masked];[email-masked];[email-masked];r
> [email-masked];[email-masked];
> Not being an errata, it seems odd to use the errata system to maintain 
> a non-errata.
>
> /Loa
>
>> To: Loa Andersson; RFC Errata System; 
>> [email-masked]; 
>> [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]
>> To: RFC Errata System; [email-masked]; 
>> [email-masked]; [email-masked]; 
>> [email-masked]; BRUNGARD, DEBORAH A; [email-masked]; 
>> [email-masked]; [email-masked]
>>> value to 0 or 1 SHOULD be avoided because it could result in 
>>> trapping the OAM packets in with wrong reason: "TTL expiration" 
>>> instead of "GAL encountered").
>>>
>>> Notes
>>> -----

--