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

[Loa Andersson <[e-mail]>]

Sasha,

On 2015-05-13 18:49, Alexander Vainshtein wrote:
> 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

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
>
> ------ Original message ------
> *From: *Loa Andersson
> *Date: *13/05/2015 18:43
> *To: *Alexander Vainshtein;BRUNGARD, DEBORAH A;
> *Cc:
> *[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];
> *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: [phone]
>> Cell:      [phone]
>> Email:   [e-mail]
>>
>> -----Original Message-----
>> From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
>> Sent: Wednesday, May 13, 2015 2:58 PM
>> To: Loa Andersson; RFC Errata System; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>> Cc: Alexander Vainshtein; [e-mail]
>> Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
>>
>> Will do -
>> Thanks Loa-
>> Deborah
>>
>>
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: Wednesday, May 13, 2015 2:59 AM
>> To: RFC Errata System; [e-mail]; [e-mail]; [e-mail]; [e-mail]; BRUNGARD, DEBORAH A; [e-mail]; [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> 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
>>> <[e-mail]>
>>>
>>> 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: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]