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@xxxxxxxxxx] > Sent: 31 March 2014 20:09 > To: Adrian Farrel > Cc: ietf@xxxxxxxx; mpls@xxxxxxxx > 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@xxxxxxxxxxxx> 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@xxxxxxxx] On Behalf Of The IESG > >> Sent: 26 March 2014 19:57 > >> To: IETF-Announce > >> Cc: mpls@xxxxxxxx > >> 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@xxxxxxxx mailing lists by 2014-04-09. Exceptionally, comments may be > >> sent to iesg@xxxxxxxx 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@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls