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

[Ole Troan <[e-mail]>]

Tomek,

thanks for good comments!

>> We had a last call on this prior to the Prague meeting, and there was
>> work done off list, but no responses on-list.   If you support this
>> work, please indicate that you support it.   If you oppose the work,
>> please provide suggestions, comments, or reasons why it's entirely a
>> bad idea.
> I read and support this draft.
> 
> I know that it's way past dead-line, so feel free to ignore my comments.
> 
> Here are my comments. If it is not too late, you could consider them:
> 
> 1. Section 1:
> "single aggregatable route/prefix has to represents one customer"
> => remove "has to" or change represents to represent.

agree.

> 2. Section 4.1
> "The requesting router MUST NOT assign the excluded prefix to any of its
> downstream interfaces.". Is this implicit suggestion that assigning
> excluded prefix to upstream interface is ok? That would be against
> RFC3633, Section 12.1 that forbids that. This is probably ok, but then
> "updates: 3633" should be added to the preamble (and possibly a simple
> clarification). However, if the excluded prefix is handled in some
> different way (like SLAAC), then it is ok in current form.

we are basically trying to say that the excluded prefix is not delegated to the requesting router.
that means the requesting router has no 'ownership' of that prefix and cannot assign it to any interface.
obviously the delegating router can advertise that prefix in an RA and then the requesting router can use SLAAC to configure an address out of the prefix. do you think this needs clarification, if so suggested text?

> 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 tend to agree, what do my co-authors think?
can't remember why we put this in the first place...

> 4. Section 5.1
> My understanding was that requesting router is supposed to include
> PD_EXCLUDE in ORO in SOLICIT, REQUEST, RENEW, REBIND and CONFIRM. Yet,
> there is only Solicit message mentioned in the first sentence of 5.1.
> Remaining message types should probably be mentioned as well.

what about:

If the requesting router implements the solution described in Section 4.1
then the requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option in DHCP messages
as described in section 22.7 of RFC3315.

> 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.

good point, I wasn't aware of this. I also think including the ORO at the correct option 'scope' is better.
any objections to that?

cheers,
Ole