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

[Eric Gray <[e-mail]>]

Alessandro,

        I think most people agree with this point, yet the fact that an
implementer may need to implement certain "usability" features is not
the point in defining protocol standards.

        More and more in the IETF, we tend to do this anyway, because it
is important to the customers.  However, while this tendency exists,
the fact remains that this is a "motherhood and apple pie" factor with
not so much importance from the perspective of defining interoperable
standards.  From that perspective, what is important is that vendors
all agree in their implementations on the fact that only the highest
priority imperative present at any point in time is acted on.

        Put another way, if my implementation notifies the user that a
specific command was ignored because of an existing higher priority
imperative/condition - and vendor X's implementation does not - my
implementation is likely to make my customers happier than vendor X's
(at least in this one respect), but the ability of our implementations
to correctly interoperate is simply not affected by this distinction.

        Because ambiguity on this point has no impact on interoperability,
it is not as important to clarify this.

--
Eric

-----Original Message-----
From: D'Alessandro Alessandro Gerardo [mailto:[e-mail]]
Sent: Thursday, April 01, 2010 7:03 AM
To: BRUNGARD, DEBORAH A (ATTLABS); [e-mail]; Eric Gray; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [mpls] [Editorial Errata Reported] RFC5654 (2073)
Importance: High

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:  [phone]
mobile: [phone]
fax: [phone]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS)
Sent: giovedì 1 aprile 2010 5.18
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, March 31, 2010 9:42 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; BRUNGARD, DEBORAH A (ATTLABS); [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Eric Gray
> Sent: Tuesday, March 30, 2010 2:53 PM
> To: LEVRAU, LIEVEN (LIEVEN); [e-mail];
> BUSI,ITALO (ITALO); [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Monday, March 29, 2010 4:16 PM
> To: Eric Gray; [e-mail]; BUSI, ITALO
> (ITALO); [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> On Behalf Of
> > [e-mail]
> > Sent: Friday, March 19, 2010 5:18 PM
> > To: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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 [[e-mail]]
> > Sent: 19 March 2010 16:11
> > To: RFC Errata System; Niven-jenkins,B,Ben,DMK5 R;
> [e-mail];
> > [e-mail]; [e-mail];
> [e-mail];
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Cc: [e-mail]
> > 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,
> [e-mail],
> > effective since 1 November 2009.
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of RFC Errata System
> > > Sent: venerdì 12 marzo 2010 17.26
> > > To: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail];
> > > [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]; [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > 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 <[e-mail]>
> > >
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailing list
[e-mail]
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.