Subject: [Gen-art] Revision results of hiopt document

From: Heejin Jang <[email-masked]>
Date: Tue, 08 Apr 2008 05:44:03 +0000 (GMT)

Hi, Suresh.

I've submitted a new version of hiopt document which reflected your comments.
The draft was modified as I proposed and you agreed previously except one comment
as I've sent an email about it previously.

Kindly see the attached file and let me know you agree with all the fixes.
Thanks for your kind help. :)

- Best regards
Heejin.
 
------- Original Message -------
Sender : Heejin Jang<[email-masked]> R&D Staff Member/Communication & Networking Lab/Samsung Advanced Institute of Technology
Date   : 2008-04-02 18:02 (GMT+09:00)
Title  : Re:RE: Gen-ART review of draft-ietf-mip6-hiopt-11.txt

Dear Suresh.
 
All of your comments were reflected in the new version except the 1st comment.
During the revision, I realized that change of Section 3 and 4 does not simply
mean the location change of text. For the seamless context, it requires much changes
on the text.  This draft has been polished through two IETF Last Calls and IESG reviewers, 
so I think that it would be better to keep as it is.

Furthurmore, this document aims at defining the DHCPv6 message format and its usage rather
than giving a full description because the referred [ietf-mip6-bootstrapping-integrated-dhc]  already
provides the whole scenario and message flow based on the proposed DHCP options.
IMO, readers of the hiopt document presumably are expected to read the above document, 
and may have no difficult understanding this document with the current text. :)

I wish it would be ok to you.
Kindly let me know your opinion. 

Thanks for your kind consideration.  :)

- Best regards, 
Heejin

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Friday, March 28, 2008 11:28 PM
> To: [email-masked]
> Cc: General Area Review Team; 
> [email-masked]; Jari Arkko; Basavaraj 
> Patil; [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-mip6-hiopt-11.txt
> 
> Hi Heejin,
>    I agree with all the fixes you proposed. I look forward to 
> the next revision.
> 
> Cheers
> Suresh
> 
> Heejin Jang wrote:
> > Hi, Suresh. 
> > Thanks for your kind and helpful review. :)
> > 
> > Please see my inline answer. 
> > 
> >> -----Original Message-----
> >> From: Suresh Krishnan [mailto:[email-masked]]
> >> Sent: Thursday, March 27, 2008 5:11 AM
> >> To: General Area Review Team; [email-masked]
> >> Cc: Jari Arkko; Basavaraj Patil; [email-masked]; 
> >> [email-masked]
> >> Subject: Gen-ART review of draft-ietf-mip6-hiopt-11.txt
> >>
> >> I am the assigned Gen-ART reviewer for draft-ietf-mip6-hiopt-11.txt
> >>
> >> For background on Gen-ART, please see the FAQ at 
> >> <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.
> >>
> >> Summary: This draft is on the right track but there are a 
> few issues 
> >> that need to be fixed.
> >>
> >> Meta-comment
> >> ============
> >>
> >> * I did not personally like the way the document flows. I 
> would have 
> >> much preferred having the current section 4 before the current 
> >> section 3. The  way the document is currently written, I 
> go through 
> >> option formats before I have any clue what they would be 
> used for and 
> >> how they would be used.
> > 
> > Ok. We&#39;ll revise it and put section 4 before section 3 for 
> easy understanding.
> >  
> >> * There does not seem to be a way for a MN to request a SPECIFIC 
> >> piece of information from the DHCP server. e.g. How does the MN 
> >> request just the home agent address and nothing else? If this is 
> >> intentional please state so in the draft.
> > 
> > Requesting a specific piece of information is not allowed 
> in the current draft.
> > We design that once the mobile node decides where the home 
> agent is to 
> > be assigned, the specific information to be assigned 
> depends mainly on 
> > the server&#39;s policy or on the server&#39;s knowledge. We&#39;ll 
> mention this 
> > in Seciton 4.3 (currently) of the draft properly.
> > 
> >> * There is no discussion regarding the interactions between 
> >> information stored in the DHCP server and that provided by 
> the relay. 
> >> What is the DHCP server supposed to do with these two (potentially 
> >> conflicting) pieces of information when it responds?
> >>
> >> Substantial
> >> ===========
> >>
> >> * Section 3.1.1
> >>
> >> Prefix-len is described as "The length of the following IPv6 Home 
> >> Network Prefix in bits". If I have the value 64 in here 
> does it mean 
> >> that the following IPv6 HNP is 8 octets in length? If not, I think 
> >> this is ambiguous and misleading. If yes, the packet 
> format has to be 
> >> redrawn
> >>   since the picture shows the IPv6 Home Network Prefix to be 16 
> >> octets
> >> (fixed) in length. I suggest the following replacement text.
> >>
> >> "The Prefix-len contains the number of leading bits in the
> >> IPv6 Home Network Prefix that are valid."
> > 
> > The answer is "yes". 
> > Ok. We&#39;ll replace the sentence with the one suggested by you. 
> > 
> >> * Section 4.1
> >>
> >> The term "Home Network information" has been overloaded in the 
> >> document and hence it is hard to figure out which of the 
> contexts is 
> >> being used.
> >> e.g. The following text in section 4.1
> >>
> >> "When provided with more than one home network information, the 
> >> mobile node is required to have a selection mechanism to determine 
> >> which one to use for establishing a Mobile IPv6 session."
> >>
> >> I could understand this as either
> >>
> >> a) "when there are multiple HNI options (say Id-Types 0,1,2)"
> >> b) "when there are multiple sub-options for the same HNI option" - 
> >> The sub-option data is ALSO referred to as "Home Network 
> Information" 
> >> in the packet format
> >>
> >> Can we rename b) to something else, say "sub-option specific data".
> > 
> > Actually we intended that the sentence means both a) and b).
> > For clarity we will revise it as below.
> > 
> > New>
> > When provided with more than one Home Network Information options 
> > having the diffierent id-types or multiple sub-options having same 
> > id-type, the mobile node is required to have a selection 
> mechanism to 
> > determine which one to use for establishing a Mobile IPv6 session.
> > 
> >> * Section 4.1
> >>
> >> "However, there SHOULD not be more than one Home Network 
> Information 
> >> option with Id-type 0 nor more than one Home Network Information 
> >> option with Id-type 2 in the request."
> >>
> >> Why is this a SHOULD and not a MUST. I have difficulty seeing any 
> >> case that is an exception to this SHOULD.
> > 
> > Ok. We will modify as below
> > 
> > Old> 
> > page 13: there SHOULD not be more than one
> >    Home Network Information option with Id-type 0 nor ~
> > 
> > page 16: note that there SHOULD not be more than one Home
> >    Network Information option with Id-type 0 nor ~
> > 
> > New> 
> > page 13: there MUST not be more than one
> >    Home Network Information option with Id-type 0 nor ~
> > 
> > page 16: note that there MUST not be more than one Home
> >    Network Information option with Id-type 0 nor ~
> > 
> >> * Section 4.3 Bullet C
> >>
> >> "include all sub-options in one or more than one Home network 
> >> Information option(s) with Id-type 1 or 2 in the reply."
> >>
> >> Did you mean "1 or 0" instead? (Because "1 or 2" is not 
> very useful)
> > 
> > Right. It need to be corrected.
> > 
> > New>
> > "include all sub-options in one or more than one Home network 
> > Information option(s) with Id-type 0 or 1 in the reply."
> > 
> > All of your comments will be reflected in next version. :)
> > 
> > - Best regards,
> > Heejin
> > 
> >> Cheers
> >> Suresh
> 

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 09 Apr 2008 19:12:18 -0400

Hi Heejin,
   I have read the latest revision of the document. It looks very good. 
It has addressed all my comments from -11.

New Comments
============

* Precedence: The following pieces of text are potentially conflicting

Section 4.3: The provided multiple options SHOULD be listed in order of	
preference. multiple sub-options also SHOULD be listed in order of	
preference within a single option.

Section 4.1: When provided with more than one Home Network Information 
options having the different id-types or multiple sub-options for the 
same id-type, the mobile node is required to have a selection mechanism 
to determine which one to use for establishing a Mobile IPv6 session.

I think it is better to change section 4.1 to use the same algorithm 
specified in 4.3

* There is also some new text added that I would like to comment upon. 
It looks like you have added support for DSMIPv6 in this document. I am 
fine with that, but I am confused as to why you would use a new option 
to carry BOTH IPv6 and IPv4 addresses when there is already an option to 
carry an IPv6 address for a HA. Isn't it simpler to just add an option 
for an IPv4 HA address? This way you can remove one conflict scenario 
where the IPv6 in sub-option 4 differs from the one in sub-option 3

Thanks
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Apr 2008 11:12:52 +0300

Suresh, Heejin,

> same id-type, the mobile node is required to have a selection
> mechanism to determine which one to use for establishing a Mobile IPv6
> session.
>

I've placed this change in the RFC Editor notes:

Please change in Section 4.1:

OLD:

   When provided with
   more than one Home Network Information options having the different
   id-types or multiple sub-options for the same id-type, the mobile
   node is required to have a selection mechanism to determine which one
   to use for establishing a Mobile IPv6 session.  For example, if the
   mobile node acquires both IPv6 address and FQDN of the home agent, it
   may try to use the address information of the home agent first.
   However, the selection mechanism is outside the scope of this
   document.

NEW:

     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
multiple sub-options
     for the same id-type, the mobile node SHOULD choose the first one
that it
     can employ.

> It looks like you have added support for DSMIPv6 in this document. I
> am fine with that, but I am confused as to why you would use a new
> option to carry BOTH IPv6 and IPv4 addresses when there is already an
> option to carry an IPv6 address for a HA. Isn't it simpler to just add
> an option for an IPv4 HA address? This way you can remove one conflict
> scenario where the IPv6 in sub-option 4 differs from the one in
> sub-option 3

Authors? I think what Suresh says makes sense. But I'm not going to
require you to change this unless you actually want to.

Jari