IETF Logo Mail Archive

RE: Review of draft-zorn-radius-keywrap

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 14 December 2010 17:25 UTC

Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CC428C0DB for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Tue, 14 Dec 2010 09:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ4m1693dkzE for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Tue, 14 Dec 2010 09:25:35 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83A013A6F9B for <radext-archive-IeZ9sae2@lists.ietf.org>; Tue, 14 Dec 2010 09:25:35 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1PSYa4-000NnI-39 for radiusext-data0@psg.com; Tue, 14 Dec 2010 17:22:28 +0000
Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <dromasca@avaya.com>) id 1PSYa0-000Nmn-Be for radiusext@ops.ietf.org; Tue, 14 Dec 2010 17:22:24 +0000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEo2B03GmAcF/2dsb2JhbACkD3ioZgKZQIVKBI4r
X-IronPort-AV: E=Sophos;i="4.59,343,1288584000"; d="scan'208";a="223182652"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Dec 2010 12:22:21 -0500
X-IronPort-AV: E=Sophos;i="4.59,343,1288584000"; d="scan'208";a="555526808"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Dec 2010 12:22:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Review of draft-zorn-radius-keywrap
Date: Tue, 14 Dec 2010 18:22:17 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A04029CB4D1@307622ANEX5.global.avaya.com>
In-Reply-To: <4D07A657.2090402@deployingradius.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-zorn-radius-keywrap
Thread-Index: AcubspupZGOcTbrvThakmnNa4FIvsQAAE9dQ
References: <4D079C0D.5000608@deployingradius.com> <EDC652A26FB23C4EB6384A4584434A04029CB4C4@307622ANEX5.global.avaya.com> <4D07A657.2090402@deployingradius.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: radext mailing list <radiusext@ops.ietf.org>
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>

So, trying to make sure that I understand your point, the document could
be possibly OK as a definition of a one vendor set of extensions but
would fail some of the criteria of the guidelines document for
multi-vendor usage. 

Dan

  

> -----Original Message-----
> From: Alan DeKok [mailto:aland@deployingradius.com] 
> Sent: Tuesday, December 14, 2010 7:16 PM
> To: Romascanu, Dan (Dan)
> Cc: radext mailing list
> Subject: Re: Review of draft-zorn-radius-keywrap
> 
> Romascanu, Dan (Dan) wrote:
> > I would like to make a clarification - draft-zorn-radius-keywrap is 
> > and Independent Stream submission. An RFC document that 
> would result 
> > from a possible approval of this document would not be an IETF 
> > document, but an Independent Submission Stream RFC. Not all 
> RFCs are 
> > IETF documents. See RFC 4844 section 5 for definitions of 
> the different RFC streams.
> 
>   Sure.  The following text from Section 3.3.1 still applies, though:
> 
>    The design and specification of VSAs for multi-vendor 
> usage SHOULD be
>    undertaken with the same level of care as standard RADIUS 
> attributes.
>    Specifically, the provisions of this document that apply 
> to standard
>    RADIUS attributes also apply to VSAs for multi-vendor usage.
> 
>   The document does not meet that criteria.
> 
>   Alan DeKok.
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

v2.23.0 | Report a Bug | By Email