Re: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 09 August 2016 17:03 UTC

Return-Path: <dromasca@avaya.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 633FA12D606; Tue, 9 Aug 2016 10:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.157
X-Spam-Level:
X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlmRHYdbQM7Q; Tue, 9 Aug 2016 10:03:33 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAFB12D1A3; Tue, 9 Aug 2016 10:03:33 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EiAQByDKpX/yYyC4ddGgEBAQGCWSEtV?= =?us-ascii?q?nwHjSard4E9QCOFegKBSzgUAQEBAQEBAQNaJ4JTOQYHLwEBAQEBASMCDy8SAQE?= =?us-ascii?q?ZAQEBAQMSZxACAQgNBAMBAQELJDIdCAEBBA4FCBqIDwENpkCaagEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFhiuETIQcJh6DDIIvBY4YhV2FRAGGHIpYhFuDJoVXjDS?= =?us-ascii?q?DeB42gVeCI24BAQGFZEYBfgEBAQ?=
X-IPAS-Result: =?us-ascii?q?A2EiAQByDKpX/yYyC4ddGgEBAQGCWSEtVnwHjSard4E9QCO?= =?us-ascii?q?FegKBSzgUAQEBAQEBAQNaJ4JTOQYHLwEBAQEBASMCDy8SAQEZAQEBAQMSZxACA?= =?us-ascii?q?QgNBAMBAQELJDIdCAEBBA4FCBqIDwENpkCaagEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BARcFhiuETIQcJh6DDIIvBY4YhV2FRAGGHIpYhFuDJoVXjDSDeB42gVeCI24BA?= =?us-ascii?q?QGFZEYBfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,495,1464667200"; d="scan'208,217";a="200277118"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Aug 2016 13:03:15 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 09 Aug 2016 13:03:15 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Tue, 9 Aug 2016 13:03:14 -0400
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART LC review of draft-ietf-radext-datatypes-04.txt
Thread-Index: AdHyUp+ehzJGYnAzRqKWyh5pUHwS4wADR5CR
Date: Tue, 9 Aug 2016 17:03:12 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75267D0D@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [198.152.73.21]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA75267D0DAZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/bPanraG1Grts6PtfS0Og-w-f2Y0>
Cc: "radext@ietf.org" <radext@ietf.org>, "draft-ietf-radext-datatypes.all@tools.ietf.org" <draft-ietf-radext-datatypes.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 09 Aug 2016 17:03:36 -0000

Hi Alan,

Thanks for the quick response. The planned edits seem to address all the issues that I raised. There are good chances that I will just say 'I am happy' when I will see the revised I-D.

Regards,

Dan

________________________________
From: Gen-art [gen-art-bounces@ietf.org] on behalf of Romascanu, Dan (Dan)
Sent: Tuesday, August 09, 2016 6:28 PM
To: General Area Review Team
Cc: radext@ietf.org; draft-ietf-radext-datatypes.all@tools.ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=CwMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=A146UD4syR9uGHj3mNEcdcuht-Sznx47S9gyH87tBfU&s=pbahG3QoEuw2lLVL8Vw1XGd--c3Ak_-FexGmP-_DqyY&e=>



Document: draft-ietf-radext-datatypes-04.txt

Reviewer: Dan Romascanu

Review Date: 8/9/16

IETF LC End Date: 8/17/16

IESG Telechat date: 8/18/16



Summary:



Ready with issues.



This is an important document that tries to bring clarification to a number of different interpretations and recommendations around the RADIUS specifications. Being familiar – up to a certain point – with the history, I believe that it’s long due and that it will be very useful. There are however a number of issues which I believe need to be clarified before the document is approved by the IESG.



Major issues:



1.       Although the document makes the claim that it does not impact previous specifications and implementations, I am not sure this is completely the case. For example, the statement in RFC 6158, section 2.1 about ‘all other data formats (than the ones defined there) being NOT RECOMMENDED is obsolete by this document. I think that there is a need to make clear what is not longer valid or recommended in specifications that this document updates.

2.       This document creates a new IANA registry and updates another one. There is no mention however about the policy of adding new entries or making other modifications to the new registry. A reminder of the RADIUS Attribute Type registry policy would also help.



Minor issues:



1.       In section 3.5 – there is no mention that the string length is limited to 253 octets. This is obvious if we assume the definition of  “string” sticking with previous RADIUS documents, and clear by the fact that “concat” deals in 3.6 with transport of more than 253 octets, but for clarity I believe that this needs to be explicitly stated.

2.       It is not clear why the Prefix-Length value greater than 128 for ipv6prefix in 3.10 and greater than 32 for ipv4prefix in 3.11 need only SHOULD be treated as “invalid attributes”. Why not MUST? If there are exception cases it would be good to explain them.



Nits/editorial comments:



1.       Section 2.1.4: The paragraph that starts with ‘The “Value” field should be given ….’ needs to use capitalized SHOULD to be consistent with the paragraph that refer to the “Name” and “Format” fields.