Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04

How about:

"An optional parameter with parameter type of 0xFF MUST NOT appear in the
list of optional parameters other than in first place and if it does appear,
then the optional parameters length MUST be 0xFF."

There is really no reason to entertain other combinations and I don't
want to have to write code to handle them.

Thanks,
jakob.

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen (enkechen)
> Sent: Friday, June 24, 2016 3:29 PM
> To: John G. Scudder <jgs@juniper.net>
> Cc: idr@ietf.org; rtg-dir@ietf.org; draft-ietf-idr-ext-opt-param@ietf.org; Bocci, Matthew (Nokia - GB)
> <matthew.bocci@nokia.com>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
> 
> Hi, John:
> 
> Please see below.
> 
> On 6/24/16 11:43 AM, John G. Scudder wrote:
> > Hi Matthew and all,
> >
> > Thanks for the review. Some comments below.
> >
> >> From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
> >> Date: 6/21/2016 6:10 AM (GMT-05:00)
> >> To: idr@ietf.org, Susan Hares <shares@ndzh.com>, jgs@juniper.net, rtg-dir@ietf.org, draft-ietf-idr-ext-opt-
> param@ietf.org
> >> Subject: [Idr] Routing directorate QA review of	draft-ietf-idr-ext-opt-param-04
> > ...
> >
> >> Minor Issues:
> >>
> >>
> >>
> >> 1) Section 2, Protocol Extensions.
> >>
> >> You have labelled the existing Length and Type fields as 0xFF. I assume the meaning of the second is still 'Type'
> since that is
> >>
> >> what any implementation would reasonably interpret it as, and that is the registry you are using a code point
> from. So it
> >>
> >> might be better to say in the text above the figure at the top of page 3 that the length and type fields in
> [RFC4271]
> >>
> >> are set to 0xFF.
> >
> > Is your proposal to use the diagram verbatim from 4271, but say in the prose that the type and length are 0xFF?
> I'm fine with whatever seems clearer to folks.
> >
> >> Also, you don't explicitly define what a receiver should do with the length field if the type is 0xFF. Does it
> ignore it,
> >>
> >> or does it check that it is 0xFF and treat the OPEN message as malformed if it is < 0xFF?
> >
> > This is a good question, and TBH I don't recall why we specified a value for the legacy length field instead of
> simply saying it should be ignored.
> > Maybe Enke remembers? Right now I'm inclined to say it should be ignored on receipt, but I'm open to discussion. I
> guess even if we make that change we can still spec it be sent as 0xFF, for purposes of debuggability, but this is
> not a big deal.
> >
> 
> Here is what RFC 4271 says about the "Optional Parameters Length":
> 
>          This 1-octet unsigned integer indicates the total length of the
>          Optional Parameters field in octets.  If the value of this
>          field is zero, no Optional Parameters are present.
> 
> If the "Optional Parameters Length" field is 0, then the Optional Parameters
> will not be parsed and thus the new length field would not be reached.
> 
> I am not sure, but that might be the reason that we have it as 0xFF.
> 
> It needs to be at least 1 for the "Parm. Type" field to be parsed.  Once the
> "Parm. type" is parsed, and if its value is 0xFF, then the two-octet length
> field follows.  The procedure is more than just "ignoring" the field.
> 
> Thanks.  -- Enke
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr