Hi, Jari
The RFC Editor notes were already reflected in hiopt-11.txt
Just regarding comment for Section 3.3.1 (in hiopt-10),
the comment is not valid in the new draft because the sub-opt-codes
of the HN information sub-option does not exactly match those of the
MIP6 Relay agent option now due to the merge of HN indentifier option
& HN information option, and change of the HN identifier field into a
sub-option.
In hiopt-10:
The Sub-option Codes for both OPTION_MIP6_RELAY and OPTION_MIP6_HNINF
options:
o Home network prefix 1
o Home agent address 2
o Home agent FQDN 3
In hiopt-11:
The Sub-option Code for OPTION_MIP6_HNINF option:
o Home network identifier 1
o Home network prefix 2
o Home agent address 3
o Home agent FQDN 4
The Sub-option Codes for OPTION_MIP6_RELAY option:
o Home network prefix 1
o Home agent address 2
o Home agent FQDN 3
Thanks. :)
- Best regards,
Heejin.
------------------------------------------------------------------------------------------------------------
Issues from my AD review have been addressed. I have also gone through the
changes related to Bernie's review. The following issues appear
insufficiently addressed:
- Adding IANA rules on how new allocations can be made
- Adding IANA instructions on id-type field
- References regarding FQDN encoding are not all in place
However, I have started IETF Last Call despite these issues. The tracker has
RFC Editor notes fixing these (copied below). If the authors can update the
draft in the next couple of days even during the last call, that would be
helpful for reviewers.
Jari
Change in Section 3.1:
OLD:
This field MUST be set in the form of FQDN [RFC1035].
NEW:
This field MUST be set in the form of FQDN, encoded
as specified in Section 8 of [RFC3315].
Change in Section 3.3.1:
OLD:
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:
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. These are encoded as specified in Section
3.2.1.
Add the following text to the end of the IANA Considerations
section:
These Sub-option Codes should be placed in a new name
space "DHCPv6 Mobile IPv6 Sub-option Codes" under the same
registry. Future values can be allocated via Standards
Action or IESG Approval.
In addition, a new name space "Home Network Identifier
Option id-type Values" should be created, again in the
same registry. Values 0, 1, and 2 are assigned by this
document as specified in Section 3.1. Future values can
be allocated via Standards Action or IESG Approval.
2008/2/13, Jari Arkko <[EMAIL PROTECTED]>:
>
> 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
