From khwolf1@gmail.com  Mon Feb  1 06:06:03 2010
Return-Path: <khwolf1@gmail.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 D737E3A6953 for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 06:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8GslP3xdsxdr for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 06:06:03 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id F35C93A6952 for <ecrit@ietf.org>; Mon,  1 Feb 2010 06:06:02 -0800 (PST)
Received: by pzk5 with SMTP id 5so5188149pzk.29 for <ecrit@ietf.org>; Mon, 01 Feb 2010 06:06:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=afh2GTUXJKB126Ft7Bz18eR0g3xkGicWAUFFySbYy+A=; b=DnP1jQHousOKzY4vJM9n7BPzupHL/ELVwYoNREa67zt1Rzf/2evnMx1bo3CvS0ucBC Oex64ktBnjIDAtKv6IvuLIl9puz3g+p8ShaMOBUoSJj5QOAPXx9yuEZyrRKt0hoi3unC egiMfkzUUAg28rNRcccxChww5HN/Lyr0bn0GE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RxBUknS+dtoOXZXMp8KIwvSPnJBBd/nToA5f9N2BZEZ//jEl2MzyUbLRJSNakmkaAx W7Ti9B7ii5kD/vt4w4OanGSSVmDUfuYWrXy6Rc2zNOZoC0KSbDjexJ/Ux00JGkkIyXZU zCMrlvz43EEaPxKB8kgmxJG0UdoCSiFXD1cIM=
MIME-Version: 1.0
Received: by 10.141.53.11 with SMTP id f11mr3217971rvk.184.1265033194598; Mon,  01 Feb 2010 06:06:34 -0800 (PST)
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com>
Date: Mon, 1 Feb 2010 15:06:34 +0100
Message-ID: <f77644531002010606n6d3342a2u432b1699c7a2d7e6@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt
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: Mon, 01 Feb 2010 14:06:04 -0000

Hi Martin!

Thank you for reviewing my document carefully and in particular for
pointing out the XML problems. In order to avoid confusion I totally
agree to rename the request-element as you suggested.

>
> Section 3.1:
> =A0- s/ist/is/
> =A0- I assume that the example civic address boundary is in English? xml:=
lang=3D"en"

I'll add the lang.

> Section 5.1:

I appreciate your help with the XML schema. (the servicelistboundary
is only for listServicesByLocation, not listServices as you wrote) I
would add the following XML to section 5.1:


<grammar xmlns=3D"urn:ietf:params:xml:ns:lost1"
xmlns:slb=3D"urn:ietf:params:xml:ns:lost1:slb">

 <include href=3D"lost.rng">
   <!-- redefinition of LoST elements -->

    <start>
      <choice>
        <ref name=3D"findService"/>
        <ref name=3D"listServices"/>
        <ref name=3D"listServicesByLocation"/>
        <ref name=3D"getServiceBoundary"/>
        <ref name=3D"findServiceResponse"/>
        <ref name=3D"listServicesResponse"/>
        <ref name=3D"listServicesByLocationResponse"/>
        <ref name=3D"getServiceBoundaryResponse"/>
        <ref name=3D"errors"/>
        <ref name=3D"redirect"/>
        <ref name=3D"slb:getServiceListBoundary"/>
        <ref name=3D"slb:getServiceListBoundaryResponse"/>
      </choice>
    </start>

      <define name=3D"listServicesByLocation">
        <element name=3D"listServicesByLocation">
          <ref name=3D"commonRequestPattern"/>
            <ref name=3D"slb:serviceListBoundaryRequest"/>
        </element>
      </define>

      <define name=3D"listServicesByLocationResponse">
        <element name=3D"listServicesByLocationResponse">
          <ref name=3D"serviceList"/>
          <ref name=3D"commonResponsePattern"/>
          <ref name=3D"locationUsed"/>
          <choice>
              <ref name=3D"slb:serviceListBoundaryResponse"/>
              <ref name=3D"slb:serviceListBoundaryReference"/>
          </choice>
        </element>
      </define>

 </include>


        <define name=3D"serviceListBoundaryRequest">
          <element name=3D"serviceListBoundary">
            <ref name=3D"slb:serviceListBoundary"/>
              <choice>
               <value>value</value>
               <value>reference</value>
            </choice>
          </element>
        </define>

        <define name=3D"serviceListBoundaryResponse">
          <element name=3D"serviceListBoundary">
            <ref name=3D"slb:serviceListBoundary"/>
              <attribute name=3D"profile"/>
              <ref name=3D"ls:locationInformation"/>
          </element>
        </define>

        <define name=3D"serviceListBoundaryReference">
          <element name=3D"serviceListBoundaryReference">
            <ref name=3D"slb:serviceListBoundaryReference"/>
              <attribute name=3D"source"/>
              <attribute name=3D"serviceListKey"/>
          </element>
        </define>



         <define name=3D"getServiceListBoundary">
           <element name=3D"getServiceListBoundary">
             <ref name=3D"slb:getServiceListBoundary"/>
               <attribute name=3D"serviceListKey"/>
           </element>
         </define>


         <define name=3D"getServiceListBoundaryResponse">
           <element name=3D"getServiceListBoundaryResponse">
             <ref name=3D"slb:getServiceListBoundaryResponse"/>
               <attribute name=3D"serviceListKey"/>
               <ref name=3D"slb:serviceListBoundary"/>
               <ref name=3D"ls:path"/>
           </element>
         </define>


</grammar>


Thank you,

Karl Heinz

From khwolf1@gmail.com  Mon Feb  1 06:06:13 2010
Return-Path: <khwolf1@gmail.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 6522628C15B for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 06:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8+D27tDr4Mzk for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 06:06:12 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 8EF7728C15A for <ecrit@ietf.org>; Mon,  1 Feb 2010 06:06:12 -0800 (PST)
Received: by mail-pz0-f175.google.com with SMTP id 5so5188149pzk.29 for <ecrit@ietf.org>; Mon, 01 Feb 2010 06:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CAYnRbl+ZITTsdtjJORz5OjXedUYytDODzynpTYDMbs=; b=oRySuaCT1JDBWMVRsH1/vS8PDMoCz9CmBeLu/BcE7g0PGUgbrcUMx6p8W3FTOlpobM NWXWLlXCOOzjcb/Cyq9xNbX5KQefsUlfR0C4GK/EBZBxprokGPcjPR6tlj2TMgAQBo/n MYuqg0eSdKhFnsxHb/zEBbbgIT2ga9ufkDUhA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EL3ioOlGlA0ZhJ4yTGyQfUwsOLTXvEH4TnAAl3TKO+03/dNRYwuhqkX1NnzW7txtqO xTKt7pC9vOE+4+vtNeZBuEf1goxLGCEiORuN73dBJEP3oN7nvHbiU2bGNmGRYdxIxEwI fdS+eZR+Xf+DdUbyz7n4FDm/j+pG2DHlMcoTA=
MIME-Version: 1.0
Received: by 10.141.53.19 with SMTP id f19mr571181rvk.233.1265033207096; Mon,  01 Feb 2010 06:06:47 -0800 (PST)
In-Reply-To: <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com>
Date: Mon, 1 Feb 2010 15:06:47 +0100
Message-ID: <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, "ecrit@ietf.org" <ecrit@ietf.org>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt
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: Mon, 01 Feb 2010 14:06:13 -0000

Hi Richard,

On Thu, Jan 28, 2010 at 6:05 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> I generally agree with Martin's comments regarding changes to the XML
> structure, especially having different elements for requesting and return=
ing
> service list boundaries.

I'll do this change.

>
> I would also like to see a little more explanation in the Security
> Considerations, e.g.:
> "
> This document extends the LoST protocol [RFC5222] to allow it to carry
> service list boundaries (and requests for them). =A0While this informatio=
n
> cannot be directly derived from information in the current protocol, it i=
s
> generally considered to have the same level of sensitivity -- namely, it =
is
> generally public information -- and thus the same access control and
> confidentiality requirements as the base LoST protocol. =A0As a result, t=
he
> security measures incorporated in the base LoST specification provide
> sufficient protection for LoST messages that use the service list boundar=
y
> extension.
> "

Thank you for this suggestion. I have slightly modified it to stress
that the servicelistboundary is calculated by the server based on the
individual service boundaries and each server may decide based on its
local policy to include the servicelistboundary or not.

"
Security considerations for LoST are discussed in RFC5222. This
document extends LoST to also carry service list boundaries (and
requests for them). These service list boundaries are calculated by
the server based on the individual service boundaries and sent to
clients in case the local policy allows this. Therefore it is
generally considered to have the same level of sensitivity as for the
service boundary and thus the same access control and confidentiality
requirements as the base LoST protocol. As a result, the security
measures incorporated in the base LoST specification provide
sufficient protection for LoST messages that use the service list
boundary extension.
"

What do you think?

Thank you for reviewing the draft,

karl heinz

From rbarnes@bbn.com  Mon Feb  1 06:29:03 2010
Return-Path: <rbarnes@bbn.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 CF20A28B797 for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 06:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  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 ONXvcB2+9QIK for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 06:29:03 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D0CE23A6963 for <ecrit@ietf.org>; Mon,  1 Feb 2010 06:28:32 -0800 (PST)
Received: from [192.1.255.186] (helo=col-dhcp-192-1-255-186.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NbxH0-0008WV-4r; Mon, 01 Feb 2010 09:29:06 -0500
Message-Id: <67DDF7A5-7332-4B9C-A839-2F946F069885@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: Karl Heinz Wolf <khwolf1@gmail.com>
In-Reply-To: <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 1 Feb 2010 09:29:03 -0500
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com> <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, "ecrit@ietf.org" <ecrit@ietf.org>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt
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: Mon, 01 Feb 2010 14:29:03 -0000

Hey Karl Heinz,

Your revision of the Security Considerations looks good to me.

--Richard


On Feb 1, 2010, at 9:06 AM, Karl Heinz Wolf wrote:

> Hi Richard,
>
> On Thu, Jan 28, 2010 at 6:05 AM, Richard L. Barnes <rbarnes@bbn.com>  
> wrote:
>> I generally agree with Martin's comments regarding changes to the XML
>> structure, especially having different elements for requesting and  
>> returning
>> service list boundaries.
>
> I'll do this change.
>
>>
>> I would also like to see a little more explanation in the Security
>> Considerations, e.g.:
>> "
>> This document extends the LoST protocol [RFC5222] to allow it to  
>> carry
>> service list boundaries (and requests for them).  While this  
>> information
>> cannot be directly derived from information in the current  
>> protocol, it is
>> generally considered to have the same level of sensitivity --  
>> namely, it is
>> generally public information -- and thus the same access control and
>> confidentiality requirements as the base LoST protocol.  As a  
>> result, the
>> security measures incorporated in the base LoST specification provide
>> sufficient protection for LoST messages that use the service list  
>> boundary
>> extension.
>> "
>
> Thank you for this suggestion. I have slightly modified it to stress
> that the servicelistboundary is calculated by the server based on the
> individual service boundaries and each server may decide based on its
> local policy to include the servicelistboundary or not.
>
> "
> Security considerations for LoST are discussed in RFC5222. This
> document extends LoST to also carry service list boundaries (and
> requests for them). These service list boundaries are calculated by
> the server based on the individual service boundaries and sent to
> clients in case the local policy allows this. Therefore it is
> generally considered to have the same level of sensitivity as for the
> service boundary and thus the same access control and confidentiality
> requirements as the base LoST protocol. As a result, the security
> measures incorporated in the base LoST specification provide
> sufficient protection for LoST messages that use the service list
> boundary extension.
> "
>
> What do you think?
>
> Thank you for reviewing the draft,
>
> karl heinz


From RMarshall@telecomsys.com  Mon Feb  1 15:46:17 2010
Return-Path: <RMarshall@telecomsys.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 6C7B828C0E4 for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 15:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0wyCjyTQ9Kf5 for <ecrit@core3.amsl.com>; Mon,  1 Feb 2010 15:46:16 -0800 (PST)
Received: from ann-mimesweep-1.telecomsys.com (ann-mimesweep-1.telecomsys.com [205.244.233.171]) by core3.amsl.com (Postfix) with ESMTP id 05EDB3A69B6 for <ecrit@ietf.org>; Mon,  1 Feb 2010 15:46:15 -0800 (PST)
Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by  ann-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP  id <T93974400690a010105390@ann-mimesweep-1.telecomsys.com>; Mon, 1  Feb 2010 18:46:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 1 Feb 2010 15:46:43 -0800
Message-ID: <8C837214C95C864C9F34F3635C2A657510E7BC37@SEA-EXCHVS-2.telecomsys.com>
In-Reply-To: <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.txt
Thread-Index: AcqjR83QIwM8VNvsS/eGfWLcmRFQWgAUMHOQ
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net><8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com><31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com> <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com>
From: "Roger Marshall" <RMarshall@telecomsys.com>
To: "Karl Heinz Wolf" <khwolf1@gmail.com>, "Richard L. Barnes"  <rbarnes@bbn.com>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.txt
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: Mon, 01 Feb 2010 23:46:17 -0000

Karl:
I've provided some comments to draft-ietf-ecrit-lost-servicelistboundary-01=
.  Please forgive if some of these comments have already been covered by ot=
hers.

Beside these (mostly minor) errors below, I think the draft looks good, and=
 is ready to move on.

-roger marshall.

/
C1. Suggested rewording to abstract in order to clarify the problem.
Change from:
" 	=09
			LoST maps service identifiers and location information to service=09
			contact URIs. If a LoST client wants to discover available services=09
			for a particular location, it will perform a <listServicesByLocation>=09
			query to the LoST server. However, the response from the LoST server=09
			does not provide information about the geographical region for which=09
			the returned service list is valid. Therefore, this document=09
			proposes a ServiceListBoundary to assist the client to not miss a=09
			change in available services when moving.
"

Change to:
"
	=09
			LoST maps service identifiers and location information to service=09
			contact URIs. If a LoST client wants to discover available services=09
			for a particular location, it will perform a <listServicesByLocation>=09
			query to the LoST server. However, the LoST server, in its response,=20
			does not provide context information, that is, it does not provide=20
                  any additional information about the geographical region =
for which=09
			the returned service list is considered valid within. Therefore, this do=
cument=09
			proposes a ServiceListBoundary message that returns a local context alon=
g=20
                  with the list of services returned, in order to assist th=
e client to not miss a=09
			change in available services when moving.
"

C2. Introduction, pp1., suggest rewording,
Change from:
" But
   the server does not inform the client for which geographical region
   the returned service list is valid.
"

Change to:
" But
   the server does not inform the client as to the extent of coverage for w=
hich geographical region
   the returned service list is valid.
"

C3. Introduction, pp1., spelling,
s/discoverers/discovers/1

c4. Introduction, question,
Change from:
" Consequently, the
   dialstring for the mountain rescue is not known by the client, and
   the emergency call to the mountain rescue service will certainly
   fail.
"
Change to:
" Consequently, the
   dialstring for the mountain rescue is not known by the client, and
   the emergency call to the mountain rescue service will certainly
   fail.
"

C5.=20
Change from:
" o  a boundary information (telling the client that the service list
      does not change inside this area)

Since the LoST protocol has the ServiceBoundary concept in order to
   avoid that clients continuously try to refresh the mapping of a
   specific service, a ServiceListBoundary would provide a similar
   mechanism for service lists.

"
Change to:
" o  boundary extent information is provided (telling the client that the s=
ervice list
      does not change inside this area)

Since the LoST protocol employs the ServiceBoundary concept in order to
   avoid having clients continuously trying to refresh the mapping of a
   specific service, a ServiceListBoundary mechanism would provide similar
   advantages for service lists.
"

C6.=20
Change from:
" 3.1. Extensions to <ListServiceByLocation>


   The query <listServicesByLocation> may contain an additional
   serviceListBoundary element to request the boundary for the service
   list, either by value or by reference.
"

Change to:
" 3.1. Extensions to <ListServiceByLocation>


   The query <listServicesByLocation> may contain an additional
   serviceListBoundary element to additionally request the boundary for the=
 service
   list based on the location provided, with the resulting location for the=
 list to be presented either=20
in a by value or by reference form.
"

C7 remove "sld:" element name placeholders (several instances - I assume th=
at these are not intentional)
Change from:
        <slb:serviceListBoundary>value</slb:serviceListBoundary>

Change to:
        <serviceListBoundary>value</serviceListBoundary>

C8.
Change from:
" 3.3. Service List Boundary


   The service list boundary indicates a region within which all
   <listServicesByLocation> queries with the same service identifiers
   result in the same serviceList. =20
"
Change to:
" 3.3. Service List Boundary


   The service list boundary indicates a region within which all
   <listServicesByLocation> queries with the same service identifiers
   result in the same serviceList. =20
"

C9. Question, Is "<locationUsed id=3D"mylocation"/> in section 3.1, (3rd ex=
ample code)
Really what you want to use here? =20
Comment: RFC5222 uses "    <locationUsed id=3D"6020688f1ce1896d"/>", which =
is a little more discrete.

C10. Comment, delete unwanted space, consistent use of brackets (see 3.1)
Change from:
"3.2. Retrieving the serviceList Boundary via getServiceListBoundary
"
Change to:
"3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>
"

C11. Comment, the use of brackets and spaces throughout document (ignore if=
 this use is intentional)
Change from:
"The serviceListKey uniquely identifies a serviceListBoundary
"
Change to:
"The <serviceListKey> uniquely identifies a <serviceListBoundary>
"

C12. Comment,=20
Change from:
"3.3. Service List Boundary


   The service list boundary indicates a region within which all
   <listServicesByLocation> queries with the same service identifiers
   result in the same serviceList. =20
"
Change to:
"3.3. <serviceListBoundary>


   The service list boundary information that gets returned, indicates the =
geographic region in which all
   the service identifiers returned from a <serviceList> element are the sa=
me, within a <listServicesByLocation> query. =20
"

/end.

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of K=
arl Heinz Wolf
Sent: Monday, February 01, 2010 6:07 AM
To: Richard L. Barnes
Cc: Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org; Thomson,Martin
Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.t=
xt

Hi Richard,

On Thu, Jan 28, 2010 at 6:05 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> I generally agree with Martin's comments regarding changes to the XML
> structure, especially having different elements for requesting and return=
ing
> service list boundaries.

I'll do this change.

>
> I would also like to see a little more explanation in the Security
> Considerations, e.g.:
> "
> This document extends the LoST protocol [RFC5222] to allow it to carry
> service list boundaries (and requests for them). =A0While this information
> cannot be directly derived from information in the current protocol, it is
> generally considered to have the same level of sensitivity -- namely, it =
is
> generally public information -- and thus the same access control and
> confidentiality requirements as the base LoST protocol. =A0As a result, t=
he
> security measures incorporated in the base LoST specification provide
> sufficient protection for LoST messages that use the service list boundary
> extension.
> "

Thank you for this suggestion. I have slightly modified it to stress
that the servicelistboundary is calculated by the server based on the
individual service boundaries and each server may decide based on its
local policy to include the servicelistboundary or not.

"
Security considerations for LoST are discussed in RFC5222. This
document extends LoST to also carry service list boundaries (and
requests for them). These service list boundaries are calculated by
the server based on the individual service boundaries and sent to
clients in case the local policy allows this. Therefore it is
generally considered to have the same level of sensitivity as for the
service boundary and thus the same access control and confidentiality
requirements as the base LoST protocol. As a result, the security
measures incorporated in the base LoST specification provide
sufficient protection for LoST messages that use the service list
boundary extension.
"

What do you think?

Thank you for reviewing the draft,

karl heinz
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

CONFIDENTIALITY NOTICE: The information contained in this message may be pr=
ivileged and/or confidential. If you are not the intended recipient, or res=
ponsible for delivering this message to the intended recipient, any review,=
 forwarding, dissemination, distribution or copying of this communication o=
r any attachment(s) is strictly prohibited. If you have received this messa=
ge in error, please notify the sender immediately, and delete it and all at=
tachments from your computer and network.

From khwolf1@gmail.com  Thu Feb  4 05:45:50 2010
Return-Path: <khwolf1@gmail.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 645B228C18A for <ecrit@core3.amsl.com>; Thu,  4 Feb 2010 05:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Xe4v9HCwyOG9 for <ecrit@core3.amsl.com>; Thu,  4 Feb 2010 05:45:48 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 96D903A6881 for <ecrit@ietf.org>; Thu,  4 Feb 2010 05:45:48 -0800 (PST)
Received: by pzk5 with SMTP id 5so3830134pzk.29 for <ecrit@ietf.org>; Thu, 04 Feb 2010 05:46:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zYMtA/zC4+MhgkjZJF5r8imo302/s0iKtn3stg40Vkw=; b=SiMEUKzUgk88jjxhzrkhlnlTaiPnLZHA330jjpjaFSY47K2rCPqnkxIqFoSw8vUQfb U7iUozZUaxEctGDjykgZrkC23ahbM80YrcJMm3CnjgxKXdDvRDWCjvo33FVzQsCbYj8F 1PgkAZ4Y+biqMP+oHWqUzFiPkCmGjLDVnAQVQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qqw5fP+5OLn1wSWnh6n8d6qIyLucHYaG+feNKMp7fATkj2OTQiGFS4G/A0jPqalxrW egavPUb26IRKMzCoZnCExNw0N8suOsyW6KxIEV9lxX3BXVHZPbHHfvfjpVRPrE910iiU UqmPTN1BcB3ajEkw8iCOV/ulOchs6qVK5HUuA=
MIME-Version: 1.0
Received: by 10.141.107.14 with SMTP id j14mr784730rvm.78.1265291191174; Thu,  04 Feb 2010 05:46:31 -0800 (PST)
In-Reply-To: <8C837214C95C864C9F34F3635C2A657510E7BC37@SEA-EXCHVS-2.telecomsys.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com> <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com> <8C837214C95C864C9F34F3635C2A657510E7BC37@SEA-EXCHVS-2.telecomsys.com>
Date: Thu, 4 Feb 2010 14:46:31 +0100
Message-ID: <f77644531002040546w7a2ca8f2n35e4884dd75ce3fe@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: Roger Marshall <RMarshall@telecomsys.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.txt
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, 04 Feb 2010 13:45:50 -0000

Roger,

thank you for your detailed review and your valuable text suggestions
- I have commented them inline. I just have a remark to C7 (the
namespace was intentional) and I didn't see you change request in C4.
I have incorporated the other comments and will publish an updated
version soon.

Thank you,
Karl Heinz

On Tue, Feb 2, 2010 at 12:46 AM, Roger Marshall
<RMarshall@telecomsys.com> wrote:
> Karl:
> I've provided some comments to draft-ietf-ecrit-lost-servicelistboundary-=
01. =A0Please forgive if some of these comments have already been covered b=
y others.
>
> Beside these (mostly minor) errors below, I think the draft looks good, a=
nd is ready to move on.
>
> -roger marshall.
>
> /
> C1. Suggested rewording to abstract in order to clarify the problem.
> Change from:
> "
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LoST maps service identifi=
ers and location information to service
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact URIs. If a LoST cl=
ient wants to discover available services
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for a particular location,=
 it will perform a <listServicesByLocation>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0query to the LoST server. =
However, the response from the LoST server
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not provide informati=
on about the geographical region for which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the returned service list =
is valid. Therefore, this document
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposes a ServiceListBoun=
dary to assist the client to not miss a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change in available servic=
es when moving.
> "
>
> Change to:
> "
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LoST maps service identifi=
ers and location information to service
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact URIs. If a LoST cl=
ient wants to discover available services
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for a particular location,=
 it will perform a <listServicesByLocation>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0query to the LoST server. =
However, the LoST server, in its response,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not provide context i=
nformation, that is, it does not provide
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0any additional information about the g=
eographical region for which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the returned service list =
is considered valid within. Therefore, this document
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposes a ServiceListBoun=
dary message that returns a local context along
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with the list of services returned, in=
 order to assist the client to not miss a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change in available servic=
es when moving.
> "

ok

>
> C2. Introduction, pp1., suggest rewording,
> Change from:
> " But
> =A0 the server does not inform the client for which geographical region
> =A0 the returned service list is valid.
> "
>
> Change to:
> " But
> =A0 the server does not inform the client as to the extent of coverage fo=
r which geographical region
> =A0 the returned service list is valid.
> "
ok
>
> C3. Introduction, pp1., spelling,
> s/discoverers/discovers/1
>
ok
> c4. Introduction, question,
> Change from:
> " Consequently, the
> =A0 dialstring for the mountain rescue is not known by the client, and
> =A0 the emergency call to the mountain rescue service will certainly
> =A0 fail.
> "
> Change to:
> " Consequently, the
> =A0 dialstring for the mountain rescue is not known by the client, and
> =A0 the emergency call to the mountain rescue service will certainly
> =A0 fail.
> "
>

I do not see your change request here.

> C5.
> Change from:
> " o =A0a boundary information (telling the client that the service list
> =A0 =A0 =A0does not change inside this area)
>
> Since the LoST protocol has the ServiceBoundary concept in order to
> =A0 avoid that clients continuously try to refresh the mapping of a
> =A0 specific service, a ServiceListBoundary would provide a similar
> =A0 mechanism for service lists.
>
> "
> Change to:
> " o =A0boundary extent information is provided (telling the client that t=
he service list
> =A0 =A0 =A0does not change inside this area)
>
> Since the LoST protocol employs the ServiceBoundary concept in order to
> =A0 avoid having clients continuously trying to refresh the mapping of a
> =A0 specific service, a ServiceListBoundary mechanism would provide simil=
ar
> =A0 advantages for service lists.
> "

ok

> C6.
> Change from:
> " 3.1. Extensions to <ListServiceByLocation>
>
>
> =A0 The query <listServicesByLocation> may contain an additional
> =A0 serviceListBoundary element to request the boundary for the service
> =A0 list, either by value or by reference.
> "
>
> Change to:
> " 3.1. Extensions to <ListServiceByLocation>
>
>
> =A0 The query <listServicesByLocation> may contain an additional
> =A0 serviceListBoundary element to additionally request the boundary for =
the service
> =A0 list based on the location provided, with the resulting location for =
the list to be presented either
> in a by value or by reference form.
> "
>

ok

> C7 remove "sld:" element name placeholders (several instances - I assume =
that these are not intentional)
> Change from:
> =A0 =A0 =A0 =A0<slb:serviceListBoundary>value</slb:serviceListBoundary>
>
> Change to:
> =A0 =A0 =A0 =A0<serviceListBoundary>value</serviceListBoundary>
>

The "slb:" is intentional. I think this is correct, because the
default namespace is the LoST namespace.

> C8.
> Change from:
> " 3.3. Service List Boundary
>
>
> =A0 The service list boundary indicates a region within which all
> =A0 <listServicesByLocation> queries with the same service identifiers
> =A0 result in the same serviceList.
> "
> Change to:
> " 3.3. Service List Boundary
>
>
> =A0 The service list boundary indicates a region within which all
> =A0 <listServicesByLocation> queries with the same service identifiers
> =A0 result in the same serviceList.
> "
> C9. Question, Is "<locationUsed id=3D"mylocation"/> in section 3.1, (3rd =
example code)
> Really what you want to use here?
> Comment: RFC5222 uses " =A0 =A0<locationUsed id=3D"6020688f1ce1896d"/>", =
which is a little more discrete.

I've changed it to a more discrete id.

> C10. Comment, delete unwanted space, consistent use of brackets (see 3.1)
> Change from:
> "3.2. Retrieving the serviceList Boundary via getServiceListBoundary
> "
> Change to:
> "3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>
> "

ok

>
> C11. Comment, the use of brackets and spaces throughout document (ignore =
if this use is intentional)
> Change from:
> "The serviceListKey uniquely identifies a serviceListBoundary
> "
> Change to:
> "The <serviceListKey> uniquely identifies a <serviceListBoundary>
> "

I'll use 'serviceListKey' and <serviceListBoundary>.

>
> C12. Comment,
> Change from:
> "3.3. Service List Boundary
>
>
> =A0 The service list boundary indicates a region within which all
> =A0 <listServicesByLocation> queries with the same service identifiers
> =A0 result in the same serviceList.
> "
> Change to:
> "3.3. <serviceListBoundary>
>
>
> =A0 The service list boundary information that gets returned, indicates t=
he geographic region in which all
> =A0 the service identifiers returned from a <serviceList> element are the=
 same, within a <listServicesByLocation> query.
> "

ok

> /end.
>

From RMarshall@telecomsys.com  Thu Feb  4 08:08:33 2010
Return-Path: <RMarshall@telecomsys.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 1C28E3A6B15 for <ecrit@core3.amsl.com>; Thu,  4 Feb 2010 08:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QVr8rNbpCWnJ for <ecrit@core3.amsl.com>; Thu,  4 Feb 2010 08:08:32 -0800 (PST)
Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id D918B3A6909 for <ecrit@ietf.org>; Thu,  4 Feb 2010 08:08:31 -0800 (PST)
Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by  sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP  id <T93a46f6c090a200c494e8@sea-mimesweep-1.telecomsys.com>; Thu, 4  Feb 2010 08:09:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 4 Feb 2010 08:08:35 -0800
Message-ID: <8C837214C95C864C9F34F3635C2A657510EDB3A0@SEA-EXCHVS-2.telecomsys.com>
In-Reply-To: <f77644531002040546w7a2ca8f2n35e4884dd75ce3fe@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.txt
Thread-Index: AcqloHZO/h4o6OPUQqKrQ2USjhJ0AQAEgRVw
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com>  <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com>  <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com>  <8C837214C95C864C9F34F3635C2A657510E7BC37@SEA-EXCHVS-2.telecomsys.com>  <f77644531002040546w7a2ca8f2n35e4884dd75ce3fe@mail.gmail.com>
From: "Roger Marshall" <RMarshall@telecomsys.com>
To: "Karl Heinz Wolf" <khwolf1@gmail.com>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.txt
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, 04 Feb 2010 16:08:33 -0000

Karl:

Thank you for agreeing to make these changes.  Here's C4 once again, this t=
ime with the proposed change.


> c4. Introduction, question,
> Change from:
> " Consequently, the
>   dialstring for the mountain rescue is not known by the client, and
>   the emergency call to the mountain rescue service will certainly
>   fail.
> "

Change to:
" Consequently, the
  dialstring for the mountain rescue is not known by the client, and
  an emergency call made may either end up being routed to a plain PSAP rat=
her=20
than to the mountain rescue service, using the already known dialstring, or=
 may fail altogether if the mountain rescue number is used but not recogniz=
ed by the client.
"

-roger.

-----Original Message-----
From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=20
Sent: Thursday, February 04, 2010 5:47 AM
To: Roger Marshall
Cc: Richard L. Barnes; Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.org;=
 Thomson,Martin
Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.t=
xt

Roger,

thank you for your detailed review and your valuable text suggestions
- I have commented them inline. I just have a remark to C7 (the
namespace was intentional) and I didn't see you change request in C4.
I have incorporated the other comments and will publish an updated
version soon.

Thank you,
Karl Heinz

On Tue, Feb 2, 2010 at 12:46 AM, Roger Marshall
<RMarshall@telecomsys.com> wrote:
> Karl:
> I've provided some comments to draft-ietf-ecrit-lost-servicelistboundary-=
01. =A0Please forgive if some of these comments have already been covered b=
y others.
>
> Beside these (mostly minor) errors below, I think the draft looks good, a=
nd is ready to move on.
>
> -roger marshall.
>
> /
> C1. Suggested rewording to abstract in order to clarify the problem.
> Change from:
> "
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LoST maps service identifi=
ers and location information to service
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact URIs. If a LoST cl=
ient wants to discover available services
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for a particular location,=
 it will perform a <listServicesByLocation>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0query to the LoST server. =
However, the response from the LoST server
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not provide informati=
on about the geographical region for which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the returned service list =
is valid. Therefore, this document
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposes a ServiceListBoun=
dary to assist the client to not miss a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change in available servic=
es when moving.
> "
>
> Change to:
> "
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LoST maps service identifi=
ers and location information to service
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact URIs. If a LoST cl=
ient wants to discover available services
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for a particular location,=
 it will perform a <listServicesByLocation>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0query to the LoST server. =
However, the LoST server, in its response,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not provide context i=
nformation, that is, it does not provide
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0any additional information about the g=
eographical region for which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the returned service list =
is considered valid within. Therefore, this document
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposes a ServiceListBoun=
dary message that returns a local context along
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with the list of services returned, in=
 order to assist the client to not miss a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change in available servic=
es when moving.
> "

ok

>
> C2. Introduction, pp1., suggest rewording,
> Change from:
> " But
> =A0 the server does not inform the client for which geographical region
> =A0 the returned service list is valid.
> "
>
> Change to:
> " But
> =A0 the server does not inform the client as to the extent of coverage fo=
r which geographical region
> =A0 the returned service list is valid.
> "
ok
>
> C3. Introduction, pp1., spelling,
> s/discoverers/discovers/1
>
ok
> c4. Introduction, question,
> Change from:
> " Consequently, the
> =A0 dialstring for the mountain rescue is not known by the client, and
> =A0 the emergency call to the mountain rescue service will certainly
> =A0 fail.
> "
> Change to:
> " Consequently, the
> =A0 dialstring for the mountain rescue is not known by the client, and
> =A0 the emergency call to the mountain rescue service will certainly
> =A0 fail.
> "
>

I do not see your change request here.

