Re: [Gen-art] Gen-art: Last call review of draft-ietf-netext-radius-pmip6-06

[jouni korhonen <[e-mail]>]

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