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

From: Elwyn Davies <[email-masked]>
Date: Mon, 16 Jan 2012 13:44:21 +0000

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? 

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/

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.

s4.8/s4.9: Need to specify how PrefixLength is represented (unsigned
integer).

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.)

s4.16, last line of figure: s/LMA IPv6/DHCP v6 server/

s5.1, bullet 1: s/Home-/Home/

s7: I am not sure if the various must's and may's ought to be MUST's and
MAY's.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 16 Jan 2012 16:13:05 +0200

Hi Elwyn,

Thanks you for you detailed review. See my comments/answers inline.

> 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?

> s4.5, para 2 and s4.7, para 2: s/If included by VAAA/If included by the

Ack for all the above.

> 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

See above.

> interface identifier/ (for consistency with field definition in last

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".

> 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

Any specific example?

- Jouni

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 16 Jan 2012 14:49:09 +0000

Hi.

That's what I call *a speedy response*!
Deleted the agreed ones.

On Mon, 2012-01-16 at 16:13 +0200, jouni korhonen wrote:
> .> 
That sounds fine.
.
> Actually the prefix length should be 128 in this case. Thanks for 
(or 32 for the IPv4 cases).

Fine.

> since IIDs are always discussed as "64 bits interface ids".
True.  Actually it started out as just inserting 'a 64 bit (long)' until
I noticed that you use 8 octets in the fields definition. Suggest you go
with 'a 64 bit long interface identifier'
> .> 
e.g s7.1 "This interface must support the transfer of
   accounting records needed for service control and charging."
I couldn't decide whether this was a protocol requirement or statement
about what the implementation ought to do. 'must support' is ambiguous
and not being a RADIUS expert (and being too lazy today to go chase the
relevant spec) I wasn't sure whether this put any requirement on the
message structure or just required the user/implementer to send the
reklevant data using the facilities that were there.  In the second case
'must' is clearly fine. Similarly in 7.2.

Thinking about it, the 'may's' in ss5.2, 6.2 and 7.3 are correct.

Once again thanks for the speedy turnaround.

Regards,
Elwyn

---

From: jouni korhonen <[email-masked]>
Date: Mon, 16 Jan 2012 16:58:08 +0200

Hi, 

> 'must' is clearly fine. Similarly in 7.2.

Hmm.. it is about statement for the implementers. Those indirectly refer
to existing attributes so having a MUST there is probably a good idea.

Ack.

- Jouni