> C5.
> Change from:
> " o =A0a boundary information (telling the client that the service list
> =A0 =A0 =A0does not change inside this area)
>
> Since the LoST protocol has the ServiceBoundary concept in order to
> =A0 avoid that clients continuously try to refresh the mapping of a
> =A0 specific service, a ServiceListBoundary would provide a similar
> =A0 mechanism for service lists.
>
> "
> Change to:
> " o =A0boundary extent information is provided (telling the client that t=
he service list
> =A0 =A0 =A0does not change inside this area)
>
> Since the LoST protocol employs the ServiceBoundary concept in order to
> =A0 avoid having clients continuously trying to refresh the mapping of a
> =A0 specific service, a ServiceListBoundary mechanism would provide simil=
ar
> =A0 advantages for service lists.
> "

ok

> C6.
> Change from:
> " 3.1. Extensions to <ListServiceByLocation>
>
>
> =A0 The query <listServicesByLocation> may contain an additional
> =A0 serviceListBoundary element to request the boundary for the service
> =A0 list, either by value or by reference.
> "
>
> Change to:
> " 3.1. Extensions to <ListServiceByLocation>
>
>
> =A0 The query <listServicesByLocation> may contain an additional
> =A0 serviceListBoundary element to additionally request the boundary for =
the service
> =A0 list based on the location provided, with the resulting location for =
the list to be presented either
> in a by value or by reference form.
> "
>

ok

> C7 remove "sld:" element name placeholders (several instances - I assume =
that these are not intentional)
> Change from:
> =A0 =A0 =A0 =A0<slb:serviceListBoundary>value</slb:serviceListBoundary>
>
> Change to:
> =A0 =A0 =A0 =A0<serviceListBoundary>value</serviceListBoundary>
>

The "slb:" is intentional. I think this is correct, because the
default namespace is the LoST namespace.

> C8.
> Change from:
> " 3.3. Service List Boundary
>
>
> =A0 The service list boundary indicates a region within which all
> =A0 <listServicesByLocation> queries with the same service identifiers
> =A0 result in the same serviceList.
> "
> Change to:
> " 3.3. Service List Boundary
>
>
> =A0 The service list boundary indicates a region within which all
> =A0 <listServicesByLocation> queries with the same service identifiers
> =A0 result in the same serviceList.
> "
> C9. Question, Is "<locationUsed id=3D"mylocation"/> in section 3.1, (3rd =
example code)
> Really what you want to use here?
> Comment: RFC5222 uses " =A0 =A0<locationUsed id=3D"6020688f1ce1896d"/>", =
which is a little more discrete.

I've changed it to a more discrete id.

> C10. Comment, delete unwanted space, consistent use of brackets (see 3.1)
> Change from:
> "3.2. Retrieving the serviceList Boundary via getServiceListBoundary
> "
> Change to:
> "3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>
> "

ok

>
> C11. Comment, the use of brackets and spaces throughout document (ignore =
if this use is intentional)
> Change from:
> "The serviceListKey uniquely identifies a serviceListBoundary
> "
> Change to:
> "The <serviceListKey> uniquely identifies a <serviceListBoundary>
> "

I'll use 'serviceListKey' and <serviceListBoundary>.

>
> C12. Comment,
> Change from:
> "3.3. Service List Boundary
>
>
> =A0 The service list boundary indicates a region within which all
> =A0 <listServicesByLocation> queries with the same service identifiers
> =A0 result in the same serviceList.
> "
> Change to:
> "3.3. <serviceListBoundary>
>
>
> =A0 The service list boundary information that gets returned, indicates t=
he geographic region in which all
> =A0 the service identifiers returned from a <serviceList> element are the=
 same, within a <listServicesByLocation> query.
> "

ok

> /end.
>

CONFIDENTIALITY NOTICE: The information contained in this message may be pr=
ivileged and/or confidential. If you are not the intended recipient, or res=
ponsible for delivering this message to the intended recipient, any review,=
 forwarding, dissemination, distribution or copying of this communication o=
r any attachment(s) is strictly prohibited. If you have received this messa=
ge in error, please notify the sender immediately, and delete it and all at=
tachments from your computer and network.

From khwolf1@gmail.com  Fri Feb  5 00:14:10 2010
Return-Path: <khwolf1@gmail.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 DC1223A6898 for <ecrit@core3.amsl.com>; Fri,  5 Feb 2010 00:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 wu800L3nxJH8 for <ecrit@core3.amsl.com>; Fri,  5 Feb 2010 00:13:59 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 6DCBC3A67E5 for <ecrit@ietf.org>; Fri,  5 Feb 2010 00:13:53 -0800 (PST)
Received: by pzk5 with SMTP id 5so26440pzk.29 for <ecrit@ietf.org>; Fri, 05 Feb 2010 00:14:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bVWR6c6eltBUPQUr6v6+w8tWhyeuvt3hDEcUlU0GVRY=; b=nBNrW8SPyO1M8MDtUS5j2Ti9NG8aMLt427UlUFJpmHvkHP6qwD1+SW6XvtdNdM3Swg 9116avkH05Co1r04+f0MOTBWuOxLWTFaw11rysbjjjBkNCxkZ8vCzLkrAqVgWxh2Bgux /H5adgj9S0oVp7aaklaWOfJ82a2FioGvRnkbY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mxTKYDJkg7922585qi7hVAaM85diic8pNu89tN2EhO2njAoEZPBfirynVW+exaYvvO YVKOblEHgJaRIui/Bn+/JVLTDa90aqjdfXCAV7QP59gJZV0LAGpdj2YE7AfkuO9b6MM7 uhIqJiMEWtuNmJYcLcvI8YAybefyeUqMSvPXQ=
MIME-Version: 1.0
Received: by 10.141.106.9 with SMTP id i9mr1621765rvm.23.1265357671687; Fri,  05 Feb 2010 00:14:31 -0800 (PST)
In-Reply-To: <8C837214C95C864C9F34F3635C2A657510EDB3A0@SEA-EXCHVS-2.telecomsys.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45021310CE@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F032E4A9A88@SISPE7MB1.commscope.com> <31620B80-EF99-4917-9F84-AE058B47EE71@bbn.com> <f77644531002010606p4dcc093dlc9a80b4e930c266a@mail.gmail.com> <8C837214C95C864C9F34F3635C2A657510E7BC37@SEA-EXCHVS-2.telecomsys.com> <f77644531002040546w7a2ca8f2n35e4884dd75ce3fe@mail.gmail.com> <8C837214C95C864C9F34F3635C2A657510EDB3A0@SEA-EXCHVS-2.telecomsys.com>
Date: Fri, 5 Feb 2010 09:14:31 +0100
Message-ID: <f77644531002050014n67def7a6y7020718157544700@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: Roger Marshall <RMarshall@telecomsys.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01.txt
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: Fri, 05 Feb 2010 08:14:14 -0000

Roger,

thank you again for help. I have reworded your suggestion a little bit
in order to make it clearer that when the user enters the dialstring
it cannot be recognized by the client in this case. Consequently the
client also wouldn't route the call to another PSAP since it does not
know that the number the user entered is an emergency dialstring.

> Change to:
> " Consequently, the
> =A0dialstring for the mountain rescue is not known by the client, and
> =A0an emergency call made may either end up being routed to a plain PSAP =
rather
> than to the mountain rescue service, using the already known dialstring, =
or may fail altogether if the mountain rescue number is used but not recogn=
ized by the client.
> "
"
Consequently, the dialstring for the mountain rescue is not known by
the client. Hence, the client is unable to recognize an emergency call
when the user enters the dialstring of the mountain rescue and thus
the emergency call may fail altogether.
"

I hope you are ok with this change.

Thank you,
Karl


>
> -roger.
>
> -----Original Message-----
> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> Sent: Thursday, February 04, 2010 5:47 AM
> To: Roger Marshall
> Cc: Richard L. Barnes; Tschofenig, Hannes (NSN - FI/Espoo); ecrit@ietf.or=
g; Thomson,Martin
> Subject: Re: [Ecrit] WGLC fordraft-ietf-ecrit-lost-servicelistboundary-01=
.txt
>
> Roger,
>
> thank you for your detailed review and your valuable text suggestions
> - I have commented them inline. I just have a remark to C7 (the
> namespace was intentional) and I didn't see you change request in C4.
> I have incorporated the other comments and will publish an updated
> version soon.
>
> Thank you,
> Karl Heinz
>
> On Tue, Feb 2, 2010 at 12:46 AM, Roger Marshall
> <RMarshall@telecomsys.com> wrote:
>> Karl:
>> I've provided some comments to draft-ietf-ecrit-lost-servicelistboundary=
-01. =A0Please forgive if some of these comments have already been covered =
by others.
>>
>> Beside these (mostly minor) errors below, I think the draft looks good, =
and is ready to move on.
>>
>> -roger marshall.
>>
>> /
>> C1. Suggested rewording to abstract in order to clarify the problem.
>> Change from:
>> "
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LoST maps service identif=
iers and location information to service
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact URIs. If a LoST c=
lient wants to discover available services
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for a particular location=
, it will perform a <listServicesByLocation>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0query to the LoST server.=
 However, the response from the LoST server
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not provide informat=
ion about the geographical region for which
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the returned service list=
 is valid. Therefore, this document
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposes a ServiceListBou=
ndary to assist the client to not miss a
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change in available servi=
ces when moving.
>> "
>>
>> Change to:
>> "
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LoST maps service identif=
iers and location information to service
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0contact URIs. If a LoST c=
lient wants to discover available services
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for a particular location=
, it will perform a <listServicesByLocation>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0query to the LoST server.=
 However, the LoST server, in its response,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not provide context =
information, that is, it does not provide
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0any additional information about the =
geographical region for which
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the returned service list=
 is considered valid within. Therefore, this document
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proposes a ServiceListBou=
ndary message that returns a local context along
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with the list of services returned, i=
n order to assist the client to not miss a
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0change in available servi=
ces when moving.
>> "
>
> ok
>
>>
>> C2. Introduction, pp1., suggest rewording,
>> Change from:
>> " But
>> =A0 the server does not inform the client for which geographical region
>> =A0 the returned service list is valid.
>> "
>>
>> Change to:
>> " But
>> =A0 the server does not inform the client as to the extent of coverage f=
or which geographical region
>> =A0 the returned service list is valid.
>> "
> ok
>>
>> C3. Introduction, pp1., spelling,
>> s/discoverers/discovers/1
>>
> ok
>> c4. Introduction, question,
>> Change from:
>> " Consequently, the
>> =A0 dialstring for the mountain rescue is not known by the client, and
>> =A0 the emergency call to the mountain rescue service will certainly
>> =A0 fail.
>> "
>> Change to:
>> " Consequently, the
>> =A0 dialstring for the mountain rescue is not known by the client, and
>> =A0 the emergency call to the mountain rescue service will certainly
>> =A0 fail.
>> "
>>
>
> I do not see your change request here.
>
>> C5.
>> Change from:
>> " o =A0a boundary information (telling the client that the service list
>> =A0 =A0 =A0does not change inside this area)
>>
>> Since the LoST protocol has the ServiceBoundary concept in order to
>> =A0 avoid that clients continuously try to refresh the mapping of a
>> =A0 specific service, a ServiceListBoundary would provide a similar
>> =A0 mechanism for service lists.
>>
>> "
>> Change to:
>> " o =A0boundary extent information is provided (telling the client that =
the service list
>> =A0 =A0 =A0does not change inside this area)
>>
>> Since the LoST protocol employs the ServiceBoundary concept in order to
>> =A0 avoid having clients continuously trying to refresh the mapping of a
>> =A0 specific service, a ServiceListBoundary mechanism would provide simi=
lar
>> =A0 advantages for service lists.
>> "
>
> ok
>
>> C6.
>> Change from:
>> " 3.1. Extensions to <ListServiceByLocation>
>>
>>
>> =A0 The query <listServicesByLocation> may contain an additional
>> =A0 serviceListBoundary element to request the boundary for the service
>> =A0 list, either by value or by reference.
>> "
>>
>> Change to:
>> " 3.1. Extensions to <ListServiceByLocation>
>>
>>
>> =A0 The query <listServicesByLocation> may contain an additional
>> =A0 serviceListBoundary element to additionally request the boundary for=
 the service
>> =A0 list based on the location provided, with the resulting location for=
 the list to be presented either
>> in a by value or by reference form.
>> "
>>
>
> ok
>
>> C7 remove "sld:" element name placeholders (several instances - I assume=
 that these are not intentional)
>> Change from:
>> =A0 =A0 =A0 =A0<slb:serviceListBoundary>value</slb:serviceListBoundary>
>>
>> Change to:
>> =A0 =A0 =A0 =A0<serviceListBoundary>value</serviceListBoundary>
>>
>
> The "slb:" is intentional. I think this is correct, because the
> default namespace is the LoST namespace.
>
>> C8.
>> Change from:
>> " 3.3. Service List Boundary
>>
>>
>> =A0 The service list boundary indicates a region within which all
>> =A0 <listServicesByLocation> queries with the same service identifiers
>> =A0 result in the same serviceList.
>> "
>> Change to:
>> " 3.3. Service List Boundary
>>
>>
>> =A0 The service list boundary indicates a region within which all
>> =A0 <listServicesByLocation> queries with the same service identifiers
>> =A0 result in the same serviceList.
>> "
>> C9. Question, Is "<locationUsed id=3D"mylocation"/> in section 3.1, (3rd=
 example code)
>> Really what you want to use here?
>> Comment: RFC5222 uses " =A0 =A0<locationUsed id=3D"6020688f1ce1896d"/>",=
 which is a little more discrete.
>
> I've changed it to a more discrete id.
>
>> C10. Comment, delete unwanted space, consistent use of brackets (see 3.1=
)
>> Change from:
>> "3.2. Retrieving the serviceList Boundary via getServiceListBoundary
>> "
>> Change to:
>> "3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>
>> "
>
> ok
>
>>
>> C11. Comment, the use of brackets and spaces throughout document (ignore=
 if this use is intentional)
>> Change from:
>> "The serviceListKey uniquely identifies a serviceListBoundary
>> "
>> Change to:
>> "The <serviceListKey> uniquely identifies a <serviceListBoundary>
>> "
>
> I'll use 'serviceListKey' and <serviceListBoundary>.
>
>>
>> C12. Comment,
>> Change from:
>> "3.3. Service List Boundary
>>
>>
>> =A0 The service list boundary indicates a region within which all
>> =A0 <listServicesByLocation> queries with the same service identifiers
>> =A0 result in the same serviceList.
>> "
>> Change to:
>> "3.3. <serviceListBoundary>
>>
>>
>> =A0 The service list boundary information that gets returned, indicates =
the geographic region in which all
>> =A0 the service identifiers returned from a <serviceList> element are th=
e same, within a <listServicesByLocation> query.
>> "
>
> ok
>
>> /end.
>>
>
> CONFIDENTIALITY NOTICE: The information contained in this message may be =
privileged and/or confidential. If you are not the intended recipient, or r=
esponsible for delivering this message to the intended recipient, any revie=
w, forwarding, dissemination, distribution or copying of this communication=
 or any attachment(s) is strictly prohibited. If you have received this mes=
sage in error, please notify the sender immediately, and delete it and all =
attachments from your computer and network.
>

From hannes.tschofenig@nsn.com  Mon Feb  8 06:44:37 2010
Return-Path: <hannes.tschofenig@nsn.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 BC2D53A67F0 for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 06:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level: 
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403,  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 vogHDJbIGthK for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 06:44:36 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3DB763A709A for <ecrit@ietf.org>; Mon,  8 Feb 2010 06:44:35 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o18EjZWY031844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Mon, 8 Feb 2010 15:45:35 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o18EjZS1031128 for <ecrit@ietf.org>; Mon, 8 Feb 2010 15:45:35 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 8 Feb 2010 15:45:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Feb 2010 16:49:48 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reminder: Virtual Interim Meeting
Thread-Index: AcqozfYd2Z/QEph6Qj+tvvXdOzjQog==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <ecrit@ietf.org>
X-OriginalArrivalTime: 08 Feb 2010 14:45:35.0039 (UTC) FILETIME=[5F1404F0:01CAA8CD]
Subject: [Ecrit] Reminder: Virtual Interim Meeting
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: Mon, 08 Feb 2010 14:44:37 -0000

Hi all,=20

Please keep our virtual interim meeting Thursday Feb. 11 8AM-10AM EST
(New York).

We plan to discuss the PSAP callback mechanism, see
http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt,
and to make some progress on the solution front.=20

The Webex info can be found below. =20

Ciao
Hannes & Marc


-- WEBEX

 Date: Thursday, February 11, 2010
 Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
Number: 209 813 488  Meeting Password: ietf
=20
=20
 -------------------------------------------------------
 To join the online meeting (Now from iPhones too!)
 -------------------------------------------------------
 1. Go to
https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D0&PW=3D=
NNjA
5ZTg4YzJm&RT=3DMiMxMQ%3D%3D
 2. Enter your name and email address.
 3. Enter the meeting password: ietf
 4. Click "Join Now".
=20
 To view in other time zones or languages, please click the link:
=20
https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D0&PW=3D=
NNjA
5ZTg4YzJm&ORT=3DMiMxMQ%3D%3D
=20
 ----------------------------------------------------------------
 ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
 ----------------------------------------------------------------
=20
 The affected toll free numbers are: (866) 432-9903 for the San
Jose/Milpitas area and (866) 349-3520 for the RTP area.
=20
 Please dial the local access number for your area from the list below:
 - San Jose/Milpitas (408) area: 525-6800
 - RTP (919) area: 392-3330
=20
 -------------------------------------------------------
 To join the teleconference only
 -------------------------------------------------------
 1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
 2. Follow the prompts to enter the Meeting Number (listed above) or
Access Code followed by the # sign.
=20
 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
=20
 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
=20
 India: +91.80.4350.1111 Germany: +49.619.6773.9002
=20
 Japan: +81.3.5763.9394 China: +86.10.8515.5666
=20
 -------------------------------------------------------
 For assistance
 -------------------------------------------------------
 1. Go to https://ciscosales.webex.com/ciscosales/mc
 2. On the left navigation bar, click "Support".
=20
 You can contact me at:
  mlinsner@cisco.com
 1-919 476 7083=20
=20
 To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
=20
https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D0&ICS=3D=
MI&
LD=3D1&RD=3D2&ST=3D1&SHA2=3DvAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE=3D=
&RT=3DMiMx
MQ%3D%3D=20
=20
 The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your
computer by going to
https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
=20
 Sign up for a free trial of WebEx
 http://www.webex.com/go/mcemfreetrial
=20
 http://www.webex.com
=20
=20
=20
 IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. By joining this session, you automatically
consent to such recordings. If you do not consent to the recording, do
not join the session.=20


From hannes.tschofenig@nsn.com  Mon Feb  8 07:11:07 2010
Return-Path: <hannes.tschofenig@nsn.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 6A8623A740C for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 07:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.397
X-Spam-Level: 
X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202,  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 5Xhxi5nlw7X1 for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 07:11:01 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 60D9D3A740A for <ecrit@ietf.org>; Mon,  8 Feb 2010 07:10:50 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o18FBprl030743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Mon, 8 Feb 2010 16:11:51 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o18FBpF6008990 for <ecrit@ietf.org>; Mon, 8 Feb 2010 16:11:51 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 8 Feb 2010 16:11:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Feb 2010 17:16:03 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45022A574F@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Reminder: Virtual Interim Meeting
Thread-Index: AcqozfYd2Z/QEph6Qj+tvvXdOzjQogAA4pcw
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, <ecrit@ietf.org>
X-OriginalArrivalTime: 08 Feb 2010 15:11:50.0687 (UTC) FILETIME=[0A3CD2F0:01CAA8D1]
Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting
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: Mon, 08 Feb 2010 15:11:07 -0000

Hi all,=20

Andrea suggested to also put the revision of the Service URN to the
agenda. He has updated the document but there are concerns from the side
of our Ads. Feedback from the group would also appreciated.=20

Thoughts about the addition of the document for discussion to the
agenda?=20

Ciao
Hannes
=20

>-----Original Message-----
>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20
>On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>Sent: 08 February, 2010 16:50
>To: ecrit@ietf.org
>Subject: [Ecrit] Reminder: Virtual Interim Meeting
>
>Hi all,=20
>
>Please keep our virtual interim meeting Thursday Feb. 11=20
>8AM-10AM EST (New York).
>
>We plan to discuss the PSAP callback mechanism, see=20
>http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt,
>and to make some progress on the solution front.=20
>
>The Webex info can be found below. =20
>
>Ciao
>Hannes & Marc
>
>
>-- WEBEX
>
> Date: Thursday, February 11, 2010
> Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
>Number: 209 813 488  Meeting Password: ietf
>=20
>=20
> -------------------------------------------------------
> To join the online meeting (Now from iPhones too!)
> -------------------------------------------------------
> 1. Go to
>https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>0&PW=3DNNjA
>5ZTg4YzJm&RT=3DMiMxMQ%3D%3D
> 2. Enter your name and email address.
> 3. Enter the meeting password: ietf
> 4. Click "Join Now".
>=20
> To view in other time zones or languages, please click the link:
>=20
>https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>0&PW=3DNNjA
>5ZTg4YzJm&ORT=3DMiMxMQ%3D%3D
>=20
> ----------------------------------------------------------------
> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> ----------------------------------------------------------------
>=20
> The affected toll free numbers are: (866) 432-9903 for the=20
>San Jose/Milpitas area and (866) 349-3520 for the RTP area.
>=20
> Please dial the local access number for your area from the list below:
> - San Jose/Milpitas (408) area: 525-6800
> - RTP (919) area: 392-3330
>=20
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20
>http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed=20
>above) or Access Code followed by the # sign.
>=20
> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>=20
> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>=20
> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>=20
> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>=20
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://ciscosales.webex.com/ciscosales/mc
> 2. On the left navigation bar, click "Support".
>=20
> You can contact me at:
>  mlinsner@cisco.com
> 1-919 476 7083=20
>=20
> To add this meeting to your calendar program (for example=20
>Microsoft Outlook), click this link:
>=20
>https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>0&ICS=3DMI&
>LD=3D1&RD=3D2&ST=3D1&SHA2=3DvAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE
>=3D&RT=3DMiMx
>MQ%3D%3D=20
>=20
> The playback of UCF (Universal Communications Format) rich=20
>media files requires appropriate players. To view this type of=20
>rich media files in the meeting, please check whether you have=20
>the players installed on your computer by going to=20
>https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>=20
> Sign up for a free trial of WebEx
> http://www.webex.com/go/mcemfreetrial
>=20
> http://www.webex.com
>=20
>=20
>=20
> IMPORTANT NOTICE: This WebEx service includes a feature that=20
>allows audio and any documents and other materials exchanged=20
>or viewed during the session to be recorded. By joining this=20
>session, you automatically consent to such recordings. If you=20
>do not consent to the recording, do not join the session.=20
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>

From hgs@cs.columbia.edu  Mon Feb  8 07:52:56 2010
Return-Path: <hgs@cs.columbia.edu>
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 AC3843A7425 for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 07:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rzp++twvU-f6 for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 07:52:55 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 57DE73A722B for <ecrit@ietf.org>; Mon,  8 Feb 2010 07:52:55 -0800 (PST)
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 o18FrtGv006408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2010 10:53:56 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45022A574F@FIESEXC015.nsn-intra.net>
Date: Mon, 8 Feb 2010 10:53:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <00B091B3-44FA-423A-9221-41CBF9B568D2@cs.columbia.edu>
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45022A574F@FIESEXC015.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting
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: Mon, 08 Feb 2010 15:52:56 -0000

Since "shadow boxing" and "tea leaf reading" aren't particularly =
productive, would the ADs consider revealing those concerns? I'm not =
sure how else we can have a productive discussion that doesn't just =
tread over the same old ground.

Henning

On Feb 8, 2010, at 10:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Hi all,=20
>=20
> Andrea suggested to also put the revision of the Service URN to the
> agenda. He has updated the document but there are concerns from the =
side
> of our Ads. Feedback from the group would also appreciated.=20
>=20
> Thoughts about the addition of the document for discussion to the
> agenda?=20
>=20
> Ciao
> Hannes
>=20
>=20
>> -----Original Message-----
>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20
>> On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>> Sent: 08 February, 2010 16:50
>> To: ecrit@ietf.org
>> Subject: [Ecrit] Reminder: Virtual Interim Meeting
>>=20
>> Hi all,=20
>>=20
>> Please keep our virtual interim meeting Thursday Feb. 11=20
>> 8AM-10AM EST (New York).
>>=20
>> We plan to discuss the PSAP callback mechanism, see=20
>> =
http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt,
>> and to make some progress on the solution front.=20
>>=20
>> The Webex info can be found below. =20
>>=20
>> Ciao
>> Hannes & Marc
>>=20
>>=20
>> -- WEBEX
>>=20
>> Date: Thursday, February 11, 2010
>> Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
>> Number: 209 813 488  Meeting Password: ietf
>>=20
>>=20
>> -------------------------------------------------------
>> To join the online meeting (Now from iPhones too!)
>> -------------------------------------------------------
>> 1. Go to
>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>> 0&PW=3DNNjA
>> 5ZTg4YzJm&RT=3DMiMxMQ%3D%3D
>> 2. Enter your name and email address.
>> 3. Enter the meeting password: ietf
>> 4. Click "Join Now".
>>=20
>> To view in other time zones or languages, please click the link:
>>=20
>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>> 0&PW=3DNNjA
>> 5ZTg4YzJm&ORT=3DMiMxMQ%3D%3D
>>=20
>> ----------------------------------------------------------------
>> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
>> ----------------------------------------------------------------
>>=20
>> The affected toll free numbers are: (866) 432-9903 for the=20
>> San Jose/Milpitas area and (866) 349-3520 for the RTP area.
>>=20
>> Please dial the local access number for your area from the list =
below:
>> - San Jose/Milpitas (408) area: 525-6800
>> - RTP (919) area: 392-3330
>>=20
>> -------------------------------------------------------
>> To join the teleconference only
>> -------------------------------------------------------
>> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20
>> http://cisco.com/en/US/about/doing_business/conferencing/index.html
>> 2. Follow the prompts to enter the Meeting Number (listed=20
>> above) or Access Code followed by the # sign.
>>=20
>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>>=20
>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>>=20
>> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>>=20
>> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>>=20
>> -------------------------------------------------------
>> For assistance
>> -------------------------------------------------------
>> 1. Go to https://ciscosales.webex.com/ciscosales/mc
>> 2. On the left navigation bar, click "Support".
>>=20
>> You can contact me at:
>> mlinsner@cisco.com
>> 1-919 476 7083=20
>>=20
>> To add this meeting to your calendar program (for example=20
>> Microsoft Outlook), click this link:
>>=20
>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>> 0&ICS=3DMI&
>> LD=3D1&RD=3D2&ST=3D1&SHA2=3DvAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE=

>> =3D&RT=3DMiMx
>> MQ%3D%3D=20
>>=20
>> The playback of UCF (Universal Communications Format) rich=20
>> media files requires appropriate players. To view this type of=20
>> rich media files in the meeting, please check whether you have=20
>> the players installed on your computer by going to=20
>> https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>>=20
>> Sign up for a free trial of WebEx
>> http://www.webex.com/go/mcemfreetrial
>>=20
>> http://www.webex.com
>>=20
>>=20
>>=20
>> IMPORTANT NOTICE: This WebEx service includes a feature that=20
>> allows audio and any documents and other materials exchanged=20
>> or viewed during the session to be recorded. By joining this=20
>> session, you automatically consent to such recordings. If you=20
>> do not consent to the recording, do not join the session.=20
>>=20
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>=20


From wwwrun@core3.amsl.com  Thu Feb  4 16:04:26 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id D7DAB28C1F0; Thu,  4 Feb 2010 16:04:26 -0800 (PST)
To: Hannes.Tschofenig@gmx.net,hgs+ecrit@cs.columbia.edu
From: IETF Secretariat <ietf-ipr@ietf.org>
Message-Id: <20100205000426.D7DAB28C1F0@core3.amsl.com>
Date: Thu,  4 Feb 2010 16:04:26 -0800 (PST)
X-Mailman-Approved-At: Mon, 08 Feb 2010 08:05:29 -0800
Cc: marc.linsner@cisco.com, ecrit@ietf.org, ipr-announce@ietf.org, rjsparks@nostrum.com
Subject: [Ecrit] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-ecrit-lost-sync-08
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: Fri, 05 Feb 2010 00:04:27 -0000

Dear Hannes Tschofenig, Henning Schulzrinne:

An IPR disclosure that pertains to your Internet-Draft entitled "Synchronizing
Location-to-Service Translation (LoST) Protocol based Service Boundaries and
Mapping Elements" (draft-ietf-ecrit-lost-sync) was submitted to the IETF
Secretariat on 2010-02-04 and has been posted on the "IETF Page of Intellectual
Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1257/). The title
of the IPR disclosure is "Cisco's Statement of IPR relating to
draft-ietf-ecrit-lost-sync-08."

The IETF Secretariat



From hannes.tschofenig@nsn.com  Mon Feb  8 08:49:14 2010
Return-Path: <hannes.tschofenig@nsn.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 A863528C14D for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 08:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level: 
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134,  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 SoJWVlNTAP1j for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 08:49:13 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8535128C153 for <ecrit@ietf.org>; Mon,  8 Feb 2010 08:49:13 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o18GoDnk026163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Mon, 8 Feb 2010 17:50:13 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o18GoBWI024278 for <ecrit@ietf.org>; Mon, 8 Feb 2010 17:50:13 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 8 Feb 2010 17:50:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Feb 2010 18:54:25 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45022A57F2@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Posting of IPR Disclosure related to Cisco's Statement ofIPR relating to draft-ietf-ecrit-lost-sync-08
Thread-Index: Acqo2LFIy8NUpA/+Sau/lm8iHdO7iwABqROw
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <ecrit@ietf.org>
X-OriginalArrivalTime: 08 Feb 2010 16:50:12.0063 (UTC) FILETIME=[C7BB56F0:01CAA8DE]
Subject: [Ecrit] FW: Posting of IPR Disclosure related to Cisco's Statement ofIPR relating to draft-ietf-ecrit-lost-sync-08
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: Mon, 08 Feb 2010 16:49:14 -0000

FYI=20

