RE: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard

Thanks Eric,

"reject the message" means send some form of error response?
Or do you mean "drop the message" and "vigorously report it"?

Thanks,
Adrian

> -----Original Message-----
> From: Eric Osborne [mailto:eric@notcom.com]
> Sent: 31 March 2014 20:09
> To: Adrian Farrel
> Cc: ietf@ietf.org; mpls@ietf.org
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates
to
> MPLS Transport Profile Linear Protection) to Proposed Standard
> 
> Hello Adrian, WG-
> 
>   I propose this:
> 
> Malformed TLV: reject the message and vigorously report it
> Unknown TLV type: report the TLV, ignore the TLV and process the rest
> of the message
> 
> I'm open to other opinions, though.
> 
> 
> 
> 
> eric
> 
> On Wed, Mar 26, 2014 at 4:33 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> > Hi,
> >
> > I have one issue I want to bring up as a last call comment. I discussed it
> > briefly with Eric and we agreed it is something that needs wider discussion
than
> > just a late editorial change.
> >
> > Currently 6378 does not describe the format of PSC TLVs and
> > draft-ietf-mpls-tp-itu introduces one without defining the format tightly.
> > Therefore, this document contains a simple statement of the fields and
> meanings
> > in a TLV.
> >
> > However, 6378 also does not state how to handle:
> > - a malformed TLV
> > - an unknown TLV type
> >
> > We need to add some simple text to cover this.
> >
> > Options for each of the above are:
> > - ignore the TLV but process the message
> > - report the TLV but ignore the TLV and process the message
> > - ignore the message
> > - report the message but ignore it
> > - reject the message
> >
> > Thanks,
> > Adrian
> >
> >> -----Original Message-----
> >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG
> >> Sent: 26 March 2014 19:57
> >> To: IETF-Announce
> >> Cc: mpls@ietf.org
> >> Subject: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to
> > MPLS
> >> Transport Profile Linear Protection) to Proposed Standard
> >>
> >>
> >> The IESG has received a request from the Multiprotocol Label Switching WG
> >> (mpls) to consider the following document:
> >> - 'Updates to MPLS Transport Profile Linear Protection'
> >>   <draft-ietf-mpls-psc-updates-03.txt> as Proposed Standard
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action. Please send substantive comments to the
> >> ietf@ietf.org mailing lists by 2014-04-09. Exceptionally, comments may be
> >> sent to iesg@ietf.org instead. In either case, please retain the
> >> beginning of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>
> >>    This document contains four updates to the Protection State
> >>    Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
> >>    (MPLS-TP) Linear Protection" . Two of the updates correct existing
> >>    behavior.  The third clarifies a behavior which was not explained in
> >>    the RFC, and the fourth adds rules around handling capabilities
> >>    mismatches.
> >>
> >>
> >> The file can be obtained via
> >> http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/
> >>
> >> IESG discussion can be tracked via
> >> http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ballot/
> >>
> >> No IPR declarations have been submitted directly on this I-D.
> >>
> >> _______________________________________________
> >> 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