Subject: [Ecrit] LoST Sync Draft Update

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 9 Aug 2009 10:07:33 +0300

Hi all, 

I asked Roger to submit the PROTO writeup for the LoST sync draft after
we got further confirmation from the implementers team. Then, Roger
pointed me to the review by Richard and I have to say that I must have
missed it. Here are Richards review comments: 
http://www.ietf.org/mail-archive/web/ecrit/current/msg06127.html

My response is inline: 

I reviewed lost-sync-04 in order to update my earlier comments on -01.
This version is much improved from the previous versions in terms of
specificity (although it's still vague in places).  It still seems to me
that there are a few layers of detail missing.  Specific comments below.
--Richard

1. The document describes transactions for requesting and delivering
mapping structures, but doesn't describe at all how these transactions
create a synchronization system.  There is clearly some tracking of
state needed (especially for "pushMappings"), and the document is silent
on how this state is initially established and then maintained.

[Hannes] I added text throught the document to address this comments. 
In particular I point to the need to keep state and also to the fact 
that the document relies on manual configuration for setting up the 
"peering" between the two nodes. 

2. In a similar vein, it would be helpful for this document to have some
discussion of how this synchronization system relates to others that are
out there (e.g., rsync).  Since the name of the draft is
"synchronization", there should be some discussion of how bidirectional
sync is handled.

[Hannes] We had a discussion about this topic at the interim meeting and

"downgraded" the document to an Experimental status to avoid having to 
Analyse all available replication mechanisms.

3. It seems like there should really be only 3 message types here
instead of 4: (1) a "syncRequest" message sent from destination to
source (getMappingsRequest), (2) a "syncUpdate" message sent from source
to destination (getMappingsResponse == pushMappingsRequest), and (3) a
"syncResult" message sent from destination to source
(pushMappingsResponse).  There can still be two types of transaction,
but they're determined by which type of message (syncRequest or
syncUpdate) is sent in the HTTP request.

[Hannes] We got similar feedback from the implementers. However, in a 
subsequent discussion with them it turned out that this change is 
rather a matter of style than anything technical. A change in the
description along the lines as you suggested (and as they had suggested)

as well only impacts the writing style of the document and not really 
the implementation as such. Hence, I left the document as is. 

4. In a similar vein to 2 and 3, the use of "client" and "server" is
confusing.  I would suggest using more appropriate names for these roles
like "source" and "destination", along with some text that explains how
these roles map to HTTP roles in each type of transaction.

[Hannes] I added text regarding the HTTP/HTTPs roles and changed the 
terminology in the document to reflect the source / destination
terminology. 
I hope it improved readability. 

5. My comment about the security considerations has not been addressed.
 The security considerations section is essentially a pointer to LoST,
but this protocol is only peripherally related to LoST (at a technical
level).  Since it's about synchronization, I would expect this document
to note that the primary risk is the injection of false location
information (since the mappings themselves are public), which means that
the parties should use HTTPS to carry the XML, authenticate the source,
and use a ciphersuite that provides integrity protection to messages.

[Hannes] You are certainly right with this comment. I changed the text. 

Here is the updated document: 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-07.txt

Ciao
Hannes

---

From: Karl Heinz Wolf <[email-masked]>
Date: Mon, 10 Aug 2009 11:49:26 +0200

Hannes,

some time ago I asked you about lost-sync and the pushing of coverage
regions up a tree.
Pushing of coverage regions is mentioned in the introduction, but all
the examples show complete mappings.
So I wonder if you assume LoST URIs to be placed in the URI elements
of the mappings to indicate that this is not a mapping but rather a
coverage region in the boundary?

cheers
karl heinz

On Sun, Aug 9, 2009 at 9:07 AM, Tschofenig, Hannes (NSN -
FI/Espoo)<[email-masked]> wrote:
> Hi all,
>
> I asked Roger to submit the PROTO writeup for the LoST sync draft after we
> got further confirmation from the implementers team. Then, Roger pointed me
> to the review by Richard and I have to say that I must have missed it. Here
> are Richards review comments:
>
> terminology in the document to reflect the source / destination terminology.
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 10 Aug 2009 15:12:01 +0300

