I think these changes look good. Please take care of the other edits too (some were duplicates to this) that I gave you as the RFC Editor notes.
Then there's still a few Discusses that I have not looked into. Jari Heejin Jang kirjoitti: > Hi, Francis. > > I'm attaching the revised document based on your feedback. > To see the revision results for each comment, kindly see below. > Kindly send a rely and let me know there are things to be revised more. > > I think that your comments really helped to enhance this document. > Thanks for your help again. > > ps> It seems that I'm not allowed to send emails to the Gen-art > and my mails may be filtered out because I'm not a member. > Could you let me know what to do to handle this problem? > > >> -----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/ >> > > Done > > >> - 4.2 page 13: the [Editor's note] is a sure source of editorial >> issues (for instance the abbrev AVP) >> > > That sentence was removed. > > >> - 4.2 page 13: s/OPTION_CLIENTID/Client-id option/ >> > > This sentence related to the use of Client-id option was removed to give > liberty to the implementation according to your suggestion. > > >> - 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. >> > > Terms are unified into Relay Message, Information-request, > Relay-reply and Relay-forward as described in RFC3315. > > >> 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). >> > > In Section 1 > > Old: > "This problem can be solved by delivering one or more home network prefix > information to the mobile node by means of DHCP." > > New: > "This problem can be solved by delivering home network prefix information > to the mobile node by means of the stateless DHCPv6 [RFC3736] [RFC3315]." > > In Section for Normative Reference, > > "[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol > (DHCP) Service for IPv6", RFC 3736, April 2004." > > >> - 3.1 page 6: the HN Identifier field must be marked as optional. >> > > The HN Identifier field is replaced with a HN Info sub-option now. > > >> - 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. >> > > In Section 3.2.1 > > Old: > "Home Network Information > > A home network prefix, home agent IP address or home agent > FQDN to be provided to a mobile node according to the > sub-opt-code.~" > > New: > "Home Network Information > > A home network prefix, home agent IP address or home agent > FQDN to be provided to the DHCP server according to the > Sub-opt-code.~" > > >> - 4.1 page 12: why the "should" for the two not more than one is not >> a SHOULD? >> > > It changed into the "SHOULD". But the sentence including latter one is > removed > because the V flag does not exist any more. This is explained later. > > >> - 4.2 page 13: RFC 3315 allows a chain of relays so the SHALL to the >> DHCP server should be relaxed. >> > > Old: > "Upon receiving the Information-request from the mobile node, the DHCP > relay agent SHALL forward the message to the DHCP server as per > [RFC3315]." > > New: > " When receiving an Information-request message from the mobile node, > the DHCP relay agent forwards the message to the DHCP server or > another DHCP relay as per [RFC3315]." > > >> - 4.2 page 14: a second "to the DHCP server" >> > > This sentence related to the use of Client-id option was removed to give > liberty to the implementation. > > >> - 4.2 page 14: the Relay-message (- and lower case m) option of the >> Relay-reply message carries a Reply, not an Information-request. >> > > Done > > >> - 4.3 page 14: the MIP6 Relay Agent option is not in the Information- >> request message. >> > > Old: > " When the mobile node receives the Information-request message with > the Home Network Identifier option in the Relay-forward message, it > checks the Information-request message includes the Home Network > Identifier option, MIP6 Relay Agent option and the Option Code for > the Home Network Information option in the OPTION_ORO." > > New: > " When a DHCP server receives an Information-request message with the > Home Network Information option in the Relay-forward message, it > SHOULD check whether the Information-request includes the Option Code > for the Home Network Information option in the Option Request option. > The Relay-forward message may include the MIP6 Relay Agent option in > case there was home information available for the mobile node at the > NAS." > > >> 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). >> > > Explained previously. > > >> - 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. >> > > The HN Id option and the HN info option are merged into a single option, > that is a HN Information option* as below according to your suggestion. > (* means a new one) And the HN id field is defined as its sub-option. > > New: > > "3.1. Home Network Information Option > > This option is proposed to allow exchange of the home network > information between the mobile node (DHCP client) and the DHCP > server. It is used to indicate the target home network requested by > the mobile node to the DHCP server in the Information-request > message. In the Reply message, it conveys the home network > information assigned by the DHCP server to the mobile node." > > "3.1.1. Home Network Information Sub-options > ... > Sub-opt-code > > A 16-bit unsigned integer for the type of the following > Home Network Information field. Possible values are: > > 1 Home network identifier > 2 Home network prefix > 3 Home agent address > 4 Home agent FQDN" > ..." > > >> - as a DHCPv6 implementor, I don't like at all optional fields (and >> the HN Indentifier is an optional field >> > > Explained previously. > > >> - IMHO the V flag should be in the option itself, not in sub-options >> > > As your recommentation in the previous email exchanges, > we decided not to require that the reply should carry the same number of > the HN info options in the reply. Thereby, the Id-type can function as a > role of V flag, so the V flag does not used any more. > > >> - 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 >> > > Old: > > "3. DHCP options for HA Dynamic Discovery > ... > The NAS and the DHCP relay agent are assumed to be collocated in this > solution. In the network where the NAS is not collocated with the > DHCP relay agent, the DHCP server will provide the home information > which has been preconfigured by the administrator or which is > acquired through the mechanism that is not described in this > document." > > "4.2. NAS/DHCP Relay Agent Behavior > > As described in Section 3, the NAS and the DHCP relay agent are > assumed to be collocated. The NAS communicates with the mobile node > during the network access authentication and interacts with the AAAH > (via the AAAV) using either Diameter NASREQ [RFC4005] or RADIUS > [I-D.ietf-mip6-radius] [Editor's note: The Diameter AVPs need to be > defined]. When receiving the MIP6 related RADIUS or Diameter > attributes returned by the AAAH, the NAS passes the information to > the collocated DHCP relay agent." > > New: > > "3. DHCP options for HA Dynamic Discovery > ... > A NAS is assumed to be co-located with a DHCP relay agent or a DHCP > server in this solution. In the network where a NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and thereby > it may assign to mobile node the home information which has been > preconfigured by the administrator or which is acquired through the > mechanism that is not described in this document." > > "4.2. NAS/DHCP Relay Agent Behavior > > As described in Section 3, a NAS is assumed to be co-located with a > DHCP relay or a DHCP server. The NAS communicates with the mobile > node during the network access authentication and interacts with the > AAAH (via the AAAV) using either Diameter NASREQ [RFC4005] or RADIUS > [I-D.ietf-mip6-radius]. When receiving the MIP6 related RADIUS or > Diameter attributes returned by the AAAH, the NAS passes the > information to the co-located DHCP relay agent or the server. The > following describes the behavior of the DHCP relay agent when the NAS > functions as a DHCP relay." > > >> - 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." >> > > New: > > "4.3. DHCP Server Behavior > ... > There is no requirement that the server return this option and its > data in a Relay message as other Relay Agent option > [RFC4580][RFC4649]." > > "8.1. Normative References > .., > [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, > June 2006. > > [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, > August 2006." > > >> - 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). >> > > This was the most difficult comment to be resolved. > We know what you are talking about after exchang of a few emails, > but such DHCP relay behavior looks inconsistent with the current > DHCP spec. After discussion, the authors decided to remove the > limitation that the NAS should be a DHCP relay, and it can forward > the received the request message to either the relay or 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... >> > > We decided to remove the texts which are about the use of Client-id, > and rely on the implementation in order search for the mapped data > for the requesting mobile node at NAS. > > Explained previously. > > >> - 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 >> > > As your recommendation, we defined so that the sub-option for the prefix > can carry preferred & valid lifetime as well and gave a figure for its > format. > It is described in Section 3.3.1, page 9. > > >> 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. >> > > Thanks. > > - Best regards, > Heejin _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
