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

["John G. Scudder" <[e-mail]>]

On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> "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."

And it's a fatal error if it's not?

(Remember this is before the session becomes established, so the principle of service survival above all that would applied in the error-handling spec doesn't apply.)

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

Is there some reason insisting that the non-extended length field be 255 is better than ignoring it once you've determined by inspection of the non-extended parameter type that the extended encoding is in use? The logic would be, if the (one byte, non-extended) parameter type = 255, then use the extended encoding, and ignore the one byte non-extended length field.

If we made this change, the spec would say, MUST send non-extended length as 255, MUST ignore on receipt if the following eight bits (the non-extended type field) are 255.

Thanks,

--John