Hi Karl Heinz, 
Hi all, 

Thanks for this question. 

To provide a bit of background to your question let us take an example provided in 
http://www.ietf.org/id/draft-ietf-ecrit-mapping-arch-04.txt

On page 10 an example of mappings stored at a server are outlined: 

   country   A1 A2         A3        resource or LoST server
   US        NJ Bergen     Leonia    sip:[email-masked]
   US        NJ Bergen     Fort Lee  sip:[email-masked]
   US        NJ Bergen     Teaneck   sip:[email-masked]
   US        NJ Bergen     Englewood englewoodnj.gov

In this case, the first three mappings point to PSAPs (or ESRPs; one cannot differentiate based on the mapping data). The final mapping, however, points to a LoST server. 

So, <uri> element of the <mapping> element accepts only URIs. The output of the U-NAPTR process (described in Section 4 of http://www.ietf.org/rfc/rfc5222.txt) leads to a HTTP/HTTPS URI.

So, the URI that is associated with the boundary is using a HTTP and HTTPS URL scheme. 
The input unfortunatley isn't; it is just a DNS name. 

In earlier versions of the LoST specifications we defined a new URI scheme (namely lost://) but later removed it. As such, there is no LoST URI to put into the <uri> element. 

So, do we have a problem here? 

Ciao
Hannes

PS: I have to check what the implementers have implemented here. 

>Hannes,
>
>some time ago I asked you about lost-sync and the pushing of 
>coverage regions up a tree.
>Pushing of coverage regions is mentioned in the introduction, 
>but all the examples show complete mappings.
>So I wonder if you assume LoST URIs to be placed in the URI 
>elements of the mappings to indicate that this is not a 
>mapping but rather a coverage region in the boundary?
>
>cheers
>karl heinz
>
>> I asked Roger to submit the PROTO writeup for the LoST sync draft 
>> after we got further confirmation from the implementers team. Then, 
>> Roger pointed me to the review by Richard and I have to say that I 
>> must have missed it. Here are Richards review comments:
>>
>> specificity (although it's still vague in places).  It still 
>seems to 
>> me that there are a few layers of detail missing.  Specific 
>comments below.
>> --Richard
>>
>> state needed (especially for "pushMappings"), and the document is 
>> silent on how this state is initially established and then 
>maintained.
>>
>> 2. In a similar vein, it would be helpful for this document to have 
>> some discussion of how this synchronization system relates to others 
>> that are out there (e.g., rsync).  Since the name of the draft is 
>> "synchronization", there should be some discussion of how 
>> bidirectional sync is handled.
>>
>> [Hannes] We had a discussion about this topic at the interim meeting 
>> and "downgraded" the document to an Experimental status to avoid 
>> having to Analyse all available replication mechanisms.
>>
>> source (getMappingsRequest), (2) a "syncUpdate" message sent from 
>> source to destination (getMappingsResponse == pushMappingsRequest), 
>> and (3) a "syncResult" message sent from destination to source 
>> description along the lines as you suggested (and as they had 
>> suggested) as well only impacts the writing style of the 
>document and 
>> not really the implementation as such. Hence, I left the 
>document as is.
>>
>> confusing.  I would suggest using more appropriate names for these 
>> roles like "source" and "destination", along with some text that 
>> explains how these roles map to HTTP roles in each type of 
>transaction.
>>
>> level).  Since it's about synchronization, I would expect this 
>> document to note that the primary risk is the injection of false 
>> location information (since the mappings themselves are 
>public), which 
>> means that the parties should use HTTPS to carry the XML, 
>authenticate 
>> the source, and use a ciphersuite that provides integrity 
>protection to messages.
>>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 17 Aug 2009 20:38:01 +0300

As I explained in my previous mail there is a potential problem with the
document. 

My current suggestion is to re-introduce the "lost:" URI scheme (we had it
once in the LoST spec)

Thoughts about it? Objections? 

-------------------

Section (A): LoST Uniform Resource Locators and Their Resolution

   LoST servers are identified by LoST Uniform Resource Locators (URLs),
   which follow the format of URLs defined in RFC 3986, with the
   following ABNF:

      LoST-URI = "lost:" host

   'host' is defined in Section 3.2.2 of RFC 3986.

   An example is 'lost:lostserver.example.com'

   If a LoST URL contains a host name rather than an IP address, 
   the resolution mechanism described in Section 4 of RFC 5222 is used. 

Section (B): URL Registration Template

   This registration template is in accordance with RFC 2717.

   URL scheme name:

      lost

   URL scheme syntax:

      See Section (A).

   Character encoding considerations:

      See Section (A).

   Intended Use:

      The intended usage is described in this document.

   Application and protocols which use this scheme:

      The usage of the LoST URL scheme is targeted for this document,
      namely for the exchange of mapping structures. 

   Interoperability considerations:

      None

   Security considerations:

      See Section 7

   Relevant publications:

      This document provides the relevant context for this URL scheme.

   Contact:

      Hannes Tschofenig, [email-masked]

   Author/Change controller:

      The IESG <[email-masked]>

-------------------

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>Sent: 10 August, 2009 15:12
>To: ext Karl Heinz Wolf
>Cc: ECRIT
>Subject: Re: [Ecrit] LoST Sync Draft Update
>
>Hi Karl Heinz,
>Hi all, 
>
>In this case, the first three mappings point to PSAPs (or 
>ESRPs; one cannot differentiate based on the mapping data). 
>The final mapping, however, points to a LoST server. 
>
>So, <uri> element of the <mapping> element accepts only URIs. 
>The output of the U-NAPTR process (described in Section 4 of 
>http://www.ietf.org/rfc/rfc5222.txt) leads to a HTTP/HTTPS URI.
>
>In earlier versions of the LoST specifications we defined a 
>new URI scheme (namely lost://) but later removed it. As such, 
>there is no LoST URI to put into the <uri> element. 
>
>elements of 
>>the mappings to indicate that this is not a mapping but rather a

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 17 Aug 2009 14:16:26 -0400

I am not thrilled with defining a new scheme just for this purpose.

Could we not just use http?  There are no other uses for http in this
context to get confused with.

I especially do not want to go back and change how the protocol works, as
opposed to how you specify referral in lost-sync.

I do wonder if we really should be consulting with the apps area and come up
with some other way to solve the class of problems that this typifies.  HELD
has the same problem.  What we want is a general solution to a URI that uses
HTTP transport, but expects to conform to a specific WSDL or REST schema.
Seems like a parameter is appropriate, rather than defining new schemes.

I am not convinced lost-sync is useful, as I have stated before, but I don't
have any objection to finishing this work.

Broan

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Monday, August 17, 2009 1:38 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext Karl Heinz Wolf'
> Cc: 'ECRIT'

---

From: Andrew Newton <[email-masked]>
Date: Mon, 17 Aug 2009 15:27:17 -0400

I think you could safely and naturally run the U-NAPTR process against  
the contents of the <source> element to get what you need.  A LOST URL  
scheme is not needed, and would have implications on tools that are  
fed them.

-andy

On Aug 10, 2009, at 8:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> In this case, the first three mappings point to PSAPs (or ESRPs; one  
> cannot differentiate based on the mapping data). The final mapping,  
> however, points to a LoST server.
>
> So, <uri> element of the <mapping> element accepts only URIs. The  
> output of the U-NAPTR process (described in Section 4 of http://www.ietf.org/rfc/rfc5222.txt) 
>  leads to a HTTP/HTTPS URI.
>
> In earlier versions of the LoST specifications we defined a new URI  
> scheme (namely lost://) but later removed it. As such, there is no  
> LoST URI to put into the <uri> element.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 17 Aug 2009 15:29:27 -0500

I tend to agree with Broan [sic] on the minting of the URI scheme.  It should be enough to use an HTTP URI, or just an unadorned domain name, depending on context.

> Sent: Tuesday, 18 August 2009 3:38 AM

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Aug 2009 16:53:44 -0400

+1

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 18 Aug 2009 20:11:29 +0300

Thanks for the suggestion. The proposal sounds indeed fairly good (and
simple). 

Here is an example of how this could look like for mapping data used by an
Austrian Forest Guide (FG). For this example I assumed that each state runs
an independent LoST server and the FG would contain pointers to these LoST
servers. I illustrated two such mappings below:

      <mapping
        expires="2009-01-01T01:44:33Z"
        lastUpdated="2009-12-01T01:00:00Z"
        source="lost.kaernten.example"
        sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
        <displayName xml:lang="de">
          Kaernten LoST Server
        </displayName>
        <service>urn:service:sos</service>
        <serviceBoundary
          profile="civic">
          <civicAddress
            xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
            <country>AT</country>
			<A1>Kaernten</A1>
          </civicAddress>
        </serviceBoundary>
        <uri></uri>
        <serviceNumber>112</serviceNumber>
      </mapping>
	  
      <mapping
        expires="2009-01-01T01:44:33Z"
        lastUpdated="2009-12-01T01:00:00Z"
        source="lost.wien.example"
        sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
        <displayName xml:lang="de">
          LoST Server Wien
        </displayName>
        <service>urn:service:sos</service>
        <serviceBoundary
          profile="civic">
          <civicAddress
            xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
            <country>AT</country>
			<A1>Wien</A1>
          </civicAddress>
        </serviceBoundary>
        <uri></uri>
        <serviceNumber>112</serviceNumber>
      </mapping>

Thoughts? 

Ciao
Hannes

>From: ext Andrew Newton [mailto:[email-masked]] 
>Sent: 17 August, 2009 22:27
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: ext Karl Heinz Wolf; ECRIT
>I think you could safely and naturally run the U-NAPTR process 
>against the contents of the <source> element to get what you 
>need.  A LOST URL scheme is not needed, and would have 
>implications on tools that are fed them.
>
>-andy
>
>ESRPs; one  
>> So, the URI that is associated with the boundary is using a 
>HTTP and  
>> HTTPS URL scheme.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Aug 2009 13:33:28 -0400

Well... I guess... kinda.

I'm not sure why it simply wouldn't look like a normal <mapping>  
element complete with the <uri> set and the normal display name.

If the intent is to sync the mappings, you shouldn't really need to  
change a thing.  If the intent is for one server to tell another that  
it is authoritative for an area, that's not really syncing so much as  
plain configuration -- and I'm not sure you want to do that in a  
protocol.  After all, the US forest guide isn't simply gonna take all  
service boundaries from lost.kaernten.example, as kaernten could claim  
a larger area than it really is responsible for -- a possible attach  
vector at worst, an opportunity for a grand screw up at best.

At least that's how this strikes me.

-andy

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 19 Aug 2009 09:21:02 +0300

Hi Andy, 

>I'm not sure why it simply wouldn't look like a normal 
><mapping> element complete with the <uri> set and the normal 
>display name.

What URI would you set there? 
The mapping points to the boundary that is covered by a LoST server rather
than a PSAP. 

>
>If the intent is to sync the mappings, you shouldn't really 
>need to change a thing.

This is a terminology issue. The document tries to provide the necessary
functionality to get the "mapping architecture" to work. 

It would also be possible for the FG to always collect all the mappings from
the LoST servers it controls. Then, the above-mentioned case would not show
up. 

  If the intent is for one server to 
>tell another that it is authoritative for an area, that's not 
>really syncing so much as plain configuration -- and I'm not 
>sure you want to do that in a protocol.

Why not? Yet another protocol to exchange mappings?

>  After all, the US 
>forest guide isn't simply gonna take all service boundaries 
>from lost.kaernten.example, as kaernten could claim a larger 
>area than it really is responsible for -- a possible attach 

Correct. It was just an example to illustrate what I meant. Austria is
obviously too small to justify LoST servers for each state. 

Ciao
Hannes

>> Here is an example of how this could look like for mapping data used 
>> by an Austrian Forest Guide (FG). For this example I assumed 
>that each 
>> state runs an independent LoST server and the FG would contain 
>> pointers to these LoST servers. I illustrated two such 
>mappings below:
>>
>>      <mapping
>>> against the contents of the <source> element to get what 
>you need.  A 
>>> LOST URL scheme is not needed, and would have implications on tools 
>>> that are fed them.
>>>
>>> -andy
>>>
>>>>> Pushing of coverage regions is mentioned in the introduction, but 
>>>>> all the examples show complete mappings.
>mapping but 
>>>>> rather a coverage region in the boundary?
>>>>>
>>>>> cheers
>>>>> karl heinz
>>>>>
>>>>>> create a synchronization system.  There is clearly some tracking 
>>>>>> of state needed (especially for "pushMappings"), and the 
>document 
>>>>>> is silent on how this state is initially established and then
>>>>> maintained.
>>>>>>

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 20 Aug 2009 09:08:52 +0200

Hannes,
this seems to be a possible solution. I would also skip the
serviceNumber element in the examples since it is not necessary for
the FG to know them - just the coverage region is of interest.
In your examples, would the LoST server also be authoritative for
possible subservices?

karl heinz

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 20 Aug 2009 10:50:24 +0300

Hi Karl Heinz, 

>serviceNumber element in the examples since it is not 
>necessary for the FG to know them - just the coverage region 
>is of interest.

You are correct that I could omit the <serviceNumber> element. 
(In fact I can also omit the <uri> element as well instead of having it
empty.)

>In your examples, would the LoST server also be authoritative 
>for possible subservices?
Your question is whether the "Kaernten" LoST server in the example below
would also be hosting entries for urn:service:sos.police etc? 

Ciao
Hannes

>>>>>> after we got further confirmation from the implementers team. 
>>>>>> Then, Roger pointed me to the review by Richard and I 
>have to say 
>>>>>> that I must have missed it. Here are Richards review comments:
>>>>>>
>>>>>> that the document relies on manual configuration for setting up 
>>>>>> the "peering" between the two nodes.
>>>>>>
>>>>>> 2. In a similar vein, it would be helpful for this document to 
>>>>>> have some discussion of how this synchronization system relates
>>>to others
>>>>>> source to destination (getMappingsResponse == 
>>>>>> pushMappingsRequest), and (3) a "syncResult" message sent from 
>>>>>> destination to source (pushMappingsResponse).  There can 
>still be 
>>>>>> two types of
>>>>> transaction,

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 20 Aug 2009 10:08:31 +0200

> would also be hosting entries for urn:service:sos.police etc?
yes, that's my question: when a server pushes up a coverage region for
urn:service:sos, is he also authoritative for urn:service:sos.police
or would he have to push up the same coverage region twice?
But theoretically a different server could be responsible for the
subservices, couldn't it?

karl heinz

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 20 Aug 2009 12:01:57 +0300

Hi Karl Heinz,  

>> Your question is whether the "Kaernten" LoST server in the example 
>> below would also be hosting entries for urn:service:sos.police etc?
>yes, that's my question: when a server pushes up a coverage 
>region for urn:service:sos, is he also authoritative for 
>urn:service:sos.police or would he have to push up the same 
>coverage region twice?
>But theoretically a different server could be responsible for 
>the subservices, couldn't it?

Ok. Your question is addressing the current form of encoding and the
semantic of it.

When the mapping indicates 'urn:service:sos' then it is only authoritive for
'urn:service:sos' and not for the sub-services as they might be provided by
other LoST servers. Maybe that's something we should make more clear in the
document.

Now, you could argue that one could instead of pushing up 2 mapping elements
(both with the same boundary but with different service URNs) just list the
service URNs within a single boundary. That's true and would be more
bandwidth efficient. 

I don't think we should optimize the bandwidth performance at this point in
time but rather get something out there for folks to play with. I am sure
that there will be lots of other feedback coming so that we have to revise
the document in the future. 

Ciao
Hannes

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 20 Aug 2009 13:04:41 +0200

Hannes,
thank you for clarifying this. I was not concerned about bandwidth
efficiency but the document doesn't say much about pushing of coverage
regions so I thought I should ask. Probably a few words in the
document would be a good idea.

karl heinz