Document: draft-ietf-mip6-hiopt-10.txt Reviewer: Francis Dupont Review Date: 2008-01-30 IETF LC End Date: 2008-02-04 IESG Telechat date: 2008-02-07 Summary: Not ready Comments: I have three series of comments: editorial (which should be handled by the RFC editor but you may fix them if (and only if) you publish a new version for a different reason), formal and not-formal. Editorial comments: - ToC page 2 and 7 page 18: s/Acknowledgements/Acknowledgments/ - 4.2 page 13: the [Editor's note] is a sure source of editorial issues (for instance the abbrev AVP) - 4.2 page 13: s/OPTION_CLIENTID/Client-id option/ - 4.[23] page 14: s/Relay Message/Relay-message/ - 4.2 page 14: s/Information Request/Information-request/ - please use the same spelling for pre(-)configured along. Formal comments: - you should explain in 1 (introduction) or 3 (options) that DHCP is used to get informations, not resources (so the client uses an Information-request message in the framework described by the RFC 3736 ("Stateless DHCPv6")) with a HN Identifier/Information option exchange. (I'll come back to this in not-formal comments). - 3.1 page 6: the HN Identifier field must be marked as optional. - 3.2.1 page 8: the HN Information is not to be provided to a mobile node because the MIP6 relay agent option is sent to a server. - 4.1 page 12: why the "should" for the two not more than one is not a SHOULD? - 4.2 page 13: RFC 3315 allows a chain of relays so the SHALL to the DHCP server should be relaxed. - 4.2 page 14: a second "to the DHCP server" - 4.2 page 14: the Relay-message (- and lower case m) option of the Relay-reply message carries a Reply, not an Information-request. - 4.3 page 14: the MIP6 Relay Agent option is not in the Information- request message. Not-formal comments: - I don't like to use DHCPv6 as a service discovery protocol as it was designed to assign resources. But as the RFC 3736 narrowed the protocol to this kind of things it is a matter of taste (but please explain this point and cite the RFC). - the HN Identifier/Information is not at all in the style of DHCPv6 which uses two (other) ways: * ORO when the client just says it'd like to get it * options, including skeleton options when the client has to say more, even it is just the number of options in the answer Applied to the Home Network options, they should be merged and the Identifier become a sub-option. - ORO doesn't make sense for HN Information (nor more it makes sense for IAs). ORO could be used to replace the id-type 2 but IMHO it is not a good idea. - as a DHCPv6 implementor, I don't like at all optional fields (and the HN Indentifier is an optional field - IMHO the V flag should be in the option itself, not in sub-options - the architecture enforces the NAS to be the first (and even the only) DHCP Relay. There is no good reason for this constraint and a better wording can remove it, i.e., the only point to keep is the excellent idea to collocate the NAS and the DHCP agent - Quoting RFC 4580/4649 this statement should be added about server behavior with MIP6 Relay Agent option: "There is no requirement that a server return this option and its data in a Relay-reply message." - the MIP6 Relay Agent option is brain damaged: either the relay doesn't know the infos to answer and it forwards the request to the next agent, or it knows and it is silly to insert the answer in an agent option when it is so simple to just answer. So in place of to get an active relay with a passive server I propose to follow the architecture of DHCPv6 as it was designed and to use an agent which is a relay or a server according it can answer or not (note as a relay may forward a request to multiple servers the "or" is not exclusive and an ORO for a very not-MIP6 option is not an issue). - the SHALL for the exclusive use of the Client-id for the MN identification should be removed as it is very unlikely the NAS knows the MN's DUID. BTW the Client-id option is not mandatory in Information-requests... - finally, prefixes have lifetimes when informative options have none (and RFC 4242 is Information-request wide) so I propose to reuse the ia-prefix option layout in HN prefix sub-option Thanks Francis.Dupont@fdupont.fr PS: as the last call is still open you can consider my not-editorial comments as last call comments, i.e., if you ask I can cut & past them to the MEXT and/or DHC list.