Hi, Francis. We appreciate your kind and through review.
We believe that those comments are very helpful to improve the document. The authors will revise the document based on your comments and will send the results in a separate mail. But some of comments are not clear to me, and kindly read the inline and clarify it to me. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 31, 2008 1:14 AM > To: [email protected] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jari Arkko > Subject: review of draft-ietf-mip6-hiopt-10.txt > > I have been selected as the General Area Review Team > (Gen-ART) reviewer for this draft (for background on Gen-ART, please > see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > > 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: unknown > > 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. Ok. All of the editorial comments will be reflected during next revision. > 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. Ok. > - 4.1 page 12: why the "should" for the two not more than one is not > a SHOULD? Are you asking that why one is "should"' and the other is "SHOULD" in Section 4.1? If my understanding is right, we will unify them to "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. Ok. > 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). Ok. If you have some good texts in your mind for this and suggest it, it would be much of help. > - 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. I think that I didn't catch this point well. Are you suggesting to use the HN identifier option as a sub-option of ORO? However, RFC3315 says as follows; " The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned." There is also an example of RFC4074 where the client sends an ORO with an independent (not sub-option) DHCPv6 option to give a hint for the specified option in ORO to the server. If you know some documents where some option is used as a sub-option of an ORO, kindly let me know it. > - as a DHCPv6 implementor, I don't like at all optional fields (and > the HN Indentifier is an optional field This issue has been discussed before in DHC wg. The field was originally designed as a fixed field but the DHC folks preferred not to carry the empty field when it is not used, finally we decided it as an optional field. > - IMHO the V flag should be in the option itself, not in sub-options When the MN has requested the home information with the id-type 2, that is no preference, some information may be assigned from the local domain while others from home network in a single HN information option. Therefore the V flag should exist in each HN information sub-option. > - 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 Ok. > - 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." Ok. > - 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). Ok. This may lead to a major change and the authors will think this issue over. In case when the MN asked the HN information with the id-type 2, the request needs to be delivered to the server though the relay agent can provide the required information. I'm not sure this can be supported by [RFC3315], and we'll look it into again. BTW, the home network information may be returned only by NAS (dhcp relay agent) or the DHCP server, but not by other relay agents because the provided home information is carried from the MN's home network to the NAS during authentication procedure (id-type=1) or configured in the local DHCP server (id-type=0). So, there is no need to ask the information to the next agent except the server. > - 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... Ok. In this case, can it be allowed that we mandate to carry the Client-id option with MUST or SHOULD in the Information-request message when it carries the HN identifier option? > - 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 Ok. > > Thanks > > [EMAIL PROTECTED] > > 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. Kindly forward your mail to MEXT and DHC ml. :) Thanks for your valuable feedback again. - Best Regards, Heejin _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
