Subject: [Gen-art] The results of revision

From: Heejin Jang <[email-masked]>
Date: Tue, 12 Feb 2008 14:35:43 +0000 (GMT)

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-masked] [mailto:[email-masked]]
> Sent: Thursday, January 31, 2008 1:14 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 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-masked]
> 
> 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-masked]
http://www.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Feb 2008 19:55:18 +0200

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

---

From: "Heejin Jang" <[email-masked]>
Date: Wed, 13 Feb 2008 09:38:00 +0900

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.

---

From: "Heejin Jang" <[email-masked]>
Date: Fri, 22 Feb 2008 15:16:36 +0900

Hi, Francis.

I sent the below mail previously to ask your opinion for the revised document.
Kindly give me a reply so that we can go forward with the document.

Regarding the relay's behavior, it was modified so that the relay
attaches the MIP6 relay option when receiving a DHCP message (not only
Information-request message). So the relay has no need to look inside
the received packets to see the HN information option in them.

FYI, I'm attaching the new document which was revised based on comments from
you and iesg members.

Thanks and have a nice weekend!

- Best regards,
Heejin.