Re: [radext] AD review of draft-ietf-radext-ieee802ext-09
Benoit Claise <bclaise@cisco.com> Tue, 21 January 2014 22:44 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA691A035E for <radext@ietfa.amsl.com>; Tue, 21 Jan 2014 14:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level:
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 JChdE75LuM05 for <radext@ietfa.amsl.com>; Tue, 21 Jan 2014 14:44:10 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8691A0356 for <radext@ietf.org>; Tue, 21 Jan 2014 14:44:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9214; q=dns/txt; s=iport; t=1390344250; x=1391553850; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BJE0ceUl8QQgoR7GiamherGlIWR65/MOtyYvjWjpKFc=; b=B0NlrGOi3w/pF7PfRihesxIFS5v8/M0ecpqUJgmDzqaNvKVSkKZn5FJW rdBIUyWwxctg9k4758SBGp8ny0ywgnO8N+rCF3wmfW3XvfyNpjE7KSewl gDiVQ9tedTCAp3KYyJ5cXnZUaRnW5NuXPug2VeIyE8VCkBO/eyT3Wh+JA o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFABP33lKQ/khN/2dsb2JhbABagws4u3ZPgRcWdIImAQEEAQEBawoBEAshFg8JAwIBAgEVMAYNAQUCAQGIAQ3CYxMEjn8HhDgEjGCLQoZHfIpVgy47
X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="3976418"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 21 Jan 2014 22:44:09 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LMi8Q2015839; Tue, 21 Jan 2014 22:44:08 GMT
Message-ID: <52DEF838.1010406@cisco.com>
Date: Tue, 21 Jan 2014 23:44:08 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
References: <52D90642.4000000@cisco.com>
In-Reply-To: <52D90642.4000000@cisco.com>
Content-Type: multipart/alternative; boundary="------------040602050202050801070203"
Cc: "<lionel.morand@orange.com>" <lionel.morand@orange.com>
Subject: Re: [radext] AD review of draft-ietf-radext-ieee802ext-09
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 21 Jan 2014 22:44:13 -0000
Dear authors, > Dear all, > > Glad that this document finally makes progress. > > >From the writeup (https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext/shepherdwriteup/) I see: > > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is uncomfortable > with certain parts of the document, or has concerns whether there really > is a need for it. In any event, if the WG has discussed those issues and > has indicated that it still wishes to advance the document, detail those > concerns here. > > The document (informatively) references to RFC4005 on its Diameter > considerations. The RFC4005 will soon be obsoleted by RFC4005bis. > The RFC4005bis also deprecates the RADIUS-Diameter automated > translation, which is discussed in detail in Section 4 Diameter Considerations. > > The shepherd would recommend removing entire Section 4, since > RADIUS-Diameter considerations are not really endorsed anymore. > > Furthermore, Section 4 uses Diameter AVP Flag rules as defined in RFC3588, > which has already been obsoleted by RFC6733 and there the AVP Flag rules > are less due to e.g. deprecation of Diameter in-band security. > > > > I would actually prefer to keep the section 4, because the AVPs are > allocated in the range 1-255. So it seems that you went the easier way, i.e. removing the entire section 4... Progressing the document now. Regards, Benoit > However, RFC 4005bis must be mentioned as well. > This specific point is also discussed in > draft-ietf-dime-app-design-guide-21 > Guidelines for implementing a RADIUS-Diameter translation agent > were put into the Diameter NASREQ Application RFC 4005. > However, it was acknowledged that such translation mechanism was not > so obvious and deeper protocol analysis was required to ensure > efficient interworking between RADIUS and Diameter. Moreover, the > interworking requirements depend on the functionalities provided by > the Diameter application under specification, and a case-by-case > analysis is required. > As a consequence, all the material related to RADIUS-to-Diameter translation has been > removed from the new version of the Diameter NASREQ application specification > [RFC4005bis], which deprecates RFC4005 > Feel free to synchronize with Lionel Morand, the > draft-ietf-dime-app-design-guide-21 editor, who is currently working > on a revised text > > Regarding this point below, I agree with Jouni, can you please make > the change to be in line with the RFC 6733 format (for example, RFC > 6733 doesn't have encryption) > Furthermore, Section 4 uses Diameter AVP Flag rules as defined in RFC3588, > which has already been obsoleted by RFC6733 and there the AVP Flag rules > are less due to e.g. deprecation of Diameter in-band security. > > EDITORIAL > The guidelines in RFC 3580 are still valid, right? > > OLD: > "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) > Usage Guidelines" [RFC3580] provided guidelines for the use of the > Remote Authentication Dialin User Service (RADIUS) within networks > utilizing IEEE 802 local area networks. > NEW: > "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) > Usage Guidelines" [RFC3580]_provides_guidelines for the use of the > Remote Authentication Dialin User Service (RADIUS) within networks > utilizing IEEE 802 local area networks. > > Regards, Benoit > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext
- [radext] AD review of draft-ietf-radext-ieee802ex… Benoit Claise
- Re: [radext] AD review of draft-ietf-radext-ieee8… Benoit Claise