Re: [earlywarning] Finishing the Charter Text Discussions

Richard Barnes <rbarnes@bbn.com> Wed, 07 April 2010 20:36 UTC

Return-Path: <rbarnes@bbn.com>
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 0460D28C154 for <earlywarning@core3.amsl.com>; Wed, 7 Apr 2010 13:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level:
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 UO4jFkaleGPI for <earlywarning@core3.amsl.com>; Wed, 7 Apr 2010 13:36:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5401528C111 for <earlywarning@ietf.org>; Wed, 7 Apr 2010 13:35:51 -0700 (PDT)
Received: from [192.1.255.171] (port=58007 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NzbyM-000DPd-VK; Wed, 07 Apr 2010 16:35:39 -0400
Message-Id: <344E691A-2A72-497E-B476-DC4FDB529C20@bbn.com>
From: Richard Barnes <rbarnes@bbn.com>
To: "DALY, BRIAN K (ATTCINW)" <BD2985@att.com>
In-Reply-To: <FDFC6E6B2064844FBEB9045DF1E3FBBC4F8160@BD01MSXMB016.US.Cingular.Net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 7 Apr 2010 16:35:36 -0400
References: <FDFC6E6B2064844FBEB9045DF1E3FBBC4F8124@BD01MSXMB016.US.Cingular.Net> <C7E260A8.2C983%br@brianrosen.net> <FDFC6E6B2064844FBEB9045DF1E3FBBC4F8160@BD01MSXMB016.US.Cingular.Net>
X-Mailer: Apple Mail (2.936)
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <DS2225@att.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, 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:36:02 -0000

Could you clarify how ATOCA "contradicts" these rules?

Isn't that kind of like saying that SIP contradicts XMPP?  The idea of  
ATOCA is to build a system with some different features than CMAS,  
that is still generally interoperable with it.  SIP has much better  
support for lots of PSTN-replacement stuff than XMPP, and conversely  
XMPP can be a lot simpler to use inter-domain, but you can still pass  
IMs and dialogues from one to another.  Likewise, we expect the ATOCA  
system to meet a different set of trade-offs than CMAS, but still  
allow alerts to move back and forth.

--Richard



On Apr 7, 2010, at 4:21 PM, DALY, BRIAN K (ATTCINW) wrote:

> We are just stating that ATOCA contradicts the CMAS (& EAS) rules, as
> well as iPAWS and DMOpen architectures, and thus is in a different
> class. Thus we believe we do need to be up front in the charter and  
> nto
> to confuse the industry.
>
> Brian
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, April 07, 2010 1:18 PM
> To: DALY, BRIAN K (ATTCINW); ken carlberg; SENNETT, DEWAYNE A  
> (ATTCINW)
> Cc: Hannes Tschofenig; earlywarning@ietf.org
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> In what way would any RFC not have to meet that requirement?
>
> I understand that you are concerned that this work overlaps layer 2
> specific
> solutions.  However, there is no need to explicitly put this work in
> second
> class.  It's not going to affect any words in a protocol  
> specification.
> If
> there is a regulatory requirement that makes ATOCA compliant
> implementations, like any other service, subservient in some way to  
> some
> other service, so be it.  The charter, and the spec, don't need to say
> that;
> it's always true.
>
> Brian
>
>
>
>
> On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <BD2985@att.com> wrote:
>
>> The second is more than a market decision - it is an interaction with
> a
>> regulatory requirement.
>>
>> Perhaps a better way to phrase is as follows:
>>
>> "Additionally, ATOCA will not interfere with nor replace solutions
>> designed to meet regulatory requirements for any authority to citizen
>> alerting of any access technology."
>>
>> Brian Daly
>> AT&T
>>
>> -----Original Message-----
>> From: earlywarning-bounces@ietf.org
>> [mailto:earlywarning-bounces@ietf.org] On Behalf Of ken carlberg
>> Sent: Wednesday, April 07, 2010 12:48 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: Hannes Tschofenig; earlywarning@ietf.org
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>>
>> 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
>
>
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning