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