Subject: [mpls] [Editorial Errata Reported] RFC6435 (4017)

From: RFC Errata System <[email-masked]>
Date: Thu, 19 Jun 2014 12:30:04 -0700 (PDT)

The following errata report has been submitted for RFC6435,
"MPLS Transport Profile Lock Instruct and Loopback Functions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=4017

--------------------------------------
Type: Editorial
Reported by: Huub van Helvoort <[email-masked]>

Section: 1

Original Text
-------------
Two useful Operations, Administration, and Maintenance (OAM)
functions in a transport network are "lock" and "loopback".  This
document discusses these functions in the context of MPLS networks.

Corrected Text
--------------
Two useful Operations, Administration, and Maintenance (OAM)
functions in a transport network are "lock" and "loopback".  This
document discusses these functions in the context of MPLS networks.

Further information about these abstract OAM functions in an MPLS
Transport Profile context can be found in RFC 6371 [6] where the
lock function is referred to as the "Lock Instruct function (LKI)"
and the loopback function is called "data-plane loopback."

Notes
-----
RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document.
RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2.
This may confuse the reader of both documents.
A similar confusion can occur for refering to the loopback function.

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. 

--------------------------------------
RFC6435 (draft-ietf-mpls-tp-li-lb-08)
--------------------------------------
Title               : MPLS Transport Profile Lock Instruct and Loopback Functions
Publication Date    : November 2011
Author(s)           : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 19 Jun 2014 22:33:11 +0100

Working Group,

Huub discussed this issue before raising it as an Errata Report.

Apparently the difference in terminology between 6371 and 6435 has caused some
doubt, and it seems best to make some clarification.

The suggested additional paragraph was drafted by be. I believe it conveys the
intent of the WG and authors when writing 6435 and does not make any change of
substance to the document.

Comments welcomed.

Adrian

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: 19 June 2014 20:30
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Editorial Errata Reported] RFC6435 (4017)
> 
> Author(s)           : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M.
Vigoureux,
> Ed., X. Dai, Ed.

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Thu, 19 Jun 2014 23:00:06 +0000

This seems a useful to make this clarification.

However it would be best start by deciding the preferred name, stating that and putting the correction in the document that uses the unpreferred name.

I have no preference, but it would be nice to make sure the error is not repeated I some future text by making one authoritative which I don't think the proposed text does.

-Stewart

Sent from my iPad

> On 19 Jun 2014, at 22:34, "Adrian Farrel" <[email-masked]> wrote:
> 
> Working Group,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 20 Jun 2014 11:31:20 +0200

Hello Stewart,

> This seems a useful to make this clarification.
OK, thanks for the support.
> However it would be best start by deciding the preferred name, stating that and putting the correction in the document that uses the unpreferred name.
Good suggestion.
> I have no preference, but it would be nice to make sure the error is not repeated I some future text by making one authoritative which I don't think the proposed text does.
rfc6435 states in section 1.1. "Updates RFC 6371"
So most logical is to use "LI", also because if "LKI" is preferred the
IANA registry has to be updated. I doubt if that can be done with
an erratum.

If "LI" is preferred than it may indeed be better to report an erratum
against rfc6371 stating that "LI" is preferred.

Cheers, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样