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

Alan DeKok <aland@deployingradius.com> Fri, 04 June 2010 05:11 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 6D1FF3A6925 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Thu, 3 Jun 2010 22:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.712
X-Spam-Level:
X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 CX20u9JF58mi for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Thu, 3 Jun 2010 22:11:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 239843A690F for <radext-archive-IeZ9sae2@lists.ietf.org>; Thu, 3 Jun 2010 22:11:15 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1OKP7l-0003Xu-9J for radiusext-data0@psg.com; Fri, 04 Jun 2010 05:07:17 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <aland@deployingradius.com>) id 1OKP7i-0003XS-NT for radiusext@ops.ietf.org; Fri, 04 Jun 2010 05:07:14 +0000
Message-ID: <4C0889FD.1010703@deployingradius.com>
Date: Fri, 04 Jun 2010 07:07:09 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Avi Lior <avi@bridgewatersystems.com>
CC: Bernard Aboba <bernard_aboba@hotmail.com>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: Re: On issue 6: Avi review of I-D Action:draft-ietf-radext-design-13.txt
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>
In-Reply-To: <DDD4FA4C-B08E-43AD-9A11-38B0B38C43DB@bridgewatersystems.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>

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.

>>... the document asserts SDOs dont have to be compatible
>>       with other SDOs.

  The only usage of "compatible" in the document is via the word
"incompatible", as in:

	... different groups taking different approaches.
	These approaches are often incompatible, leading to
	additional complexity

  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.

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