>-----Original Message-----
>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20
>On Behalf Of ext IETF Secretariat
>Sent: 05 February, 2010 02:04
>To: Hannes.Tschofenig@gmx.net; hgs+ecrit@cs.columbia.edu
>Cc: marc.linsner@cisco.com; ecrit@ietf.org;=20
>ipr-announce@ietf.org; rjsparks@nostrum.com
>Subject: [Ecrit] Posting of IPR Disclosure related to Cisco's=20
>Statement ofIPR relating to draft-ietf-ecrit-lost-sync-08
>
>Dear Hannes Tschofenig, Henning Schulzrinne:
>
>An IPR disclosure that pertains to your Internet-Draft=20
>entitled "Synchronizing Location-to-Service Translation (LoST)=20
>Protocol based Service Boundaries and Mapping Elements"=20
>(draft-ietf-ecrit-lost-sync) was submitted to the IETF=20
>Secretariat on 2010-02-04 and has been posted on the "IETF=20
>Page of Intellectual Property Rights Disclosures"=20
>(https://datatracker.ietf.org/ipr/1257/). The title of the IPR=20
>disclosure is "Cisco's Statement of IPR relating to=20
>draft-ietf-ecrit-lost-sync-08."
>
>The IETF Secretariat
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>

From root@core3.amsl.com  Mon Feb  8 23:45:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 397183A753F; Mon,  8 Feb 2010 23:45:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100209074502.397183A753F@core3.amsl.com>
Date: Mon,  8 Feb 2010 23:45:02 -0800 (PST)
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-02.txt
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: Tue, 09 Feb 2010 07:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.


	Title           : Location-to-Service Translation Protocol (LoST) Extension: <serviceListBoundary>
	Author(s)       : K. Wolf
	Filename        : draft-ietf-ecrit-lost-servicelistboundary-02.txt
	Pages           : 13
	Date            : 2010-02-08

LoST maps service identifiers and location information to service
contact URIs.  If a LoST client wants to discover available services
for a particular location, it will perform a <listServicesByLocation>
query to the LoST server.  However, the LoST server, in its response,
does not provide context information, that is, it does not provide
any additional information about the geographical region for which
the returned list of services is considered valid within.  Therefore,
this document proposes a <serviceListBoundary> element that returns a
local context along with the list of services returned, in order to
assist the client to not miss a change in available services when
moving.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboundary-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ecrit-lost-servicelistboundary-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-02-08233944.I-D@ietf.org>


--NextPart--

From khwolf1@gmail.com  Mon Feb  8 23:51:53 2010
Return-Path: <khwolf1@gmail.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 C560F3A68F2 for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 23:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nKjkXmcOdD53 for <ecrit@core3.amsl.com>; Mon,  8 Feb 2010 23:51:53 -0800 (PST)
Received: from mail-pz0-f173.google.com (mail-pz0-f173.google.com [209.85.222.173]) by core3.amsl.com (Postfix) with ESMTP id F2CAB3A67A5 for <ecrit@ietf.org>; Mon,  8 Feb 2010 23:51:52 -0800 (PST)
Received: by pzk3 with SMTP id 3so1216118pzk.5 for <ecrit@ietf.org>; Mon, 08 Feb 2010 23:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=UNAyxz519FeEm1gzK+X/NNS7a/4K/TvZ9JKtKYvkY4o=; b=ogc02w1rdD6R59eHL0FjFHmVNCCcyeVWYkiFnFAp+Ii41+x3oMeLWyYTVtDUfrQevS VZl/mTSOnNdPSv3lzBijtwW/ytMl9I7oxZFdCtBWDMT5wfHhusBrPYhOT8IRGyLqJN1x xUcsHaPOskcBFxMSvPJjBlaEpbqqVPimMaq64=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=VoErnkI0SwPV+te3y4hy0I14kXbbvubTX1sVfXevWru0EFr1eoZpkxBpvdImhKb3hJ HNmq48xRM0wPT3W7BXQw7lhWnkUUIIbNUiqX4z7m19hQDKHC9qVWP6K+jh8IdaQcNGIG 8a/0qZjtsbS/T+j9IB7e7ZnKcA6QBzuKu7oIw=
MIME-Version: 1.0
Received: by 10.141.139.11 with SMTP id r11mr5280167rvn.195.1265701975894;  Mon, 08 Feb 2010 23:52:55 -0800 (PST)
In-Reply-To: <20100209074502.397183A753F@core3.amsl.com>
References: <20100209074502.397183A753F@core3.amsl.com>
Date: Tue, 9 Feb 2010 08:52:55 +0100
Message-ID: <f77644531002082352x59e3b8f6n6ef3bce4d4d56d3a@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: ECRIT <ecrit@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-02.txt
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: Tue, 09 Feb 2010 07:51:53 -0000

I've just posted a new version of the draft based on the WGLC
comments. I'd like to thank Martin, Richard and Roger for their
detailed review.

karl heinz

On Tue, Feb 9, 2010 at 8:45 AM,  <Internet-Drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Emergency Context Resolution with Intern=
et Technologies Working Group of the IETF.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Location-to-Service Translatio=
n Protocol (LoST) Extension: <serviceListBoundary>
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : K. Wolf
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ecrit-lost-servicelis=
tboundary-02.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-02-08
>
> LoST maps service identifiers and location information to service
> contact URIs. =A0If a LoST client wants to discover available services
> for a particular location, it will perform a <listServicesByLocation>
> query to the LoST server. =A0However, the LoST server, in its response,
> does not provide context information, that is, it does not provide
> any additional information about the geographical region for which
> the returned list of services is considered valid within. =A0Therefore,
> this document proposes a <serviceListBoundary> element that returns a
> local context along with the list of services returned, in order to
> assist the client to not miss a change in available services when
> moving.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboun=
dary-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
>

From Milan.Patel@InterDigital.com  Tue Feb  9 04:21:56 2010
Return-Path: <Milan.Patel@InterDigital.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 4CFA028C1F1 for <ecrit@core3.amsl.com>; Tue,  9 Feb 2010 04:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 rZTZ6kaN8Oao for <ecrit@core3.amsl.com>; Tue,  9 Feb 2010 04:21:49 -0800 (PST)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 4E53428C1D6 for <ecrit@ietf.org>; Tue,  9 Feb 2010 04:21:49 -0800 (PST)
Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 9 Feb 2010 07:22:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA982.9B2D7B4C"
Date: Tue, 9 Feb 2010 07:22:54 -0500
Message-ID: <61CAF342FE1EE34EAC8FB19B765914000D7637EE@SABRE.InterDigital.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-patel-ecrit-sos-parameter
Thread-Index: Acqpgpsb2LrMuwagRN2idXq/HDT7gQ==
From: "Patel, Milan" <Milan.Patel@InterDigital.com>
To: <ecrit@ietf.org>, <fluffy@cisco.com>
X-OriginalArrivalTime: 09 Feb 2010 12:22:54.0763 (UTC) FILETIME=[9B2B4FB0:01CAA982]
Subject: [Ecrit] draft-patel-ecrit-sos-parameter
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: Tue, 09 Feb 2010 12:21:56 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAA982.9B2D7B4C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

At the previous meeting, it was requested that a feedback mechanism is
introduced to allow the UA to know if the registrar supports the
emergency registration extension or not (e.g. use of option-tag). It
seems from a 3GPP point of view this is not important. However, I can
understand that for other reg-type values, it may be useful to introduce
such feedback mechanism.=20

In order to progress this draft (since this seems to be the only
sticking point), I propose the following:

UA may include an option-tag (name to be decided) in the Supported
header field, if the UA needs to know if the reg-type URI parameter is
supported by the registrar. The registrar returns the option-tag in the
200 (OK) upon successful registration if the extension is supported.=20

Note, I am proposing this mechanism is introduced as an option...not
mandating the UA must include the option-tag during such registration.
Additionally, I am not including the option-tag in the Required header
field since if the emergency registration is not supported at the
registrar, fall back to normal non-emergency registration should occur -
not the failure of registration.=20

=20

Please let me know what you think. I will start on the revision.=20

Best regards,

Milan


------_=_NextPart_001_01CAA982.9B2D7B4C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>At the previous meeting, it was requested that =
a
feedback mechanism is introduced to allow the UA to know if the =
registrar
supports the emergency registration extension or not (e.g. use of =
option-tag).
It seems from a 3GPP point of view this is not important. However, I can
understand that for other reg-type values, it may be useful to introduce =
such
feedback mechanism. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>In order to progress this draft (since this =
seems to
be the only sticking point), I propose the =
following:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>UA may include an option-tag (name to be =
decided) in
the Supported header field, if the UA needs to know if the reg-type URI
parameter is supported by the registrar. The registrar returns the =
option-tag
in the 200 (OK) upon successful registration if the extension is =
supported. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Note, I am proposing this mechanism is =
introduced as
an option&#8230;not mandating the UA must include the option-tag during =
such
registration. Additionally, I am not including the option-tag in the =
Required
header field since if the emergency registration is not supported at the =
registrar,
fall back to normal non-emergency registration should occur &#8211; not =
the
failure of registration. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Please let me know what you think. I will =
start on
the revision. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Milan<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01CAA982.9B2D7B4C--

From peter.leis@nsn.com  Tue Feb  9 06:50:44 2010
Return-Path: <peter.leis@nsn.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 352FD3A71FA for <ecrit@core3.amsl.com>; Tue,  9 Feb 2010 06:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 a2nFZo9W65xA for <ecrit@core3.amsl.com>; Tue,  9 Feb 2010 06:50:43 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E26153A6BF8 for <ecrit@ietf.org>; Tue,  9 Feb 2010 06:50:42 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o19EpjKX017715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2010 15:51:45 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o19EpjEb018258; Tue, 9 Feb 2010 15:51:45 +0100
Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 9 Feb 2010 15:51:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Feb 2010 15:51:43 +0100
Message-ID: <D075E484906AB6479EEDA3624C87FAD18D4424@DEMUEXC035.nsn-intra.net>
In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000D7637EE@SABRE.InterDigital.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] draft-patel-ecrit-sos-parameter
Thread-Index: Acqpgpsb2LrMuwagRN2idXq/HDT7gQAE/FDA
References: <61CAF342FE1EE34EAC8FB19B765914000D7637EE@SABRE.InterDigital.com>
From: "Leis, Peter (NSN - DE/Munich)" <peter.leis@nsn.com>
To: "ext Patel, Milan" <Milan.Patel@InterDigital.com>, <ecrit@ietf.org>, <fluffy@cisco.com>
X-OriginalArrivalTime: 09 Feb 2010 14:51:44.0896 (UTC) FILETIME=[65F17800:01CAA997]
Subject: Re: [Ecrit] draft-patel-ecrit-sos-parameter
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: Tue, 09 Feb 2010 14:50:44 -0000

hello Milan,

I do support your approach as outlined below.

Peter

________________________________

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
Of ext Patel, Milan
Sent: Tuesday, February 09, 2010 1:23 PM
To: ecrit@ietf.org; fluffy@cisco.com
Subject: [Ecrit] draft-patel-ecrit-sos-parameter



Hi,

=20

At the previous meeting, it was requested that a feedback mechanism is
introduced to allow the UA to know if the registrar supports the
emergency registration extension or not (e.g. use of option-tag). It
seems from a 3GPP point of view this is not important. However, I can
understand that for other reg-type values, it may be useful to introduce
such feedback mechanism.=20

In order to progress this draft (since this seems to be the only
sticking point), I propose the following:

UA may include an option-tag (name to be decided) in the Supported
header field, if the UA needs to know if the reg-type URI parameter is
supported by the registrar. The registrar returns the option-tag in the
200 (OK) upon successful registration if the extension is supported.=20

Note, I am proposing this mechanism is introduced as an option...not
mandating the UA must include the option-tag during such registration.
Additionally, I am not including the option-tag in the Required header
field since if the emergency registration is not supported at the
registrar, fall back to normal non-emergency registration should occur -
not the failure of registration.=20

=20

Please let me know what you think. I will start on the revision.=20

Best regards,

Milan


From hannes.tschofenig@nsn.com  Wed Feb 10 06:09:58 2010
Return-Path: <hannes.tschofenig@nsn.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 A75053A71D6 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 06:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  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 UHuC9xUhCDed for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 06:09:54 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 380A63A71BC for <ecrit@ietf.org>; Wed, 10 Feb 2010 06:09:53 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1AEB2E7017075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Wed, 10 Feb 2010 15:11:02 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1AEB1iF015035 for <ecrit@ietf.org>; Wed, 10 Feb 2010 15:11:02 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 10 Feb 2010 15:10:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Feb 2010 16:15:08 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45022D5B59@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: == PSAP Callback == 
Thread-Index: AcqqW3MzkUOYagP8RJCdKM2NIBhDDA==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <ecrit@ietf.org>
X-OriginalArrivalTime: 10 Feb 2010 14:10:54.0545 (UTC) FILETIME=[DBD55410:01CAAA5A]
Subject: [Ecrit] == PSAP Callback ==
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: Wed, 10 Feb 2010 14:09:58 -0000

Hi all,=20

I have added text about PSAP callbacks to the our ECRIT Wiki page
http://trac.tools.ietf.org/wg/ecrit/trac/wiki/WikiStart. I have copied
the text into this mail to simplify the response. YOUR FEEDBACK IS
IMPORTANT.=20

http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt
defines PSAP callback and illustrates what solution is provided with
existing specifications. It then goes on describing under what
circumstances the existing solution does not work.=20

A few design decisions impact the direction of a solution, namely:

1)  Approach 1: Indication that the caller is a PSAP.

2)  Approach 2: Indication that the call is in response to a previous
emergency
    call.=20

3)  Approach 3: Indication is that the communication attempt is of
emergency nature.=20

The group needs to make a decision about the solution direction.=20

We discuss each solution approach in more detail below.=20

*** Approach 2: Indication that the call is in response to a previous
emergency
    call.=20
=09
A variant of approach (2) is already described in Section 13 of
[I-D.ietf-ecrit-framework] and provides the following guidance regarding
callback handling:

      A UA may be able to determine a PSAP call back by examining the
      domain of incoming calls after placing an emergency call and
      comparing that to the domain of the answering PSAP from the
      emergency call.  Any call from the same domain and directed to the
      supplied Contact header or AoR after an emergency call should be
      accepted as a call-back from the PSAP if it occurs within a
      reasonable time after an emergency call was placed.

This approach mimics a stateful packet filtering firewall functionality.
Although this approach is quite coarse grained since any call from the
PSAP's domain is given preferential treatment it is likely to be
practical.

It is possible to reduce the granularity by storing additional
information (such as the username part of the called party rather than
just the domain part).=20

*** Approach 1: Indication that the caller is a PSAP.

Approach (1) requires more discussion. Consider the following
approaches:

                 +----------+
                 | List of  |+
                 | valid    ||
                 | PSAP ids ||
                 +----------+|
                  +----------+
                      *
                      * whitelist
                      *
                      V
   Incoming      +----------+    Normal
   SIP Msg       | SIP      |+   Treatment
  -------------->| Entity   ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
   + Identity    |          ||(if not in whitelist)
                 +----------+|
                 +----------+
                      ||
                      ||
                      || Preferential
                      || Treatment
                      ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
                        (in whitelist)

Figure 1: Identity Based Authorization

In Figure 1 an interaction is presented that allows a SIP entity to make
a policy decision whether to bypass installed authorization policies and
thereby providing preferential treatment. To make this decision the
sender's identity is compared with a whitelist of valid PSAPs. The
identity assurances in SIP can come in different forms, such as SIP
Identity [RFC4474] or with P-Asserted-Identity [RFC3325]. The former
technique relies on a cryptographic assurance and the latter on a chain
of trust.=20

The establishment of a whitelist with PSAP identities is operationally
complex and might not easily scale world wide. When there is a local
relationship between the VSP/ASP and the PSAP then populating the
whitelist is far simpler.=20

A drawback of the presented solution is that this method does not allow
any mechanism to distinguish different types of calls initiated by
PSAPs.=20

An approach that extends the one presented in Figure 1 is outlined in
Figure 2. RFC 4484 illustrated the basic requirements for this
technique.

               +----------+
               | List of  |+
               | trust    ||
               | anchor   ||
               +----------+|
                +----------+
                    *
                    *
                    *
                    V
 Incoming      +----------+    Normal
 SIP Msg       | SIP      |+   Treatment
-------------->| Entity   ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
 + trait       |          ||(no indication
               +----------+| of PSAP)
               +----------+
                    ||
                    ||
                    || Preferential
                    || Treatment
                    ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
                      (indicated as
                       PSAP)

Figure 2: Trait Based Authorization

In a trait-based authorization scenario an incoming SIP message contains
a form of trait, i.e. some form of assertion. The assertion contains an
indication that the sending party has the role of a PSAP (or similar
emergency services entity). The assertion is either cryptographically
protected to enable end-to-end verification or an chain of trust
security model has to be assumed. In Figure 2 we assume an end-to-end
security model where trust anchors are provisioned to ensure the ability
for a SIP entity to verify the received assertion.=20

>From a solution point of view various approaches are feasible, such as
SIP SAML (see http://tools.ietf.org/html/draft-ietf-sip-saml-06) or URI
Parameters for indicating the Calling Party's Category and Originating
Line Information (see
http://tools.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-02.txt).


*** Approach 3: Indication is that the communication attempt is of
emergency nature.=20

This approach is a slight modification of the one presented in the
previous section. Instead of indicating that the calling party has the
role of a PSAP it instead indicates the emergency services nature. This
indication cannot be verified by external parties because it heavily
depends on the intention of the call taker itself. Call takers might
make calls that cannot be classified as emergency calls.  It is,
however, possible to combine this marking with the indication of the
PSAP role. A receiving entity might be more inclined to execute
preferential treatment in case (a) there is a close relationship with
the emergency services authorities (e.g. the PSAP identity is listed in
a white list), and (b) an assertion is provided that indicates the
sender's role as a PSAP (or similar emergency services entities).


*** Decisions for the WG to make

a) Do you believe that approach (3) is the correct direction for further
standardization work?=20

b) Is it useful to specify the technical capabilities for offering trait
based authorization to simplify decision making with approach (3)?=20

Ciao
Hannes

From fluffy@cisco.com  Wed Feb 10 10:44:00 2010
Return-Path: <fluffy@cisco.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 EFEA63A6858 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 10:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.47
X-Spam-Level: 
X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 x4Dc9gyc82QO for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 10:44:00 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 139D83A6821 for <ecrit@ietf.org>; Wed, 10 Feb 2010 10:44:00 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.49,445,1262563200"; d="scan'208";a="481186380"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2010 18:45:11 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1AIjAEd002843; Wed, 10 Feb 2010 18:45:11 GMT
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
Date: Wed, 10 Feb 2010 11:45:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <831EB959-DB2E-403A-A4B2-BFF5D8692953@cisco.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, Marc Linsner <marc.linsner@cisco.com>
X-Mailer: Apple Mail (2.1077)
Cc: ecrit@ietf.org
Subject: [Ecrit] Virtual Interim Meeting Agenda
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: Wed, 10 Feb 2010 18:44:01 -0000

I'm working on the assumption that the agenda for the call is text =
below. If there is more to the agenda, it never made it to the list.=20

On Feb 8, 2010, at 7:49 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Please keep our virtual interim meeting Thursday Feb. 11 8AM-10AM EST
> (New York).
>=20
> We plan to discuss the PSAP callback mechanism, see
> http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt,
> and to make some progress on the solution front.=20

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html




From fluffy@cisco.com  Wed Feb 10 10:44:27 2010
Return-Path: <fluffy@cisco.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 8B0F628C22D for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 10:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.474
X-Spam-Level: 
X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 8XB0MCW7YPpk for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 10:44:26 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 49AAD3A6858 for <ecrit@ietf.org>; Wed, 10 Feb 2010 10:44:26 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.49,445,1262563200"; d="scan'208";a="481186473"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2010 18:45:37 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1AIjAEe002843; Wed, 10 Feb 2010 18:45:36 GMT
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
Date: Wed, 10 Feb 2010 11:45:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DB23FCD-3226-410B-8F16-B0DED0B1AE71@cisco.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>
To: ECRIT <ecrit@ietf.org>
X-Mailer: Apple Mail (2.1077)
Cc: Marc Linsner <marc.linsner@cisco.com>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting
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: Wed, 10 Feb 2010 18:44:27 -0000

It has been pointed out that this virtual meeting did not get properly =
announced on the IETF list which brings up the question of if it should =
be canceled.=20

I am asking the WG chairs to go ahead any run the meeting anyways but to =
be even more diligent than normal about assuming that the people on the =
phone call do not represent all the relevant opinions and any decisions =
need to be made and confirmed on the list. For controversial topics or =
things the chairs judge to have very weak consensus, the topics can be =
discussed again at the next IETF meeting where we can confirm the =
consensus and try and get to a stronger consensus.  I want meetings to =
be properly announced but I believe that running this meeting will help =
the WG get towards consensus on the callback issue and that the harm of =
canceling this meeting is greater than running it. My experience in this =
WG is that nearly all the people likely to come to this virtual meeting =
did receive the notification via the ECRIT list. If the the meeting =
topic was different, I might have come to a different conclusion about =
canceling it.

Cullen <RAI AD>




On Feb 8, 2010, at 7:49 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Hi all,=20
>=20
> Please keep our virtual interim meeting Thursday Feb. 11 8AM-10AM EST
> (New York).
>=20
> We plan to discuss the PSAP callback mechanism, see
> http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt,
> and to make some progress on the solution front.=20
>=20
> The Webex info can be found below. =20
>=20
> Ciao
> Hannes & Marc
>=20
>=20
> -- WEBEX
>=20
> Date: Thursday, February 11, 2010
> Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
> Number: 209 813 488  Meeting Password: ietf
>=20
>=20
> -------------------------------------------------------
> To join the online meeting (Now from iPhones too!)
> -------------------------------------------------------
> 1. Go to
> =
https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D0&PW=3D=
NNjA
> 5ZTg4YzJm&RT=3DMiMxMQ%3D%3D
> 2. Enter your name and email address.
> 3. Enter the meeting password: ietf
> 4. Click "Join Now".
>=20
> To view in other time zones or languages, please click the link:
>=20
> =
https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D0&PW=3D=
NNjA
> 5ZTg4YzJm&ORT=3DMiMxMQ%3D%3D
>=20
> ----------------------------------------------------------------
> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> ----------------------------------------------------------------
>=20
> The affected toll free numbers are: (866) 432-9903 for the San
> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>=20
> Please dial the local access number for your area from the list below:
> - San Jose/Milpitas (408) area: 525-6800
> - RTP (919) area: 392-3330
>=20
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed above) or
> Access Code followed by the # sign.
>=20
> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>=20
> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>=20
> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>=20
> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>=20
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://ciscosales.webex.com/ciscosales/mc
> 2. On the left navigation bar, click "Support".
>=20
> You can contact me at:
>  mlinsner@cisco.com
> 1-919 476 7083=20
>=20
> To add this meeting to your calendar program (for example Microsoft
> Outlook), click this link:
>=20
> =
https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D0&ICS=3D=
MI&
> =
LD=3D1&RD=3D2&ST=3D1&SHA2=3DvAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE=3D=
&RT=3DMiMx
> MQ%3D%3D=20
>=20
> The playback of UCF (Universal Communications Format) rich media files
> requires appropriate players. To view this type of rich media files in
> the meeting, please check whether you have the players installed on =
your
> computer by going to
> https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>=20
> Sign up for a free trial of WebEx
> http://www.webex.com/go/mcemfreetrial
>=20
> http://www.webex.com
>=20
>=20
>=20
> IMPORTANT NOTICE: This WebEx service includes a feature that allows
> audio and any documents and other materials exchanged or viewed during
> the session to be recorded. By joining this session, you automatically
> consent to such recordings. If you do not consent to the recording, do
> not join the session.=20
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html




From fluffy@cisco.com  Wed Feb 10 10:45:48 2010
Return-Path: <fluffy@cisco.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 D3A2E28C22D for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 10:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.477
X-Spam-Level: 
X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qPYHV9kYys6c for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 10:45:47 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 27C4728C224 for <ecrit@ietf.org>; Wed, 10 Feb 2010 10:45:47 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALaNckurR7H+/2dsb2JhbACaY3SHcZ4nijkEBY0vgk4RBoFwBI4SCw
X-IronPort-AV: E=Sophos;i="4.49,445,1262563200"; d="scan'208";a="148916824"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2010 18:46:52 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1AIkpvB023892; Wed, 10 Feb 2010 18:46:51 GMT
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <00B091B3-44FA-423A-9221-41CBF9B568D2@cs.columbia.edu>
Date: Wed, 10 Feb 2010 11:46:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE968933-B0D6-4170-A2BF-3A9EB4516495@cisco.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45022A574F@FIESEXC015.nsn-intra.net> <00B091B3-44FA-423A-9221-41CBF9B568D2@cs.columbia.edu>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Apple Mail (2.1077)
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, ecrit@ietf.org
Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting
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: Wed, 10 Feb 2010 18:45:48 -0000

I spoke about the issues in a very concrete way at the last meeting - =
I'm really trying to avoid any tea leaf reading. Nothing new since then. =
I can try and reconstruct the state from that but if you already have =
the info from the last meeting, well no change since then.


On Feb 8, 2010, at 8:53 AM, Henning Schulzrinne wrote:

> Since "shadow boxing" and "tea leaf reading" aren't particularly =
productive, would the ADs consider revealing those concerns? I'm not =
sure how else we can have a productive discussion that doesn't just =
tread over the same old ground.
>=20
> Henning
>=20
> On Feb 8, 2010, at 10:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) =
wrote:
>=20
>> Hi all,=20
>>=20
>> Andrea suggested to also put the revision of the Service URN to the
>> agenda. He has updated the document but there are concerns from the =
side
>> of our Ads. Feedback from the group would also appreciated.=20
>>=20
>> Thoughts about the addition of the document for discussion to the
>> agenda?=20
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>>> -----Original Message-----
>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20
>>> On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>>> Sent: 08 February, 2010 16:50
>>> To: ecrit@ietf.org
>>> Subject: [Ecrit] Reminder: Virtual Interim Meeting
>>>=20
>>> Hi all,=20
>>>=20
>>> Please keep our virtual interim meeting Thursday Feb. 11=20
>>> 8AM-10AM EST (New York).
>>>=20
>>> We plan to discuss the PSAP callback mechanism, see=20
>>> =
http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt,
>>> and to make some progress on the solution front.=20
>>>=20
>>> The Webex info can be found below. =20
>>>=20
>>> Ciao
>>> Hannes & Marc
>>>=20
>>>=20
>>> -- WEBEX
>>>=20
>>> Date: Thursday, February 11, 2010
>>> Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
>>> Number: 209 813 488  Meeting Password: ietf
>>>=20
>>>=20
>>> -------------------------------------------------------
>>> To join the online meeting (Now from iPhones too!)
>>> -------------------------------------------------------
>>> 1. Go to
>>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>>> 0&PW=3DNNjA
>>> 5ZTg4YzJm&RT=3DMiMxMQ%3D%3D
>>> 2. Enter your name and email address.
>>> 3. Enter the meeting password: ietf
>>> 4. Click "Join Now".
>>>=20
>>> To view in other time zones or languages, please click the link:
>>>=20
>>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>>> 0&PW=3DNNjA
>>> 5ZTg4YzJm&ORT=3DMiMxMQ%3D%3D
>>>=20
>>> ----------------------------------------------------------------
>>> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
>>> ----------------------------------------------------------------
>>>=20
>>> The affected toll free numbers are: (866) 432-9903 for the=20
>>> San Jose/Milpitas area and (866) 349-3520 for the RTP area.
>>>=20
>>> Please dial the local access number for your area from the list =
below:
>>> - San Jose/Milpitas (408) area: 525-6800
>>> - RTP (919) area: 392-3330
>>>=20
>>> -------------------------------------------------------
>>> To join the teleconference only
>>> -------------------------------------------------------
>>> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20
>>> http://cisco.com/en/US/about/doing_business/conferencing/index.html
>>> 2. Follow the prompts to enter the Meeting Number (listed=20
>>> above) or Access Code followed by the # sign.
>>>=20
>>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>>>=20
>>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>>>=20
>>> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>>>=20
>>> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>>>=20
>>> -------------------------------------------------------
>>> For assistance
>>> -------------------------------------------------------
>>> 1. Go to https://ciscosales.webex.com/ciscosales/mc
>>> 2. On the left navigation bar, click "Support".
>>>=20
>>> You can contact me at:
>>> mlinsner@cisco.com
>>> 1-919 476 7083=20
>>>=20
>>> To add this meeting to your calendar program (for example=20
>>> Microsoft Outlook), click this link:
>>>=20
>>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>>> 0&ICS=3DMI&
>>> LD=3D1&RD=3D2&ST=3D1&SHA2=3DvAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygG=
E
>>> =3D&RT=3DMiMx
>>> MQ%3D%3D=20
>>>=20
>>> The playback of UCF (Universal Communications Format) rich=20
>>> media files requires appropriate players. To view this type of=20
>>> rich media files in the meeting, please check whether you have=20
>>> the players installed on your computer by going to=20
>>> https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>>>=20
>>> Sign up for a free trial of WebEx
>>> http://www.webex.com/go/mcemfreetrial
>>>=20
>>> http://www.webex.com
>>>=20
>>>=20
>>>=20
>>> IMPORTANT NOTICE: This WebEx service includes a feature that=20
>>> allows audio and any documents and other materials exchanged=20
>>> or viewed during the session to be recorded. By joining this=20
>>> session, you automatically consent to such recordings. If you=20
>>> do not consent to the recording, do not join the session.=20
>>>=20
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>=20
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>>=20
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html




From hannes.tschofenig@nsn.com  Wed Feb 10 12:09:49 2010
Return-Path: <hannes.tschofenig@nsn.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 B54393A75D5 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 12:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  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 cTwBVeLbHGjr for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 12:09:48 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C96043A75D0 for <ecrit@ietf.org>; Wed, 10 Feb 2010 12:09:47 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1AKAq0N019621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2010 21:10:52 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1AKAqf7004944; Wed, 10 Feb 2010 21:10:52 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 10 Feb 2010 21:10:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Feb 2010 22:14:29 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45022D5CC9@FIESEXC015.nsn-intra.net>
In-Reply-To: <00B091B3-44FA-423A-9221-41CBF9B568D2@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Service Classification ... Was RE: [Ecrit] Reminder: Virtual Interim Meeting
Thread-Index: Acqo1u/2VdaTolJ3RWGdweblDYl7rQBtatFQ
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45022A574F@FIESEXC015.nsn-intra.net> <00B091B3-44FA-423A-9221-41CBF9B568D2@cs.columbia.edu>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Henning Schulzrinne" <hgs@cs.columbia.edu>
X-OriginalArrivalTime: 10 Feb 2010 20:10:52.0241 (UTC) FILETIME=[25103410:01CAAA8D]
Cc: ecrit@ietf.org
Subject: [Ecrit] Service Classification ... Was RE: Reminder: Virtual Interim Meeting
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: Wed, 10 Feb 2010 20:09:49 -0000

Hi Henning,=20

Cullen essentially pointed out that service classification is rather
complicated and we should consult some other folks outside the IETF
(since they have tried similar things already and failed).=20

I then solicited more feedback from Lisa and see provided roughly the
following response:=20

---=20

In effect, this actually starts to move into W3C Semantic Web territory,
thus I've cc'ed Mark Nottingham.  You could check out the W3C's pages on
ontology <http://www.w3.org/standards/semanticweb/ontology> as well as
vertical apps <http://www.w3.org/standards/semanticweb/applications> and
<http://www.w3.org/2001/sw/sweo/public/UseCases/> -- it's in the
vertical apps that specific themed vocabularies get developed.  For
example, the city of Zaragoza developed an ontology for city services
<http://www.w3.org/2001/sw/sweo/public/UseCases/Zaragoza/>

I believe many of these vocabularies get developed in vertical industry
consortia and for specific coordination activities.  For example, the
classifications of diseases was begun as a scholarly activity in the
18th century, and international uniform classification of causes of
death was adopted in 1853.  Different disease and cause--of-death
classifications have popped up in different countries and different
industries, and there have been constant and painful attempts to unify.
It is a tremendous amount of work to revise the list of causes of death
and when one does so, statistics change in ways that can't be compared
forward and backward.    For example --
see <http://wonder.cdc.gov/mortSQL.html>, where the datasets for two
very similar disease classification systems are completely disjoint.

Contrasting the classification of diseases to classification of
services: in the case of diseases, only professionals tend to know about
disease classification codes.  Thus, uniformity can be encouraged in
professional training.  New diseases are comparably rare; they are
studied carefully and there are recognized venues for analysing the type
and classification of new diseases.   In the case of services, we have a
free for all where anybody can invent a new service (hey, I'm now
offering custom knit sweater fit analyses at my yarn studio) and all
kinds of people are expected to search for them.

I believe the incredible range, scope and dynamism of classifying
services means that any vocabulary definition mechanism will be awfully
limited.

---=20

I have no good suggestion on how to reflect the feedback in these two
documents:=20
http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy=20
http://tools.ietf.org/id/draft-forte-ecrit-service-classification

Maybe someone else in the working group has or maybe someone in the
application area can provide us with help.=20

Ciao
Hannes



>-----Original Message-----
>From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
>Sent: 08 February, 2010 17:54
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: ecrit@ietf.org
>Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting
>
>Since "shadow boxing" and "tea leaf reading" aren't=20
>particularly productive, would the ADs consider revealing=20
>those concerns? I'm not sure how else we can have a productive=20
>discussion that doesn't just tread over the same old ground.
>
>Henning
>
>On Feb 8, 2010, at 10:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>
>> Hi all,
>>=20
>> Andrea suggested to also put the revision of the Service URN to the=20
>> agenda. He has updated the document but there are concerns from the=20
>> side of our Ads. Feedback from the group would also appreciated.
>>=20
>> Thoughts about the addition of the document for discussion to the=20
>> agenda?
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>>> -----Original Message-----
>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20
>>> Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>>> Sent: 08 February, 2010 16:50
>>> To: ecrit@ietf.org
>>> Subject: [Ecrit] Reminder: Virtual Interim Meeting
>>>=20
>>> Hi all,
>>>=20
>>> Please keep our virtual interim meeting Thursday Feb. 11=20
>8AM-10AM EST=20
>>> (New York).
>>>=20
>>> We plan to discuss the PSAP callback mechanism, see=20
>>>=20
>http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt
>>> , and to make some progress on the solution front.
>>>=20
>>> The Webex info can be found below. =20
>>>=20
>>> Ciao
>>> Hannes & Marc
>>>=20
>>>=20
>>> -- WEBEX
>>>=20
>>> Date: Thursday, February 11, 2010
>>> Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
>>> Number: 209 813 488  Meeting Password: ietf
>>>=20
>>>=20
>>> -------------------------------------------------------
>>> To join the online meeting (Now from iPhones too!)
>>> -------------------------------------------------------
>>> 1. Go to
>>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>>> 0&PW=3DNNjA
>>> 5ZTg4YzJm&RT=3DMiMxMQ%3D%3D
>>> 2. Enter your name and email address.
>>> 3. Enter the meeting password: ietf
>>> 4. Click "Join Now".
>>>=20
>>> To view in other time zones or languages, please click the link:
>>>=20
>>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>>> 0&PW=3DNNjA
>>> 5ZTg4YzJm&ORT=3DMiMxMQ%3D%3D
>>>=20
>>> ----------------------------------------------------------------
>>> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
>>> ----------------------------------------------------------------
>>>=20
>>> The affected toll free numbers are: (866) 432-9903 for the San=20
>>> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>>>=20
>>> Please dial the local access number for your area from the=20
>list below:
>>> - San Jose/Milpitas (408) area: 525-6800
>>> - RTP (919) area: 392-3330
>>>=20
>>> -------------------------------------------------------
>>> To join the teleconference only
>>> -------------------------------------------------------
>>> 1. Dial into Cisco WebEx (view all Global Access Numbers at=20
>>> http://cisco.com/en/US/about/doing_business/conferencing/index.html
>>> 2. Follow the prompts to enter the Meeting Number (listed
>>> above) or Access Code followed by the # sign.
>>>=20
>>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>>>=20
>>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>>>=20
>>> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>>>=20
>>> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>>>=20
>>> -------------------------------------------------------
>>> For assistance
>>> -------------------------------------------------------
>>> 1. Go to https://ciscosales.webex.com/ciscosales/mc
>>> 2. On the left navigation bar, click "Support".
>>>=20
>>> You can contact me at:
>>> mlinsner@cisco.com
>>> 1-919 476 7083
>>>=20
>>> To add this meeting to your calendar program (for example Microsoft=20
>>> Outlook), click this link:
>>>=20
>>> https://ciscosales.webex.com/ciscosales/j.php?ED=3D133856902&UID=3D
>>> 0&ICS=3DMI&
>>> =
LD=3D1&RD=3D2&ST=3D1&SHA2=3DvAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE
>>> =3D&RT=3DMiMx
>>> MQ%3D%3D
>>>=20
>>> The playback of UCF (Universal Communications Format) rich media=20
>>> files requires appropriate players. To view this type of rich media=20
>>> files in the meeting, please check whether you have the players=20
>>> installed on your computer by going to=20
>>> https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>>>=20
>>> Sign up for a free trial of WebEx
>>> http://www.webex.com/go/mcemfreetrial
>>>=20
>>> http://www.webex.com
>>>=20
>>>=20
>>>=20
>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows=20
>>> audio and any documents and other materials exchanged or viewed=20
>>> during the session to be recorded. By joining this session, you=20
>>> automatically consent to such recordings. If you do not consent to=20
>>> the recording, do not join the session.
>>>=20
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>=20
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>>=20
>
>

From gunnar.hellstrom@omnitor.se  Wed Feb 10 15:59:49 2010
Return-Path: <gunnar.hellstrom@omnitor.se>
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 DD4DE3A74BE for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 15:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.99
X-Spam-Level: 
X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449]
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 zk0TE+V-ePuC for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 15:59:49 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 986003A74B9 for <ecrit@ietf.org>; Wed, 10 Feb 2010 15:59:48 -0800 (PST)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6022D36C77B for <ecrit@ietf.org>; Thu, 11 Feb 2010 00:58:29 +0100 (CET)
Received: (qmail 27261 invoked from network); 10 Feb 2010 23:58:19 -0000
Received: from 93-158-4-103.subs.ibrowse.com (HELO AllaneCDator) (gunnar.hellstrom@omnitor.se@[93.158.4.103]) (envelope-sender <gunnar.hellstrom@omnitor.se>) by s24.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for <ecrit@ietf.org>; 10 Feb 2010 23:58:19 -0000
From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>
To: "Ecrit@Ietf. Org" <ecrit@ietf.org>
Date: Thu, 11 Feb 2010 00:58:24 +0100
Message-ID: <00c401caaaac$ef3efd60$cdbcf820$@hellstrom@omnitor.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01CAAAB5.51036560"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqqrO3QMhTsTpslQ4W1aJrQ/1Uvtg==
Content-Language: sv
Subject: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM protocols in endpoints
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: Wed, 10 Feb 2010 23:59:50 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00C5_01CAAAB5.51036560
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I found a potential small inconsistency in draft-ietf-ecrit-phonebcp

 

