RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 08 April 2010 08:13 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255563A68F8 for <ietf@core3.amsl.com>; Thu, 8 Apr 2010 01:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599]
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 cqoCp2TXTdh7 for <ietf@core3.amsl.com>; Thu, 8 Apr 2010 01:13:08 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6F0FC3A69B3 for <ietf@ietf.org>; Thu, 8 Apr 2010 01:12:45 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 04:12:41 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 04:12:41 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Cullen Jennings <fluffy@cisco.com>
Date: Thu, 08 Apr 2010 04:12:41 -0400
Subject: RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Thread-Topic: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Thread-Index: AcrVqguN0rIotfZcT9+I0obhcgkYegBQhVnw
Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D1B9@mail>
References: <430FC6BDED356B4C8498F634416644A91A79E92FC7@mail> <2AA0BE29-340C-4C8E-8541-087C9A9EE2D2@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CBFD@mail> <1270492215.30814.227.camel@localhost> <430FC6BDED356B4C8498F634416644A91A79F3CC6D@mail> <1270497302.30814.265.camel@localhost> <430FC6BDED356B4C8498F634416644A91A79F3CCE0@mail> <04CD732B-2D7D-45E5-8ED8-A0B27E5BAB8B@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CE40@mail> <26E13A8A-8E74-40D0-89AA-618546918ACF@cisco.com>
In-Reply-To: <26E13A8A-8E74-40D0-89AA-618546918ACF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 08:13:09 -0000

Howdy,
I said I would shut up, but I missed one question from Cullen, which was:
> This conversation constantly confuses the issue of must implement vs must
> deploy. Which one are you objecting to here.

Answer: I am objecting to there not *being* a distinction between must implement vs. must deploy in this draft.  The draft requires the implementation and DEPLOYMENT of a SIP Subscription service.  It is not optional to use.  It is not optional to deploy.  

Through some careful analysis of the implementation requirements stipulated in the draft, one may be able to find an exemption path to avoid deployment by means of configuration - but the language of the requirements to do so is so weak that it's meaningless.

You cannot stipulate that a "UA MAY do foo" in a SIP-Forum profile or IETF RFC, and then expect administrators to rely on that foo for anything useful whatsoever, because not all UAs are required to do foo.  Some will, some won't.  All of them will be compliant.  This basically defeats the whole point of having an "implementation profile", imho.

For example, the following requirements are stipulated:
   The User Agent MAY obtain configuration information by any means in
   addition to those specified here, and MAY use such information in
   preference to any of the steps specified below, but MUST be capable
   of using these procedures alone in order to be compliant with this
   specification.
...
   The UA MAY at any time return to any earlier step in the
   process of obtaining configuration data.
...
   The UA MAY use configuration data that is of unknown validity, or
   configuration data that is known to be no longer valid, while
   attempting to revalidate that data or obtain new data.  There is no
   assurance that such configuration data is still useful, but the UA is
   NOT REQUIRED to stop using or delete the data.

These requirements are all completely meaningless, in the sense that they do not provide any reliable behavior.

-hadriel