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

From: RFC Errata System <[email-masked]>
Date: Fri, 12 Mar 2010 08:26:29 -0800 (PST)

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 <[email-masked]>

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

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 19 Mar 2010 17:11:37 +0100

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:

            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, [email-masked], effective since 1 November 2009.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of RFC Errata System
> Sent: venerdì 12 marzo 2010 17.26
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] [Editorial Errata Reported] RFC5654 (2073)
> 
> 
> 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. 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: <[email-masked]>
Date: Fri, 19 Mar 2010 21:17:30 +0000

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 [[email-masked]]
Sent: 19 March 2010 16:11
To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)

Italo

---

From: Eric Gray <[email-masked]>
Date: Mon, 29 Mar 2010 15:47:43 -0400

Ben,

	I agree with your interpretation of what it means for a command 
to be rejected (to reject and instruction or input is more active than 
to ignore).  Further, unless the explanation Italo gives below means
that - in his terms - "reject" means the same thing as "ignore", I am
at a loss to understand the statement:

"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.

	Further, I have encountered very explicit examples of in-depth
specification of exactly how a lower-priority instruction is supposed
to be handled.  In IEEE state-machine specifications, for example, the
behavior expected when an operator asserts an input that has a lower
priority than an existing input to the state machine, is that the input
has no effect (unless the operator hold the input constant until all 
higher-priority inputs are removed, at which time the lower-priority 
input is acted on).

	Unless there is an explicitly stated - universally agreed on - 
requirement that an explicit rejection is required, I believe that it
is sufficient to say that the input is ignored.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 19, 2010 5:18 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073)

Ben

Italo

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Mon, 29 Mar 2010 22:15:38 +0200

Eric to the your point... (snippet)

> 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
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
> 
> To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> The term "ignored" is not semantically equivalent to the intent of the
> original word "dropped". I would therefore propose the following
> rephrase:
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 30 Mar 2010 08:26:18 +0200

Hi all,

according to my investigation, it is actually the case that "the NE actively informs the Operator that the attempt by the Operator to execute the external command was unsuccessful".

As a consequence, I would prefer to say "MUST be rejected".

Italo

> From: LEVRAU LIEVEN 
> Sent: lunedì 29 marzo 2010 22.16
> To: Eric Gray; [email-masked]; BUSI ITALO; 
> [email-masked]; [email-masked]; 
> > 	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
> > 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of [email-masked]
> > I understand the source of the confusion that the word 
> "dropped" can 
> > create in a packet world.
> > 
> > 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, 
> [email-masked], 
> > effective since 1 November 2009.
> > 
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of RFC Errata System
> > > 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:
> > > -------------
> > > rejected. When a decision is reached, the verifying party 
> (IESG) can 
> > > log in to change the status and edit the report, if necessary.
> > >

---

From: Eric Gray <[email-masked]>
Date: Tue, 30 Mar 2010 08:52:55 -0400

I think that there is some consensus developing both in this discussion
and elsewhere.  There is (of course) some confusion over the meaning of
certain terms, and the way things might be specified in the IETF - as
opposed to elsewhere.

Essentially, a reasonable implementation will not quite ignore a user
instruction (users would doubtless resent that rather severely).  It
is not quite clear what it means to "not quite ignore" instructions
from the user.  The idea is that only the highest-priority input at
any given instant in time will result in a state-change for equipment
(services, or the network).

In my opinion, we don't really want to get bogged down in terminology
issues or detailed over-specification - particularly after the fact
(this is an already published RFC, after all).

The reason why I created this errata in the first place is that - in
other work in progress - we feel almost compelled to perpetuate the
exiting wording even though it is clearly incorrect.  Specifically,
in the MPLS-TP CP draft, we captured requirements from a number of 
drafts (unfortunately including this already published RFC).  In the
process, it came to light that it makes no sense to "drop" a command
- yet this is what the referenced source document says.

So, either we take some steps to correct the error, or we find our
selves constrained to perpetuate it.

I think there is some agreement developing around using "reject" as
a repalcement for either "drop" or "ignore" - as long as we can do
this without creating the ripple-down effect of being compelled to
define exactly what we mean by "reject"...

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 15:42:27 +0200

I also believe that we need to phrase it stronger than just saying "drop" or "ignore" - to imply that some (whatever) kind of feedback to the "requester" needs to be considered as well.
Using "reject" makes sense for me.

Regards,
Manuel

> Behalf Of Eric Gray
> Sent: Tuesday, March 30, 2010 2:53 PM
> To: LEVRAU, LIEVEN (LIEVEN); [email-masked]; 
> BUSI,ITALO (ITALO); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> From: LEVRAU, LIEVEN (LIEVEN) 
> [mailto:[email-masked]] 
> To: Eric Gray; [email-masked]; BUSI, ITALO 
> (ITALO); [email-masked]; [email-masked]; 
> On Behalf Of
> > [email-masked]
> [email-masked];

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Wed, 31 Mar 2010 23:17:42 -0400

It depends if you are specifying the data plane or mibs. Always, if selecting one sentence out of many, it is not complete (as Eric says). This sentence from RFC5654 was more from the data plane view using the familiar packet term "dropped" vs. transport's G.808.1 "discarded".

I also agree we don't want to load this too much. "Reject" is not familiar wording. Suggest using then wording from G808.1:
"External commands which are preempted or denied by other higher priority conditions, states or requests, are discarded."

I think the choices are: "denied" or "discarded".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 31, 2010 9:42 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; BRUNGARD, DEBORAH A (ATTLABS); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)

Regards,
Manuel