Re: [Ecrit] PhoneBCP

"Edge, Stephen" <sedge@qualcomm.com> Thu, 30 April 2009 16:28 UTC

Return-Path: <sedge@qualcomm.com>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1163A3A677D for <ecrit@core3.amsl.com>; Thu, 30 Apr 2009 09:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.491
X-Spam-Level:
X-Spam-Status: No, score=-105.491 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 u7UVD3wg7txx for <ecrit@core3.amsl.com>; Thu, 30 Apr 2009 09:28:05 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E9CA23A6885 for <ecrit@ietf.org>; Thu, 30 Apr 2009 09:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1241108968; x=1272644968; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20<sedge@qualcomm.com>|To:=20B ernard=20Aboba=20<bernard_aboba@hotmail.com>,=0D=0A=20=20 =20=20=20=20=20=20"martin.thomson@andrew.com"=0D=0A=09<ma rtin.thomson@andrew.com>,=0D=0A=20=20=20=20=20=20=20=20"e crit@ietf.org"=20<ecrit@ietf.org>|Date:=20Thu,=2030=20Apr =202009=2009:28:32=20-0700|Subject:=20RE:=20[Ecrit]=20Pho neBCP|Thread-Topic:=20[Ecrit]=20PhoneBCP|Thread-Index:=20 AcnJa27EY580z/r8T4SuVdCY50VYCgAQMkdg|Message-ID:=20<1288E 74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualco mm.com>|References:=20<C6177BF4.147ED%mlinsner@cisco.com> <p0624080dc617d32a1604@[10.227.68.132]><49F27637.7050201@ bbn.com><E51D5B15BFDEFD448F90BDD17D41CFF104A3430A@AHQEX1. andrew.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><E51D5B15 BFDEFD448F90BDD17D41CFF104A3430B@AHQEX1.andrew.com><28B7C 3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.a lcatel-lucent.com><p0624060ac61bfca58f3b@[172.28.171.53]> <7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><F5582 86E-B950-43B2-9FB6-52FCBECBB3D1@cs.columbia.edu><p0624061 3c61ce567d224@[172.28.171.53]><1288E74A73964940B132A0B9EA 8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090 902@bbn.com>=0D=0A=09<1288E74A73964940B132A0B9EA8D8ABC592 6A470@NASANEXMB04.na.qualcomm.com>=0D=0A=20=09<E51D5B15BF DEFD448F90BDD17D41CFF105B360E9@AHQEX1.andrew.com>=0D=0A =20=09<1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB 04.na.qualcomm.com>=0D=0A=20=09<E51D5B15BFDEFD448F90BDD17 D41CFF105B36158@AHQEX1.andrew.com>=0D=0A=20=20<1288E74A73 964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.co m>=0D=0A=20<BLU137-W27D6569C839B0D68D4C054936C0@phx.gbl> |In-Reply-To:=20<BLU137-W27D6569C839B0D68D4C054936C0@phx. gbl>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_1288E74A73964940B132A0B9EA8D8ABC5926A 4D4NASANEXMB04naqu_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5601"=3B=20a=3D"17642136"; bh=3/eMV2OthoJ2H+CrHuo70stwj7INsvijfPmaVm2ronc=; b=fLEu4VqAPkt5ytiXcOs5khx4F2imo+WNsA4r1pBDhLnlyNpc2IH09kK7 zkDFIuXog3F9+uar2Ru3Fxa2BVzPMZKbkYXXZIKmA+pkmJWGGPbmoZCLz hTRXFW8hqcWYSjViZ0vVdP9dHITc6qKDDpZWMmqDcHh4HETIhiY+PQq0B k=;
X-IronPort-AV: E=McAfee;i="5300,2777,5601"; a="17642136"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 09:29:27 -0700
Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UGTRhG021357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 09:29:27 -0700
Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3UGTQ4k009553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Apr 2009 09:29:26 -0700
Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 30 Apr 2009 09:29:26 -0700
From: "Edge, Stephen" <sedge@qualcomm.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, "martin.thomson@andrew.com" <martin.thomson@andrew.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Date: Thu, 30 Apr 2009 09:28:32 -0700
Thread-Topic: [Ecrit] PhoneBCP
Thread-Index: AcnJa27EY580z/r8T4SuVdCY50VYCgAQMkdg
Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5926A4D4@NASANEXMB04.na.qualcomm.com>
References: <C6177BF4.147ED%mlinsner@cisco.com><p0624080dc617d32a1604@[10.227.68.132]><49F27637.7050201@bbn.com><E51D5B15BFDEFD448F90BDD17D41CFF104A3430A@AHQEX1.andrew.com><058701c9c5d0$53c5ef40$fb51cdc0$@net><E51D5B15BFDEFD448F90BDD17D41CFF104A3430B@AHQEX1.andrew.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BD8E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><p0624060ac61bfca58f3b@[172.28.171.53]><7582BC68E4994F4ABF0BD4723975C3FA0E0471BA@crexc41p><F558286E-B950-43B2-9FB6-52FCBECBB3D1@cs.columbia.edu><p06240613c61ce567d224@[172.28.171.53]><1288E74A73964940B132A0B9EA8D8ABC5926A365@NASANEXMB04.na.qualcomm.com><49F761CC.3090902@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5926A470@NASANEXMB04.na.qualcomm.com> <E51D5B15BFDEFD448F90BDD17D41CFF105B360E9@AHQEX1.andrew.com> <1288E74A73964940B132A0B9EA8D8ABC5926A498@NASANEXMB04.na.qualcomm.com> <E51D5B15BFDEFD448F90BDD17D41CFF105B36158@AHQEX1.andrew.com> <1288E74A73964940B132A0B9EA8D8ABC5926A4B2@NASANEXMB04.na.qualcomm.com> <BLU137-W27D6569C839B0D68D4C054936C0@phx.gbl>
In-Reply-To: <BLU137-W27D6569C839B0D68D4C054936C0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_1288E74A73964940B132A0B9EA8D8ABC5926A4D4NASANEXMB04naqu_"
MIME-Version: 1.0
Subject: Re: [Ecrit] PhoneBCP
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2009 16:28:13 -0000

