Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01

[Stephen Jacob <[e-mail]>]

On Tue, May 10, 2011 at 12:04:01AM +0200, Tomasz Mrugalski wrote:
> 3. Section 4.2
> "The OPTION_PD_EXCLUDE option MUST be located before the possible Status
> Code option in the IAprefix-options field." Why forcing to use specific
> order? DHCPv6 does not impose any restrictions regarding sequence, in
> which options appear in a message or within other options. There's good
> reason for that - implementations may keep the options in structures
> other than simple lists or vector, like hash tables. Enforcing any
> specific order would be troublesome in that case. I propose to remove
> this sentence.

I very much agree with Tomek. I would prefer that no draft impose option
ordering constraints.

It sounds like Ole agrees, which is great. :)

> 5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is
> located in IA_PD (not in the message options field), but draft says that
> requesting router should request PD_EXCLUDE in ORO placed in message
> options field. Wouldn't it be more appropriate to put second instance of
> ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may
> consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its
> suggestions, if you that they are reasonable.

That would seem to make more sense.

It sounds like Ole agrees with this too, so I trust it'll be worked
out. :)

I have only one additional comment on this draft. It is not critical,
and I know I'm commenting on this awfully late in the game...

It is not wrong as-is, but I think it is a bit strange/confusing that
OPTION_PD_EXCLUDE (in 4.2. Prefix Exclude Option) is defined in such
a way that the "IPv6 subnet ID" is a suffix appended to the
'OPTION_IAPREFIX prefix-length', except maybe not ust a suffix because
it has to be octet-aligned so it might include some of the bits of
'OPTION_IAPREFIX prefix-length'.

I misunderstood the definition in section 4.2 until I read the
example at the end.

It also seems like a strange way to define option data. Does anything
else use this way of declaring a sub-prefix?

It would seem to me to have two pros:

	1) It saves some number of bytes of option space.
	2) It ensures that the OPTION_PD_EXCLUDE prefix is contained
	   in the OPTION_IAPREFIX prefix[*].

	   [*] except if octet-alignment requires replication of
	       the final few bits of the OPTION_IAPREFIX prefix,
	       in which case those could be incorrectly included
	       as different bit values, presumably, so it doesn't
	       really even guarantee #2, does it?

It would seem to have 2 cons:

	1) It is hard to understand.
	2) I think implementors may implement it incorrectly, causing
	   interoperability issues.

Given that pro #2 is a weak assurance and pro #1 only means saving a
few bytes (how much does that really matter? I would say not at all),
I think the cons significantly outweigh the pros.

I would suggest that OPTION_PD_EXCLUDE ought to include the full
prefix to exclude.

A downside is that clients (Requesting Routers) will need to validate
the value they receive to ensure that OPTION_PD_EXCLUDE is a subset
of OPTION_IAPREFIX (but they already ought to do some validation due
to the issue I raised in the subscript of pro #2, and that validation
is harder to get right than a simple "is this prefix contained in
this other prefix" comparison; something that one can probably do
with existing library code).

If a client fails to validate, that's its problem, and it will
probably be ok anyway if we make it a MUST for the server that
OPTION_PD_EXCLUDE be a subset of OPTION_IAPREFIX.

For the server implementor, the up-side is not having to write custom
code to handle this special kind of field type, and it means we don't
create an option whose value is defined based on the value of another
option (a situation which I also dislike).

Regards,
Stephen
-- 
 Stephen Jacob | [e-mail] | [phone]
 Nominum, Inc. |  http://www.nominum.com/  | [phone]