draft-ietf-ecrit-phonebcp-14  has a requirement in the media section 14,
saying:

 

" ED-78 Endpoints supporting Instant Messaging (IM) MUST support both

   [RFC3428] and [RFC4975]."

 

Is this to require too much from the endpoints? Currently the users'
endpoints seldom implement both IM protocols. Would an endpoint only
supporting SIP Message be forbidden to use it in an emergency situation
because it does not have MSRP support?  

 

I would expect this double requirement on the PSAPs, so that they can handle
IM of both kinds.

 

This is an endpoint requirement, so I would expect the "both" replaced by
"either"/"or".

 

Proposal:

"ED-78 Endpoints supporting Instant Messaging (IM) MUST support either

   [RFC3428] or [RFC4975]."

 

I suggest to make that change in phonebcp unless there is a good explanation
why both IM protocols shall be required in the end-user devices.

 

Or is there a use case thought behind it:  Alice sends a SIP Message to the
PSAP saying "Help!". The PSAP want to establish an IM session to find out
all details and therefore tries to connect for an MSRP IM session.  If they
responded by SIP Message outside a dialogue, their messages would appear on
all terminals logged in on the same SIP address as the one that Alice uses
causing an integrity risk.

Was that the thought behind this double protocol requirement?

  

/Gunnar


------=_NextPart_000_00C5_01CAAAB5.51036560
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.E-postmall17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>I found a potential small =
inconsistency in draft-ietf-ecrit-phonebcp<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>draft-ietf-ecrit-phonebcp-14=A0 =
has a
requirement in the media section 14, saying:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>&quot; ED-78 Endpoints =
supporting Instant
Messaging (IM) MUST support both<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>=A0=A0 [RFC3428] and =
[RFC4975].&quot;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Is this to require too much from =
the
endpoints? Currently the users' endpoints seldom implement both IM =
protocols.
Would an endpoint only supporting SIP Message be forbidden to use it in =
an
emergency situation because it does not have MSRP support?=A0 =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I would expect this double =
requirement on
the PSAPs, so that they can handle IM of both =
kinds.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>This is an endpoint requirement, =
so I would
expect the &quot;both&quot; replaced by =
&quot;either&quot;/&quot;or&quot;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Proposal:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>&quot;ED-78 Endpoints supporting =
Instant
Messaging (IM) MUST support either<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>=A0=A0 [RFC3428] or =
[RFC4975].&quot;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I suggest to make that change in =
phonebcp unless
there is a good explanation why both IM protocols shall be required in =
the
end-user devices.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Or is there a use case thought =
behind it: =A0Alice
sends a SIP Message to the PSAP saying &quot;Help!&quot;. The PSAP want =
to
establish an IM session to find out all details and therefore tries to =
connect
for an MSRP IM session. =A0If they responded by SIP Message outside a =
dialogue,
their messages would appear on all terminals logged in on the same SIP =
address
as the one that Alice uses causing an integrity =
risk.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Was that the thought behind this =
double
protocol requirement?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>=A0=A0<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>/Gunnar<o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_00C5_01CAAAB5.51036560--


From bernard_aboba@hotmail.com  Wed Feb 10 19:47:57 2010
Return-Path: <bernard_aboba@hotmail.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 8CEDC3A7255 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 19:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.862
X-Spam-Level: 
X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.436,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 1XbVClFox995 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 19:47:56 -0800 (PST)
Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by core3.amsl.com (Postfix) with ESMTP id 864193A6F89 for <ecrit@ietf.org>; Wed, 10 Feb 2010 19:47:56 -0800 (PST)
Received: from BLU137-DS1 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 10 Feb 2010 19:49:09 -0800
X-Originating-IP: [131.107.0.77]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS1C2DD7BC3BD634FBC4B17934E0@phx.gbl>
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: =?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?= <gunnar.hellstrom@omnitor.se>, "'Ecrit@Ietf. Org'" <ecrit@ietf.org>
References: <00c401caaaac$ef3efd60$cdbcf820$@hellstrom@omnitor.se>
In-Reply-To: <00c401caaaac$ef3efd60$cdbcf820$@hellstrom@omnitor.se>
Date: Wed, 10 Feb 2010 19:49:08 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CAAA8A.1C149480"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqqrO3QMhTsTpslQ4W1aJrQ/1UvtgAIDZpA
Content-Language: en-us
X-OriginalArrivalTime: 11 Feb 2010 03:49:09.0357 (UTC) FILETIME=[2A9F21D0:01CAAACD]
Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM protocols in	endpoints
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, 11 Feb 2010 03:47:57 -0000

------=_NextPart_000_0033_01CAAA8A.1C149480
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

=20

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf =
Of
Gunnar Hellstr=F6m
Sent: Wednesday, February 10, 2010 3:58 PM
To: Ecrit@Ietf. Org
Subject: [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM protocols =
in
endpoints

=20

I found a potential small inconsistency in draft-ietf-ecrit-phonebcp

=20

draft-ietf-ecrit-phonebcp-14  has a requirement in the media section 14,
saying:

=20

" ED-78 Endpoints supporting Instant Messaging (IM) MUST support both

   [RFC3428] and [RFC4975]."

=20

Is this to require too much from the endpoints? Currently the users'
endpoints seldom implement both IM protocols. Would an endpoint only
supporting SIP Message be forbidden to use it in an emergency situation
because it does not have MSRP support? =20

=20

I would expect this double requirement on the PSAPs, so that they can =
handle
IM of both kinds.

=20

This is an endpoint requirement, so I would expect the "both" replaced =
by
"either"/"or".

=20

Proposal:

"ED-78 Endpoints supporting Instant Messaging (IM) MUST support either

   [RFC3428] or [RFC4975]."

=20

I suggest to make that change in phonebcp unless there is a good =
explanation
why both IM protocols shall be required in the end-user devices.

=20

Or is there a use case thought behind it:  Alice sends a SIP Message to =
the
PSAP saying "Help!". The PSAP want to establish an IM session to find =
out
all details and therefore tries to connect for an MSRP IM session.  If =
they
responded by SIP Message outside a dialogue, their messages would appear =
on
all terminals logged in on the same SIP address as the one that Alice =
uses
causing an integrity risk.

Was that the thought behind this double protocol requirement?

 =20

/Gunnar


------=_NextPart_000_0033_01CAAA8A.1C149480
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>

<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>+1<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b>On Behalf Of =
</b>Gunnar
Hellstr=F6m<br>
<b>Sent:</b> Wednesday, February 10, 2010 3:58 PM<br>
<b>To:</b> Ecrit@Ietf. Org<br>
<b>Subject:</b> [Ecrit] draft-ietf-ecrit-phonebcp requirements on IM =
protocols
in endpoints<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I found a potential small inconsistency in
draft-ietf-ecrit-phonebcp<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>draft-ietf-ecrit-phonebcp-14&nbsp; has a =
requirement in the
media section 14, saying:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&quot; ED-78 Endpoints supporting Instant Messaging =
(IM)
MUST support both<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; [RFC3428] and =
[RFC4975].&quot;<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Is this to require too much from the endpoints? =
Currently
the users' endpoints seldom implement both IM protocols. Would an =
endpoint only
supporting SIP Message be forbidden to use it in an emergency situation =
because
it does not have MSRP support?&nbsp; <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I would expect this double requirement on the =
PSAPs, so that
they can handle IM of both kinds.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>This is an endpoint requirement, so I would expect =
the
&quot;both&quot; replaced by =
&quot;either&quot;/&quot;or&quot;.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Proposal:<o:p></o:p></p>

<p class=3DMsoNormal>&quot;ED-78 Endpoints supporting Instant Messaging =
(IM) MUST
support either<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp; [RFC3428] or =
[RFC4975].&quot;<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I suggest to make that change in phonebcp unless =
there is a
good explanation why both IM protocols shall be required in the end-user
devices.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Or is there a use case thought behind it: =
&nbsp;Alice sends
a SIP Message to the PSAP saying &quot;Help!&quot;. The PSAP want to =
establish
an IM session to find out all details and therefore tries to connect for =
an
MSRP IM session. &nbsp;If they responded by SIP Message outside a =
dialogue,
their messages would appear on all terminals logged in on the same SIP =
address
as the one that Alice uses causing an integrity risk.<o:p></o:p></p>

<p class=3DMsoNormal>Was that the thought behind this double protocol
requirement?<o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>/Gunnar<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0033_01CAAA8A.1C149480--

From andreaf@cs.columbia.edu  Wed Feb 10 20:41:01 2010
Return-Path: <andreaf@cs.columbia.edu>
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 ECF433A7654 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 20:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 20thChLWP6z2 for <ecrit@core3.amsl.com>; Wed, 10 Feb 2010 20:40:58 -0800 (PST)
Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 9D82428C110 for <ecrit@ietf.org>; Wed, 10 Feb 2010 20:40:58 -0800 (PST)
Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o1B4g3cw017421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 23:42:09 -0500 (EST)
Message-ID: <4B738AA3.7000707@cs.columbia.edu>
Date: Wed, 10 Feb 2010 23:42:11 -0500
From: "Andrea G. Forte" <andreaf@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
References: <3D3C75174CB95F42AD6BCC56E5555B45022A571B@FIESEXC015.nsn-intra.net>	<3D3C75174CB95F42AD6BCC56E5555B45022A574F@FIESEXC015.nsn-intra.net>	<00B091B3-44FA-423A-9221-41CBF9B568D2@cs.columbia.edu> <3D3C75174CB95F42AD6BCC56E5555B45022D5CC9@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45022D5CC9@FIESEXC015.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090609060904030200010106"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Service Classification ... Was RE: Reminder: Virtual Interim Meeting
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, 11 Feb 2010 04:41:02 -0000

This is a multi-part message in MIME format.
--------------090609060904030200010106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hannes,

while I see Lisa's point, I do not think that the solution is to just 
let "others" deal with it or not to deal with it at all. Building one 
comprehensive list of all possible items is not possible and that is why 
we define a way for other people to add new terms (policy-urn draft) to 
the list. Whomever will try to tackle this issue will face the same 
kinds of problems.
Since the IETF is defining protocols and standards for the provisioning 
of location-based services I think it makes sense for the IETF to pave 
the road for defining new labels. Yes, there are many issues involved in 
defining new terms and in deciding how to categorize such terms but 
there is where the "expert" review comes into help. It would be up to 
the expert reviewer(s) as such to be able to mediate and assign the 
correct label to the correct category and perhaps to decide how to 
"import" previously defined terms.

We need something that is consistent among service providers. If not, 
let's not talk service URNs and LoST any more and let's just go back to 
Google local search.

-Andrea

http://www.cs.columbia.edu/~andreaf 
<http://www.cs.columbia.edu/%7Eandreaf/>

On 2/10/2010 3:14 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi Henning,
>
> Cullen essentially pointed out that service classification is rather
> complicated and we should consult some other folks outside the IETF
> (since they have tried similar things already and failed).
>
> I then solicited more feedback from Lisa and see provided roughly the
> following response:
>
> ---
>
> In effect, this actually starts to move into W3C Semantic Web territory,
> thus I've cc'ed Mark Nottingham.  You could check out the W3C's pages on
> ontology<http://www.w3.org/standards/semanticweb/ontology>  as well as
> vertical apps<http://www.w3.org/standards/semanticweb/applications>  and
> <http://www.w3.org/2001/sw/sweo/public/UseCases/>  -- it's in the
> vertical apps that specific themed vocabularies get developed.  For
> example, the city of Zaragoza developed an ontology for city services
> <http://www.w3.org/2001/sw/sweo/public/UseCases/Zaragoza/>
>
> I believe many of these vocabularies get developed in vertical industry
> consortia and for specific coordination activities.  For example, the
> classifications of diseases was begun as a scholarly activity in the
> 18th century, and international uniform classification of causes of
> death was adopted in 1853.  Different disease and cause--of-death
> classifications have popped up in different countries and different
> industries, and there have been constant and painful attempts to unify.
> It is a tremendous amount of work to revise the list of causes of death
> and when one does so, statistics change in ways that can't be compared
> forward and backward.    For example --
> see<http://wonder.cdc.gov/mortSQL.html>, where the datasets for two
> very similar disease classification systems are completely disjoint.
>
> Contrasting the classification of diseases to classification of
> services: in the case of diseases, only professionals tend to know about
> disease classification codes.  Thus, uniformity can be encouraged in
> professional training.  New diseases are comparably rare; they are
> studied carefully and there are recognized venues for analysing the type
> and classification of new diseases.   In the case of services, we have a
> free for all where anybody can invent a new service (hey, I'm now
> offering custom knit sweater fit analyses at my yarn studio) and all
> kinds of people are expected to search for them.
>
> I believe the incredible range, scope and dynamism of classifying
> services means that any vocabulary definition mechanism will be awfully
> limited.
>
> ---
>
> I have no good suggestion on how to reflect the feedback in these two
> documents:
> http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy
> http://tools.ietf.org/id/draft-forte-ecrit-service-classification
>
> Maybe someone else in the working group has or maybe someone in the
> application area can provide us with help.
>
> Ciao
> Hannes
>
>
>
>    
>> -----Original Message-----
>> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>> Sent: 08 February, 2010 17:54
>> To: Tschofenig, Hannes (NSN - FI/Espoo)
>> Cc: ecrit@ietf.org
>> Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting
>>
>> Since "shadow boxing" and "tea leaf reading" aren't
>> particularly productive, would the ADs consider revealing
>> those concerns? I'm not sure how else we can have a productive
>> discussion that doesn't just tread over the same old ground.
>>
>> Henning
>>
>> On Feb 8, 2010, at 10:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>
>>      
>>> Hi all,
>>>
>>> Andrea suggested to also put the revision of the Service URN to the
>>> agenda. He has updated the document but there are concerns from the
>>> side of our Ads. Feedback from the group would also appreciated.
>>>
>>> Thoughts about the addition of the document for discussion to the
>>> agenda?
>>>
>>> Ciao
>>> Hannes
>>>
>>>
>>>        
>>>> -----Original Message-----
>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On
>>>> Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>>>> Sent: 08 February, 2010 16:50
>>>> To: ecrit@ietf.org
>>>> Subject: [Ecrit] Reminder: Virtual Interim Meeting
>>>>
>>>> Hi all,
>>>>
>>>> Please keep our virtual interim meeting Thursday Feb. 11
>>>>          
>> 8AM-10AM EST
>>      
>>>> (New York).
>>>>
>>>> We plan to discuss the PSAP callback mechanism, see
>>>>
>>>>          
>> http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt
>>      
>>>> , and to make some progress on the solution front.
>>>>
>>>> The Webex info can be found below.
>>>>
>>>> Ciao
>>>> Hannes&  Marc
>>>>
>>>>
>>>> -- WEBEX
>>>>
>>>> Date: Thursday, February 11, 2010
>>>> Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
>>>> Number: 209 813 488  Meeting Password: ietf
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> To join the online meeting (Now from iPhones too!)
>>>> -------------------------------------------------------
>>>> 1. Go to
>>>> https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&UID=
>>>> 0&PW=NNjA
>>>> 5ZTg4YzJm&RT=MiMxMQ%3D%3D
>>>> 2. Enter your name and email address.
>>>> 3. Enter the meeting password: ietf
>>>> 4. Click "Join Now".
>>>>
>>>> To view in other time zones or languages, please click the link:
>>>>
>>>> https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&UID=
>>>> 0&PW=NNjA
>>>> 5ZTg4YzJm&ORT=MiMxMQ%3D%3D
>>>>
>>>> ----------------------------------------------------------------
>>>> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
>>>> ----------------------------------------------------------------
>>>>
>>>> The affected toll free numbers are: (866) 432-9903 for the San
>>>> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>>>>
>>>> Please dial the local access number for your area from the
>>>>          
>> list below:
>>      
>>>> - San Jose/Milpitas (408) area: 525-6800
>>>> - RTP (919) area: 392-3330
>>>>
>>>> -------------------------------------------------------
>>>> To join the teleconference only
>>>> -------------------------------------------------------
>>>> 1. Dial into Cisco WebEx (view all Global Access Numbers at
>>>> http://cisco.com/en/US/about/doing_business/conferencing/index.html
>>>> 2. Follow the prompts to enter the Meeting Number (listed
>>>> above) or Access Code followed by the # sign.
>>>>
>>>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>>>>
>>>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>>>>
>>>> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>>>>
>>>> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>>>>
>>>> -------------------------------------------------------
>>>> For assistance
>>>> -------------------------------------------------------
>>>> 1. Go to https://ciscosales.webex.com/ciscosales/mc
>>>> 2. On the left navigation bar, click "Support".
>>>>
>>>> You can contact me at:
>>>> mlinsner@cisco.com
>>>> 1-919 476 7083
>>>>
>>>> To add this meeting to your calendar program (for example Microsoft
>>>> Outlook), click this link:
>>>>
>>>> https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&UID=
>>>> 0&ICS=MI&
>>>> LD=1&RD=2&ST=1&SHA2=vAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE
>>>> =&RT=MiMx
>>>> MQ%3D%3D
>>>>
>>>> The playback of UCF (Universal Communications Format) rich media
>>>> files requires appropriate players. To view this type of rich media
>>>> files in the meeting, please check whether you have the players
>>>> installed on your computer by going to
>>>> https://ciscosales.webex.com/ciscosales/systemdiagnosis.php
>>>>
>>>> Sign up for a free trial of WebEx
>>>> http://www.webex.com/go/mcemfreetrial
>>>>
>>>> http://www.webex.com
>>>>
>>>>
>>>>
>>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows
>>>> audio and any documents and other materials exchanged or viewed
>>>> during the session to be recorded. By joining this session, you
>>>> automatically consent to such recordings. If you do not consent to
>>>> the recording, do not join the session.
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>>          
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>        
>>
>>      
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
>    

--------------090609060904030200010106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hannes,<br>
<br>
while I see Lisa's point, I do not think that the solution is to just
let "others" deal with it or not to deal with it at all. Building one
comprehensive list of all possible items is not possible and that is
why we define a way for other people to add new terms (policy-urn
draft) to the list. Whomever will try to tackle this issue will face
the same kinds of problems.<br>
Since the IETF is defining protocols and standards for the provisioning
of location-based services I think it makes sense for the IETF to pave
the road for defining new labels. Yes, there are many issues involved
in defining new terms and in deciding how to categorize such terms but
there is where the "expert" review comes into help. It would be up to
the expert reviewer(s) as such to be able to mediate and assign the
correct label to the correct category and perhaps to decide how to
"import" previously defined terms. <br>
<br>
We need something that is consistent among service providers. If not,
let's not talk service URNs and LoST any more and let's just go back to
Google local search.<br>
<br>
-Andrea<br>
<br>
<div class="moz-signature">
<a href="http://www.cs.columbia.edu/%7Eandreaf/">http://www.cs.columbia.edu/~andreaf</a>
</div>
<br>
On 2/10/2010 3:14 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
<blockquote
 cite="mid:3D3C75174CB95F42AD6BCC56E5555B45022D5CC9@FIESEXC015.nsn-intra.net"
 type="cite">
  <pre wrap="">Hi Henning, 

Cullen essentially pointed out that service classification is rather
complicated and we should consult some other folks outside the IETF
(since they have tried similar things already and failed). 

I then solicited more feedback from Lisa and see provided roughly the
following response: 

--- 

In effect, this actually starts to move into W3C Semantic Web territory,
thus I've cc'ed Mark Nottingham.  You could check out the W3C's pages on
ontology <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/standards/semanticweb/ontology">&lt;http://www.w3.org/standards/semanticweb/ontology&gt;</a> as well as
vertical apps <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/standards/semanticweb/applications">&lt;http://www.w3.org/standards/semanticweb/applications&gt;</a> and
<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/sw/sweo/public/UseCases/">&lt;http://www.w3.org/2001/sw/sweo/public/UseCases/&gt;</a> -- it's in the
vertical apps that specific themed vocabularies get developed.  For
example, the city of Zaragoza developed an ontology for city services
<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/sw/sweo/public/UseCases/Zaragoza/">&lt;http://www.w3.org/2001/sw/sweo/public/UseCases/Zaragoza/&gt;</a>

I believe many of these vocabularies get developed in vertical industry
consortia and for specific coordination activities.  For example, the
classifications of diseases was begun as a scholarly activity in the
18th century, and international uniform classification of causes of
death was adopted in 1853.  Different disease and cause--of-death
classifications have popped up in different countries and different
industries, and there have been constant and painful attempts to unify.
It is a tremendous amount of work to revise the list of causes of death
and when one does so, statistics change in ways that can't be compared
forward and backward.    For example --
see <a class="moz-txt-link-rfc2396E" href="http://wonder.cdc.gov/mortSQL.html">&lt;http://wonder.cdc.gov/mortSQL.html&gt;</a>, where the datasets for two
very similar disease classification systems are completely disjoint.

Contrasting the classification of diseases to classification of
services: in the case of diseases, only professionals tend to know about
disease classification codes.  Thus, uniformity can be encouraged in
professional training.  New diseases are comparably rare; they are
studied carefully and there are recognized venues for analysing the type
and classification of new diseases.   In the case of services, we have a
free for all where anybody can invent a new service (hey, I'm now
offering custom knit sweater fit analyses at my yarn studio) and all
kinds of people are expected to search for them.

I believe the incredible range, scope and dynamism of classifying
services means that any vocabulary definition mechanism will be awfully
limited.

--- 

I have no good suggestion on how to reflect the feedback in these two
documents: 
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy">http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy</a> 
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/id/draft-forte-ecrit-service-classification">http://tools.ietf.org/id/draft-forte-ecrit-service-classification</a>

Maybe someone else in the working group has or maybe someone in the
application area can provide us with help. 

Ciao
Hannes



  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: ext Henning Schulzrinne [<a class="moz-txt-link-freetext" href="mailto:hgs@cs.columbia.edu">mailto:hgs@cs.columbia.edu</a>] 
Sent: 08 February, 2010 17:54
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ecrit@ietf.org">ecrit@ietf.org</a>
Subject: Re: [Ecrit] Reminder: Virtual Interim Meeting

Since "shadow boxing" and "tea leaf reading" aren't 
particularly productive, would the ADs consider revealing 
those concerns? I'm not sure how else we can have a productive 
discussion that doesn't just tread over the same old ground.

Henning

On Feb 8, 2010, at 10:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi all,

Andrea suggested to also put the revision of the Service URN to the 
agenda. He has updated the document but there are concerns from the 
side of our Ads. Feedback from the group would also appreciated.

Thoughts about the addition of the document for discussion to the 
agenda?

Ciao
Hannes


      </pre>
      <blockquote type="cite">
        <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:ecrit-bounces@ietf.org">ecrit-bounces@ietf.org</a> [<a class="moz-txt-link-freetext" href="mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org</a>] On 
Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
Sent: 08 February, 2010 16:50
To: <a class="moz-txt-link-abbreviated" href="mailto:ecrit@ietf.org">ecrit@ietf.org</a>
Subject: [Ecrit] Reminder: Virtual Interim Meeting

Hi all,

Please keep our virtual interim meeting Thursday Feb. 11 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">8AM-10AM EST 
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">(New York).

We plan to discuss the PSAP callback mechanism, see 

        </pre>
      </blockquote>
    </blockquote>
    <pre wrap=""><a class="moz-txt-link-freetext" href="http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt">http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt</a>
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">, and to make some progress on the solution front.

The Webex info can be found below.  

Ciao
Hannes &amp; Marc


-- WEBEX

Date: Thursday, February 11, 2010
Time: 8:00 am, Eastern Standard Time (New York, GMT-05:00)  Meeting
Number: 209 813 488  Meeting Password: ietf


-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to
<a class="moz-txt-link-freetext" href="https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&amp;UID=">https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&amp;UID=</a>
0&amp;PW=NNjA
5ZTg4YzJm&amp;RT=MiMxMQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: ietf
4. Click "Join Now".

To view in other time zones or languages, please click the link:

<a class="moz-txt-link-freetext" href="https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&amp;UID=">https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&amp;UID=</a>
0&amp;PW=NNjA
5ZTg4YzJm&amp;ORT=MiMxMQ%3D%3D

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San 
Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the 
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">list below:
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at 
<a class="moz-txt-link-freetext" href="http://cisco.com/en/US/about/doing_business/conferencing/index.html">http://cisco.com/en/US/about/doing_business/conferencing/index.html</a>
2. Follow the prompts to enter the Meeting Number (listed
above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to <a class="moz-txt-link-freetext" href="https://ciscosales.webex.com/ciscosales/mc">https://ciscosales.webex.com/ciscosales/mc</a>
2. On the left navigation bar, click "Support".

You can contact me at:
<a class="moz-txt-link-abbreviated" href="mailto:mlinsner@cisco.com">mlinsner@cisco.com</a>
1-919 476 7083

To add this meeting to your calendar program (for example Microsoft 
Outlook), click this link:

<a class="moz-txt-link-freetext" href="https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&amp;UID=">https://ciscosales.webex.com/ciscosales/j.php?ED=133856902&amp;UID=</a>
0&amp;ICS=MI&amp;
LD=1&amp;RD=2&amp;ST=1&amp;SHA2=vAuFJ4sX5SuD8pTdUg8W6UR7Yr24ecYH0d3iPGYygGE
=&amp;RT=MiMx
MQ%3D%3D

The playback of UCF (Universal Communications Format) rich media 
files requires appropriate players. To view this type of rich media 
files in the meeting, please check whether you have the players 
installed on your computer by going to 
<a class="moz-txt-link-freetext" href="https://ciscosales.webex.com/ciscosales/systemdiagnosis.php">https://ciscosales.webex.com/ciscosales/systemdiagnosis.php</a>

Sign up for a free trial of WebEx
<a class="moz-txt-link-freetext" href="http://www.webex.com/go/mcemfreetrial">http://www.webex.com/go/mcemfreetrial</a>

<a class="moz-txt-link-freetext" href="http://www.webex.com">http://www.webex.com</a>



IMPORTANT NOTICE: This WebEx service includes a feature that allows 
audio and any documents and other materials exchanged or viewed 
during the session to be recorded. By joining this session, you 
automatically consent to such recordings. If you do not consent to 
the recording, do not join the session.

_______________________________________________
Ecrit mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ecrit@ietf.org">Ecrit@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.org/mailman/listinfo/ecrit</a>

        </pre>
      </blockquote>
      <pre wrap="">_______________________________________________
Ecrit mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ecrit@ietf.org">Ecrit@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.org/mailman/listinfo/ecrit</a>

      </pre>
    </blockquote>
    <pre wrap="">

    </pre>
  </blockquote>
  <pre wrap="">_______________________________________________
Ecrit mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ecrit@ietf.org">Ecrit@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.org/mailman/listinfo/ecrit</a>

  </pre>
</blockquote>
</body>
</html>

--------------090609060904030200010106--

From jbakker@rim.com  Thu Feb 11 08:35:37 2010
Return-Path: <jbakker@rim.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 913D93A773D for <ecrit@core3.amsl.com>; Thu, 11 Feb 2010 08:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 6X0yiBS7wnbQ for <ecrit@core3.amsl.com>; Thu, 11 Feb 2010 08:35:32 -0800 (PST)
Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id A707A3A773C for <ecrit@ietf.org>; Thu, 11 Feb 2010 08:35:31 -0800 (PST)
X-AuditID: 0a401fcb-b7b8eae000001dc5-50-4b74321da37c
Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id FD.61.07621.D12347B4; Thu, 11 Feb 2010 11:36:45 -0500 (EST)
Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 11:36:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAAB38.653E6CBD"
Date: Thu, 11 Feb 2010 10:36:42 -0600
Message-ID: <A6741735F236784CBB00AAD60DCED23F03F14330@XCH02DFW.rim.net>
In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000D7637EE@SABRE.InterDigital.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] draft-patel-ecrit-sos-parameter
thread-index: Acqpgpsb2LrMuwagRN2idXq/HDT7gQBtPgQg
References: <61CAF342FE1EE34EAC8FB19B765914000D7637EE@SABRE.InterDigital.com>
From: "John-Luc Bakker" <jbakker@rim.com>
To: "Patel, Milan" <Milan.Patel@InterDigital.com>, <ecrit@ietf.org>, <fluffy@cisco.com>
X-OriginalArrivalTime: 11 Feb 2010 16:36:45.0359 (UTC) FILETIME=[662353F0:01CAAB38]
X-Brightmail-Tracker: AAAAAgAAAZES1qJU
Subject: Re: [Ecrit] draft-patel-ecrit-sos-parameter
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, 11 Feb 2010 16:35:37 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAAB38.653E6CBD
Content-Type: text/plain;
	charset="us-ascii"
content-transfer-encoding: quoted-printable

Hi Milan,

 

What would a UA do if a SIP message is received and the option-tag is
included in the "unsupported" header field? Should a 3GPP UA the not use
"draft-patel-ecrit-sos-parameter" in that case? 

 

Regards,

 

                John-Luc

 

 

--- 
John-Luc Bakker 
Standards Manager 
Research In Motion 
BlackBerry: +1 (908) 463 7321 
Office: +1 (972) 373-1761 
Internal: (820) 63761 
E-mail: jbakker@rim.com 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
Of Patel, Milan
Sent: Tuesday, February 09, 2010 6:23 AM
To: ecrit@ietf.org; fluffy@cisco.com
Subject: [Ecrit] draft-patel-ecrit-sos-parameter

 

Hi,

 

At the previous meeting, it was requested that a feedback mechanism is
introduced to allow the UA to know if the registrar supports the
emergency registration extension or not (e.g. use of option-tag). It
seems from a 3GPP point of view this is not important. However, I can
understand that for other reg-type values, it may be useful to introduce
such feedback mechanism. 

In order to progress this draft (since this seems to be the only
sticking point), I propose the following:

UA may include an option-tag (name to be decided) in the Supported
header field, if the UA needs to know if the reg-type URI parameter is
supported by the registrar. The registrar returns the option-tag in the
200 (OK) upon successful registration if the extension is supported. 

Note, I am proposing this mechanism is introduced as an option...not
mandating the UA must include the option-tag during such registration.
Additionally, I am not including the option-tag in the Required header
field since if the emergency registration is not supported at the
registrar, fall back to normal non-emergency registration should occur -
not the failure of registration. 

 

Please let me know what you think. I will start on the revision. 

Best regards,

Milan


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

------_=_NextPart_001_01CAAB38.653E6CBD
Content-Type: text/html;
	charset="us-ascii"
content-transfer-encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro=
soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" xm=
lns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-micr=
osoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office:acc=
ess" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"uuid:=
BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsoft-com:=
rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-com:offic=
e:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" xmlns=
:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc=3D"u=
rn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-microsoft-com:o=
ffice:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" xmlns:q=3D"=
http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://microsoft.com=
/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.micro=
soft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/mee=
tings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmln=
s:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=3D"http://schemas=
.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.microsoft.c=
om/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig=
#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc=3D"ht=
tp://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org/2001/XML=
Schema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/ale=
rts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"http://sche=
mas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.microsoft.com/sha=
repoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" xmlns=
:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf=3D"http://s=
chemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http://schemas.micros=
oft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.microsoft.com/sharep=
oint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/=
digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig"=
 xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-signa=
ture" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2=
006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrel=
s=3D"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spw=
p=3D"http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t=3D"http://sch=
emas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"http://schem=
as.microsoft.com/exchange/services/2006/messages" xmlns:pptsl=3D"http://sche=
mas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl=3D"http://micros=
oft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z=3D=
"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR=
/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'>Hi Milan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'>What would a UA do if a SIP message is received and the optio=
n-tag
is included in the &#8220;unsupported&#8221; header field? Should a 3GPP UA=
 the not use &#8220;draft-patel-ecrit-sos-parameter&#8221;
in that case? <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; John-Luc<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial","san=
s-serif";
color:silver'>--- <br>
John-Luc Bakker <br>
Standards Manager <br>
Research In Motion <br>
BlackBerry: +1 (908) 463 7321 <br>
Office: +1 (972) 373-1761 <br>
Internal: (820) 63761 <br>
E-mail: jbakker@rim.com </span><span style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0=
in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma"=
,"sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> ecrit-bounces@=
ietf.org
[mailto:ecrit-bounces@ietf.org] <b>On Behalf Of </b>Patel, Milan<br>
<b>Sent:</b> Tuesday, February 09, 2010 6:23 AM<br>
<b>To:</b> ecrit@ietf.org; fluffy@cisco.com<br>
<b>Subject:</b> [Ecrit] draft-patel-ecrit-sos-parameter<o:p></o:p></span></p=
>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>Hi,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>At
the previous meeting, it was requested that a feedback mechanism is introduc=
ed
to allow the UA to know if the registrar supports the emergency registration
extension or not (e.g. use of option-tag). It seems from a 3GPP point of vie=
w
this is not important. However, I can understand that for other reg-type
values, it may be useful to introduce such feedback mechanism. <o:p></o:p></=
span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>In
order to progress this draft (since this seems to be the only sticking point=
),
I propose the following:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>UA
may include an option-tag (name to be decided) in the Supported header field=
,
if the UA needs to know if the reg-type URI parameter is supported by the re=
gistrar.
The registrar returns the option-tag in the 200 (OK) upon successful
registration if the extension is supported. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>Note,
I am proposing this mechanism is introduced as an option&#8230;not mandating=
 the UA
must include the option-tag during such registration. Additionally, I am not
including the option-tag in the Required header field since if the emergency
registration is not supported at the registrar, fall back to normal
non-emergency registration should occur &#8211; not the failure of registrat=
ion. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>Please
let me know what you think. I will start on the revision. <o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>Best
regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif"'>Milan<o:p></o:p></span></p>

</div>

--------------------------------------------------------------------- <br>
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.
</body>

</html>

------_=_NextPart_001_01CAAB38.653E6CBD--

From Milan.Patel@InterDigital.com  Thu Feb 11 08:51:04 2010
Return-Path: <Milan.Patel@InterDigital.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 E3A3228C0FC for <ecrit@core3.amsl.com>; Thu, 11 Feb 2010 08:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 jsQgn4GuOXVJ for <ecrit@core3.amsl.com>; Thu, 11 Feb 2010 08:50:57 -0800 (PST)
Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 13E243A7752 for <ecrit@ietf.org>; Thu, 11 Feb 2010 08:50:55 -0800 (PST)
Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 11 Feb 2010 11:52:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAAB3A.7C140595"
Date: Thu, 11 Feb 2010 11:51:41 -0500
Message-ID: <61CAF342FE1EE34EAC8FB19B765914000D76380C@SABRE.InterDigital.com>
In-Reply-To: <A6741735F236784CBB00AAD60DCED23F03F14330@XCH02DFW.rim.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] draft-patel-ecrit-sos-parameter
Thread-Index: Acqpgpsb2LrMuwagRN2idXq/HDT7gQBtPgQgAABE27A=
From: "Patel, Milan" <Milan.Patel@InterDigital.com>
To: "John-Luc Bakker" <jbakker@rim.com>, <ecrit@ietf.org>, <fluffy@cisco.com>
X-OriginalArrivalTime: 11 Feb 2010 16:52:08.0909 (UTC) FILETIME=[8C9DDFD0:01CAAB3A]
Subject: Re: [Ecrit] draft-patel-ecrit-sos-parameter
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, 11 Feb 2010 16:51:05 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAAB3A.7C140595
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

