Re: [dhcwg] VIV*O options.

David W. Hankins wrote:
> Does anyone know of a client or server that has implemented VIV*O (RFC3925)?
> I'm looking for targets for interoperability testing.
>
> RFC4243 relay agents would be interesting too.
>
>
> While looking at this, I had to come to grips with a minor code reuse
> problem I'd like to solicit opinions on.
>
> We currently use the same code to dissect the options buffer as we do
> any encapsulated space (so, VIV*O would use this as well).
>   

As long as you start after the Enterprise OID (and data length), that 
shouldn't be an issue.

> This loop that traverses options looks for PAD and END options, which
> RFC 3925 explicitly states are not special cases, with no special
> handling.  Unless I'm mistaken, RFC 4243 makes no mention.
>   

I'd interpret 42423 to align with 3925.  Sub-options 0 and 255 have no 
special meaning.

> That means I get to add more instructions to this loop, or write a new
> loop, neither of which I particularly fancy.
>
> However, enterprise id 0 is reserved according to IANA, which I take to
> mean is an illegal value, so it shouldn't appear in packets at all.
>   

I'm a little confused... what does the Enterprise OID have to do with 
parsing the sub-optioned space?

> My most-code-reused solution, then, is to use 0x00000000 as both PAD
> and END options for this encapsulated space (END trumps PAD, so this
> causes the server to stop processing the buffer if it's encountered -
> a zero is effectively an error condition).
>   

Even more confused... where's that 4-byte value coming from (in the 
context of this discussion)?  And, what PAD option?  There is no pad.  
No END either.

> That would be true for any encapsulated space with no defined END option.
>
> What are folks opinions on this approach, not just for VIV*O, but for
> encapsulated spaces in general?
>   

Re: [dhcwg] VIV*O options.

Attachment: akostur.vcf