Bernard and others

This is an interesting view - an admission that the Ecrit solution will probably not be universally applied and when it is may be subject to modification. On the 3GPP/3GPP2 sides, solutions are defined with a specific and explicit scope and are expected to be - and nearly always actually are - supported exactly as defined in the appropriate spec.s for all scenarios covered by the scope. A solution whose deployment is unpredictable will be less useful because of the implied interworking problems between incompatible implementations. That is a main reason why I and others initially tried to include a more precise applicability/scope statement than the one we are now discussing. Specifically, the Ecrit solution will probably not be deployed by 3GPP/3GPP2 operators for cellular terminals because they have defined a somewhat different solution more suitable for cellular operation. That means that a terminal supporting only the Ecrit solution (based on an assertion of universal applicability) will encounter problems when its user attempts an emergency call on a 3GPP/3GPP2 network. If I can extend your analogies, this would be like not including a precise menu description for a meal containing meat and/or fish in a restaurant catering to both vegetarians and non-vegetarians.

Kind Regards

Stephen
________________________________
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Thursday, April 30, 2009 1:13 AM
To: Edge, Stephen; martin.thomson@andrew.com; ecrit@ietf.org
Subject: RE: [Ecrit] PhoneBCP

> Your interpretation of applicability is certainly extreme (yes or qualified yes to all questions) - removing any dependence on suitability or feasibility (which are the more normal benchmarks) and simply making a legalistic blanket assertion. (I can now more understand incidentally why the fictitious protocol police are so often invoked on matters of conformance.)
>
> But do others have any views on this?

Here is my 2 pence.   As noted in the Introduction, the Phone BCP document and framework documents are closely related documents that need to be read (and understood) together.  In looking at Phone BCP, there have been many situations in which  I wondered what the justification was for a requirement, only to find the (usually persuasive) explanation in the corresponding section of the framework document.

IMHO, the separation of the two documents is somewhat unnatural. It's a bit like taking a meal, freeze drying it, and then presenting the diner with a cup of powder and a cup of water and wondering why they are left with a quizical look on their faces.  Including cooking instructions along with the two cups is not a fully satisfactory answer.

Given this reality, if there is a need for text explaining the fundamental assumptions of the architecture, the place for that text is not in the BCP document, but in the framework document.  As has been noted by others, the entire BCP document is an applicability statement, and when viewed in that way, the proposed text is not only unnecessary, but somewhat confusing since required context for the BCP document belongs in the framework document.  If anything more is necesary, it would probably be some additional instructions for the reader  delving into the document set for the first time.

Like any IETF effort, the framework and BCP documents will be evaluated on their own merits. Athough this is an area with a considerable regulatory component, I see little evidence that the world at large is so in awe of the IETF that every word will be taken as immutable truth.  No doubt other SDOs will take issue with these documents in whole or in part and will explain the basis of their assessments and where necessary, their alternatives. As a result, some portions of the architecture may be adopted, some portions may be ignored, and others will be revised in an effort to address the issues encountered and improve their chances for deployment.

With respect to this process, the addition of cautionary text is a bit like the warning labels that we find on consumer products.  While it may be necessary in some legalistic sense, given the expertise of the individuals assessing these documents, one wonders what the practical effect will be.  Typically these are individuals who already understand that it is a good idea to double-cup hot coffee.