As a result of today's interim meeting, we decided that the next version
of the draft will not include the feedback mechanism since it is not
required by 3GPP. Furthermore the next version of the draft will give
some explanation on the backwards compatibility case and what occurs at
the registrar and how the UA proceeds with the emergency call, once
registered. Also, it will be further clarified why the sos parameter is
used in the emergency registration in order to clear up this confusion
and help non-3GPP folks understand further the requirements.

=20

John-Luc, the lack of support of the URI parameter at the registrar does
not impact the UA's ability to place an emergency call. The registration
is handled as a normal non-emergency registration. If the UA was
previously registered, then if the IMS system is pre-release 8, the
current registration would be overwritten by this new registration. One
use of the sos parameter  is to prevent this, but if you can't
distinguish emergency registration at the registrar, the result is the
registration is handled by normal registration procedures. We can't let
lack of support of the URI parameter at the registrar result in a failed
registration.=20

=20

Best regards,

Milan

=20

________________________________

From: John-Luc Bakker [mailto:jbakker@rim.com]=20
Sent: Thursday, February 11, 2010 4:37 PM
To: Patel, Milan; ecrit@ietf.org; fluffy@cisco.com
Subject: RE: [Ecrit] draft-patel-ecrit-sos-parameter

=20

Hi Milan,

=20

What would a UA do if a SIP message is received and the option-tag is
included in the "unsupported" header field? Should a 3GPP UA the not use
"draft-patel-ecrit-sos-parameter" in that case?=20

=20

Regards,

=20

                John-Luc

=20

=20

---=20
John-Luc Bakker=20
Standards Manager=20
Research In Motion=20
BlackBerry: +1 (908) 463 7321=20
Office: +1 (972) 373-1761=20
Internal: (820) 63761=20
E-mail: jbakker@rim.com=20

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
Of Patel, Milan
Sent: Tuesday, February 09, 2010 6:23 AM
To: ecrit@ietf.org; fluffy@cisco.com
Subject: [Ecrit] draft-patel-ecrit-sos-parameter

=20

Hi,

=20

At the previous meeting, it was requested that a feedback mechanism is
introduced to allow the UA to know if the registrar supports the
emergency registration extension or not (e.g. use of option-tag). It
seems from a 3GPP point of view this is not important. However, I can
understand that for other reg-type values, it may be useful to introduce
such feedback mechanism.=20

In order to progress this draft (since this seems to be the only
sticking point), I propose the following:

UA may include an option-tag (name to be decided) in the Supported
header field, if the UA needs to know if the reg-type URI parameter is
supported by the registrar. The registrar returns the option-tag in the
200 (OK) upon successful registration if the extension is supported.=20

Note, I am proposing this mechanism is introduced as an option...not
mandating the UA must include the option-tag during such registration.
Additionally, I am not including the option-tag in the Required header
field since if the emergency registration is not supported at the
registrar, fall back to normal non-emergency registration should occur -
not the failure of registration.=20

=20

Please let me know what you think. I will start on the revision.=20

Best regards,

Milan

---------------------------------------------------------------------=20
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.=20


------_=_NextPart_001_01CAAB3A.7C140595
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:st=3D"&#1;" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns0=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/"
xmlns:ns1=3D"http://schemas.microsoft.com/office/2006/digsig-setup"
xmlns:ns2=3D"http://schemas.microsoft.com/office/2006/digsig"
xmlns:ns3=3D"http://schemas.openxmlformats.org/package/2006/digital-signa=
ture"
xmlns:ns4=3D"http://schemas.openxmlformats.org/markup-compatibility/2006"=

xmlns:ns5=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns:ns6=3D"http://schemas.openxmlformats.org/package/2006/relationships=
"
xmlns:ns7=3D"http://microsoft.com/sharepoint/webpartpages"
xmlns:ns8=3D"http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ns9=3D"http://schemas.microsoft.com/exchange/services/2006/messages=
"
xmlns:ns10=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/"=

xmlns:ns11=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService"
xmlns:ns12=3D"urn:schemas-microsoft-com:">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a result of today&#8217;s =
interim
meeting, we decided that the next version of the draft will not include =
the
feedback mechanism since it is not required by 3GPP. Furthermore the =
next
version of the draft will give some explanation on the backwards =
compatibility
case and what occurs at the registrar and how the UA proceeds with the
emergency call, once registered. Also, it will be further clarified why =
the sos
parameter is used in the emergency registration in order to clear up =
this
confusion and help non-3GPP folks understand further the =
requirements.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>John-Luc, the lack of support of =
the URI
parameter at the registrar does not impact the UA&#8217;s ability to =
place an
emergency call. The registration is handled as a normal non-emergency
registration. If the UA was previously registered, then if the IMS =
system is
pre-release 8, the current registration would be overwritten by this new
registration. One use of the sos parameter &nbsp;is to prevent this, but =
if you
can&#8217;t distinguish emergency registration at the registrar, the =
result is
the registration is handled by normal registration procedures. We =
can&#8217;t
let lack of support of the URI parameter at the registrar result in a =
failed
registration. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Best =
regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font =
size=3D2
  color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Milan</span></font></st1:place></st1:City><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
John-Luc Bakker
[mailto:jbakker@rim.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, February =
11, 2010
4:37 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Patel, Milan; =
ecrit@ietf.org;
fluffy@cisco.com<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Ecrit]
draft-patel-ecrit-sos-parameter</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Hi =
<st1:City w:st=3D"on"><st1:place
 w:st=3D"on">Milan</st1:place></st1:City>,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>What would =
a UA do
if a SIP message is received and the option-tag is included in the
&#8220;unsupported&#8221; header field? Should a 3GPP UA the not use
&#8220;draft-patel-ecrit-sos-parameter&#8221; in that case? =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Regards,<o:p=
></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
John-Luc<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dsilver face=3DArial><span =
style=3D'font-size:
7.5pt;font-family:Arial;color:silver'>--- <br>
John-Luc Bakker <br>
Standards Manager <br>
Research In Motion <br>
BlackBerry: +1 (908) 463 7321 <br>
Office: +1 (972) 373-1761 <br>
Internal: (820) 63761 <br>
E-mail: jbakker@rim.com </span></font><font size=3D2 color=3D"#1f497d"
face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p></o:p><=
/span></font></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Patel, Milan<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, February =
09, 2010
6:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ecrit@ietf.org;
fluffy@cisco.com<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Ecrit]
draft-patel-ecrit-sos-parameter<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>At the previous meeting, it was requested that =
a
feedback mechanism is introduced to allow the UA to know if the =
registrar
supports the emergency registration extension or not (e.g. use of =
option-tag).
It seems from a 3GPP point of view this is not important. However, I can
understand that for other reg-type values, it may be useful to introduce =
such
feedback mechanism. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>In order to progress this draft (since this =
seems to
be the only sticking point), I propose the =
following:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>UA may include an option-tag (name to be =
decided) in
the Supported header field, if the UA needs to know if the reg-type URI
parameter is supported by the registrar. The registrar returns the =
option-tag
in the 200 (OK) upon successful registration if the extension is =
supported. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Note, I am proposing this mechanism is =
introduced as
an option&#8230;not mandating the UA must include the option-tag during =
such
registration. Additionally, I am not including the option-tag in the =
Required
header field since if the emergency registration is not supported at the
registrar, fall back to normal non-emergency registration should occur =
&#8211;
not the failure of registration. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Please let me know what you think. I will =
start on
the revision. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font =
size=3D2
  face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Milan</span></font></st1:pla=
ce></st1:City><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>-----------------------------------------------------------------=
---- <br>
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute =
non-public
information. Any use of this information by anyone other than the =
intended
recipient is prohibited. If you have received this transmission in =
error,
please immediately reply to the sender and delete this information from =
your
system. Use, dissemination, distribution, or reproduction of this =
transmission
by unintended recipients is not authorized and may be unlawful. =
<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01CAAB3A.7C140595--

From wwwrun@rfc-editor.org  Fri Feb 12 05:18:50 2010
Return-Path: <wwwrun@rfc-editor.org>
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 748B33A6F41 for <ecrit@core3.amsl.com>; Fri, 12 Feb 2010 05:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 n01KyAV4xpGl for <ecrit@core3.amsl.com>; Fri, 12 Feb 2010 05:18:48 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 7CB523A72B2 for <ecrit@ietf.org>; Fri, 12 Feb 2010 05:18:48 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 2BD2CE06C0; Fri, 12 Feb 2010 05:20:07 -0800 (PST)
To: hgs+ecrit@cs.columbia.edu, rjsparks@nostrum.com, fluffy@cisco.com, Hannes.Tschofenig@gmx.net, marc.linsner@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100212132007.2BD2CE06C0@rfc-editor.org>
Date: Fri, 12 Feb 2010 05:20:07 -0800 (PST)
Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org
Subject: [Ecrit] [Editorial Errata Reported] RFC5582 (2041)
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: Fri, 12 Feb 2010 13:18:50 -0000

The following errata report has been submitted for RFC5582,
"Location-to-URL Mapping Architecture and Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5582&eid=2041

--------------------------------------
Type: Editorial
Reported by: Karl Heinz Wolf <khwolf1@gmail.com>

Section: 7.1

Original Text
-------------
Each tree can map a location described by either civic or geographic
coordinates, but not both, for one type of service (such as
'sos.police', 'sos.fire' or 'counseling') and one location profile,
although nothing prevents re-using the same servers for multiple,
different services or both types of coordinates.  The collection of
all trees for one service and location profile is known as a forest.


Corrected Text
--------------
Each tree can map a location described by civic and/or geographic
coordinates, for one type of service (such as 'sos.police', 'sos.fire' or
'counseling'), although nothing prevents re-using the same servers for
multiple, different services.  The collection of all trees for one service 
is known as a forest.


Notes
-----
Trees may have mapping data in multiple location profiles, not only in a single profile. In particular, according to RFC 5222, a LoST server must understand civic and geographic coordinates. Furthermore, there is no mechanism to discover LoST servers based on the location profile.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5582 (draft-ietf-ecrit-mapping-arch-04)
--------------------------------------
Title               : Location-to-URL Mapping Architecture and Framework
Publication Date    : September 2009
Author(s)           : H. Schulzrinne
Category            : INFORMATIONAL
Source              : Emergency Context Resolution with Internet Technologies
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

From wwwrun@rfc-editor.org  Fri Feb 12 05:21:02 2010
Return-Path: <wwwrun@rfc-editor.org>
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 17C573A6F41 for <ecrit@core3.amsl.com>; Fri, 12 Feb 2010 05:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 rnI6zVs68P-N for <ecrit@core3.amsl.com>; Fri, 12 Feb 2010 05:21:00 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6E6D93A7357 for <ecrit@ietf.org>; Fri, 12 Feb 2010 05:21:00 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 30D99E06CA; Fri, 12 Feb 2010 05:22:19 -0800 (PST)
To: hgs+ecrit@cs.columbia.edu, rjsparks@nostrum.com, fluffy@cisco.com, Hannes.Tschofenig@gmx.net, marc.linsner@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100212132219.30D99E06CA@rfc-editor.org>
Date: Fri, 12 Feb 2010 05:22:19 -0800 (PST)
Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org
Subject: [Ecrit] [Editorial Errata Reported] RFC5582 (2042)
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: Fri, 12 Feb 2010 13:21:02 -0000

The following errata report has been submitted for RFC5582,
"Location-to-URL Mapping Architecture and Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5582&eid=2042

--------------------------------------
Type: Editorial
Reported by: Karl Heinz Wolf <khwolf1@gmail.com>

Section: 8

Original Text
-------------
   To facilitate orientation among the trees, we introduce a forest
   guide (FG), which keeps track of the coverage regions of all the
   trees for one service and location profile.  


Corrected Text
--------------
   To facilitate orientation among the trees, we introduce a forest
   guide (FG), which keeps track of the coverage regions of all the
   trees for one service.  


Notes
-----
Trees may have mapping data in multiple location profiles, not only in a single profile. In particular, according to RFC 5222, a LoST server must understand civic and geographic coordinates. Furthermore, there is no mechanism to discover LoST servers based on the location profile.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5582 (draft-ietf-ecrit-mapping-arch-04)
--------------------------------------
Title               : Location-to-URL Mapping Architecture and Framework
Publication Date    : September 2009
Author(s)           : H. Schulzrinne
Category            : INFORMATIONAL
Source              : Emergency Context Resolution with Internet Technologies
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

From wwwrun@rfc-editor.org  Fri Feb 12 05:22:58 2010
Return-Path: <wwwrun@rfc-editor.org>
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 2824D3A72D7 for <ecrit@core3.amsl.com>; Fri, 12 Feb 2010 05:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 W12jxVwdrEAL for <ecrit@core3.amsl.com>; Fri, 12 Feb 2010 05:22:57 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 5761D3A72B2 for <ecrit@ietf.org>; Fri, 12 Feb 2010 05:22:57 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 20154130001; Fri, 12 Feb 2010 05:24:16 -0800 (PST)
To: hgs+ecrit@cs.columbia.edu, rjsparks@nostrum.com, fluffy@cisco.com, Hannes.Tschofenig@gmx.net, marc.linsner@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100212132416.20154130001@rfc-editor.org>
Date: Fri, 12 Feb 2010 05:24:16 -0800 (PST)
Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org
Subject: [Ecrit] [Editorial Errata Reported] RFC5582 (2043)
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: Fri, 12 Feb 2010 13:22:58 -0000

The following errata report has been submitted for RFC5582,
"Location-to-URL Mapping Architecture and Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5582&eid=2043

--------------------------------------
Type: Editorial
Reported by: Karl Heinz Wolf <khwolf1@gmail.com>

Section: 3

Original Text
-------------
   resolver:  A resolver is contacted by a seeker, consults a forest
      mapping server, and then resolves the query using an appropriate
      tree.  Resolvers may cache query results.


   tree:  A tree consists of a self-contained hierarchy of authoritative
      mapping servers for a particular service.  Each tree exports its
      coverage region to the forest mapping servers.


Corrected Text
--------------
   resolver:  A resolver is contacted by a seeker, consults a forest
      guide, and then resolves the query using an appropriate
      tree.  Resolvers may cache query results.


   tree:  A tree consists of a self-contained hierarchy of authoritative
      mapping servers for a particular service.  Each tree exports its
      coverage region to the forest guide.


Notes
-----
The server should be correctly referred to as "forest guide", there is no "forest mapping server" in the architecture.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5582 (draft-ietf-ecrit-mapping-arch-04)
--------------------------------------
Title               : Location-to-URL Mapping Architecture and Framework
Publication Date    : September 2009
Author(s)           : H. Schulzrinne
Category            : INFORMATIONAL
Source              : Emergency Context Resolution with Internet Technologies
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

From hannes.tschofenig@nsn.com  Sun Feb 14 10:22:35 2010
Return-Path: <hannes.tschofenig@nsn.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 3451A3A7725 for <ecrit@core3.amsl.com>; Sun, 14 Feb 2010 10:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059,  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 Agw9Cb+oRIIZ for <ecrit@core3.amsl.com>; Sun, 14 Feb 2010 10:22:33 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 907713A7315 for <ecrit@ietf.org>; Sun, 14 Feb 2010 10:22:32 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1EINtJb009828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Sun, 14 Feb 2010 19:23:56 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1EINtw6001333 for <ecrit@ietf.org>; Sun, 14 Feb 2010 19:23:55 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 14 Feb 2010 19:23:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Feb 2010 20:28:09 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502305685@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PSAP Callback: Feedback needed
Thread-Index: AcqtooBbSidC0MmPTeep9oI3dVsdogAAAjgw
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <ecrit@ietf.org>
X-OriginalArrivalTime: 14 Feb 2010 18:23:54.0552 (UTC) FILETIME=[DD799380:01CAADA2]
Subject: [Ecrit] FW: PSAP Callback: Feedback needed
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: Sun, 14 Feb 2010 18:22:35 -0000

FYI: In response to the ECRIT virtual interim meeting I listened to the
audio recording and tried to make sense out of the discussion. I
compiled a few questions (see below) that I then distributed to the NENA
LTD, EENA NG112 technical committee and EENA operations committee, and
EMTEL mailing list. I hope to get some feedback from there. =20

Ciao
Hannes

>-----Original Message-----
>From: Tschofenig, Hannes (NSN - FI/Espoo)=20
>Subject: PSAP Callback: Feedback needed
>
>Hi all,=20
>
>To progress the work on PSAP callback in the IETF ECRIT group=20
>we are soliciting feedback from a number of groups. =20
>
>A little bit of background first:  When you make an IP-based=20
>emergency call to an IP-based PSAP then the PSAP will get two=20
>pieces of identity information about the emergency caller:=20
>
>  * Contact-URI: Information that uniquely identifies the=20
>device the call came from.=20
>  * Address of Record: Long-term contact information=20
>
>Imagine that the communication between the PSAP and the=20
>emergency caller gets interrupted prematurely and the PSAP=20
>wants to call back to the emergency caller, for example to=20
>obtain more information about the incident.=20
>
>The idea of the ongoing PSAP callback work is to allow the=20
>emergency call to override call forwarding procedures=20
>configured by the emergency caller's phone, do not disturb=20
>functionality, etc. so that the call indeed reaches the=20
>emergency caller. This includes the ability to disable network=20
>based services, such as network based call forwarding, in=20
>addition to functionality configured at the phone itself.
>
>1st question: What functionality is available in today's CS networks?=20
>
>2nd question: Is this useful functionality to have for=20
>IP-based emergency services?=20
>
>3rd question: Do you envision a time-restriction on this capability?
>Example: only within one hour callbacks from the PSAP are=20
>treated differently to normal calls.=20
>
>4th question: Would you expect the call to reach primarily the=20
>device that initiated the emergency call?=20
>  =20
>5th question: In some cases the device that was used to=20
>originally initiate the call does not respond anymore to a=20
>callback (e.g. imagine a fixed line phone that was used to=20
>report a fire in a house and is out of order soon afterwards).=20
>Since the initial emergency call provided a second contact=20
>mechanism (namely the address of record) it could be used by=20
>the call taker as well. Should this communication also=20
>experience the same type of override privilege as the=20
>initially transmitted callback to the emergency caller's device? =20
>
>Thank you for your time. Your feedback is very valuable to us.=20
>
>Ciao
>Hannes

From thompson@ieee.org  Mon Feb 15 11:15:36 2010
Return-Path: <thompson@ieee.org>
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 E67F53A7BCA for <ecrit@core3.amsl.com>; Mon, 15 Feb 2010 11:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 HezJ2Tzg3nBG for <ecrit@core3.amsl.com>; Mon, 15 Feb 2010 11:15:35 -0800 (PST)
Received: from smtp106.prem.mail.sp1.yahoo.com (smtp106.prem.mail.sp1.yahoo.com [98.136.44.61]) by core3.amsl.com (Postfix) with SMTP id CC6E43A7BB8 for <ecrit@ietf.org>; Mon, 15 Feb 2010 11:15:35 -0800 (PST)
Received: (qmail 95508 invoked from network); 15 Feb 2010 19:17:05 -0000
Received: from user-64-9-238-93.googlewifi.com (thompson@64.9.238.93 with plain) by smtp106.prem.mail.sp1.yahoo.com with SMTP; 15 Feb 2010 11:17:04 -0800 PST
X-Yahoo-SMTP: QyU90.qswBBpdAOL14e1mfwUogr5DY5wzs_aWTD7HWypLbttNQmnq7k-
X-YMail-OSG: 6t8U.boVM1nj.RYToa5_n_pNRgy83Y7xd9CCHJcSzjTH6J73zKeAPA6Hv3LxG18ZemV1PNrN2KN05.f9gwqKPd5MQ9VsIf6msUxxzb1IV2ZscIkfONH.1XzIBKYHCoNCmsZhvtS8u0HjbbzXn1Dn4cJ3Bf59J5oX4JMG_DaW15Lz7MKpux_115nC0l8pTv69WOw47VDdONGugdqDpRF2gUbhy.tpWE1iQSyKi2.znLOI15QZl6xt.zvBbU44sEbPgEumlm4g8RhyqvpJsBQDAMXTolOotzOc
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4B799DAE.5050608@ieee.org>
Date: Mon, 15 Feb 2010 11:17:02 -0800
From: Geoff Thompson <thompson@ieee.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: ecrit@ietf.org
References: <mailman.47.1266177612.18072.ecrit@ietf.org>
In-Reply-To: <mailman.47.1266177612.18072.ecrit@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Geoff Thompson <thompson@ieee.org>
Subject: Re: [Ecrit] Ecrit Digest, Vol 61, Issue 12
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: thompson@ieee.org
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: Mon, 15 Feb 2010 19:15:37 -0000

Hannes-

My comments on callback to other than originating device are inserted below.

Geoff Thompson

On 2/14/10 12:00 PM, ecrit-request@ietf.org wrote:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 14 Feb 2010 20:28:09 +0200
> From: "Tschofenig, Hannes (NSN - FI/Espoo)"
> 	<hannes.tschofenig@nsn.com>
> Subject: [Ecrit] FW: PSAP Callback: Feedback needed
> To:<ecrit@ietf.org>
> Message-ID:
> 	<3D3C75174CB95F42AD6BCC56E5555B4502305685@FIESEXC015.nsn-intra.net>
> Content-Type: text/plain;	charset="us-ascii"
>
> FYI: In response to the ECRIT virtual interim meeting I listened to the
> audio recording and tried to make sense out of the discussion. I
> compiled a few questions (see below) that I then distributed to the NENA
> LTD, EENA NG112 technical committee and EENA operations committee, and
> EMTEL mailing list. I hope to get some feedback from there.
>
> Ciao
> Hannes
>
>    
>> -----Original Message-----
>> From: Tschofenig, Hannes (NSN - FI/Espoo)
>> Subject: PSAP Callback: Feedback needed
>>
>> Hi all,
>>
>> To progress the work on PSAP callback in the IETF ECRIT group
>> we are soliciting feedback from a number of groups.
>>
>> A little bit of background first:  When you make an IP-based
>> emergency call to an IP-based PSAP then the PSAP will get two
>> pieces of identity information about the emergency caller:
>>
>>   * Contact-URI: Information that uniquely identifies the
>> device the call came from.
>>   * Address of Record: Long-term contact information
>>
>> Imagine that the communication between the PSAP and the
>> emergency caller gets interrupted prematurely and the PSAP
>> wants to call back to the emergency caller, for example to
>> obtain more information about the incident.
>>
>> The idea of the ongoing PSAP callback work is to allow the
>> emergency call to override call forwarding procedures
>> configured by the emergency caller's phone, do not disturb
>> functionality, etc. so that the call indeed reaches the
>> emergency caller. This includes the ability to disable network
>> based services, such as network based call forwarding, in
>> addition to functionality configured at the phone itself.
>>
>> 1st question: What functionality is available in today's CS networks?
>>
>> 2nd question: Is this useful functionality to have for
>> IP-based emergency services?
>>
>> 3rd question: Do you envision a time-restriction on this capability?
>> Example: only within one hour callbacks from the PSAP are
>> treated differently to normal calls.
>>      
I believe that should be adequate for "automatic" callback.  We have to 
expect that the PSAP logging function will have captured the data 
required to place a callback.  At some point, I believe, we have to 
revert back to whatever is the normal override capabilities of a PSAP 
(without regard to the call history of the device).  It is perfectly 
reasonable to assume that public service entities have some sort of 
privileges in this area.
>> 4th question: Would you expect the call to reach primarily the
>> device that initiated the emergency call?
>>      
Absolutely.
>>
>> 5th question: In some cases the device that was used to
>> originally initiate the call does not respond anymore to a
>> callback (e.g. imagine a fixed line phone that was used to
>> report a fire in a house and is out of order soon afterwards).
>> Since the initial emergency call provided a second contact
>> mechanism (namely the address of record) it could be used by
>> the call taker as well. Should this communication also
>> experience the same type of override privilege as the
>> initially transmitted callback to the emergency caller's device?
>>      
I believe we need to be careful here.
It may be well and good to be able to place a call to a device that was 
near to the calling device when the emergency call was placed.
We do not want the callback to ring at the home of someone who has just 
died in a car crash.
(Providing the home phone number of such a party to the PSAP as 
reference information is an entirely different matter.)
>> Thank you for your time. Your feedback is very valuable to us.
>>
>> Ciao
>> Hannes
>>      
Best regards
     Geoff Thompson

From jsalowey@cisco.com  Tue Feb 16 09:02:45 2010
Return-Path: <jsalowey@cisco.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 1528528C0E9 for <ecrit@core3.amsl.com>; Tue, 16 Feb 2010 09:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level: 
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 N0TWI3nV3rn2 for <ecrit@core3.amsl.com>; Tue, 16 Feb 2010 09:02:43 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5717D3A7B90 for <ecrit@ietf.org>; Tue, 16 Feb 2010 09:02:43 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFZeekurRN+J/2dsb2JhbACbGnSHdZ4iikoIB40LgkcOBggMgWwEgxSLPk0
X-IronPort-AV: E=Sophos;i="4.49,485,1262563200"; d="scan'208";a="152101393"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2010 17:04:18 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1GH4I00024489; Tue, 16 Feb 2010 17:04:18 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 16 Feb 2010 09:04:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Feb 2010 09:04:15 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5099F6AA1@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <BLU137-DS794C4428F279BDAE95E2C93AA0@phx.gbl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access
Thread-Index: AcpicA6su24Zxn+bQ6KOYF92eTsy4xJ2suhA
References: <BLU137-DS794C4428F279BDAE95E2C93AA0@phx.gbl>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Bernard Aboba" <bernard_aboba@hotmail.com>, "ECRIT" <ecrit@ietf.org>
X-OriginalArrivalTime: 16 Feb 2010 17:04:18.0504 (UTC) FILETIME=[138DFC80:01CAAF2A]
Subject: Re: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access
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: Tue, 16 Feb 2010 17:02:45 -0000

I agree with Barnard's comments on section 6 of this draft. =20

I would like to emphasize the following:

- I'm a bit concerned about using an EAP method type to indicate
emergency authentication.  The EAP method type should be orthogonal to
whether emergency access is requested or not.  Combining the two will
cause and artificial linkages between the two and likely cause problems
down the road.  For this reason I am strongly against options 2.a and
2.c in section 6.2.

- In section 6.3, I don't think that anonymous cipher suites or
publically known shared keys are a good idea.  In general, a server
authenticated method using public key certificates can be used.  If the
client is in an emergency it can forgo certificate validation to get
access.  If it knows the trust root then it can validate it. =20


> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
Of
> Bernard Aboba
> Sent: Tuesday, November 10, 2009 5:41 PM
> To: 'ECRIT'
> Subject: [Ecrit] Comments on Section 6 ofdraft-schulzrinne-ecrit-
> unauthenticated-access
>=20
> Section 6
>=20
> "   signalling allows an IEEE 802.1X to occur without exchanging
>=20
>    cryptogrpahic keys"
>=20
>=20
>=20
> [BA] Not sure what this is saying.  In IEEE 802.1X-2004, there is no
> encryption supported.  However, EAP is still run.  This can include
> methods that don't generate keys (e.g. EAP-MD5).  But the issue here
is
> client unauthenticated access, not key generation, right?
>=20
>=20
>=20
> Section 6.1
>=20
>=20
>=20
> "   In general, link layer emergency indications provide good
integration
>    into the actual network access procedure regarding the enabling of
>    means to recognize and prioritize an emergency service request from
>    an end host at a very early stage of the network attachment
>    procedure.  However, support in end hosts for such methods cannot
be
>    considered to be commonly available.
>=20
> "
>=20
>=20
>=20
> [BA] I'm not sure what this is referring to.  If it's referring to
QoS,
> those mechanisms are independent of emergency indications (e.g. WFA
WMM).
> If it's talking about higher layer emergency service prioritization,
> that's also independent of the lower layer.  So what exactly is a host
> expected to do at the lower layer to distinguish an emergency call?
>=20
>=20
>=20
> Section 6.2
>=20
>=20
>=20
> "In normal operation, EAP related
>    information will only be recognized in the NAS.  Any entity
residing
>    between end host and NAS should not be expected to understand/parse
>    EAP messages.
>=20
> "
>=20
>=20
>=20
> [BA] The EAP architecture requires the NAS to be EAP-method agnostic
if
> it's acting as a pass-through.  So even the NAS can't be depended upon
to
> understand/parse EAP methods.  But why would it need to?
>=20
>=20
>=20
> "   1.b) Emergency NAI: The NAI comes with a realm or username part
>    indicating emergency (e.g. 'emergency@emergency.com').  An
advantage
>    of this method for NAA cases is that no new requirements are put on
>    the involved signaling procedures.  Only the identity used for
>    network entry is impacted.  Potential disadvantages include that
>    different methods to indicate emergency for NAA cases and standard
>    emergency network attachments may be required.  Also, modifying the
>    NAI itself (the username@realm part) may conflict with network
>    selection and network entry procedures, depending on the actual
>    access network.
>=20
> "
>=20
>=20
>=20
> [BA] There are two distinct ideas being presented here.  One is to
define
> an emergency user name (e.g. "emergency"); another is to define an
> emergency domain (e.g. "emergency.com").  The former concept may make
> sense, but the latter one is dangerous since existing systems not
> including the emergency realm in their routing tables may just return
an
> error.  So the question is what realm should be used, if any.  The
problem
> with including any realm is that it assumes realm reachability.  If
> reachability doesn't exist, then the host will get an error.  If there
is
> no realm, then the local realm needs to recognize the emergency
username,
> and utilize an appropriate EAP method that allows client
unauthenticated
> access.
>=20
>=20
>=20
> "   2) Emergency EAP method
>=20
>    An emergency indication can be given by using a dedicated EAP
method
>    that is reserved for emergency network attachment only.
>=20
> "
>=20
>=20
>=20
> [BA] Why is a dedicated EAP method needed for emergency access?  EMU
WG
> has already discussed this and come up with mechanisms that would
allow
> client unauthenticated access from any TLS-based method (e.g. server
side
> either doesn't ask for a client cert, or accepts the client not
providing
> one).  That mechanism is supported in RFC 5216, and can also be
applied to
> existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc.
>=20
>=20
>=20
> In effect, the only real constraint here is that a local network
> advertising support for emergency calling needs to support one or more
of
> these methods.
>=20
>=20
>=20
> "   2.a) Existing EAP method with new type: An existing EAP method may
be
>    used.  EAP methods themselves typically do not support emergency
>    indication.  One option would be to pick a common EAP method like
>    EAP-TLS and allocate a new method type for the same method that is
>    exclusively reserved to emergency use.  Such EAP method should be
>    chosen in a way that the same method can support NAA cases as well
as
>    standard emergency network attachment.
>=20
>=20
> "
>=20
>=20
>=20
> Given that RFC 5216 already supports client-unauthenticated anonymous
> access (see Sections 2.1.4 and 2.2), why is it necessary to request
> allocation of a new method type?
>=20
>=20
>=20
> "   2.b) Existing EAP method: Same as 2a), but without assigning a new
>    EAP method type for emergency.  In this case some implicit
indication
>    must be used.  For example, in cases where EAP-TLS is used in
network
>    attachment in combination with client certificates, the absence of
a
>    client certificate could be interpreted by the network as a request
>    for emergency network attachment.
>=20
> "
>=20
>=20
>=20
> [BA] The combination of an emergency NAI *and* the absence of a client
> certificate would be considered a request for emergency attachment.
If an
> NAI corresponding to an existing account is used, then normal policies
> will apply (which would probably require authenticated access).
>=20
>=20
>=20
> "   2.c) Emergency EAP method: A new EAP method could be defined that
is
>    specifically designed for emergency network entry in NAA cases.
Most
>    likely, such EAP method would not be usable for standard emergency
>    network attachment with an existing subscription.  Such dedicated
>    emergency EAP method should be key-generating in compliance with
>    RFC3748 <http://tools.ietf.org/html/rfc3748>  to enable the regular
air
> interface security methods even in
>    unauthenticated operation.
>=20
> "
>=20
>=20
>=20
> [BA] Since any TLS-based method can potentially support client-
> unauthenticated access, it's not clear to me that there is a good case
for
> creating yet another method.
>=20
>=20
>=20
> Section 6.3
>=20
>=20
>=20
> "   Therefore, for network attachment that is by default based on EAP
>    authentication it is desirable also for NAA network attachment to
use
>    a key-generating EAP method (that provides an MSK key to the
>    authenticator to bootstrap further key derivation for protecting
the
>    wireless link).
>=20
> "
>=20
>=20
>=20
> [BA] Where key generation is required (e.g. WPA/WPA2 enterprise) you
don't
> really have a choice.
>=20
>=20
>=20
> "   2) Null authentication: an EAP method is performed.  However, no
>    credentials specific to either the server or the device or
>    subscription are used as part of the authentication exchange.  An
>    example for this would be an EAP-TLS exchange with using the
>    TLS_DH_anon (anonymous) ciphersuite.  Alternatively, a publicly
>    available static key for emergency access could be used.  In the
>    latter case, the device would need to be provisioned with the
>    appropriate emergency key for the IAP/ISP in advance.
>=20
>=20
> "
>=20
>=20
>=20
> [BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode only
> uses the 4-way handshake, not EAP.
>=20
>=20
>=20
> "   3) Device authentication: This case extends the server-only
>    authentication case.  If the device is configured with a device
>    certificate and the IAP/ISP EAP server can rely on a trusted root
>    allowing the EAP server to verify the device certificate, at least
>    the device identity (e.g. the MAC address) can be authenticated by
>    the IAP/ISP in NAA cases.  An example for this are WiMAX devices
that
>    are shipped with device certificates issued under the global WiMAX
>    device public-key infrastructure.  To perform unauthenticated
>    emergency calls, if allowed by the IAP/ISP, such devices perform
EAP-
>    TLS based network attachment with client authentication based on
the
>    device certificate.
>=20
> "
>=20
>=20
>=20
> IEEE 802.1ar might also be an example of this.


From jsalowey@cisco.com  Tue Feb 16 09:02:56 2010
Return-Path: <jsalowey@cisco.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 978B428C19C for <ecrit@core3.amsl.com>; Tue, 16 Feb 2010 09:02:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.479
X-Spam-Level: 
X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Qdt2XX83SvaA for <ecrit@core3.amsl.com>; Tue, 16 Feb 2010 09:02:55 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 40A2228C19B for <ecrit@ietf.org>; Tue, 16 Feb 2010 09:02:55 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFZeekurR7Hu/2dsb2JhbACbGnSHdZ4iikoIB40LgkcOBggMgWwEgxSLPk0
X-IronPort-AV: E=Sophos;i="4.49,485,1262563200"; d="scan'208";a="152101519"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2010 17:04:30 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1GH4U96021095; Tue, 16 Feb 2010 17:04:30 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 16 Feb 2010 09:04:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Feb 2010 09:04:28 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5099F6AA4@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <BLU137-DS794C4428F279BDAE95E2C93AA0@phx.gbl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access
Thread-Index: AcpicA6su24Zxn+bQ6KOYF92eTsy4xJ2sU5Q
References: <BLU137-DS794C4428F279BDAE95E2C93AA0@phx.gbl>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Bernard Aboba" <bernard_aboba@hotmail.com>, "ECRIT" <ecrit@ietf.org>
X-OriginalArrivalTime: 16 Feb 2010 17:04:30.0429 (UTC) FILETIME=[1AA998D0:01CAAF2A]
Subject: Re: [Ecrit] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access
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: Tue, 16 Feb 2010 17:02:56 -0000

I agree with Barnard's comments on section 6 of this draft. =20

I would like to emphasize the following:

- I'm a bit concerned about using an EAP method type to indicate
emergency authentication.  The EAP method type should be orthogonal to
whether emergency access is requested or not.  Combining the two will
cause and artificial linkages between the two and likely cause problems
down the road.  For this reason I am strongly against options 2.a and
2.c in section 6.2.

- In section 6.3, I don't think that anonymous cipher suites or
publically known shared keys are a good idea.  In general, a server
authenticated method using public key certificates can be used.  If the
client is in an emergency it can forgo certificate validation to get
access.  If it knows the trust root then it can validate it. =20

> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
Of
> Bernard Aboba
> Sent: Tuesday, November 10, 2009 5:41 PM
> To: 'ECRIT'
> Subject: [Ecrit] Comments on Section 6 ofdraft-schulzrinne-ecrit-
> unauthenticated-access
>=20
> Section 6
>=20
> "   signalling allows an IEEE 802.1X to occur without exchanging
>=20
>    cryptogrpahic keys"
>=20
>=20
>=20
> [BA] Not sure what this is saying.  In IEEE 802.1X-2004, there is no
> encryption supported.  However, EAP is still run.  This can include
> methods that don't generate keys (e.g. EAP-MD5).  But the issue here
is
> client unauthenticated access, not key generation, right?
>=20
>=20
>=20
> Section 6.1
>=20
>=20
>=20
> "   In general, link layer emergency indications provide good
integration
>    into the actual network access procedure regarding the enabling of
>    means to recognize and prioritize an emergency service request from
>    an end host at a very early stage of the network attachment
>    procedure.  However, support in end hosts for such methods cannot
be
>    considered to be commonly available.
>=20
> "
>=20
>=20
>=20
> [BA] I'm not sure what this is referring to.  If it's referring to
QoS,
> those mechanisms are independent of emergency indications (e.g. WFA
WMM).
> If it's talking about higher layer emergency service prioritization,
> that's also independent of the lower layer.  So what exactly is a host
> expected to do at the lower layer to distinguish an emergency call?
>=20
>=20
>=20
> Section 6.2
>=20
>=20
>=20
> "In normal operation, EAP related
>    information will only be recognized in the NAS.  Any entity
residing
>    between end host and NAS should not be expected to understand/parse
>    EAP messages.
>=20
> "
>=20
>=20
>=20
> [BA] The EAP architecture requires the NAS to be EAP-method agnostic
if
> it's acting as a pass-through.  So even the NAS can't be depended upon
to
> understand/parse EAP methods.  But why would it need to?
>=20
>=20
>=20
> "   1.b) Emergency NAI: The NAI comes with a realm or username part
>    indicating emergency (e.g. 'emergency@emergency.com').  An
advantage
>    of this method for NAA cases is that no new requirements are put on
>    the involved signaling procedures.  Only the identity used for
>    network entry is impacted.  Potential disadvantages include that
>    different methods to indicate emergency for NAA cases and standard
>    emergency network attachments may be required.  Also, modifying the
>    NAI itself (the username@realm part) may conflict with network
>    selection and network entry procedures, depending on the actual
>    access network.
>=20
> "
>=20
>=20
>=20
> [BA] There are two distinct ideas being presented here.  One is to
define
> an emergency user name (e.g. "emergency"); another is to define an
> emergency domain (e.g. "emergency.com").  The former concept may make
> sense, but the latter one is dangerous since existing systems not
> including the emergency realm in their routing tables may just return
an
> error.  So the question is what realm should be used, if any.  The
problem
> with including any realm is that it assumes realm reachability.  If
> reachability doesn't exist, then the host will get an error.  If there
is
> no realm, then the local realm needs to recognize the emergency
username,
> and utilize an appropriate EAP method that allows client
unauthenticated
> access.
>=20
>=20
>=20
> "   2) Emergency EAP method
>=20
>    An emergency indication can be given by using a dedicated EAP
method
>    that is reserved for emergency network attachment only.
>=20
> "
>=20
>=20
>=20
> [BA] Why is a dedicated EAP method needed for emergency access?  EMU
WG
> has already discussed this and come up with mechanisms that would
allow
> client unauthenticated access from any TLS-based method (e.g. server
side
> either doesn't ask for a client cert, or accepts the client not
providing
> one).  That mechanism is supported in RFC 5216, and can also be
applied to
> existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc.
>=20
>=20
>=20
> In effect, the only real constraint here is that a local network
> advertising support for emergency calling needs to support one or more
of
> these methods.
>=20
>=20
>=20
> "   2.a) Existing EAP method with new type: An existing EAP method may
be
>    used.  EAP methods themselves typically do not support emergency
>    indication.  One option would be to pick a common EAP method like
>    EAP-TLS and allocate a new method type for the same method that is
>    exclusively reserved to emergency use.  Such EAP method should be
>    chosen in a way that the same method can support NAA cases as well
as
>    standard emergency network attachment.
>=20
>=20
> "
>=20
>=20
>=20
> Given that RFC 5216 already supports client-unauthenticated anonymous
> access (see Sections 2.1.4 and 2.2), why is it necessary to request
> allocation of a new method type?
>=20
>=20
>=20
> "   2.b) Existing EAP method: Same as 2a), but without assigning a new
>    EAP method type for emergency.  In this case some implicit
indication
>    must be used.  For example, in cases where EAP-TLS is used in
network
>    attachment in combination with client certificates, the absence of
a
>    client certificate could be interpreted by the network as a request
>    for emergency network attachment.
>=20
> "
>=20
>=20
>=20
> [BA] The combination of an emergency NAI *and* the absence of a client
> certificate would be considered a request for emergency attachment.
If an
> NAI corresponding to an existing account is used, then normal policies
> will apply (which would probably require authenticated access).
>=20
>=20
>=20
> "   2.c) Emergency EAP method: A new EAP method could be defined that
is
>    specifically designed for emergency network entry in NAA cases.
Most
>    likely, such EAP method would not be usable for standard emergency
>    network attachment with an existing subscription.  Such dedicated
>    emergency EAP method should be key-generating in compliance with
>    RFC3748 <http://tools.ietf.org/html/rfc3748>  to enable the regular
air
> interface security methods even in
>    unauthenticated operation.
>=20
> "
>=20
>=20
>=20
> [BA] Since any TLS-based method can potentially support client-
> unauthenticated access, it's not clear to me that there is a good case
for
> creating yet another method.
>=20
>=20
>=20
> Section 6.3
>=20
>=20
>=20
> "   Therefore, for network attachment that is by default based on EAP
>    authentication it is desirable also for NAA network attachment to
use
>    a key-generating EAP method (that provides an MSK key to the
>    authenticator to bootstrap further key derivation for protecting
the
>    wireless link).
>=20
> "
>=20
>=20
>=20
> [BA] Where key generation is required (e.g. WPA/WPA2 enterprise) you
don't
> really have a choice.
>=20
>=20
>=20
> "   2) Null authentication: an EAP method is performed.  However, no
>    credentials specific to either the server or the device or
>    subscription are used as part of the authentication exchange.  An
>    example for this would be an EAP-TLS exchange with using the
>    TLS_DH_anon (anonymous) ciphersuite.  Alternatively, a publicly
>    available static key for emergency access could be used.  In the
>    latter case, the device would need to be provisioned with the
>    appropriate emergency key for the IAP/ISP in advance.
>=20
>=20
> "
>=20
>=20
>=20
> [BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode only
> uses the 4-way handshake, not EAP.
>=20
>=20
>=20
> "   3) Device authentication: This case extends the server-only
>    authentication case.  If the device is configured with a device
>    certificate and the IAP/ISP EAP server can rely on a trusted root
>    allowing the EAP server to verify the device certificate, at least
>    the device identity (e.g. the MAC address) can be authenticated by
>    the IAP/ISP in NAA cases.  An example for this are WiMAX devices
that
>    are shipped with device certificates issued under the global WiMAX
>    device public-key infrastructure.  To perform unauthenticated
>    emergency calls, if allowed by the IAP/ISP, such devices perform
EAP-
>    TLS based network attachment with client authentication based on
the
>    device certificate.
>=20
> "
>=20
>=20
>=20
> IEEE 802.1ar might also be an example of this.


From RMarshall@telecomsys.com  Tue Feb 16 10:08:54 2010
Return-Path: <RMarshall@telecomsys.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 300A53A7D75 for <ecrit@core3.amsl.com>; Tue, 16 Feb 2010 10:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 XFezai6WHx1K for <ecrit@core3.amsl.com>; Tue, 16 Feb 2010 10:08:52 -0800 (PST)
Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id C90DB3A7B08 for <ecrit@ietf.org>; Tue, 16 Feb 2010 10:08:52 -0800 (PST)
Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by  sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP  id <T93e2a9874f0a200c49684@sea-mimesweep-1.telecomsys.com>; Tue, 16  Feb 2010 10:09:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Feb 2010 10:08:38 -0800
Message-ID: <8C837214C95C864C9F34F3635C2A65751108FC69@SEA-EXCHVS-2.telecomsys.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502305752@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interim Meeting Notes
Thread-Index: AcqtoxW2fk+biyviT7W0nuYdScuk4AAHD71QABOeWvAASC1EsA==
References: <3D3C75174CB95F42AD6BCC56E5555B4502305683@FIESEXC015.nsn-intra.net> <8C837214C95C864C9F34F3635C2A65751108F96A@SEA-EXCHVS-2.telecomsys.com>  <3D3C75174CB95F42AD6BCC56E5555B4502305752@FIESEXC015.nsn-intra.net>
From: "Roger Marshall" <RMarshall@telecomsys.com>
To: <ecrit@ietf.org>
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, marc.linsner@cisco.com
Subject: [Ecrit] Interim Meeting Notes
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: Tue, 16 Feb 2010 18:08:54 -0000

All:
I'm forwarding my raw (non-summarized) notes from the ECRIT interim
meeting held on 2/11/2010.

Please send back any corrections as you see fit.

-roger marshall.

***

ECRIT Interim Meeting, 2/11/2010 8:00AM Eastern US Timezone

Attendees:
Andrea Forte
Bernard Aboba
Cullen Jennings
Dan Romascanu
Geoff Thompson
Janet Gunn
John Elwell
Keith Drage
Marc Linsner
Hannes Tschofenig
Roger Marshall

Hannes - meeting opening

Roger - status of drafts

in IESG review:
in AD review:
expired: rph-namespace
active:=20

expired, rph-namespace,=20
Cullen - we talked about it way back, but don't remember exactly at this
point

plus special AD-direct handling of sos-parameter draft
Milan - to have a revised draft by the end of the week

Keith - now we're talking about an option type which some don't think is
necessary.

Cullen - need to think through carefully the difference between "do what
I mean" vs. "do what I say".

Cullen - if 3GPP needs bits on the wire,=20

Cullen - Be careful that you don't put an extra parameter there if you
don't fully explain it - because, in that case, it won't fly.

Milan - you don't need to know it if it's not supported, it will then be
backward compatible.

Keith - ordinary registration will replace emergency registration.

Milan - the doc is ready to move forward.

Keith - the option tag breaks SIP.

Cullen - I don't remember saying that we needed an option tag.

Cullen - suggest not to add an option tag.


end of sos-param discussion

next - callback

Hannes - sent email to the list yesterday, proposing some things.

Hannes - 3 types of approaches

1. response to a previous emergency call.

2. PSAP
a. Identity as a PSAP
b. in the role of a PSAP, regardless of my Identity

3.=20


Hannes - feedback on this proposal?

(nothing)

Hannes - is there any interest from these on this call?

John Elwell - description is good.

Milan - may need to be a combination of more than one of these.

Hannes - John's proposal.

Milan - maybe leverage urn:service:sos

Cullen - discussion in the weeds here, if you are going to do this
requirement, bits in are ok, but now you need to verify authenticity of
the call.

Cullen - wishing away the hard part here.

Hannes - some ideas,=20

a. you would need a registry of something, list of PSAPs is one possible
way.

b. if not on this list, then might be treated as a normal call.

Hannes - the other way might be role based assertion (might have much of
this already there, would just need to leverage it).

c. local relationships (white list).

Cullen - in review, the coherent thing heard so far.

a. white list.

b. white list w/cert.

c. walled garden.

Marc - want to make sure that the mechanism doesn't get too complicated.

Hannes - they don't know complexities

Marc - they don't care about costs (they are gov't people)=20

(one hour is all we need)

Hannes - also what is missing is to provide what Marc just said

John - may be some other reasons to know that it is a PSAP calling.

Hannes - yes, we need to combine with something else.

e.g., if contacted with SIP would it be ok to return with xmpp?

John - yes, can't assume that the device supports other modes.

Cullen (as individual) I'd say that the device would be assumed to
support phonebcp requirements.

Keith - it'd be nice, but I don't think you can assume...

Marc - but that's the ground rules

Janet Gunn - you'll have to make some assumptions.

Keith - PSAPs can make other calls, don't constrain capabilities that
the PSAP has (extra)

(?) Dan - what if "do not disturb"

Hannes - never have heard of this requirement

Cullen - that's how we split before - different working group - under
authority-to-citizen.

Marc - phonebcp talks about disabling do not call, etc.

Hannes - there is a requirement in phonebcp.

Keith -=20

Hannes - sos gets replaced by PSAP URI by the E-CSCF

(Storage) of requirement

Keith - don't know how this would work.

Hannes - could be even in the device.

Keith - you need to make this work in the CS domain as well.

Hannes - right, no token to pass back - wouldn't work.

Keith - we do have a token in i2.

Roger - called an ESQK

Marc - this is just a token for ALI info.

Hannes -=20

Marc - So, if in SIP (not 3GPP) LoST gives me the country level to state
to PSAP.  Is there anything in SIP that shows where in the hierarchy?

Cullen - if the PSAP sends an updated Identity.  Otherwise, no.

Marc - then you could use that Identity, say not to block.  Simpler
without all this other stuff.

Cullen - has all (some) of that under the covers, including a Cert.

Marc - Do we all agree to a 1 hr max timer allowance?

Hannes - yeah, when to start the timer and how precisely do you want to
keep that state?

Phonebcp doesn't say that specific entity.

Marc - Ok, we could go back and say must be from the same device?

Keith - Be careful - make sure of a global solution, not just a NENA
one.

Marc - sure we can solicit, but NENA provides 90% of our input.

Hannes - others' thoughts?

Keith - other calls like prepaid calls might be blocked.

Keith - call could get blocked.

Marc - other cases like uninitialized calls - can't call back - no TN.

*Janet - Could be down a different path - many other elements - may not
have awareness that the original call was an emergency call.

Cullen - get the previous statement into the notes.

Marc - return path different, then the UA has to know about it and would
need to say, shut all of this stuff off for psap1234.

Hannes - can't do that, a UA in a local domain has its own set of
policies vs. the network domain policies.

--

--

SIP Identities carry across international borders?

(?) Dan -=20

Keith - how to know between office phone and regular phone?

John - this is a case where forking is used.

Hannes - where are we?

Marc - need to decide requirements - whether to decide if applicable to
i2, IMS, etc., or just SIP ECRIT.

Keith - If PSAP calls override forking, then you've got the general SIP
case.

Marc - why we mark the call.

Keith -=20

John - think there are solutions in that space.

John - what I've heard today is that you want to go back to original
device, but if you can't then, ______

Cullen - call back phone number or device?

Marc - in phonebcp, use the contact header

Cullen - then it's the device.

Keith - yes, the device.

Marc - more confusing or less?

Hannes - more confusing.

Hannes - not sure how to table this.

Summary assumption: messaging direction, forward vs. backward - might
take a different path, do we agree?

Marc - yes.

Hannes - If true, then it would be hard to store state at the entities.

Fixed phone or other device.

Hannes - So, callback can happpen during a definite amount of time.

Does it matter whether a callback is from any PSAP or the same PSAP.

Keith - 2 requirements then...

PSAPs can make ordinary calls or falls back to go on to ordinary
forking.

John - we've delivered two pieces of info contact the GRUU and the AoR
(From, or PAI).

Hannes - It works for me it needs to work for both.

John - would the requirement be met if it says it,

a. fails, then it can make a second call to ____

b. _____

Keith - getting into solutions

John -=20

Geoff - Be careful to putting too much automation (to not spring this on
them)

Marc - We don't have to build too much into this (no god status)

Geoff -=20

*Keith -=20

Geoff - think we're trying to get too much into the callback.

Hannes - to talk a little about possible solution helps some of us think
about what requirement

forking, IMS, other things.

John - point is if callback is addressed back to the original device,
then wouldn't be subject to call forwarding.

Keith - yes, if IP PSAP, not for CS connected PSAP.

Hannes - how would you scope it?

John - wouldn't need to scope it.

Keith - Still have a requirement in enterprise.

Marc - don't think we need to include legacy PSAPs.

Janet - in ISUP there are some specific call parameters that may mark it
as an emergency call.

Keith - for any requirement, let's say whether or not it's applicable to
a legacy PSAP.

Marc - if list traffic generated, then we'll discuss it at IETF77.

/end of discussion around callback

next topic, service URN draft

John - list issues one per email to the list.

Andrea - policy around approving service URNs

Cullen - IESG thought idea of expert review approval may not have
adequate level of expertise present.

Cullen - just a ontology exercise, something that may already exist
elsewhere, or from some other group.

/end.

















CONFIDENTIALITY NOTICE: The information contained in this message may be pr=
ivileged and/or confidential. If you are not the intended recipient, or res=
ponsible for delivering this message to the intended recipient, any review,=
 forwarding, dissemination, distribution or copying of this communication o=
r any attachment(s) is strictly prohibited. If you have received this messa=
ge in error, please notify the sender immediately, and delete it and all at=
tachments from your computer and network.

From hannes.tschofenig@nsn.com  Sat Feb 20 23:26:58 2010
Return-Path: <hannes.tschofenig@nsn.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 1DDF53A77A9 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:26:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level: 
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044,  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 0voBLuuu0QS3 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:26:57 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 107363A7D8D for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:26:56 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7Smpc016721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 08:28:48 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7Sm2l027277; Sun, 21 Feb 2010 08:28:48 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 08:28:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 09:27:25 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389173@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: COMMENT on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya2RdWSrzmPz3RdmvjyTQO2jm+g==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "Alexey Melnikov" <alexey.melnikov@isode.com>
X-OriginalArrivalTime: 21 Feb 2010 07:28:48.0280 (UTC) FILETIME=[8200B180:01CAB2C7]
Cc: ecrit@ietf.org
Subject: [Ecrit] COMMENT on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 07:26:58 -0000

Hi Alexey,=20

You wrote:=20

"This document only has 1 normative reference which is RFC 2119. I don't
believe
this is correct, several other references are needed to properly
understand
requirements. Please check which references are normative and which are
truly
informative.
"

When splitting the references into normative and informative my decision
making was guided by the question: "Do I need this document for an
interoperable implementation?" For draft-ietf-ecrit-location-hiding-req,
which focuses only on requirements, there is nothing to implement and
hence there are not really any normative references.=20

If the question is more "What do I have to know in order to better
understand the text in draft-ietf-ecrit-location-hiding-req?" then I
would have to add a lot of references, including those pointing to
informational RFCs (leading to DOWNREFs).  =20

The references are there. So, the reader is not prevented from looking
them up. However, I was wondering whether they have to be placed into
the normative part leading to all sort of dependency issues and
downrefs. =20

Ciao
Hannes

From hannes.tschofenig@nsn.com  Sat Feb 20 23:27:01 2010
Return-Path: <hannes.tschofenig@nsn.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 34F3528C0D8 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042,  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 8GQbVfRqWoxF for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:27:00 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0A16C28C0CF for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:26:59 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7Slxb016658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 08:28:47 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SlKn027235; Sun, 21 Feb 2010 08:28:47 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 08:28:46 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 09:27:19 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS  on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya3XpdZhB1FyqT8O5XHqIErjj1g==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-OriginalArrivalTime: 21 Feb 2010 07:28:46.0858 (UTC) FILETIME=[8127B6A0:01CAB2C7]
Cc: ecrit@ietf.org
Subject: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 07:27:01 -0000

Hi Dan,=20

You wrote:=20
"
I like the document and I belive that it's ready for approval, but I
have a
rather minor detail to clarify.

 Req-6:  The solution MUST work if PSAP boundaries have holes.  (For a
      discussion about holes in PSAP boundaries and their encoding the
      reader is referred to [I-D.ietf-ecrit-specifying-holes].)

I do not see how the requirement can be understood without understanding
the
concept of holes in PSAP or LoST service boundaries. This being a MUST
requirement it looks to me like [I-D.ietf-ecrit-specifying-holes] should
be a
Normative rather than Informative reference.
"

[I-D.ietf-ecrit-specifying-holes] specifies one specific way of encoding
holes in PSAP boundaries but the requirement itself is independent of
the chosen approach.=20

So, in that sense I would believe there is no normative dependency.
However, if someone does not know what "a hole in a PSAP boundary" means
then they should better read a document and there is only one document
they can read from the IETF ECRIT group that explains this aspect.=20

So, what you you suggest me to do?=20

Ciao
Hannes


From hannes.tschofenig@nsn.com  Sat Feb 20 23:27:02 2010
Return-Path: <hannes.tschofenig@nsn.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 580AE28C0D8 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040,  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 XXAqb0tK6+Kt for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:27:01 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 4C5D828C0CF for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:27:01 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SpjY017347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 08:28:51 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SoQX027352; Sun, 21 Feb 2010 08:28:50 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 08:28:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 09:27:16 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450238916B@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: COMMENT on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya2ioeV449NEbRfux8hB7De4TxA==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Jari Arkko" <jari.arkko@piuha.net>
X-OriginalArrivalTime: 21 Feb 2010 07:28:50.0718 (UTC) FILETIME=[8374B3E0:01CAB2C7]
Cc: ecrit@ietf.org
Subject: [Ecrit] COMMENT on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 07:27:02 -0000

Hi Jari,=20

You wrote:=20
"
The document says:

   Req-3:  The solution MUST offer automated discovery of servers and
   other behavior, i.e., no manual configuration can be assumed.

I am confused by the phrase "other behaviour" in this context. Perhaps
you should rewrite this to: "... automated discovery of servers and
other
necessary configuration information ..."
"

Your suggestion makes a lot of sense to me. Thanks.=20

Ciao
Hannes


From hannes.tschofenig@nsn.com  Sat Feb 20 23:30:19 2010
Return-Path: <hannes.tschofenig@nsn.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 D0A6D28C0ED for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  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 SGknp42sZBVY for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:30:18 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DE25328C0DD for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:30:17 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SpQm016817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 08:28:52 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7Sp1x027361; Sun, 21 Feb 2010 08:28:51 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 08:28:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 09:27:19 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450238916C@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: GenART Telechat review of draft-ietf-ecrit-location-hiding-req-02
Thread-Index: AcqvT22EAGL9MOrkR2m5ssox4nkwNwDGEcwQ
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Ben Campbell" <ben@estacado.net>
X-OriginalArrivalTime: 21 Feb 2010 07:28:51.0233 (UTC) FILETIME=[83C34910:01CAB2C7]
Cc: ecrit@ietf.org
Subject: [Ecrit] FW: GenART Telechat review of draft-ietf-ecrit-location-hiding-req-02
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: Sun, 21 Feb 2010 07:30:19 -0000

Thanks for your review, Ben.=20

Let me provide a response below.=20

>-----Original Message-----
>From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
>Behalf Of ext Ben Campbell
>Sent: 16 February, 2010 23:31
>To: hgs+ecrit@cs.columbia.edu; Laura.Liess@t-systems.com;=20
>Hannes Tschofenig; barbara.stark@att.com;=20
>andres.kytt@skype.net; General Area Review Team
>Cc: Cullen Jennings; marc.linsner@cisco.com; IETF-Discussion list
>Subject: GenART Telechat review of=20
>draft-ietf-ecrit-location-hiding-req-02
>
>I have been selected as the General Area Review Team (Gen-ART)=20
>reviewer for this draft (for background on Gen-ART, please see=20
>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
>Please wait for direction from your document shepherd or AD=20
>before posting a new version of the draft.
>
>Document: draft-ietf-ecrit-location-hiding-req-02
>Reviewer: Ben Campbell
>Review Date: 16 Feb 2010
>IESG Telechat date: 18 Feb 2010
>
>Summary: This draft is really close to ready for publication=20
>as an informational RFC. I have one unaddressed editorial=20
>comment, which on reflection I am promoting to a minor issue,=20
>as well as a few more editorial comments that should probably=20
>not block publication.
>
>Major issues:
>Minor issues:
>
>-- section 3.3, first bullet:
>
>I'm still a little confused by seeing a normative MUST in a=20
>section entitled "Desirable Properties". If it's really a=20
>MUST, then perhaps it should be promoted to a bona-fide=20
>requirement? Otherwise, perhaps it should be a SHOULD?

That was probably my mistake from an English point of view.=20
I changed it to "Miscellaneous Properties".=20

>
>Nits/editorial comments:
>
>-- Req-10:  The solution MUST allow the end host to determine=20
>PSAP/ESRP URLs prior to the call, for all emergency services.
>
>Who is the "end host"?

Your laptop, your mobile phone, your desktop PC, your Internet tablet,
...
Do you think I should add something like "end host (such as a laptop or
a mobile phone)" to clarify this issue?=20

>
>-- section 3.3, third bullet:
>
>s/"...break by the presence..."/"...break in the presence..." =20
>  [or "...be broken by the presence..."]
>
Fixed.=20

>
>-- idnits has some new things to say. (I suspect the=20
>boilerplate complaints have to do with the paragraphs=20
>splitting across page breaks.)
>
>> tmp/draft-ietf-ecrit-location-hiding-req-02.txt:
>>=20
>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>   http://trustee.ietf.org/license-info):
>>  =20
>>=20
>----------------------------------------------------------------------
>> ------
>>=20
>>   ** The document seems to lack a License Notice according IETF Trust
>>      Provisions of 28 Dec 2009, Section 6.b.i or Provisions=20
>of 12 Sep 2009
>>      Section 6.b -- however, there's a paragraph with a=20
>matching beginning.
>>      Boilerplate error?
>>=20
>>      (You're using the IETF Trust Provisions' Section 6.b=20
>License Notice from
>>      12 Feb 2009 rather than one of the newer Notices.  See
>>      http://trustee.ietf.org/license-info/.)
>>=20
>>=20
>>   Checking nits according to=20
>http://www.ietf.org/ietf/1id-guidelines.txt:
>>  =20
>>=20
>----------------------------------------------------------------------
>> ------
>>=20
>>      No issues found here.
>>=20
>>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>>  =20
>>=20
>----------------------------------------------------------------------
>> ------
>>=20
>>      No issues found here.
>>=20
>>   Miscellaneous warnings:
>>  =20
>>=20
>----------------------------------------------------------------------
>> ------
>>=20
>>   =3D=3D The copyright year in the IETF Trust and authors=20
>Copyright Line does not
>>      match the current year
>>=20
>>   =3D=3D The document seems to lack the recommended RFC 2119=20
>boilerplate, even if
>>      it appears to use RFC 2119 keywords -- however, there's=20
>a paragraph with
>>      a matching beginning. Boilerplate error?
>>=20
>>      (The document does seem to have the reference to RFC=20
>2119 which the
>>      ID-Checklist requires).
>>   =3D=3D The document seems to lack a disclaimer for pre-RFC5378=20
>work, but was
>>      first submitted before 10 November 2008.  Should you=20
>add the disclaimer?
>>      (See the Legal Provisions document at
>>      http://trustee.ietf.org/license-info for more information.).=20
>>=20
>>=20
>>   Checking references for intended status: Informational
>>  =20
>>=20
>----------------------------------------------------------------------
>> ------
>>=20
>>   =3D=3D Outdated reference: A later version (-10) exists of
>>      draft-ietf-geopriv-l7-lcp-ps-09
>>=20
>>   =3D=3D Outdated reference: A later version (-10) exists of
>>      draft-ietf-ecrit-framework-09
>>=20
>>   =3D=3D Outdated reference: A later version (-09) exists of
>>      draft-ietf-geopriv-lbyr-requirements-07
>>=20
>>   =3D=3D Outdated reference: A later version (-16) exists of
>>      draft-ietf-geopriv-http-location-delivery-15
>>=20
>>=20
>>      Summary: 1 error (**), 7 warnings (=3D=3D), 0 comments (--).
>>=20
>>      Run idnits with the --verbose option for more detailed=20
>information about
>>      the items above.
>>=20
>>=20
>

Fixed the indicated references and update IPR template.=20

Ciao
Hannes

From hannes.tschofenig@nsn.com  Sat Feb 20 23:32:54 2010
Return-Path: <hannes.tschofenig@nsn.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 F082628B797 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037,  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 laljaiwVp8Vq for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:32:54 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id F33B83A7616 for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:32:53 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SqJf016821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ecrit@ietf.org>; Sun, 21 Feb 2010 08:28:52 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7Sp21027361 for <ecrit@ietf.org>; Sun, 21 Feb 2010 08:28:52 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 08:28:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 09:27:25 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389172@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IESG Feedback for draft-ietf-ecrit-location-hiding-req
Thread-Index: AcqyaxUXa+3NFPUeQi2cI+8ZBf94fQ==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <ecrit@ietf.org>
X-OriginalArrivalTime: 21 Feb 2010 07:28:51.0812 (UTC) FILETIME=[841BA240:01CAB2C7]
Subject: [Ecrit] IESG Feedback for draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 07:32:55 -0000

Hi all,=20

as our documents progress through the IESG we get our feedback. This
time the location hiding requirments document got reviewed. Responding
to the comments I will put the WG on CC. Share your thoughts with my
response.=20

The feedback is here:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-hiding-req/

Ciao
Hannes


From dromasca@avaya.com  Sat Feb 20 23:44:38 2010
Return-Path: <dromasca@avaya.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 CACED3A7C41 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061,  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 QsQNzSIpQwMA for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:44:38 -0800 (PST)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id C1A503A6825 for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:44:37 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,511,1262581200";  d="scan'208";a="4555873"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 21 Feb 2010 02:46:30 -0500
X-IronPort-AV: E=Sophos;i="4.49,511,1262581200"; d="scan'208";a="448040986"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Feb 2010 02:46:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 08:46:06 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS  on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya3XpdZhB1FyqT8O5XHqIErjj1gAXeVVw
References: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 07:44:38 -0000

=20

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)=20
> [mailto:hannes.tschofenig@nsn.com]=20
> Sent: Sunday, February 21, 2010 9:27 AM
> To: Romascanu, Dan (Dan)
> Cc: ecrit@ietf.org
> Subject: DISCUSS on draft-ietf-ecrit-location-hiding-req
>=20
> Hi Dan,=20
>=20
> You wrote:=20
> "
> I like the document and I belive that it's ready for=20
> approval, but I have a rather minor detail to clarify.
>=20
>  Req-6:  The solution MUST work if PSAP boundaries have holes.  (For a
>       discussion about holes in PSAP boundaries and their encoding the
>       reader is referred to [I-D.ietf-ecrit-specifying-holes].)
>=20
> I do not see how the requirement can be understood without=20
> understanding the concept of holes in PSAP or LoST service=20
> boundaries. This being a MUST requirement it looks to me like=20
> [I-D.ietf-ecrit-specifying-holes] should be a Normative=20
> rather than Informative reference.
> "
>=20
> [I-D.ietf-ecrit-specifying-holes] specifies one specific way=20
> of encoding holes in PSAP boundaries but the requirement=20
> itself is independent of the chosen approach.=20
>=20
> So, in that sense I would believe there is no normative dependency.
> However, if someone does not know what "a hole in a PSAP=20
> boundary" means then they should better read a document and=20
> there is only one document they can read from the IETF ECRIT=20
> group that explains this aspect.=20
>=20
> So, what you you suggest me to do?=20
>=20
> Ciao
> Hannes
>=20

Yes - the problem is that the document lacks a definition of what "a
hole in a PSAP  boundary" means. That 'one document they can read from
the IETF ECRIT group that explains this aspect' should be a normative
reference IMO. What document are we talking about -
[I-D.ietf-ecrit-specifying-holes] or something else? The alternative is
to define the term here.=20

Regards,

Dan

From James.Winterbottom@andrew.com  Sat Feb 20 23:49:42 2010
Return-Path: <James.Winterbottom@andrew.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 F23473A7B55 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 d+BoBYafhGOL for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:49:41 -0800 (PST)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E4E9E3A7B42 for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:49:40 -0800 (PST)
Received: from [10.86.20.103] ([10.86.20.103]:35633 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S12076791Ab0BUHve convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org>); Sun, 21 Feb 2010 01:51:34 -0600
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 21 Feb 2010 01:51:34 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 21 Feb 2010 15:51:32 +0800
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Date: Sun, 21 Feb 2010 15:50:12 +0800
Thread-Topic: DISCUSS  on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya3XpdZhB1FyqT8O5XHqIErjj1gAXeVVwAABJGiA=
Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DBE5310F@SISPE7MB1.commscope.com>
References: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net>, <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.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: 8BIT
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: James.Winterbottom@andrew.com
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 07:49:42 -0000

Holes in Polygons has been waiting for nearly 18 months to actually appear on an IESG telechat.
I don't know what the hold up has been, but hopefully the incoming AD for this area will speed things up a bit.. *hint* hint*

Cheers
James

________________________________________
From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) [dromasca@avaya.com]
Sent: Sunday, February 21, 2010 1:46 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:hannes.tschofenig@nsn.com]
> Sent: Sunday, February 21, 2010 9:27 AM
> To: Romascanu, Dan (Dan)
> Cc: ecrit@ietf.org
> Subject: DISCUSS on draft-ietf-ecrit-location-hiding-req
>
> Hi Dan,
>
> You wrote:
> "
> I like the document and I belive that it's ready for
> approval, but I have a rather minor detail to clarify.
>
>  Req-6:  The solution MUST work if PSAP boundaries have holes.  (For a
>       discussion about holes in PSAP boundaries and their encoding the
>       reader is referred to [I-D.ietf-ecrit-specifying-holes].)
>
> I do not see how the requirement can be understood without
> understanding the concept of holes in PSAP or LoST service
> boundaries. This being a MUST requirement it looks to me like
> [I-D.ietf-ecrit-specifying-holes] should be a Normative
> rather than Informative reference.
> "
>
> [I-D.ietf-ecrit-specifying-holes] specifies one specific way
> of encoding holes in PSAP boundaries but the requirement
> itself is independent of the chosen approach.
>
> So, in that sense I would believe there is no normative dependency.
> However, if someone does not know what "a hole in a PSAP
> boundary" means then they should better read a document and
> there is only one document they can read from the IETF ECRIT
> group that explains this aspect.
>
> So, what you you suggest me to do?
>
> Ciao
> Hannes
>

