Re: [earlywarning] Finishing the Charter Text Discussions

[Richard Barnes <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, April 07, 2010 1:18 PM
> To: DALY, BRIAN K (ATTCINW); ken carlberg; SENNETT, DEWAYNE A  
> (ATTCINW)
> Cc: Hannes Tschofenig; [e-mail]
> 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)" <[e-mail]> 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: [e-mail]
>> [mailto:[e-mail]] On Behalf Of ken carlberg
>> Sent: Wednesday, April 07, 2010 12:48 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: Hannes Tschofenig; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> _______________________________________________
>> earlywarning mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
>
> _______________________________________________
> earlywarning mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/earlywarning