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

Eric to the your point... (snippet)

:
> 
> "The NE rejects the operator's command and behave like the command has
>  never been requested."
> 
> 	IMHO, acting as if a command has not been given is exactly the
> same thing as ignoring it.
>
I think there should be some logic behind it that the request was indeed received, parsed and ignored so that it is eventually a traceable event.
./
Lieven
> 
> --
> Eric
> 
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> benjamin.niven-jenkins@bt.com
> Sent: Friday, March 19, 2010 5:18 PM
> To: Italo.Busi@alcatel-lucent.com; rfc-editor@rfc-editor.org;
> 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)
> 
> 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
> >
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls