Subject: [Gen-art] Review of draft-ietf-mip6-hiopt-13

From: Alfred Hönes <[email-masked]>
Date: Wed, 16 Apr 2008 14:33:09 +0200 (MESZ)

At 16 Apr 2008 12:52:00 +0300, Jari Arkko <[email-masked]> wrote:

> Alfred, thanks for your review. The stuff that you sent me seems to be
> things that we need to fix. Please prepare a report and send it to
> Heejin. Heejin, please wait for Alfred's fixes before you submit the -14.
> 
> Jari

Here we go.

Note 1:
  As usual, change bars ('|') in column 1 and ^^^/vvv style pointer
  lines are used to precisely point to dangling text or changes
  proposed; they are annotation and in no way intended to become
  part of the draft.  Proposed text is re-`adjust`ed to RFC style.

Note #2:
  Numbering of items preserved from discussion with Jari,
  thus item (c) now intentionally left off below.

Note #3:
  All paragraphs affected by the retrofit requested by
  Jari (no MIP4, only dual-stack support) and already
  modified by Heejin in the meantime are excluded from
  the list below.  The same holds for the other small
  corrections already requested in this thread.

(a) Section 4.1, 4th paragraph

OLD:

   When the mobile node sets the Id-type to 1 in the request, it MUST
   include a sub-option with Sub-opt-code 1 which carries the FQDN of
   the target network such as "example.com".  Note that a single Home
|  Network Information option can carry at most one sub-option with Id-
|  type 1 in the request.
   ^^^^                                                             ^^^

NEW.1:

   When the mobile node sets the Id-type to 1 in the request, it MUST
   include a sub-option with Sub-opt-code 1 which carries the FQDN of
   the target network such as "example.com".  Note that a single Home
|  Network Information option can carry at most one sub-option with Sub-
|  opt-code 1 in the request.
   ^^^^^^^^                                                         ^^^^
or:

NEW.2:

   When the mobile node sets the Id-type to 1 in the request, it MUST
   include a sub-option with Sub-opt-code 1 which carries the FQDN of
   the target network such as "example.com".  Note that a single Home
|  Network Information option can carry at most one sub-option with Sub-
|  opt-code 1.
   ^^^^^^^^^^^                                                      ^^^^

RATIONALE:

Sub-options do not have an Id-type of their own.
The 6th paragraph of 4.1 and Section 4.3 clearly admit multiple
Home Network Information options in the request with Id-type 1,
but different Home Network Identifiers (target MSPs) in their
(single) sub-option of Sub-opt-type 1.  Therefore,
"Sub-opt-code" should be substituted there for "Id-Type".

But the modified last sentence -- per NEW.1 -- equally holds for
the response, if I truly understand the intent of the draft.
Thus, it apparently makes sense to also suppress the trailing
"in the request", as done in NEW.2.

Related PRO/CON considerations:
- The mobile node cannot enforce this condition in the response.
- The 8th paragraph already requests that the MN ignore a HNINF
  option with Id-type 1 in the reply which does not contain a
  home network identifier (Sub-opt-type 1) sub-option.

I recommend NEW.2, but also have no objections to using NEW.1,
if you have arguments in preference of that.
(Jari also has indicated leaving the choice to the authors.)

(b) Section 4.1, 5th paragraph

OLD:

   The mobile node MUST NOT include a Home Network Information option
   whose Id-type is other than 0, 1, and 2 as defined as Section 3.1. A
|  value of 1 is only available Sub-opt-code in the request.
                ^
SYMPTOM:

The last sentence is ambiguous.
Does "A value of 1" refer to the Id-type or to the Sub-opt-code?
Hence, does it mean:

   [...]
|  A value of 1 is the only Sub-opt-available code in the request.
                  ^^^^^
or:

  [...]
| In the Request, only a Home Network Information option whose Id-type
| is 1 can carry a sub-option, and this sub-option must have Sub-opt-
| code 1.

DISCUSSION:

In any case, I suggest to separate the clarified sentence from the
preceding one by a paragraph break (blank line), to better decouple
it from the preceding statement that is only related to the Id-type.
Thus, the two alternatives above result in the two proposals (below).

I'd prefer (NEW.1) over (NEW.2) because the latter restates
requirements already expressed in preceding parts of the text
and thus would add redunduncy to the text.
(Jari also has indicated leaving the choice to the authors.)

NEW.1:

   The mobile node MUST NOT include a Home Network Information option
|  whose Id-type is other than 0, 1, and 2 as defined as Section 3.1.
|
|  A value of 1 is the only Sub-opt-code available in the request.

or:

NEW.2:

   The mobile node MUST NOT include a Home Network Information option
|  whose Id-type is other than 0, 1, and 2 as defined as Section 3.1.
|
|  In the Request, only a Home Network Information option whose Id-type
|  is 1 can carry a sub-option, and this sub-option must have Sub-opt-
|  code 1.

(d)  Section 4.1, 2nd-to-last paragraph

OLD:

   As described later in Section 4.3, servers attempt to place multiple
   options and in the order of preference.  When provided with more than
|  one Home Network Information options having the different id-types or
                                               ^^^^
   with multiple sub-options for the same id-type, the mobile node
   SHOULD choose the first one that it can employ.

NEW:

   As described later in Section 4.3, servers attempt to place multiple
|  options and in the order of preference.  When provided with multiple
|  Home Network Information options having different id-types or with
|  multiple sub-options of the same id-type, the mobile node SHOULD
   choose the first one that it can employ.

RATIONALE:

Delete the tagged "the" for clarity.
Also tried to improve the readability and avoid a dangling singular/
plural conflict by again replacing "more than one" with "multiple".

(e)  Section 4.3, 1st paragraph, last line

Typo; please change   "a Id-type"  -->   "an Id-type"

(f)  4.3, 3rd paragraph, 1st sentence

OLD:
                                                              vvvvvvvv
|  When a DHCP server receives an Information-request message or it in
   the Relay-forward message, it SHOULD check whether the Information-
   request includes the Home Network Information option.  [...]

NEW.1:

|  When a DHCP server receives an Information-request message or it is
   vvvvvvvvvvvvv   v                                               ^^^
|  encapsulated in a Relay-forward message, it SHOULD check whether the
   Information-request includes the Home Network Information option.
   [...]

or, with more pleasant wording:

NEW.2:

|  When a DHCP server receives an Information-request message either
   vvvvvvvvvvvvvvvvvvvvvvvv    v                              ^^^^^^
|  directly or encapsulated in a Relay-forward message, it SHOULD check
   whether the Information-request includes the Home Network Information
   option.  [...]

RATIONALE:

Sentence is incomplete.  I guess that "is encapsulated" is missing
and should be inserted to give proper sense to the sentence.  NEW.2
should further improve the readability; I recommend it over NEW.1.

[Heejin: A hint to this garbled/incomplete sentence was intended for
 inclusion in my review of -12, but inadvertantly misplaced to point
 to another section, and has triggered a change there; I apologize.]

(g)  Section 4.3, 5th paragraph:

DISCUSSION:

To clarify the causality in the reasoning, "In case" needs to be
added in front of the second sentence (which introduces a three-
fold alternative discussion).

OLD (abbreviated):

   It MUST construct the Home Network Information option(s) according to
|  the following logic, and include it or them in the Reply.  The
   Information-request message includes:
       [...]

NEW (with more context, for clarity):

   It MUST construct the Home Network Information option(s) according to
|  the following logic, and include it or them in the Reply.  In case
|  the Information-request message includes:
   ^                                                          ^^^^^^^
       o A. Home Network Information option with Id-type 0

         [...]

       o B. Home Network Information option with Id-type 1

         [...]

       o C. Home Network Information option with Id-type 2

         [...]

(h)  Section 4.3, 2nd-to-last paragraph

OLD:

   The DHCP server should provide all of the matching home information
   in Home Network Information option(s) based on its policy.  It may
|  return the partially matched results.  [...]
         ^^^^^

NEW:

   The DHCP server should provide all of the matching home information
   in Home Network Information option(s) based on its policy.  It may
|  return partially matched results.  [...]
         ^

RATIONALE:

Matching is not considered in detail beforehand, so there is
no point in talking about "*the* partially matched results".
Thus, for clarity and consistency, delete the tagged "the".

(i)  Section 4.3, last paragraph

OLD:

   There can be several ways that the DHCP server knows the requested
   home network information.  For instance, as described in [I-D.ietf-
|  mip6-radius], a NAS can learn the information via RADIUS during
   network access authentication, and the DHCP relay co-located with the
   NAS can transfer it to the DHCP server [...]

NEW:

   There can be several ways that the DHCP server knows the requested
   home network information.  For instance, as described in [I-D.ietf-
|  mip6-radius] and [I-D.ietf-dime-mip6-integrated], a NAS can learn the
|  information via RADIUS or Diameter, respectively, during network
   access authentication, and the DHCP relay co-located with the NAS can
   transfer it to the DHCP server [...]

RATIONALE:

Other parts of the draft already have been updated to always
mention the DIAMETER work-in-progress in parallel to the
RADIUS work-in-progress as a suitable building block in AAA.

For consistency, this should be done here equally.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Heejin Jang <[email-masked]>
Date: Thu, 17 Apr 2008 07:44:21 +0000 (GMT)

Hi, Alfred.

All of the commets were reflected. 
Thanks for your sincere and kind review. 

Please see below. 

> -----Original Message-----
> From: Alfred H?es [mailto:[email-masked]] 
> Sent: Wednesday, April 16, 2008 9:33 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Review of draft-ietf-mip6-hiopt-13
> 
>       ^^^
>    ^^^^^^^^                                                   
>    ^^^^^^^^^^^                                                
> The 6th paragraph of 4.1 and Section 4.3 clearly admit 
> multiple Home Network Information options in the request with 
> Id-type 1, but different Home Network Identifiers (target 
> MSPs) in their
> But the modified last sentence -- per NEW.1 -- equally holds 
> for the response, if I truly understand the intent of the draft.
> I recommend NEW.2, but also have no objections to using 
> NEW.1, if you have arguments in preference of that.

NEW.2 was reflected for clarity.
It is natural that  a single Home Network Information option in the reply carries 
at most one sub-option with Sub-opt-code 1 if it in the request does.  

> In any case, I suggest to separate the clarified sentence 
> from the preceding one by a paragraph break (blank line), to 
> better decouple it from the preceding statement that is only 
> related to the Id-type.

NEW.1 was reflected. 

> Also tried to improve the readability and avoid a dangling 
> singular/ plural conflict by again replacing "more than one" 
> with "multiple".

Done.
 
> Typo; please change   "a Id-type"  -->   "an Id-type"

Done.

> Sentence is incomplete.  I guess that "is encapsulated" is 
> missing and should be inserted to give proper sense to the 
> sentence.  NEW.2 should further improve the readability; I 
> recommend it over NEW.1.
> 
> [Heejin: A hint to this garbled/incomplete sentence was 
> intended for  inclusion in my review of -12, but 
> inadvertantly misplaced to point  to another section, and has 
> triggered a change there; I apologize.]
> 

NEW.2 was reflected.

> To clarify the causality in the reasoning, "In case" needs to 
> be added in front of the second sentence (which introduces a 
> three- fold alternative discussion).
> 
> OLD (abbreviated):
> 

Done.
 
> For consistency, this should be done here equally.

Done.

- Best regards, 
Heejin

>   Alfred H?es.