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

From: <[email-masked]>
Date: Thu, 1 Apr 2010 18:12:42 +0200

I also see Deborah's point if only the data plane is concerned. However, as the chapter adresses functions for control by the operator and is headlined "Management-Plane Operation of Protection and Restoration", I felt it is usefull to having this as a "traceable event" (like I think Eric called it earlier).

If the majority is fine with it, however, I could live with "discard".

(and I saw some mails coming in while I was typing this...)

But, in case of using "discard", wouldn't we need to add the word "requests" to the sentence as well?
I.E. making it:   
] A.  External control requests...  [  
instead of    
] A.  External controls ... [

Remember, up to now the RFC text says "control", not "control messages" or "control requests".
(and as I had understood, clarifying this was Eric's main motivation...)

Thanks,
Manuel

> -----Original Message-----
> From: BUSI ITALO [mailto:[email-masked]] 
> Sent: Thursday, April 01, 2010 5:29 PM
> To: D'Alessandro Alessandro Gerardo; BRUNGARD, DEBORAH A 
> (ATTLABS); Paul, Manuel; [email-masked]; LEVRAU 
> LIEVEN; [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)
> 
> I understand that Deborah has some issues with "reject".
> 
> Therefore it looks like that we can converge on "discard".
> 
> Is "discard" acceptable?
> 
> For me it is fine.
> 
> Thanks, Italo
> 
> P.S. Please note my new email address, 
> [email-masked], effective since 1 November 2009.
>  
> 
> > -----Original Message-----
> > From: D'Alessandro Alessandro Gerardo 
> > [mailto:[email-masked]] 
> > Sent: giovedì 1 aprile 2010 13.03
> > To: BRUNGARD, DEBORAH A (ATTLABS); [email-masked]; 
> > [email-masked]; LEVRAU LIEVEN; 
> > [email-masked]; BUSI ITALO; 
> > [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)
> > 
> > I agree with Manuel's comment (some feedback to the operator 
> > shall be considered).
> > About the correct word to be used, I'm fine with either 
> > "reject" or "discard" clarifying the previous point.
> > 
> > Regards,
> > Alessandro
> > ------------------------------------------------------------------
> > Telecom Italia
> > Alessandro D'Alessandro
> > Transport & OPB Innovation
> > Via Reiss Romoli, 274 - 10148 Torino
> > phone:  +39 011 228 5887
> > mobile: +39 335 766 9607
> > fax: +39 06 418 639 07
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of BRUNGARD, DEBORAH A (ATTLABS)
> > Sent: giovedì 1 aprile 2010 5.18
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; 
> > [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)
> > 
> > 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)
> > 
> > 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
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] 
> > On 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]; 
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [mpls] [Editorial Errata Reported] RFC5654 (2073)
> > >
> > > 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"...
> > >
> > > -----Original Message-----
> > > From: LEVRAU, LIEVEN (LIEVEN)
> > > [mailto:[email-masked]]
> > > Sent: Monday, March 29, 2010 4:16 PM
> > > To: Eric Gray; [email-masked]; BUSI, ITALO 
> (ITALO); 
> > > [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)
> > > Importance: High
> > >
> > > 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: [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)
> > > >
> > > > 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)
> > > >
> > > > 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,
> > > [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)
> > > > >
> > > > >
> > > > > 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
> > > > > _______________________________________________
> > > > > mpls mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/mpls
> > > > >
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls
> > > _______________________________________________
> > > mpls mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> > 
> > Questo messaggio e i suoi allegati sono indirizzati 
> > esclusivamente alle persone indicate. La diffusione, copia o 
> > qualsiasi altra azione derivante dalla conoscenza di queste 
> > informazioni sono rigorosamente vietate. Qualora abbiate 
> > ricevuto questo documento per errore siete cortesemente 
> > pregati di darne immediata comunicazione al mittente e di 
> > provvedere alla sua distruzione, Grazie.
> > 
> > This e-mail and any attachments is confidential and may 
> > contain privileged information intended for the addressee(s) 
> > only. Dissemination, copying, printing or use by anybody else 
> > is unauthorised. If you are not the intended recipient, 
> > please delete this message and any attachments and advise the 
> > sender by return e-mail, Thanks.
> > 
> > 
>