Re: [mpls] [Editorial Errata Reported] RFC5654 (2073)

Rejected implies to me that the NE actively informs the Operator that the attempt by the Operator to execute the external command was unsuccessful, is this the case? Otherwise how about "MUST NOT be honored"?

Ben

________________________________________
From: BUSI ITALO [Italo.Busi@alcatel-lucent.com]
Sent: 19 March 2010 16:11
To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; dbrungard@att.com; malcolm.betts@huawei.com; nurit.sprecher@nsn.com; satoshi.ueno@ntt.com; rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu
Cc: mpls@ietf.org
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)

I understand the source of the confusion that the word "dropped" can create in a packet world.

The term "ignored" is not semantically equivalent to the intent of the original word "dropped". I would therefore propose the following rephrase:

        A.  External controls overruled by higher priority requests
            (e.g., administrative requests and requests due to link/node
            failures) or unable to be signaled to the remote end (e.g.,
            due to a coordination failure of the protection state) MUST
            be rejected.

The NE rejects the operator's command and behave like the command has never been requested.

Italo

P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 November 2009.

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
> Behalf Of RFC Errata System
> Sent: venerdì 12 marzo 2010 17.26
> To: benjamin.niven-jenkins@bt.com; dbrungard@att.com;
> malcolm.betts@huawei.com; nurit.sprecher@nsn.com;
> satoshi.ueno@ntt.com; rcallon@juniper.net;
> adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu
> Cc: mpls@ietf.org; rfc-editor@rfc-editor.org
> Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073)
>
>
> The following errata report has been submitted for RFC5654,
> "Requirements of an MPLS Transport Profile".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5654&eid=2073
>
> --------------------------------------
> Type: Editorial
> Reported by: Eric Gray <eric.gray@ericsson.com>
>
> Section: 2.5.4
>
> Original Text
> -------------
> 83  The external controls as defined in [RFC4427] MUST be supported.
>
>        A.  External controls overruled by higher priority requests
>            (e.g., administrative requests and requests due to
> link/node
>            failures) or unable to be signaled to the remote end (e.g.,
>            due to a coordination failure of the protection state) MUST
>            be dropped.
>
>
> Corrected Text
> --------------
> 83  The external controls as defined in [RFC4427] MUST be supported.
>
>        A.  External controls overruled by higher priority requests
>            (e.g., administrative requests and requests due to
> link/node
>            failures) or unable to be signaled to the remote end (e.g.,
>            due to a coordination failure of the protection state) MUST
>            be ignored.
>
>
> Notes
> -----
> Dropping a control is meaningless.  The original intent may
> have been to say "control messages", but this requirement is
> stated in the section "Management-Plane Operation of
> Protection and Restoration"
>
> In any case, using "ignored" instead of "dropped" fixes the
> problem regardless of the original intention.
>
> 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.
>
> --------------------------------------
> RFC5654 (draft-ietf-mpls-tp-requirements-10)
> --------------------------------------
> Title               : Requirements of an MPLS Transport Profile
> Publication Date    : September 2009
> Author(s)           : B. Niven-Jenkins, Ed., D. Brungard,
> Ed., M. Betts, Ed., N. Sprecher, S. Ueno
> Category            : PROPOSED STANDARD
> Source              : Multiprotocol Label Switching
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>