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

Elwyn Davies <elwynd@dial.pipex.com> Mon, 16 January 2012 14:48 UTC

Return-Path: <elwynd@dial.pipex.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31D321F8613; Mon, 16 Jan 2012 06:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.044
X-Spam-Level:
X-Spam-Status: No, score=-101.044 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, MANGLED_SAVELE=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj1PTY4nyHNp; Mon, 16 Jan 2012 06:48:05 -0800 (PST)
Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id DAD6F21F8607; Mon, 16 Jan 2012 06:48:03 -0800 (PST)
Received: from 250.254.187.81.in-addr.arpa ([81.187.254.250]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <elwynd@dial.pipex.com>) id 1Rmnqr-0005fo-83; Mon, 16 Jan 2012 14:48:01 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
To: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <E1FB2079-15F8-4A20-A6D4-CB6450E745A5@gmail.com>
References: <1326721461.4790.1331.camel@mightyatom.folly.org.uk> <E1FB2079-15F8-4A20-A6D4-CB6450E745A5@gmail.com>
Content-Type: text/plain
Date: Mon, 16 Jan 2012 14:49:09 +0000
Message-Id: <1326725349.4790.1345.camel@mightyatom.folly.org.uk>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
Content-Transfer-Encoding: 7bit
Cc: netext@ietf.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-netext-radius-pmip6.all@tools.ietf.org
Subject: Re: [Gen-art] Gen-art: Last call review of draft-ietf-netext-radius-pmip6-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2012 14:48:05 -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:
> .> 
> > 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?
> 
That sounds fine.
> 
.
> > 
> > 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.
(or 32 for the IPv4 cases).

Fine.

> 
> 
> > 
> > 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".
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'
> .> 
> > s7: I am not sure if the various must's and may's ought to be MUST's and
> > MAY's.
> > 
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
> 
> Any specific example?
> 
> - Jouni
>