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

[Alexander Vainshtein <[e-mail]>]

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]