Yes - the problem is that the document lacks a definition of what "a
hole in a PSAP  boundary" means. That 'one document they can read from
the IETF ECRIT group that explains this aspect' should be a normative
reference IMO. What document are we talking about -
[I-D.ietf-ecrit-specifying-holes] or something else? The alternative is
to define the term here.

Regards,

Dan
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

From hannes.tschofenig@nsn.com  Sun Feb 21 00:15:49 2010
Return-Path: <hannes.tschofenig@nsn.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 6C63328C11E for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 00:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level: 
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035,  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 Wg5yrm9r7NTw for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 00:15:48 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5610D28C0FC for <ecrit@ietf.org>; Sun, 21 Feb 2010 00:15:46 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SlaM016671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 08:28:47 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L7SlKp027235; Sun, 21 Feb 2010 08:28:47 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 08:28:47 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 09:27:19 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450238916E@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS  on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya383u4Rj+LeJRz+YtV8tzvFVug==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <tim.polk@nist.gov>
X-OriginalArrivalTime: 21 Feb 2010 07:28:47.0405 (UTC) FILETIME=[817B2DD0:01CAB2C7]
Cc: ecrit@ietf.org
Subject: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 08:15:49 -0000

Hi Tim,=20

You wrote:=20
"
I may be missing something, but it seems that these requirements should
be in addition to the requirements specified in
[I-D.ietf-geopriv-lbyr-requirements].
The document does not say that anywhere, and the specification of
[I-D.ietf-geopriv-lbyr-requirements] as informative adds to my
confusion.
"

I guess I know where your comment comes from. You have looked at the
security consideration section and it essentially points to another
document and that document is only in the informative references
section.=20

I guess I have two options:=20
* move the reference into the normative section=20
* copy the text and adjust it

Did I correctly understood the root of your concern? What approach of
addressing your comment would you prefer?=20

Ciao
Hannes


From hannes.tschofenig@nsn.com  Sun Feb 21 01:24:38 2010
Return-Path: <hannes.tschofenig@nsn.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 3C7E23A80E5 for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 01:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032,  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 nlAH9rkiJJsT for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 01:24:37 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id BCAE83A7102 for <ecrit@ietf.org>; Sun, 21 Feb 2010 01:24:36 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1L8BRqY026888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 09:11:27 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1L8BLfQ023162; Sun, 21 Feb 2010 09:11:27 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 09:11:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 10:14:50 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389180@FIESEXC015.nsn-intra.net>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS  on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya3XpdZhB1FyqT8O5XHqIErjj1gAXeVVwAAEQJNA=
References: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net> <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-OriginalArrivalTime: 21 Feb 2010 08:11:24.0437 (UTC) FILETIME=[75974C50:01CAB2CD]
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 09:24:38 -0000

I did see the differentiation between normative and information in a
slightly different fashion, as I responded to Alexey.=20

With the holes document there would not necessarily be a problem to put
it into the normative dependency section but then I would have to follow
the suggestion by Alexey as well and the consequence is that there is a
large list of informative documents in the normative reference section
that only provide background on certain subjects.=20

I could, to address your specific comment, also add a sentence saying
what a "hole in a PSAP boundary" means.=20

Ciao
Hannes


>-----Original Message-----
>From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20
>Sent: 21 February, 2010 09:46
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: ecrit@ietf.org
>Subject: RE: DISCUSS on draft-ietf-ecrit-location-hiding-req
>
>=20
>
>> -----Original Message-----
>> From: Tschofenig, Hannes (NSN - FI/Espoo)=20
>> [mailto:hannes.tschofenig@nsn.com]
>> Sent: Sunday, February 21, 2010 9:27 AM
>> To: Romascanu, Dan (Dan)
>> Cc: ecrit@ietf.org
>> Subject: DISCUSS on draft-ietf-ecrit-location-hiding-req
>>=20
>> Hi Dan,
>>=20
>> You wrote:=20
>> "
>> I like the document and I belive that it's ready for approval, but I=20
>> have a rather minor detail to clarify.
>>=20
>>  Req-6:  The solution MUST work if PSAP boundaries have=20
>holes.  (For a
>>       discussion about holes in PSAP boundaries and their=20
>encoding the
>>       reader is referred to [I-D.ietf-ecrit-specifying-holes].)
>>=20
>> I do not see how the requirement can be understood without=20
>> understanding the concept of holes in PSAP or LoST service=20
>boundaries.=20
>> This being a MUST requirement it looks to me like=20
>> [I-D.ietf-ecrit-specifying-holes] should be a Normative rather than=20
>> Informative reference.
>> "
>>=20
>> [I-D.ietf-ecrit-specifying-holes] specifies one specific way of=20
>> encoding holes in PSAP boundaries but the requirement itself is=20
>> independent of the chosen approach.
>>=20
>> So, in that sense I would believe there is no normative dependency.
>> However, if someone does not know what "a hole in a PSAP boundary"=20
>> means then they should better read a document and there is only one=20
>> document they can read from the IETF ECRIT group that explains this=20
>> aspect.
>>=20
>> So, what you you suggest me to do?=20
>>=20
>> Ciao
>> Hannes
>>=20
>
>Yes - the problem is that the document lacks a definition of=20
>what "a hole in a PSAP  boundary" means. That 'one document=20
>they can read from the IETF ECRIT group that explains this=20
>aspect' should be a normative reference IMO. What document are=20
>we talking about - [I-D.ietf-ecrit-specifying-holes] or=20
>something else? The alternative is to define the term here.=20
>
>Regards,
>
>Dan
>

From dromasca@avaya.com  Sun Feb 21 05:06:21 2010
Return-Path: <dromasca@avaya.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 986BB28C125 for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  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 QkXLsk2sLcJY for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:06:20 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2E3BA28C0E0 for <ecrit@ietf.org>; Sun, 21 Feb 2010 05:06:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,511,1262581200"; d="scan'208";a="177370255"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Feb 2010 08:08:12 -0500
X-IronPort-AV: E=Sophos;i="4.49,511,1262581200"; d="scan'208";a="448074081"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Feb 2010 08:08:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 14:07:47 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401F8BCE0@307622ANEX5.global.avaya.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502389180@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS  on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya3XpdZhB1FyqT8O5XHqIErjj1gAXeVVwAAEQJNAAChXVUA==
References: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net> <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com> <3D3C75174CB95F42AD6BCC56E5555B4502389180@FIESEXC015.nsn-intra.net>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 13:06:21 -0000

Hannes,=20

I can go with the later proposal. The rough rule of thumb in such
situations is that if a reference is needed in order to understand the
document in review than this reference should be normative. In this case
adding a sentence that explains what a "hole in a PSAP boundary" means
would eliminate the need for another document where a definition of the
hole can be found to be made a normative reference.=20

Dan



> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)=20
> [mailto:hannes.tschofenig@nsn.com]=20
> Sent: Sunday, February 21, 2010 10:15 AM
> To: Romascanu, Dan (Dan)
> Cc: ecrit@ietf.org
> Subject: RE: DISCUSS on draft-ietf-ecrit-location-hiding-req
>=20
> I did see the differentiation between normative and=20
> information in a slightly different fashion, as I responded=20
> to Alexey.=20
>=20
> With the holes document there would not necessarily be a=20
> problem to put it into the normative dependency section but=20
> then I would have to follow the suggestion by Alexey as well=20
> and the consequence is that there is a large list of=20
> informative documents in the normative reference section that=20
> only provide background on certain subjects.=20
>=20
> I could, to address your specific comment, also add a=20
> sentence saying what a "hole in a PSAP boundary" means.=20
>=20
> Ciao
> Hannes
>=20
>=20
> >-----Original Message-----
> >From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> >Sent: 21 February, 2010 09:46
> >To: Tschofenig, Hannes (NSN - FI/Espoo)
> >Cc: ecrit@ietf.org
> >Subject: RE: DISCUSS on draft-ietf-ecrit-location-hiding-req
> >
> >=20
> >
> >> -----Original Message-----
> >> From: Tschofenig, Hannes (NSN - FI/Espoo)=20
> >> [mailto:hannes.tschofenig@nsn.com]
> >> Sent: Sunday, February 21, 2010 9:27 AM
> >> To: Romascanu, Dan (Dan)
> >> Cc: ecrit@ietf.org
> >> Subject: DISCUSS on draft-ietf-ecrit-location-hiding-req
> >>=20
> >> Hi Dan,
> >>=20
> >> You wrote:=20
> >> "
> >> I like the document and I belive that it's ready for=20
> approval, but I=20
> >> have a rather minor detail to clarify.
> >>=20
> >>  Req-6:  The solution MUST work if PSAP boundaries have
> >holes.  (For a
> >>       discussion about holes in PSAP boundaries and their
> >encoding the
> >>       reader is referred to [I-D.ietf-ecrit-specifying-holes].)
> >>=20
> >> I do not see how the requirement can be understood without=20
> >> understanding the concept of holes in PSAP or LoST service
> >boundaries.=20
> >> This being a MUST requirement it looks to me like=20
> >> [I-D.ietf-ecrit-specifying-holes] should be a Normative=20
> rather than=20
> >> Informative reference.
> >> "
> >>=20
> >> [I-D.ietf-ecrit-specifying-holes] specifies one specific way of=20
> >> encoding holes in PSAP boundaries but the requirement itself is=20
> >> independent of the chosen approach.
> >>=20
> >> So, in that sense I would believe there is no normative dependency.
> >> However, if someone does not know what "a hole in a PSAP boundary"=20
> >> means then they should better read a document and there is=20
> only one=20
> >> document they can read from the IETF ECRIT group that=20
> explains this=20
> >> aspect.
> >>=20
> >> So, what you you suggest me to do?=20
> >>=20
> >> Ciao
> >> Hannes
> >>=20
> >
> >Yes - the problem is that the document lacks a definition of what "a=20
> >hole in a PSAP  boundary" means. That 'one document they can=20
> read from=20
> >the IETF ECRIT group that explains this aspect' should be a=20
> normative=20
> >reference IMO. What document are we talking about -=20
> >[I-D.ietf-ecrit-specifying-holes] or something else? The=20
> alternative is=20
> >to define the term here.
> >
> >Regards,
> >
> >Dan
> >
>=20

From hannes.tschofenig@nsn.com  Sun Feb 21 05:18:14 2010
Return-Path: <hannes.tschofenig@nsn.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 E011D28C1CF for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030,  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 nBh7EPKGZrF4 for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:18:10 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9A54C28C13A for <ecrit@ietf.org>; Sun, 21 Feb 2010 05:18:09 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1LDJw5T021697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 14:19:58 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1LDJwDv031180; Sun, 21 Feb 2010 14:19:58 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 14:19:57 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 15:24:15 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389211@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ecrit-rough-loc-01
Thread-Index: Acqy6QXSxqEnuh+eTemNQE54qT5iAQ==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "Richard Barnes" <richard.barnes@gmail.com>, "Matt Lepinski" <mlepinski@bbn.com>
X-OriginalArrivalTime: 21 Feb 2010 13:19:57.0940 (UTC) FILETIME=[907FAB40:01CAB2F8]
Cc: ecrit@ietf.org
Subject: [Ecrit] draft-ietf-ecrit-rough-loc-01
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: Sun, 21 Feb 2010 13:18:14 -0000

Hi Richard, Hi Matt,=20

preparing the PROTO writeup I noticed the following issues with the
document:=20

* Document structure:=20

I don't understand why "Location filtering" is a sub-section of
"Determining sufficient location precision". Section "Civic address
considerations" is the only sub-section and this typically does not look
good.=20

I would create the following structure:=20

   3. The Need for Location
   4. The Location Filter Concept
   4.1. Introducing Location Filters
   4.2. Constructing Location Filters
        (including civic address considerations)
   4.3.  Maintaining Location Filters
   4.4.  Applying Location Filters

I wonder whether is so clear to the reader why the LIS has to create the
location filter in a way that it has to consider all the emergency
services.=20

The description of the non-emergency services use case is a bit
confusing, I believe. We focused with our discussion on the emergency
services case.=20

* Implementation:

Section 3.2 provides a pseudo-algorithm for the location filter concept.

Have you tried to implement the proposed mechanism to increase our
confidence?=20

* License:=20

  =3D=3D You're using the IETF Trust Provisions' Section 6.b License =
Notice
from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

* References:=20

I don't think that this reference is mandatory and hence putting it into
the informative section would be just fine:

   [4]   Wolf, K., "Location-to-Service Translation Protocol (LoST)
         Extension: ServiceListBoundary",
         draft-ietf-ecrit-lost-servicelistboundary-01 (work in
         progress), November 2009.


There are a few references out of date, such as:

   [7]   Schulzrinne, H., "Location-to-URL Mapping Architecture and
         Framework", draft-ietf-ecrit-mapping-arch-04
<http://tools.ietf.org/html/draft-ietf-ecrit-mapping-arch-04>  (work in
         progress), March 2009.


The reference section should also point to the requirements document.=20
=20

* A few comments on the content:=20

"
   In
   addition, when that location is provided to the endpoint, the
   endpoint is able to verify that the location is correct (to the
   extent of the endpoint's knowledge of its own location) prior to an
   emergency call, and is able to perform emergency call routing
   functions on its own, providing redundancy for network-provided
   functions.
"

I don't think we expect the human to check the location.=20
The advantage of having location information at the end host is to allow
him to=20
* learn about the available emergency service numbers available to that
specific region, and (as discussed more extensively end of last year) to

* route the emergency call directly to the PSAP (potentially without any
involvement of the VSP/ASP).=20


"=20
       The location SHOULD be sufficiently precise that a LoST request
       with the location and any service URN will return a unique URI
       mapping value.
"

You should better say "any emergency service URN" since non-emergency
service URNs may be treated entirely different. The same is true for
item 2 in your list. =20


* Editorial:=20

Please look at the subject headings and use capitalized characters.
Example: s/Location filtering/Location Filtering

This will save the RFC editor time.=20

s/"A filter
   can used to determine whether a location is usable for emergency call
   routing in the following way:"/"A filter
   can be used to determine whether a location is usable for emergency
call
   routing in the following way:"

Please replace the term "Target" with the term "Device" in the security
consideration section based on the discussions we had in the lo-sec
document.=20

"At the same time,
   because endpoints can roam between networks, it is not generally
   possible to have strong client authentication for LCPs.
"

I would write "operationally difficult" rather than "not generally
possible".=20

-- invalid vs. valid
"
   With each service-to-URI mapping, a LoST query provides a service
   boundary that represents the set of locations in which that mapping
   is valid.=20
"

Don't talk about "valid" as there is a special semantic attached to that
word.=20

Instead, the response to the LoST query contains a <serviceBoundary>
element that can be used by the recipient as a hint to skip subsequent
queries for the same Service URN when the location falls within the
indicated service boundary.=20

"
A consequence of this is that given a set of service
   boundaries for different services, the intersection of those service
   boundaries is the region in which two mappings are valid.
"

This sentence is a bit wrong. At least you shouldn't say "two mappings"
in the later part of the sentence when you start generically.=20

s/"then the
   intersection is the are where both of these mappings are valid"/then
the
   intersection is the area where both of these mappings are valid"



* Acknowledgements

Weren't there more reviewers? Not many people are listed.=20

Ciao
Hannes

From hannes.tschofenig@nsn.com  Sun Feb 21 05:22:35 2010
Return-Path: <hannes.tschofenig@nsn.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 57D6328C13A for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030,  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 8-7lI+u14Q6T for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:22:34 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5ECD728C0EB for <ecrit@ietf.org>; Sun, 21 Feb 2010 05:22:33 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1LDOQEn030433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 14:24:26 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1LDOQU3009420; Sun, 21 Feb 2010 14:24:26 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 14:24:25 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 15:28:44 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389212@FIESEXC015.nsn-intra.net>
In-Reply-To: <4B8129BC.4010603@isode.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: COMMENT on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqy8xqDCBtVOrvKRTq3izB7eREtswABqC4Q
References: <3D3C75174CB95F42AD6BCC56E5555B4502389173@FIESEXC015.nsn-intra.net> <4B8129BC.4010603@isode.com>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Alexey Melnikov" <alexey.melnikov@isode.com>
X-OriginalArrivalTime: 21 Feb 2010 13:24:25.0383 (UTC) FILETIME=[2FE83B70:01CAB2F9]
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] COMMENT on draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 13:22:35 -0000

OK.=20


>The document is already Informational, so there are no issues=20
>with donwrefs.

You are right.=20


From hannes.tschofenig@nsn.com  Sun Feb 21 05:33:05 2010
Return-Path: <hannes.tschofenig@nsn.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 8A7CF28C1C1 for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:33:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level: 
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028,  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 id8qK9-CCoQr for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 05:33:04 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 738DA28C1E3 for <ecrit@ietf.org>; Sun, 21 Feb 2010 05:33:04 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1LDYuZB009345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 14:34:56 +0100
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1LDYuts012487; Sun, 21 Feb 2010 14:34:56 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 14:34:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 15:35:47 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389214@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ecrit-lost-servicelistboundary-02
Thread-Index: Acqy2i/V3psrYv+FQlC2Z6gGi3PaNg==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "Karl Heinz Wolf" <karlheinz.wolf@nic.at>
X-OriginalArrivalTime: 21 Feb 2010 13:34:56.0275 (UTC) FILETIME=[A7F2B630:01CAB2FA]
Cc: ecrit@ietf.org
Subject: [Ecrit] draft-ietf-ecrit-lost-servicelistboundary-02
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: Sun, 21 Feb 2010 13:33:05 -0000

Hi Karl Heinz,=20

Preparing the PROTO writeup I noticed the following issues with the
document:=20

* References: I believe RFC 5582 should be moved to the informative
references since it is not required for the implementation of this
specification and it would lead to a DOWNREF.=20

* Relax NG Schema: Given that you have a fairly complex Relax NG schema
in the document I was wondering whether you have solicited feedback from
the XML directorate?=20

I also had a question regarding the include statement and whether it
wouldn't be possible to reference the LoST schema here by URL rather
than by filename.=20

* Editorial bugs. There are bunch of editorial issues in the document
and I was wondering whether you have asked a native speaker to have a
quick look at it (so that the RFC editor does not have all the work in
the end).=20

* ID nits: I ran the document through the IDNITs tool and it reported a
few issues:=20
http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-ec=
r
it-lost-servicelistboundary-02.txt

(including old license statement, no intended status of the document,
...)

* Document title: it seems that the document title does not fit nicely
into the IETF ECRIT WG charter page. I would suggest to change it to
"LoST Service List Boundary Extension".=20

Ciao
Hannes

From root@core3.amsl.com  Sun Feb 21 06:45:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 08E0528C1D8; Sun, 21 Feb 2010 06:45:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100221144502.08E0528C1D8@core3.amsl.com>
Date: Sun, 21 Feb 2010 06:45:02 -0800 (PST)
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-location-hiding-req-03.txt
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: Sun, 21 Feb 2010 14:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.


	Title           : Location Hiding: Problem Statement and Requirements
	Author(s)       : H. Schulzrinne, et al.
	Filename        : draft-ietf-ecrit-location-hiding-req-03.txt
	Pages           : 11
	Date            : 2010-02-21

The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by
access networks to end points or VoIP service providers in order to
determine the correct dial string and information to route the call
to a Public Safety Answering Point (PSAP).  For determining the PSAP
Uniform Resource Identifier (URI) the usage of the Location-to-
Service Translation (LoST) Protocol is envisioned.

This document provides a problem statement and lists requirements for
situations where the Internet Access Provider (IAP) and/or the
Internet Service Provider (ISP) are only willing to disclose limited
or no location information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ecrit-location-hiding-req-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-02-21063148.I-D@ietf.org>


--NextPart--

From Hannes.Tschofenig@gmx.net  Sun Feb 21 07:16:04 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 10F5C3A7C92 for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 07:16:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 c7xEa4Ag9dEN for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 07:16:03 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B2A0C3A7B31 for <ecrit@ietf.org>; Sun, 21 Feb 2010 07:16:02 -0800 (PST)
Received: (qmail invoked by alias); 21 Feb 2010 15:17:56 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp070) with SMTP; 21 Feb 2010 16:17:56 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19F7cMt0zFFZdzWNUzqq7UyKIKJyklxc2OfFQOCnq 5moutg7KaLXhxO
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: "'Karl Heinz Wolf'" <karlheinz.wolf@nic.at>
Date: Sun, 21 Feb 2010 17:22:14 +0200
Message-ID: <000001cab309$a69a2d40$04ffa8c0@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acqy2i/V3psrYv+FQlC2Z6gGi3PaNg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.55000000000000004
Cc: ecrit@ietf.org
Subject: [Ecrit] draft-ietf-ecrit-lost-servicelistboundary-02
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: Sun, 21 Feb 2010 15:16:04 -0000

Hi Karl Heinz, 

Preparing the PROTO writeup I noticed the following issues with the
document: 

* References: I believe RFC 5582 should be moved to the informative
references since it is not required for the implementation of this
specification and it would lead to a DOWNREF. 

* Relax NG Schema: Given that you have a fairly complex Relax NG schema in
the document I was wondering whether you have solicited feedback from the
XML directorate? 

I also had a question regarding the include statement and whether it
wouldn't be possible to reference the LoST schema here by URL rather than by
filename. 

* Editorial bugs. There are bunch of editorial issues in the document and I
was wondering whether you have asked a native speaker to have a quick look
at it (so that the RFC editor does not have all the work in the end). 

* ID nits: I ran the document through the IDNITs tool and it reported a few
issues: 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ecrit-l
ost-servicelistboundary-02.txt

(including old license statement, no intended status of the document, ...)

* Document title: it seems that the document title does not fit nicely into
the IETF ECRIT WG charter page. I would suggest to change it to "LoST
Service List Boundary Extension". 

Ciao
Hannes


From hannes.tschofenig@nsn.com  Sun Feb 21 07:19:25 2010
Return-Path: <hannes.tschofenig@nsn.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 DA2A828C10A for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 07:19:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level: 
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026,  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 gsqP4dTqywIj for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 07:19:23 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 6BE1528C143 for <ecrit@ietf.org>; Sun, 21 Feb 2010 07:19:15 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1LFL4Yh014559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2010 16:21:04 +0100
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1LFL36o012025; Sun, 21 Feb 2010 16:21:03 +0100
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Sun, 21 Feb 2010 16:21:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 21 Feb 2010 17:21:03 +0200
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502389233@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version of draft-ietf-ecrit-location-hiding-req
Thread-Index: AcqzCG0zo2aENuLFR62HJJAroD8USA==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>, "ext Alexey Melnikov" <alexey.melnikov@isode.com>, <tim.polk@nist.gov>
X-OriginalArrivalTime: 21 Feb 2010 15:21:03.0643 (UTC) FILETIME=[7B31F6B0:01CAB309]
Cc: ecrit@ietf.org
Subject: [Ecrit] New Version of draft-ietf-ecrit-location-hiding-req
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: Sun, 21 Feb 2010 15:19:25 -0000

Based on the feedback from Dan, Alexey, and Tim I have moved those
references necessary for the understanding of the document from the
informative to the normative part.=20

The updated draft version can be found here:=20
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req
-03.txt=20

Ciao
Hannes


From ben@estacado.net  Sun Feb 21 11:34:14 2010
Return-Path: <ben@estacado.net>
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 8E7FA3A824B for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 11:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.124
X-Spam-Level: 
X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475,  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 kI6-8GfYGiRW for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 11:34:13 -0800 (PST)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 5FD473A8198 for <ecrit@ietf.org>; Sun, 21 Feb 2010 11:34:13 -0800 (PST)
Received: from [10.0.1.12] (adsl-68-94-45-145.dsl.rcsntx.swbell.net [68.94.45.145]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o1LJa1F9004014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Feb 2010 13:36:06 -0600 (CST) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Ben Campbell <ben@estacado.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450238916C@FIESEXC015.nsn-intra.net>
Date: Sun, 21 Feb 2010 13:35:55 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <D438D3CB-F207-4D75-A5DC-D40736BE3B63@estacado.net>
References: <3D3C75174CB95F42AD6BCC56E5555B450238916C@FIESEXC015.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
X-Mailer: Apple Mail (2.1077)
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] GenART Telechat review of draft-ietf-ecrit-location-hiding-req-02
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: Sun, 21 Feb 2010 19:34:14 -0000

Thanks! I have one remaining comment. The rest are handled by your other =
comments.

On Feb 21, 2010, at 1:27 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

>>=20
>> I'm still a little confused by seeing a normative MUST in a=20
>> section entitled "Desirable Properties". If it's really a=20
>> MUST, then perhaps it should be promoted to a bona-fide=20
>> requirement? Otherwise, perhaps it should be a SHOULD?
>=20
> That was probably my mistake from an English point of view.=20
> I changed it to "Miscellaneous Properties".=20

Thanks, that helps, and I think it pushes it back down to an editorial =
comment.  But I still wonder why a normative requirement like this is =
not one of the labeled requirements. Right now, it's sort of like saying =
"We've got requirements A, B,C, 1, 2, 3, and this other thing".



From Hannes.Tschofenig@gmx.net  Sun Feb 21 11:44:44 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 6998728C0E1 for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 11:44:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 JU9M6eWS+pdp for <ecrit@core3.amsl.com>; Sun, 21 Feb 2010 11:44:43 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8DB3C3A6B67 for <ecrit@ietf.org>; Sun, 21 Feb 2010 11:44:42 -0800 (PST)
Received: (qmail 20840 invoked by uid 0); 21 Feb 2010 19:46:35 -0000
Received: from 88.115.222.204 by www001.gmx.net with HTTP; Sun, 21 Feb 2010 20:46:33 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 21 Feb 2010 20:46:33 +0100
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <D438D3CB-F207-4D75-A5DC-D40736BE3B63@estacado.net>
Message-ID: <20100221194633.52090@gmx.net>
MIME-Version: 1.0
References: <3D3C75174CB95F42AD6BCC56E5555B450238916C@FIESEXC015.nsn-intra.net> <D438D3CB-F207-4D75-A5DC-D40736BE3B63@estacado.net>
To: Ben Campbell <ben@estacado.net>, hannes.tschofenig@nsn.com
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX19O/U9KDKFO0ZjQ2c6qJekh06BFp4q4Zifb+d441C v7lCg9H8UzV723yU1LAtL7OGq9rqwV0PmKbA== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: q7u0eix8bUk7IcVQ8GknYkpsZ2hlN4rm
X-FuHaFi: 0.73999999999999999
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] GenART Telechat review of	draft-ietf-ecrit-location-hiding-req-02
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: Sun, 21 Feb 2010 19:44:44 -0000

