Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt

From: Karl Heinz Wolf <[email-masked]>
Date: Mon, 1 Feb 2010 15:06:34 +0100

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:
>  - s/ist/is/
>  - I assume that the example civic address boundary is in English? xml:lang="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="urn:ietf:params:xml:ns:lost1"
xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">

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

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

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

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

 </include>

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

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

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

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

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

</grammar>

Thank you,

Karl Heinz

---

From: Karl Heinz Wolf <[email-masked]>
Date: Mon, 1 Feb 2010 15:06:47 +0100

Hi Richard,

On Thu, Jan 28, 2010 at 6:05 AM, Richard L. Barnes <[email-masked]> 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: "Richard L. Barnes" <[email-masked]>
Date: Mon, 1 Feb 2010 09:29:03 -0500

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:

>> boundary

---

From: "Roger Marshall" <[email-masked]>
Date: Mon, 1 Feb 2010 15:46:43 -0800

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 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:
" 		
			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 response from the LoST server	
			does not provide information about the geographical region for which	
			the returned service list is valid. Therefore, this document	
			proposes a ServiceListBoundary to assist the client to not miss a	
			change in available services when moving.
"

Change to:
"
		
			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 service list is considered valid within. Therefore, this document	
			proposes a ServiceListBoundary message 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.
"

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 which 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. 
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 service 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. 
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 
in a by value or by reference form.
"

C7 remove "sld:" element name placeholders (several instances - I assume that 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.  
"
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.  
"

C9. Question, Is "<locationUsed id="mylocation"/> in section 3.1, (3rd example code)
Really what you want to use here?  
Comment: RFC5222 uses "    <locationUsed id="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, 
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.  
"
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 same, within a <listServicesByLocation> query.  
"

/end.

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

Hi Richard,

I'll do this change.

"

What do you think?

karl heinz
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

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

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 4 Feb 2010 14:46:31 +0100

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

>                        change in available services when moving.

ok

>   the returned service list is valid.
ok
> s/discoverers/discovers/1
ok
>   the emergency call to the mountain rescue service will certainly

I do not see your change request here.

>   advantages for service lists.

ok

> in a by value or by reference form.

ok

>        <serviceListBoundary>value</serviceListBoundary>

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

> Comment: RFC5222 uses "    <locationUsed id="6020688f1ce1896d"/>", which is a little more discrete.

I've changed it to a more discrete id.

> "3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>

ok

> "The <serviceListKey> uniquely identifies a <serviceListBoundary>

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

>   the service identifiers returned from a <serviceList> element are the same, within a <listServicesByLocation> query.

ok

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 4 Feb 2010 08:08:35 -0800

Karl:

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

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 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 recognized by the client.
"

-roger.

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

Roger,

Thank you,
Karl Heinz

ok

ok
ok

ok

ok

ok

ok

---

From: Karl Heinz Wolf <[email-masked]>
Date: Fri, 5 Feb 2010 09:14:31 +0100

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.

> than to the mountain rescue service, using the already known dialstring, or may fail altogether if the mountain rescue number is used but not recognized 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