Re: [earlywarning] Finishing the Charter Text Discussions

Henning Schulzrinne <hgs@cs.columbia.edu> Wed, 07 April 2010 20:20 UTC

Return-Path: <hgs@cs.columbia.edu>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484BF28C10B for <earlywarning@core3.amsl.com>; Wed, 7 Apr 2010 13:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ZhlFX8FKb6pQ for <earlywarning@core3.amsl.com>; Wed, 7 Apr 2010 13:20:44 -0700 (PDT)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id AD6C03A67A4 for <earlywarning@ietf.org>; Wed, 7 Apr 2010 13:20:02 -0700 (PDT)
Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o37KJtEu020771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 Apr 2010 16:19:55 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <C7E25F64.232E8%mlinsner@cisco.com>
Date: Wed, 7 Apr 2010 16:19:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DF705D7-8F92-4F4C-A8C0-E032731A0055@cs.columbia.edu>
References: <C7E25F64.232E8%mlinsner@cisco.com>
To: Marc Linsner <mlinsner@cisco.com>
X-Mailer: Apple Mail (2.1078)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
Cc: "earlywarning@ietf.org" <earlywarning@ietf.org>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 20:20:47 -0000

+1

The notion that ATOCA, or any IETF WG, can somehow accommodate "regulation" is a bit peculiar. Which regulation? Of which country or countries? Does it mean that if a country rules out use of VoIP, as some do, that we can't standardize protocols for that? Would the charter of the RAI WGs have to note that use of this technology is illegal in Egypt?

Clearly, any product or service using IETF protocols is subject to regulation in the country or other jurisdiction it is being deployed in. The FCC (assuming an appellate court lets them...) can prohibit the use of ATOCA mechanisms, but that's not our problem, except in the sense that the technology may not be deployed at all or only in limited environments. However, if we went by the deployment regulations in force at the time of standardization, we'd still be working on ISDN at this point. It's pretty clear that mobile technology is in transition; mechanisms that made perfect sense with 2G technologies may not be nearly as useful in 4G networks.

Henning

On Apr 7, 2010, at 4:12 PM, Marc Linsner wrote:

> I agree with Ken, strike the last sentence.
> 
> -Marc-
> 
> 
> On 4/7/10 3:48 PM, "ken carlberg" <carlberg@g11.org.uk> wrote:
> 
>> 
>> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>> 
>>> "The ATOCA solutions will not adversely affect the ability of any access
>>> technology to provide emergency services to the citizens (e.g. 9-1-1
>>> calls) or to provide communication services to first responders or other
>>> authorized emergency services personnel.  Additionally, ATOCA is not
>>> replacement solution for any authority to citizen alerting supported by
>>> any access technology."
>> 
>> given the previous thread on this list, I'm a bit leery of that first
>> sentence.  But, if it were agreed to add it in, then I would expect the
>> individuals who make a claim that an ATOCA solution adversely affects 9-1-1
>> type calls will be required to prove it instead of simply stating a position.
>> 
>> as for the second sentence, that is out of scope of the IETF.  any deployment
>> of what is considered an ATOCA solution is a market decision.
>> 
>> -ken
>> 
>> _______________________________________________
>> earlywarning mailing list
>> earlywarning@ietf.org
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning
>