> Thanks, that helps, and I think it pushes it back down to an editorial
> comment.  But I still wonder why a normative requirement like this is not one
> of the labeled requirements. Right now, it's sort of like saying "We've got
> requirements A, B,C, 1, 2, 3, and this other thing".


I looked at it again and the classification appears to be a bit arbitrary.
I changed it again and flattened the structure. 

I re-submitted a new version. 

Ciao
Hannes

From root@core3.amsl.com  Sun Feb 21 12:00:01 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id E43403A7349; Sun, 21 Feb 2010 12:00:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100221200001.E43403A7349@core3.amsl.com>
Date: Sun, 21 Feb 2010 12:00:01 -0800 (PST)
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-location-hiding-req-04.txt
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: Sun, 21 Feb 2010 20:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.


	Title           : Location Hiding: Problem Statement and Requirements
	Author(s)       : H. Schulzrinne, et al.
	Filename        : draft-ietf-ecrit-location-hiding-req-04.txt
	Pages           : 11
	Date            : 2010-02-21

The emergency services architecture developed in the IETF Emergency
Context Resolution with Internet Technology (ECRIT) working group
describes an architecture where location information is provided by
access networks to end points or VoIP service providers in order to
determine the correct dial string and information to route the call
to a Public Safety Answering Point (PSAP).  For determining the PSAP
Uniform Resource Identifier (URI) the usage of the Location-to-
Service Translation (LoST) Protocol is envisioned.

This document provides a problem statement and lists requirements for
situations where the Internet Access Provider (IAP) and/or the
Internet Service Provider (ISP) are only willing to disclose limited
or no location information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-hiding-req-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ecrit-location-hiding-req-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-02-21115254.I-D@ietf.org>


--NextPart--

From dromasca@avaya.com  Mon Feb 22 04:00:06 2010
Return-Path: <dromasca@avaya.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 0DCA128C29D for <ecrit@core3.amsl.com>; Mon, 22 Feb 2010 04:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063,  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 yF4sh2l0Bwgi for <ecrit@core3.amsl.com>; Mon, 22 Feb 2010 04:00:04 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EAA0D28C2B2 for <ecrit@ietf.org>; Mon, 22 Feb 2010 04:00:03 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,518,1262581200"; d="scan'208";a="177452594"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Feb 2010 07:02:00 -0500
X-IronPort-AV: E=Sophos;i="4.49,518,1262581200"; d="scan'208";a="448259813"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2010 07:01:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 22 Feb 2010 13:01:19 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401F8BE94@307622ANEX5.global.avaya.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502389233@FIESEXC015.nsn-intra.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version of draft-ietf-ecrit-location-hiding-req
Thread-Index: AcqzCG0zo2aENuLFR62HJJAroD8USAArj8Hg
References: <3D3C75174CB95F42AD6BCC56E5555B4502389233@FIESEXC015.nsn-intra.net>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "ext Alexey Melnikov" <alexey.melnikov@isode.com>, <tim.polk@nist.gov>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] New Version of draft-ietf-ecrit-location-hiding-req
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: Mon, 22 Feb 2010 12:00:06 -0000

I cleared my DISCUSS.=20

Thank you for addressing my concern.=20

Regards,

Dan
=20

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)=20
> [mailto:hannes.tschofenig@nsn.com]=20
> Sent: Sunday, February 21, 2010 5:21 PM
> To: Romascanu, Dan (Dan); ext Alexey Melnikov; tim.polk@nist.gov
> Cc: ecrit@ietf.org
> Subject: New Version of draft-ietf-ecrit-location-hiding-req
>=20
> Based on the feedback from Dan, Alexey, and Tim I have moved=20
> those references necessary for the understanding of the=20
> document from the informative to the normative part.=20
>=20
> The updated draft version can be found here:=20
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-location-
> hiding-req
> -03.txt=20
>=20
> Ciao
> Hannes
>=20
>=20

From rbarnes@bbn.com  Mon Feb 22 07:55:44 2010
Return-Path: <rbarnes@bbn.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 0A1BE28C2A0 for <ecrit@core3.amsl.com>; Mon, 22 Feb 2010 07:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.355
X-Spam-Level: 
X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_40=-0.185]
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 3II0JG1ys6fG for <ecrit@core3.amsl.com>; Mon, 22 Feb 2010 07:55:43 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 05F8C28C1D8 for <ecrit@ietf.org>; Mon, 22 Feb 2010 07:55:43 -0800 (PST)
Received: from [192.1.255.191] (helo=col-dhcp-192-1-255-191.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NjafF-000NoR-7U for ecrit@ietf.org; Mon, 22 Feb 2010 10:57:41 -0500
Message-Id: <61783270-7C60-40B9-B5B7-0C5A6A8FE686@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: ecrit@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 22 Feb 2010 10:57:40 -0500
X-Mailer: Apple Mail (2.936)
Subject: [Ecrit] Emergency Services Workshop 7 & 8: Save the Dates
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: Mon, 22 Feb 2010 15:55:44 -0000

Dear colleagues,

We're pleased to announce the dates and venues for the next two  
Emergency Services Workshops.

ESW7:
11-13 May 2010
College Park, MD, USA

ESW8:
20-22 September 2010
Berlin, Germany

As planning progresses, updated information will be posted to the ESW  
website:
<http://www.emergency-services-coordination.info/>

For both workshops, we invite talks of 30-60 minutes on topics related  
to IP emergency services.  Please send proposals for presentations to <esw-submit@googlegroups.com 
 >.

Background:
The Emergency Services Workshop series is an ongoing effort in the  
emergency services community to coordinate global standards and  
technologies for emergency calling and emergency notification. The  
primary focus of the workshop series is foster coordination among the  
many standards development organizations (SDOs) involved in emergency  
services as they all work toward a global solution for emergency  
communications using Internet technologies. In addition, the workshops  
try to bring in operational and regulatory perspectives on emergency  
services, so that these experiences and requirements can be  
incorporated into ongoing technical development processes.  
Participation is open  all stakeholders in the emergency  
communications system, including industry (e.g., equipment vendors or  
telecommunications companies) as well as government (e.g., regulatory  
bodies or emergency response  organizations).

Thanks for your interest,
The ESW Coordination Team

From wwwrun@core3.amsl.com  Wed Feb 24 11:16:01 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 0C0103A84D3; Wed, 24 Feb 2010 11:16:00 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20100224191601.0C0103A84D3@core3.amsl.com>
Date: Wed, 24 Feb 2010 11:16:00 -0800 (PST)
Cc: ecrit@ietf.org
Subject: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (Specifying Holes in LoST Service Boundaries) to Proposed Standard
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
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: Wed, 24 Feb 2010 19:16:02 -0000

The IESG has received a request from the Emergency Context Resolution 
with Internet Technologies WG (ecrit) to consider the following document:

- 'Specifying Holes in LoST Service Boundaries '
   <draft-ietf-ecrit-specifying-holes-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17331&rfc_flag=0


From wwwrun@core3.amsl.com  Wed Feb 24 14:19:57 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id C9A2628C0DE; Wed, 24 Feb 2010 14:19:57 -0800 (PST)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20100224221957.C9A2628C0DE@core3.amsl.com>
Date: Wed, 24 Feb 2010 14:19:57 -0800 (PST)
Cc: ecrit@ietf.org
Subject: [Ecrit] Last Call: draft-ietf-ecrit-framework (Framework for Emergency Calling using Internet Multimedia) to Informational RFC
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
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: Wed, 24 Feb 2010 22:19:58 -0000

The IESG has received a request from the Emergency Context Resolution 
with Internet Technologies WG (ecrit) to consider the following document:

- 'Framework for Emergency Calling using Internet Multimedia '
   <draft-ietf-ecrit-framework-10.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-10.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15438&rfc_flag=0


From apenniston@geo-comm.com  Thu Feb 25 09:17:39 2010
Return-Path: <apenniston@geo-comm.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 8176028C395 for <ecrit@core3.amsl.com>; Thu, 25 Feb 2010 09:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lHa-aKzQ6vcV for <ecrit@core3.amsl.com>; Thu, 25 Feb 2010 09:17:27 -0800 (PST)
Received: from mail.geo-comm.com (geo-comm.com [66.173.42.242]) by core3.amsl.com (Postfix) with ESMTP id E36CA28C1E4 for <ecrit@ietf.org>; Thu, 25 Feb 2010 09:17:26 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Feb 2010 11:19:25 -0600
Message-ID: <909A20ADCD98AD4FB9984A87063A560503C77BE0@exchange.geo-comm.local>
In-Reply-To: <20100224191601.0C0103A84D3@core3.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
Thread-Index: Acq1hjIu+BUi4yaGS2KFMd9pqd0ujwAtN6Kw
References: <20100224191601.0C0103A84D3@core3.amsl.com>
From: "Avery Penniston" <apenniston@geo-comm.com>
To: <James.Winterbottom@andrew.com>, <Martin.Thomson@andrew.com>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
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, 25 Feb 2010 17:17:40 -0000

Hello,

I had a couple of comments on draft-ietf-ecrit-specifying-holes:

1.) In figure 6 and 8 the <gml:interior> ring has its points specified
in a counterclockwise order, but I think the interior ring's points
should be ordered clockwise.  I believe it is common practice (and
perhaps even mandated) that the interior ring's point orientation should
be opposite orientation of the polygon's exterior ring point
orientation.  Since GML 3.1.1. and the [geoshape] document referenced in
the draft both define a surface's upward normal as counterclockwise this
would make the interior ring's orientation clockwise.=20

2.) The last paragraph on page 12 talks about storing holes as polygons
in a separate table.  I think this statement may be going a bit far in
specifying technology specific details.  In general, spatially enabled
databases support the notion of interior rings and can quickly calculate
polygon intersections, even between polygons that contain holes, without
the need for a secondary check against an exception table for hole
polygons. =20

Avery
apenniston@geo-comm.com




> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
> Of The IESG
> Sent: Wednesday, February 24, 2010 1:16 PM
> To: IETF-Announce
> Cc: ecrit@ietf.org
> Subject: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes
> (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
>=20
> The IESG has received a request from the Emergency Context Resolution
> with Internet Technologies WG (ecrit) to consider the following
> document:
>=20
> - 'Specifying Holes in LoST Service Boundaries '
>    <draft-ietf-ecrit-specifying-holes-01.txt> as a Proposed Standard
>=20
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to
the
> ietf@ietf.org mailing lists by 2010-03-10. Exceptionally,
> comments may be sent to iesg@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>=20
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-
> 01.txt
>=20
>=20
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=

> =3D17331&rfc_flag=3D0
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

From James.Winterbottom@andrew.com  Thu Feb 25 10:31:16 2010
Return-Path: <James.Winterbottom@andrew.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 4450C3A8709 for <ecrit@core3.amsl.com>; Thu, 25 Feb 2010 10:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.803
X-Spam-Level: 
X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_00=-2.599, FRT_PENIS1=3.592]
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 Wf9ribpe4V+k for <ecrit@core3.amsl.com>; Thu, 25 Feb 2010 10:31:15 -0800 (PST)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 558CF3A870B for <ecrit@ietf.org>; Thu, 25 Feb 2010 10:31:15 -0800 (PST)
Received: from [10.86.20.103] ([10.86.20.103]:55390 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S109668Ab0BYSd0 convert rfc822-to-8bit (ORCPT <rfc822;ecrit@ietf.org>); Thu, 25 Feb 2010 12:33:26 -0600
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 25 Feb 2010 12:33:26 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 26 Feb 2010 02:33:24 +0800
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: Avery Penniston <apenniston@geo-comm.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Date: Fri, 26 Feb 2010 02:30:26 +0800
Thread-Topic: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
Thread-Index: Acq1hjIu+BUi4yaGS2KFMd9pqd0ujwAtN6KwAANiSIg=
Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DBE53120@SISPE7MB1.commscope.com>
References: <20100224191601.0C0103A84D3@core3.amsl.com>, <909A20ADCD98AD4FB9984A87063A560503C77BE0@exchange.geo-comm.local>
In-Reply-To: <909A20ADCD98AD4FB9984A87063A560503C77BE0@exchange.geo-comm.local>
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: 8BIT
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: James.Winterbottom@andrew.com
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
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, 25 Feb 2010 18:31:16 -0000

Hi Avery,

Thanks for your comments.
If we have a counterclockwise ring then you are right, this is wrong. I will take a look.

It has been so long since this draft left the WG that I will need to go and look at separate table comment. I do recall that when we wrote the draft we were asked to provide some guidance as to how the presence or holes might be checked for.

Cheers
James

________________________________________
From: Avery Penniston [apenniston@geo-comm.com]
Sent: Thursday, February 25, 2010 11:19 AM
To: Winterbottom, James; Thomson, Martin
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard

Hello,

I had a couple of comments on draft-ietf-ecrit-specifying-holes:

1.) In figure 6 and 8 the <gml:interior> ring has its points specified
in a counterclockwise order, but I think the interior ring's points
should be ordered clockwise.  I believe it is common practice (and
perhaps even mandated) that the interior ring's point orientation should
be opposite orientation of the polygon's exterior ring point
orientation.  Since GML 3.1.1. and the [geoshape] document referenced in
the draft both define a surface's upward normal as counterclockwise this
would make the interior ring's orientation clockwise.

2.) The last paragraph on page 12 talks about storing holes as polygons
in a separate table.  I think this statement may be going a bit far in
specifying technology specific details.  In general, spatially enabled
databases support the notion of interior rings and can quickly calculate
polygon intersections, even between polygons that contain holes, without
the need for a secondary check against an exception table for hole
polygons.

Avery
apenniston@geo-comm.com




> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
> Of The IESG
> Sent: Wednesday, February 24, 2010 1:16 PM
> To: IETF-Announce
> Cc: ecrit@ietf.org
> Subject: [Ecrit] Last Call: draft-ietf-ecrit-specifying-holes
> (SpecifyingHoles in LoST Service Boundaries) to Proposed Standard
>
> The IESG has received a request from the Emergency Context Resolution
> with Internet Technologies WG (ecrit) to consider the following
> document:
>
> - 'Specifying Holes in LoST Service Boundaries '
>    <draft-ietf-ecrit-specifying-holes-01.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to
the
> ietf@ietf.org mailing lists by 2010-03-10. Exceptionally,
> comments may be sent to iesg@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-
> 01.txt
>
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> =17331&rfc_flag=0
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

From khwolf1@gmail.com  Fri Feb 26 04:37:20 2010
Return-Path: <khwolf1@gmail.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 1AF1A28C166 for <ecrit@core3.amsl.com>; Fri, 26 Feb 2010 04:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 ys0+BBKfFNpN for <ecrit@core3.amsl.com>; Fri, 26 Feb 2010 04:37:19 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E90CD28C118 for <ecrit@ietf.org>; Fri, 26 Feb 2010 04:37:18 -0800 (PST)
Received: by pwi3 with SMTP id 3so14693pwi.31 for <ecrit@ietf.org>; Fri, 26 Feb 2010 04:39:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=TWy3p5NbvuHQ5hkjuiMApcVCkZZFJEKbTGmc0yE1lag=; b=Ly/2z5OR65iZnOHyQ9FZI8l3NeaGywSEAunM6LxCEg9fy92JOzgnaOiFr13VOYj2ju KdHtCSes8c/2n/bX8wcaIadkb9Vwpv/FifLrWlQr6nXwlEtqP1/JlPV2RdMF7uPxdK07 7nl8dPjNtJsNjqkTsThvR5ZdZL+bIUcATmb5Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=e5RyBnRfJX06i3ycw648wW8p62CRLVtKlGimq5WMWTAgmqUOKNn3Pv7B6LBNTFIkc8 NDIqKni69OpUCYCbJMPXukp532wjEdRcpx5WxNraxU4f1Pm4+/fDpbI0uepEUX4Hydxp XtcloD1W/q1NbTMdJLbvhFp0J3S+Mh9JFENxw=
MIME-Version: 1.0
Received: by 10.140.251.11 with SMTP id y11mr177089rvh.96.1267187970909; Fri,  26 Feb 2010 04:39:30 -0800 (PST)
In-Reply-To: <000001cab309$a69a2d40$04ffa8c0@nsnintra.net>
References: <Acqy2i/V3psrYv+FQlC2Z6gGi3PaNg==> <000001cab309$a69a2d40$04ffa8c0@nsnintra.net>
Date: Fri, 26 Feb 2010 13:39:30 +0100
Message-ID: <f77644531002260439s488414dase4d109978bfc354a@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: ECRIT <ecrit@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Ecrit] draft-ietf-ecrit-lost-servicelistboundary-02
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: Fri, 26 Feb 2010 12:37:20 -0000

Hannes,

I have already incorporated your comments into the draft for the next
update. Thank you for requesting a review at the XML directorate -
I'll wait for their feedback before I submit a new version.

karl heinz

On Sun, Feb 21, 2010 at 4:22 PM, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net> wrote:
> * References: I believe RFC 5582 should be moved to the informative
> references since it is not required for the implementation of this
> specification and it would lead to a DOWNREF.

I moved the reference.

>
> * Relax NG Schema: Given that you have a fairly complex Relax NG schema in
> the document I was wondering whether you have solicited feedback from the
> XML directorate?
>
> I also had a question regarding the include statement and whether it
> wouldn't be possible to reference the LoST schema here by URL rather than by
> filename.

I used the same include statement like you in the LoST-sync document.

>
> * Editorial bugs. There are bunch of editorial issues in the document and I
> was wondering whether you have asked a native speaker to have a quick look
> at it (so that the RFC editor does not have all the work in the end).
>
> * ID nits: I ran the document through the IDNITs tool and it reported a few
> issues:
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ecrit-l
> ost-servicelistboundary-02.txt
>
> (including old license statement, no intended status of the document, ...)
>
> * Document title: it seems that the document title does not fit nicely into
> the IETF ECRIT WG charter page. I would suggest to change it to "LoST
> Service List Boundary Extension".

I changed the title.

>
> Ciao
> Hannes
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>

From Hannes.Tschofenig@gmx.net  Fri Feb 26 05:14:05 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 1FA8F3A8795 for <ecrit@core3.amsl.com>; Fri, 26 Feb 2010 05:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level: 
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180,  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 m5YnFDQ8XL11 for <ecrit@core3.amsl.com>; Fri, 26 Feb 2010 05:14:02 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AB8123A8796 for <ecrit@ietf.org>; Fri, 26 Feb 2010 05:14:01 -0800 (PST)
Received: (qmail invoked by alias); 26 Feb 2010 13:16:15 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp058) with SMTP; 26 Feb 2010 14:16:15 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+51JkDSnm5uJAs+2v9qTrddGQZuztg0cDXx0f7zK j1h5BED3OYNTLX
Message-ID: <4B87C978.4000509@gmx.net>
Date: Fri, 26 Feb 2010 15:15:36 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Karl Heinz Wolf <khwolf1@gmail.com>
References: <Acqy2i/V3psrYv+FQlC2Z6gGi3PaNg==>	 <000001cab309$a69a2d40$04ffa8c0@nsnintra.net> <f77644531002260439s488414dase4d109978bfc354a@mail.gmail.com>
In-Reply-To: <f77644531002260439s488414dase4d109978bfc354a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.53000000000000003
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] draft-ietf-ecrit-lost-servicelistboundary-02
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: Fri, 26 Feb 2010 13:14:05 -0000

Please go ahead and submit the updated version.
I will drop a mail to the XML directorate pointing to your document and 
to the LoST sync draft.


Ciao
Hannes

Karl Heinz Wolf wrote:
> Hannes,
>
> I have already incorporated your comments into the draft for the next
> update. Thank you for requesting a review at the XML directorate -
> I'll wait for their feedback before I submit a new version.
>
> karl heinz
>
> On Sun, Feb 21, 2010 at 4:22 PM, Hannes Tschofenig
> <Hannes.Tschofenig@gmx.net> wrote:
>   
>> * References: I believe RFC 5582 should be moved to the informative
>> references since it is not required for the implementation of this
>> specification and it would lead to a DOWNREF.
>>     
>
> I moved the reference.
>
>   
>> * Relax NG Schema: Given that you have a fairly complex Relax NG schema in
>> the document I was wondering whether you have solicited feedback from the
>> XML directorate?
>>
>> I also had a question regarding the include statement and whether it
>> wouldn't be possible to reference the LoST schema here by URL rather than by
>> filename.
>>     
>
> I used the same include statement like you in the LoST-sync document.
>
>   
>> * Editorial bugs. There are bunch of editorial issues in the document and I
>> was wondering whether you have asked a native speaker to have a quick look
>> at it (so that the RFC editor does not have all the work in the end).
>>
>> * ID nits: I ran the document through the IDNITs tool and it reported a few
>> issues:
>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ecrit-l
>> ost-servicelistboundary-02.txt
>>
>> (including old license statement, no intended status of the document, ...)
>>
>> * Document title: it seems that the document title does not fit nicely into
>> the IETF ECRIT WG charter page. I would suggest to change it to "LoST
>> Service List Boundary Extension".
>>     
>
> I changed the title.
>
>   
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>>     


From khwolf1@gmail.com  Fri Feb 26 05:22:35 2010
Return-Path: <khwolf1@gmail.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 96EA33A879F for <ecrit@core3.amsl.com>; Fri, 26 Feb 2010 05:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0Y8Sap2aRc2I for <ecrit@core3.amsl.com>; Fri, 26 Feb 2010 05:22:30 -0800 (PST)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 63DC328C1A2 for <ecrit@ietf.org>; Fri, 26 Feb 2010 05:22:30 -0800 (PST)
Received: by pvg2 with SMTP id 2so16921pvg.31 for <ecrit@ietf.org>; Fri, 26 Feb 2010 05:24:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M/Ab7ghwhdzvYNo4SYfMw2F+HH26jj8361LN/roHR6c=; b=aCkHCrWY3c0af/Lwerf1K3ezBCkS4xpQ7haK/AtUOdZnYD0fI4X/E3132tAwuIASCn 49YYaIT24FIl6wetqbuzNW+fH42wjXikw5DWCW6J6ZwXM5XCOD5E77Z8aj3K7ziF+9SS RJLuKr3YAiiRvzzhEVauK8DmHKucArcPrtD/k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JLejPhFAj8YVrZiw/cFmv1wFuaV6HUN54sQEbccSl6aRWXspMj8JU5rUmVzPRzPkNe pyXZqKq8DIwCSNEYunjEOLkMDEELBEV9XOdnA4z/ngV78s8u/LdvwT9obeT3S7TvEx9j i1qmmNtH6HTL5TMcY+6VViOMLg9Djqva7X+sw=
MIME-Version: 1.0
Received: by 10.140.237.14 with SMTP id k14mr213495rvh.3.1267190681895; Fri,  26 Feb 2010 05:24:41 -0800 (PST)
In-Reply-To: <4B87C978.4000509@gmx.net>
References: <000001cab309$a69a2d40$04ffa8c0@nsnintra.net> <f77644531002260439s488414dase4d109978bfc354a@mail.gmail.com> <4B87C978.4000509@gmx.net>
Date: Fri, 26 Feb 2010 14:24:41 +0100
Message-ID: <f77644531002260524v806974x766d2a7353f3a54f@mail.gmail.com>
From: Karl Heinz Wolf <khwolf1@gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] draft-ietf-ecrit-lost-servicelistboundary-02
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: Fri, 26 Feb 2010 13:22:36 -0000

ok, I just submitted the new version.

thanks
karl heinz

On Fri, Feb 26, 2010 at 2:15 PM, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net> wrote:
> Please go ahead and submit the updated version.
> I will drop a mail to the XML directorate pointing to your document and to
> the LoST sync draft.
>
>
> Ciao
> Hannes
>
> Karl Heinz Wolf wrote:
>>
>> Hannes,
>>
>> I have already incorporated your comments into the draft for the next
>> update. Thank you for requesting a review at the XML directorate -
>> I'll wait for their feedback before I submit a new version.
>>
>> karl heinz
>>
>> On Sun, Feb 21, 2010 at 4:22 PM, Hannes Tschofenig
>> <Hannes.Tschofenig@gmx.net> wrote:
>>
>>>
>>> * References: I believe RFC 5582 should be moved to the informative
>>> references since it is not required for the implementation of this
>>> specification and it would lead to a DOWNREF.
>>>
>>
>> I moved the reference.
>>
>>
>>>
>>> * Relax NG Schema: Given that you have a fairly complex Relax NG schema
>>> in
>>> the document I was wondering whether you have solicited feedback from the
>>> XML directorate?
>>>
>>> I also had a question regarding the include statement and whether it
>>> wouldn't be possible to reference the LoST schema here by URL rather than
>>> by
>>> filename.
>>>
>>
>> I used the same include statement like you in the LoST-sync document.
>>
>>
>>>
>>> * Editorial bugs. There are bunch of editorial issues in the document and
>>> I
>>> was wondering whether you have asked a native speaker to have a quick
>>> look
>>> at it (so that the RFC editor does not have all the work in the end).
>>>
>>> * ID nits: I ran the document through the IDNITs tool and it reported a
>>> few
>>> issues:
>>>
>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ecrit-l
>>> ost-servicelistboundary-02.txt
>>>
>>> (including old license statement, no intended status of the document,
>>> ...)
>>>
>>> * Document title: it seems that the document title does not fit nicely
>>> into
>>> the IETF ECRIT WG charter page. I would suggest to change it to "LoST
>>> Service List Boundary Extension".
>>>
>>
>> I changed the title.
>>
>>
>>>
>>> Ciao
>>> Hannes
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>
>

From root@core3.amsl.com  Fri Feb 26 05:30:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id CC59828C1E0; Fri, 26 Feb 2010 05:30:02 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100226133002.CC59828C1E0@core3.amsl.com>
Date: Fri, 26 Feb 2010 05:30:02 -0800 (PST)
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-03.txt
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: Fri, 26 Feb 2010 13:30:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF.


	Title           : LoST Service List Boundary Extension
	Author(s)       : K. Wolf
	Filename        : draft-ietf-ecrit-lost-servicelistboundary-03.txt
	Pages           : 15
	Date            : 2010-02-26

LoST maps service identifiers and location information to service
contact URIs.  If a LoST client wants to discover available services
for a particular location, it will perform a <listServicesByLocation>
query to the LoST server.  However, the LoST server, in its response,
does not provide context information, that is, it does not provide
any additional information about the geographical region for which
the returned list of services is considered valid within.  Therefore,
this document proposes a <serviceListBoundary> element that returns a
local context along with the list of services returned, in order to
assist the client to not miss a change in available services when
moving.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboundary-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ecrit-lost-servicelistboundary-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-02-26052233.I-D@ietf.org>


--NextPart--

From ben@estacado.net  Fri Feb 26 13:23:29 2010
Return-Path: <ben@estacado.net>
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 01D263A8722; Fri, 26 Feb 2010 13:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level: 
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230,  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 T8NS4aTokt8B; Fri, 26 Feb 2010 13:23:28 -0800 (PST)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id C8C283A8849; Fri, 26 Feb 2010 13:23:27 -0800 (PST)
Received: from dn3-174.estacado.net (dn3-174.estacado.net [172.16.3.174]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o1QLPbwG041819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Feb 2010 15:25:38 -0600 (CST) (envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Ben Campbell <ben@estacado.net>
X-Priority: 3
In-Reply-To: <20100221194633.52090@gmx.net>
Date: Fri, 26 Feb 2010 15:25:37 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6903DD98-05C1-489C-86F6-C92DDE47F564@estacado.net>
References: <3D3C75174CB95F42AD6BCC56E5555B450238916C@FIESEXC015.nsn-intra.net> <D438D3CB-F207-4D75-A5DC-D40736BE3B63@estacado.net> <20100221194633.52090@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, General Area Review Team <gen-art@ietf.org>
X-Mailer: Apple Mail (2.1077)
Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org
Subject: Re: [Ecrit] GenART Telechat review of draft-ietf-ecrit-location-hiding-req-02
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: Fri, 26 Feb 2010 21:23:29 -0000

Hi,

Version 04 addresses all of my concerns.

Thanks!

Ben.

On Feb 21, 2010, at 1:46 PM, Hannes Tschofenig wrote:

>> Thanks, that helps, and I think it pushes it back down to an =
editorial
>> comment.  But I still wonder why a normative requirement like this is =
not one
>> of the labeled requirements. Right now, it's sort of like saying =
"We've got
>> requirements A, B,C, 1, 2, 3, and this other thing".
>=20
>=20
> I looked at it again and the classification appears to be a bit =
arbitrary.
> I changed it again and flattened the structure.=20
>=20
> I re-submitted a new version.=20
>=20
> Ciao
> Hannes


From Hannes.Tschofenig@gmx.net  Sat Feb 27 04:34:02 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 0C0633A8779 for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 04:34:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level: 
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098,  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 0WKHdliAZVLw for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 04:34:01 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DA5403A8776 for <ecrit@ietf.org>; Sat, 27 Feb 2010 04:34:00 -0800 (PST)
Received: (qmail invoked by alias); 27 Feb 2010 12:36:18 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp053) with SMTP; 27 Feb 2010 13:36:18 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+yHxItCS6yYxTRrw0joEkIbNLBoCk5UWGOKGb3m8 Rde33iSpmuwS6b
Message-ID: <4B89119B.9090606@gmx.net>
Date: Sat, 27 Feb 2010 14:35:39 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: xml-dir@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.72999999999999998
Cc: 'ECRIT' <ecrit@ietf.org>
Subject: [Ecrit] XML Directorate Review Request for draft-ietf-ecrit-lost-servicelistboundary-03.txt
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: Sat, 27 Feb 2010 12:34:02 -0000

Hi all,

in the ECRIT group we are currently finishing the work on an extension 
for an XML based protocol and this specification contains a Relax NG 
schema. It would be great if you could have a brief look at it to see 
whether you spot some obvious problems.

The document can be found here:
http://www.ietf.org/id/draft-ietf-ecrit-lost-servicelistboundary-03.txt

Ciao
Hannes


From Hannes.Tschofenig@gmx.net  Sat Feb 27 04:40:18 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 41EEF3A878E for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 04:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  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 4UjUVZmrArQ9 for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 04:40:18 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9C1973A878A for <ecrit@ietf.org>; Sat, 27 Feb 2010 04:40:17 -0800 (PST)
Received: (qmail invoked by alias); 27 Feb 2010 12:35:54 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp065) with SMTP; 27 Feb 2010 13:35:54 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/oI6UDEX3oV6QjA+3KyMEP/IiNvqji2FnQmblGe3 WkvXHnTQttCY4d
Message-ID: <4B891184.1090601@gmx.net>
Date: Sat, 27 Feb 2010 14:35:16 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: xml-dir@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.72999999999999998
Cc: 'ECRIT' <ecrit@ietf.org>
Subject: [Ecrit] XML Directorate Review Request for draft-ietf-ecrit-lost-sync-08.txt
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: Sat, 27 Feb 2010 12:40:18 -0000

Hi all,

in the ECRIT group we are currently finishing the work on an extension 
for an XML based protocol and this specification contains a Relax NG 
schema. It would be great if you could have a brief look at it to see 
whether you spot some obvious problems.

The document can be found here:
http://www.ietf.org/id/draft-ietf-ecrit-lost-sync-08.txt

Ciao
Hannes


From Hannes.Tschofenig@gmx.net  Sat Feb 27 08:01:35 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 B2FC228C23C for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 08:01:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,  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 xpcjlgs3TN0Q for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 08:01:35 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BCC9D28C174 for <ecrit@ietf.org>; Sat, 27 Feb 2010 08:01:34 -0800 (PST)
Received: (qmail invoked by alias); 27 Feb 2010 16:03:53 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp009) with SMTP; 27 Feb 2010 17:03:53 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18aNTYeHDgayZ2kAPIqq5OzeYmsxILa9iA+PaAswK tmxCVGjI1Oog5K
Message-ID: <4B894242.40003@gmx.net>
Date: Sat, 27 Feb 2010 18:03:14 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: 'ECRIT' <ecrit@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.82999999999999996
Subject: [Ecrit] Call for Agenda Items
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: Sat, 27 Feb 2010 16:01:35 -0000

Hi all,

please drop us a mail to request a presentation slot at the upcoming 
IETF meeting.

Ciao
Hannes & Marc


From Hannes.Tschofenig@gmx.net  Sat Feb 27 08:21:13 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 272AB28C22A for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 08:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077,  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 x0GVpObsZH1G for <ecrit@core3.amsl.com>; Sat, 27 Feb 2010 08:21:12 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EF93D28C195 for <ecrit@ietf.org>; Sat, 27 Feb 2010 08:21:11 -0800 (PST)
Received: (qmail invoked by alias); 27 Feb 2010 16:23:29 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp036) with SMTP; 27 Feb 2010 17:23:29 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+1CrINlBe1CvVFhQLnFG12P3i+7wr/LcsYYNU/Al g9VhRGwWAbwKyb
Message-ID: <4B8946DB.3050701@gmx.net>
Date: Sat, 27 Feb 2010 18:22:51 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: 'ECRIT' <ecrit@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.70999999999999996
Subject: [Ecrit] PSAP Callback: Status?
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: Sat, 27 Feb 2010 16:21:13 -0000

Hi all,

as you have seen from my previous mails I have distributed questions to 
other organizations, namely NENA, EENA and ETSI EMTEL, to solicit 
feedback and clarification regarding PSAP callback requirements.

So far, I have not seen a lot of feedback but I am sure we will receive 
something (after some time).

Since the submission deadline is ahead of us I am suggestion to reflect 
the discussions we had during the virtual interim meeting in the 
draft-schulzrinne-ecrit-psap-callback document itself.

Other suggestions?

Ciao
Hannes