[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] LoST Review - part 1

Comments on the comments; I'm hoping that Patrik is on the list.

Thanks for the comments!

To simplify discussion a bit, I'm stripping out the text. I think most of the comments can be understood as-is.

On Jan 31, 2007, at 9:51 AM, Marc Linsner wrote:

Hannes and I asked Patrik Falstrom to review the LoST/Mapping Arch
drafts....here is the first of his comments.....
...................................................................... ......

FYI: I have always been nervous when using as an index something that is a
well known abstraction of a location, such as a civic location.
My argument all the time has been that the most important piece of the
puzzle is that "the device" have some kind of identifier that later can be
mapped to a PSAP. Secondly (and not the same, note that) that the device can
send information to the PSAP so that the PSAP can (at least in Sweden) (a)
locate the device and (b) reinitiate the connection if the communication
breaks.

I have seen too many discussions in ECRIT where the two uses of "the
location" (the routing issue, and the data that is sent to the PSAP) is
claimed to be the same.

Anyway... You have heard me saying this before :-)


LoST only deals with mapping and doesn't say anything about whether the same location is delivered to the PSAP. Indeed, for geo, this is unlikely to be the case if the device moves around.

Thus, I don't understand the comment.



Hmm...so LoST include caching. This is the first thing I think one should
look at. Who defines the appropriate caching time? Do you need notifications
for emergency updates? Etc?


The authoritative server defines the object lifetime, as discussed later. There are several other layers of indirection, such as DNS NAPTR, SRV and proxies, that are much better for short-term changes. Duplicating this at the LoST level seems unlikely to be effective or necessary.




Oh, no! Not HTTP again!!! Why? Also, you can not rely on client certificates 

Because it works :-)

or other mechanisms for the authentication of the client sending the query.
You need another layer of username/password/ whatever on top of TLS. TLS is
usable for the encryption of the traffic, but not (much) more.


Hmm, server certs seem to be fairly widespread. If they are deeply problematic, I think the world has larger problems than the use of LoST over HTTP.

This implies to me that the payload that is moved with the HTTP protocol
have to include enough signatures, passwords, usernames and possibly
encryption to handle the authentication and authorization of the LoST
transaction.


LoST deals with public information, so client authentication is generally not a concern. It is also not clear to me that if we should need client authentication, why Basic or Digest (or client certs) would not be sufficient. It would be helpful to have this concern elaborated on, as this is a fairly fundamental design issue.


I am a little bit nervous about the fact that the server can either
give back a referral OR do a recursive query. For the client the
difference is of course that all clients MUST implement the ability
to handle referrals, but on the other hand, the ability for a server
to query another server might not have to be in this document. Why is
that needed? Because it is needed to know wether the data comes from
an authoritative source? Or "just" because it imitates the way DNS
works?


A server can obviously choose to only refer, so I don't quite understand the comment. The reason for referrals is two-fold:

- allows intermediaries to cache results

- avoids multiple trips across a possibly narrow-bandwidth last-hop link



Have this URI spec been reviewed on the URI-review list? If not, I
urge you to pass it on asap.


Will do so.



(1) Please use the same examples all the time. Above you use the
example lostserver.example.com, and now example.com.


Noted.


(2) Why do you not only use SRV records for this as lost is only
defined for HTTP/HTTPS?

lost:example.com -> _lost._tcp.example.com:80

I do not see any need for NAPTR records, unless LOST can be used with
some other protocol than HTTP. That is though not what it seems the
overall design is for.

I.e. possible over-engineering for an abstraction that in reality is
not, and will never, be used.


I tend to agree with that simplification.




How do the end device get the LOST URL?


Later.



Are really all elements optional? sourceId, version, and source
attributes as well?


Just the elements, not the attributes. Maybe that's too non-obvious a distinction.

This draft contain a lot of words. Not as crisp as I would like to
see a protocol specification. Why for example does the above

I'm always happy to remove text, as long as somebody else then doesn't complain that they need more examples, more background and design information and a longer security considerations section...


Should not the URI definition include the ability to also include the
sourceId and version in the URI?


At this point, the URI does not attempt to provide the ability to issue arbitrary LoST queries. We'd have to add a lot more to the URI to be able to do this, such as the location information and query type. One could define a URI that allow to simply retrieve a specific mapping, but not be rich enough to express a query.

Else you will not be able to get a URI for the record itself, and I
think that would be an opportunity that should not be missed.


Retrieving a particular mapping by identifier (as opposed to by location) doesn't seem a particularly important operation for LoST, but I don't have a strong opinion on this.

[Since this is getting far too long for a single message, I'll continue the discussion in a separate message.]



Why btw are several attributes in
Do you need time stamps on the via headers?


Good question; unlike email, it seems highly unlikely (and broken) if the requests take more than a few milliseconds for each hop, so second-resolution timestamps are unlikely to be useful and below that, clock synchronization seems to make the timestamp more or less random.

Henning




_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit