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 Heejin Jang wrote: > 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 PROTECTED]> 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 PROTECTED] >> Sent: Friday, March 28, 2008 11:28 PM >> To: [EMAIL PROTECTED] >> Cc: General Area Review Team; >> [EMAIL PROTECTED]; Jari Arkko; Basavaraj >> Patil; [EMAIL PROTECTED]; [EMAIL PROTECTED] >> 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 PROTECTED] >>>> Sent: Thursday, March 27, 2008 5:11 AM >>>> To: General Area Review Team; [EMAIL PROTECTED] >>>> Cc: Jari Arkko; Basavaraj Patil; [EMAIL PROTECTED]; >>>> [EMAIL PROTECTED] >>>> 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'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's policy or on the server's knowledge. We'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'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 protected] https://www.ietf.org/mailman/listinfo/gen-art
