[dhcwg] Comments on draft-ietf-dhc-pd-exclude-02

[Tomasz Mrugalski <[e-mail]>]

Hi,
I've just read the updated version of draft-ietf-dhc-pd-exclude-02
draft. Thank you for amending the draft according to most of my
comments. It looks good.

I have several more comments:

1. Section 5.1 describes SOLICIT-ADVERTISE exchange and concludes that
received PD_EXCLUDE may be used to select best server. You may want to
add a single sentence similar to "Requesting router MUST proceed to
Prefix Delegation procedure described in section 6.1".

2. Section 5.1 describes 4 message exchange. What if delegating router
wants to use rapid-commit (SOLICIT-REPLY)? You should add a
clarification that requesting router MUST use received values in REPLY
if rapid-commit option was sent in SOLICIT (recommended). Alternatively,
you may say that rapid-commit is not allowed with PD_EXCLUDE (that would
be unnecessary restriction, so it is not recommended).

3. I acknowledge that authors chose not to follow ORO suboption approach
proposed in draft-mrugalski-dhc-dhcpv6-suboptions. That is unfortunate,
but I can live with it. However, if you still considering that
possibility, I'd like to present additional arguments that may support
ORO suboption approach.

Since PD_EXCLUDE implementation requires modification of both server
(delegating router) and client (requesting router) code, there's no real
difference if you:
a) send top-level ORO and server needs to know that this specific
PD_EXCLUDE option does not go to the message directly, but rathere
within IAPPREFIX
b) send ORO within IA_PD (or IAPREFIX) and server needs to parse it in
those scopes

In both cases, server requires custom logic to be coded to serve
PD_EXCLUDE to requesting routers. My opinion is that option b) would be
generic and would allow reusing this logic for other options that may be
stored as suboptions.

Think about this in a long term. 10 years from now, there will  probably
be around 200 options defined. With your current approach, server will
need to decide on a per option basis, where to return requested options
- directly in message or perhaps within other options.

Ok, that was the last time I tried to convince you to use ORO suboption.
Regardless of your decision, I strongly support your draft.

Good luck with the presentation on Thursday!

Regards,
Tomek