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
