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

[Enke Chen <[e-mail]>]

Hi, John:

I now remember the reason for having 0xFF there.  It was something that we discussed years ago.

It was something like: since the actual length is larger than 255 and there is only one octet,
we just go with the largest possible value 255.  (The value does not matter once the real length
field is reached.)

Thanks.  -- Enke

On 6/24/16 3:29 PM, Enke Chen wrote:
> 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)" <[e-mail]>
>>> Date: 6/21/2016 6:10 AM (GMT-05:00)
>>> To: [e-mail], Susan Hares <[e-mail]>, [e-mail], [e-mail], [e-mail]
>>> 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
>