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

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.

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

---

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

Hi, 

On Jan 16, 2012, at 4:49 PM, Elwyn Davies wrote:

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

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

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

Ack.

- Jouni

> Once again thanks for the speedy turnaround.
> 
> Regards,
> Elwyn
>> 
>> 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'
> .> 

Regards,
Elwyn