Hi Elwyn, Thanks you for you detailed review. See my comments/answers inline.
On Jan 16, 2012, at 3:44 PM, Elwyn Davies wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-netext-radius-pmip6-06 > Reviewer: Elwyn Davies > Review Date: 16 January 2012 > IETF LC End Date: 19 January 2012 > IESG Telechat date: (if known) - > > Summary: Almost ready with just some minor nits. > > Major issues: - > > Minor issues: > s4.1, IP4_HOA_ONLY_SUPPORTED: Is there need to discuss what happens if > the MUST/MUST NOT conditions are not satisfied? If you mean this part of the MUST/MUST NOT: When this bit is set the PMIP6_SUPPORTED flag MUST also be set, and the IP4_HOA_SUPPORTED flag MUST NOT be set. If these conditions are not met, then e.g. AAA end points are misbehaving. I could clarify that in case of client receiving a wrong combination it treats the Access-Accept as an Access-Reject and in a case the AAA server received a wrong combination answers with an Access-Reject. Would this be ok? > > Nits/editorial comments: > s1, last para: s/visitor/visited/ > > s2, Home AAA: s/to mobile/to the mobile/ > > s3: Expand acronym PBU on first use. > > s3, para 7 (before numbered list): s/Following/The following/ > > s3, para below figure 2: s/illustrates topology where MAG/illustrates a > topologywhere the MAG/ > > s4, general: It might be helpful to replace the text 'to be defined by > IANA' in the Type specification fields with the relevant '(TBDxx)' if > that is the format that is wanted eventually. > > s4.1, para 1: "reserves a new capability bit" - I think two new bits are > reserved in this section. > > s4.1, IP4_HOA_ONLY_SUPPORTED: Expand acronym HNP on first use. > > s4.2: Expand acronyms NAI, PBA on first use. > > s4.2, et seq, Length fields: The formula '>= 3 octets' is confusing. > Suggest 'In octets, including Type and Length fields (>= 3)' > > s4.2: The abbreviated name used for this field is inconsistent: > MN-Identifier in para 1, MN-ID in last para. > > s4.5, para 2 and s4.7, para 2: s/If included by VAAA/If included by the > VAAA/ Ack for all the above. > > s4.8/s4.9/s4.12/s4.13: Is the all-zeroes case specified by prefix length > zero or 16 octets of zeroes? Not sure if an actual prefix of zero > length is meaningful here. Actually the prefix length should be 128 in this case. Thanks for spotting this. > > s4.8/s4.9: Need to specify how PrefixLength is represented (unsigned > integer). See above. > > s4.10: s/conveys 64 bits interface identifier/conveys an 8 octet long > interface identifier/ (for consistency with field definition in last > para.) > > s4.11: s/contains 64 bits interface identifier/contains an 8 octet long > interface identifier/ (for consistency with field definition in last > para.) I would say: ... conveys 64 bits (8 octets) interface identifier representing a particular MN's interface. since IIDs are always discussed as "64 bits interface ids". > > s4.16, last line of figure: s/LMA IPv6/DHCP v6 server/ > > s5.1, bullet 1: s/Home-/Home/ Ack. > > s7: I am not sure if the various must's and may's ought to be MUST's and > MAY's. > Any specific example? - Jouni _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
