Re: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04

"Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com> Thu, 04 April 2013 19:55 UTC

Return-Path: <maximilian.riegel@nsn.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6484821F9530 for <radext@ietfa.amsl.com>; Thu, 4 Apr 2013 12:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 kdCA21ViIfwz for <radext@ietfa.amsl.com>; Thu, 4 Apr 2013 12:55:25 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9228421F8BF8 for <radext@ietf.org>; Thu, 4 Apr 2013 12:55:18 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r34JtEKk026484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Apr 2013 21:55:14 +0200
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r34JtDH6007495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Apr 2013 21:55:14 +0200
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Apr 2013 21:55:13 +0200
Received: from DEMUMBX008.nsn-intra.net ([169.254.8.58]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Thu, 4 Apr 2013 21:55:13 +0200
From: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>
To: ext Jouni Korhonen <jouni.nospam@gmail.com>, "radext@ietf.org" <radext@ietf.org>
Thread-Topic: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04
Thread-Index: AQHOMD67KcBlpXeW0UuH4RxXW+ebSZjGepQg
Date: Thu, 04 Apr 2013 19:55:13 +0000
Message-ID: <CE3022AA8028FE4BA38A31768F1716BA070DBA@DEMUMBX008.nsn-intra.net>
References: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com>
In-Reply-To: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.122]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3971
X-purgate-ID: 151667::1365105314-000077CC-12C43168/0-0/0-0
Cc: "radext-chairs@tools.ietf.org" <radext-chairs@tools.ietf.org>
Subject: Re: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 19:55:26 -0000

There may be a couple of minor, mostly editorial issues in draft-ietf-radext-ieee802ext-04:


-	2.9. WLAN-SSID
The usage statement is missing.
>> add 'A single WLAN-SSID Attribute is permitted within an Access-Accept or Accounting-Request packet.'

-	2.10. WLAN-HESSID
The usage statement is missing.
>> add 'A single WLAN-HESSID Attribute is permitted within an Access-Accept or Accounting-Request packet.'
In line 763 the term 'subscription service provider network (SSPN)' is used without any indication, that the term has special meaning in IEEE 802.11
>> adding 'as described in [IEEE-802.11].' may provide more clarity. 

-	2.11. WLAN-Venue-Info
WLAN Venue Group and Venue Type is defined without binding dashes in IEEE 802.11, however shown as Venue-Group and Venue-Type in the radext-ieee802ext specification. Furthermore the Length of this attribute is 6 bytes instead of 4 as written.
>> correct Length to '6'
>> use 'Venue Group' and 'Venue Type' instead of 'Venue-Group' and 'Venue-Type', respectively.
>> probably it would be better to make direct reference to clause 8.4.1.34 of [IEEE-802.11] instead of re-specifying the attribute elements in radext-ieee802ext

-	2.12. WLAN-Venue-Language
The attribute may appear in Accounting-Request messages as well
>>add 'or Accounting-Request'

-	2.13. WLAN-Venue-Name
The attribute may appear in Accounting-Request messages as well
>>add 'or Accounting-Request'

-	2.14. WLAN-Reason-Code
The length of this attribute is 6 bytes instead of 4 bytes as written
The usage statement is missing.
>> add 'A single WLAN-Reason-Code Attribute is permitted within a RADIUS Access-Reject or Accounting-Request packet.'
>> correct Length to '6'

-	2.15. WLAN-Pairwise-Cipher
The length of this attribute is 6 bytes instead of 4 bytes as written
>> correct Length to '6'

-	2.16. WLAN-Group-Cipher
The length of this attribute is 6 bytes instead of 4 bytes as written
>> correct Length to '6'

-	2.17. WLAN-AKM-Suite
The length of this attribute is 6 bytes instead of 4 bytes as written
>> correct Length to '6'

-	2.18. WLAN-Group-Mgmt-Cipher
The length of this attribute is 6 bytes instead of 4 bytes as written
>> correct Length to '6'

-	2.19. WLAN-RF-Band
IEEE 802.11ad-2012 is meanwhile available. Therefore the note in lines 1185-1191 can be removed with insertion of the proper reference to IEEE 802.11ad-2012.
Furthermore the value field should be directly adopted from Table 8-53a of IEEE 802.11ad-2012 instead of defining specific values in the radext-ieee802ext specification. Please take into account that the Table 8-53a defines single octet values, while a 4 octets field is defined for this attribute.
How are access points handled supporting multiple bands? Shouldn't the attribute be allowed multiple times within an Access Request message?

-	3. Table of attributes
The definition of WLAN-Venue-Language and WLAN-Venue-Name allows multiple entries within an Access-Request or Accounting-Request message. The table states that zero or one are present is the Access-Request or Accounting-Request message


Bye
Max



-----Original Message-----
From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, April 03, 2013 09:42
To: radext@ietf.org
Cc: radext-chairs@tools.ietf.org
Subject: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04

Folks,

This email starts a quick one week WGLC #2 for "RADIUS Attributes for IEEE 802 Networks"
I-D (draft-ietf-radext-ieee802ext-04). The WGLC ends 10-Apr-2013. Send your comments to
the mailer and please also use the IssueTracker. No comments would this time also imply
that everybody agrees with the content.

- Jouni & Mauricio
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext