Re: On issue 6: Avi review of I-D Action:draft-ietf-radext-design-13.txt

Avi Lior <avi@bridgewatersystems.com> Fri, 04 June 2010 13:33 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 23E033A6A37 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 4 Jun 2010 06:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.106
X-Spam-Level:
X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 dwY9-Q0WrHuc for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 4 Jun 2010 06:33:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6046F3A6A66 for <radext-archive-IeZ9sae2@lists.ietf.org>; Fri, 4 Jun 2010 06:33:38 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1OKWwV-0002S9-Pa for radiusext-data0@psg.com; Fri, 04 Jun 2010 13:28:11 +0000
Received: from [216.82.249.147] (helo=mail29.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <avi@bridgewatersystems.com>) id 1OKWwS-0002RM-RY for radiusext@ops.ietf.org; Fri, 04 Jun 2010 13:28:09 +0000
X-VirusChecked: Checked
X-Env-Sender: avi@bridgewatersystems.com
X-Msg-Ref: server-14.tower-29.messagelabs.com!1275658086!59693285!2
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [72.35.6.119]
Received: (qmail 23398 invoked from network); 4 Jun 2010 13:28:07 -0000
Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-14.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 4 Jun 2010 13:28:07 -0000
Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Fri, 4 Jun 2010 09:28:06 -0400
From: Avi Lior <avi@bridgewatersystems.com>
To: Alan DeKok <aland@deployingradius.com>
CC: Bernard Aboba <bernard_aboba@hotmail.com>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Date: Fri, 04 Jun 2010 09:26:54 -0400
Subject: Re: On issue 6: Avi review of I-D Action:draft-ietf-radext-design-13.txt
Thread-Topic: On issue 6: Avi review of I-D Action:draft-ietf-radext-design-13.txt
Thread-Index: AcsD6cQOQ/rtT0gFQuqV9prjEx5xwg==
Message-ID: <C8AFF4BF-0046-464C-BE14-1C0805E639B0@bridgewatersystems.com>
References: <20100414121503.8200128C281@core3.amsl.com> <4BC5BB10.4080006@deployingradius.com>, <0b1001cadbf4$6631bfc0$32953f40$@com> <BLU137-W3272B8995285C2B99C9DF0930F0@phx.gbl> <4BC875D5.1060802@deployingradius.com> <7FDC2F64-EAC6-4E2E-A541-9AEF4BB22347@bridgewatersystems.com> <4C076FAB.2070001@deployingradius.com> <1957F063-9C44-43D4-9619-FAEA1681F828@bridgewatersystems.com> <4C07A571.6040004@deployingradius.com> <0089109D-5260-482B-B65B-DD7EF94A4076@bridgewatersystems.com> <4C0809E7.2050103@deployingradius.com> <DDD4FA4C-B08E-43AD-9A11-38B0B38C43DB@bridgewatersystems.com> <4C0889FD.1010703@deployingradius.com>
In-Reply-To: <4C0889FD.1010703@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>

On 04-06-2010, at 01:07 , Alan DeKok wrote:

> Avi Lior wrote:
>> Section 1.3 ....
>> 
>> While SDOs and vendors MAY choose to create specifications not
>>   following these guidelines, this should be done only when those
>>   specifications are intended for use in scenarios within a limited
>>   scope of applicability.  Where general usage is possible, adhering to
>>   these guidelines is RECOMMENDED.
>> 
>> Unless i am missing something  -- the above states that they dont have to be compatible.
> 
>  No, it does not.  The word "compatible" does not appear in that text.
> I have no idea what you mean by "compatible".  That word could mean
> almost anything.
> 
>  Two SDOs may choose to ignore the guidelines, but may still both be
> "compatible", or they may not be "compatible".  The document does not
> distinguish between those two scenarios.

In the context of this document and in the context of the specific section I was commenting on --  i think it is darn clear what we mean by compatible or incompatible.

In any case....

>  The document suggests that incompatibility is a problem to be avoided.
> You assert that the document says the exact opposite.
> 
>  I repeat my objection: No, it doesn't.

No i don't assert the opposite.  I am saying the document allows for SDOs to create incompatible specifications.  To repeat what I said with appropriate words highlighted:  "the document asserts SDOs DONT HAVE TO BE COMPATIBLE." 

back to the original issue - that is issue 6:

Issue 6: Section 3.2

" These approaches are often incompatible, leading to
  additional complexity in RADIUS implementations."

Just say "These approaches often lead to additional complexity in RADIUS implementations."

I dont see the need to bring incompatibility statement into this paragraph.



--
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/>