On 12-04-05 19:25, Bernie Volz (volz) wrote:
> I kindly request that we adopt this document as a DHC WG work item.
I do support this work and its adoption.

I also have couple of comments:

0. Would it be reasonable to name this work 3315bis?

1. I assume this work will also cover all combinations of
IA_NA/IA_PD/IA_TA. But what about IA_PA, specified in
draft-ietf-dhc-host-gen-id? This work was adopted by DHC, so authors
should take a closer look at it. (I'm sorry I can't offer any better
comments here. I haven't read host-gen-id yet).

2. stateful-issues draft is a very useful work. Once adopted it should
also look at CGA issues - my understanding is that it basically degrades
DHCP into registration service, compared to normal assignment service. I
haven't read CGA drafts recently, so again this is only a pointer to
something that should be looked at. It is possible that there's nothing
to do in that matter.

3. Abstract could be reworded: "the ne options for Prefix Delegation
options for DHCPv6 into DHCPv6" part is repetitive. The same is true for
first paragraph of Introduction section.

4. Text refer to different IA options as IA_. I think it would look
better without the underscore. If that is not clear, perhaps it could be
clarified that "IA option" means any of IA_NA, IA_TA or IA_PD.

5. Section 3.1 states that client MUST ignore IAs with status code
NoAddrAvail. That doesn't help much. What about other status codes?
IA_PD may be returned with NoPrefixAvail. Much better would be to say
that client MUST ignore IAs with status code other than Success.

We should also add that client SHOULD rate advertise without assigned
IAs lower than other advertises, but exact advertise rating algorithm is
up to client imlementors. For example, I would implement a client that
accepts advertise with preference=5 and all IAs assigned rather than one
with preference=10, but without IA_NA or IA_PD assigned.

6. Section 3.2 says that 3 non-success status codes (NoAddrsAvail,
NoPrefixAvail and NotOnLink) should appear within IA options. It would
be better to not explicitely limit to those 3 status code, but say all
non-success status codes to maintain forward compatibility. Something
like "e.g. NoAddrsAvail, NoPrefixAvail, NotOnLink and other non-success
status codes" will do. BTW you missed UnspecFail code that is already
defined and could be used, so the text as it is does not cover all
situations from day 1.

7. It should be clarified that status codes are specified per instance
of an option, not per option type. Think about client that sends 3 IA_NA
options. It can receive 2 addresses and NoAddrAvail in the third
instance. That could be either due to pool depletion (unlikely) or
server policy that allow server to assign no more than 2 addresses per
client (likely).

8. Proposed replacement errata in section 3.2 should clarify that such
proposed action should be taken on each IA being answered.

9. Section 3.3 could mention relation between T1/T2 and information
refresh option (RFC4242). The reasonable clarification would be that
client MAY request other options in ORO when sending RENEW or REBIND.

10. Allowing PD to be confirmed with CONFIRM could be tricky. In many
deployment scenarios routing is configured separately for each delegated
prefix and server can't really say "yeah, I've never assigned you that
one, but it should be valid on your link.". I don't object allowing
IA_PD in CONFRIM, but it should be accompanied with a clause that server
MUST include IA_PD response only if it is certain that delegated prefix
is really valid. This will complicate things. What is client sends
CONFIRM with IA_NA and IA_PD and server can confirm that address is
on-link, but is not sure about prefix? There's no such status as
IdontKnow. Different IA combinations should be given more thought.

11. Section 3.5. A what??? Are you suggesting that client can send RENEW
*after* it sent RELEASE? If that is the case, I strongly object. Once
client released a lease, it has no further claims to released
address/prefix. It MUST NOT send RENEW. Proper way it to send REQUEST,
not RENEW. Also. Section 3.5 title mentions DECLINE, but there is
nothing about DECLINE in the text. Authors probably forgot adding a
sentence that DECLINE may be sent at any time when client owns a lease.

12. A question about proposed operation in section 3.6. What if there
are two servers. Imagines a case with 2 servers: one that provides
addresses and second one that provides prefixes. Client requests IA_NA
and IA_PD. What should client do?

13. In 3rd paragraph in section 3.6 it would be better to say
non-success status codes rather than NoAddrsAvail (or at least
NoAddrsAvail/NoPrefixAvail/NotOnLink/UnspecFail).

14. Section 3.7 is the most unfortunate. I understand the reasons that
led authors to that decision, so I sadly accept it.

Despite my comments, I strongly support this work and it adoption. It is
great that we will get this thing clarified.

Greetings to all woods dwellers,
Tomek