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

Re: [Ecrit] LoST Review - part 4



[I'm skipping the parts where I made wording updates to hopefully address the issue.]

The identifier is a random token with at least 128 bits of entropy
and can be assumed to be globally unique. It uniquely references a
particular boundary. If the boundary changes, a new identifier
MUST
be chosen. Because of these properties, a client receiving a
mapping
response can simply check if it already has a copy of the boundary
with that identifier. 

Should the reference then not be a URL plus an identifier?


Not quite. It couldn't really be a LoST URL, unless we add the query type as an attribute to that URL. This doesn't seem to be a good approach. We clearly don't want to allow random URLs, such as an http or mailto URL here, so allowing URLs just seems to open up more error conditions.


5.9.  Service URLs: the <uri> Element

   The response returns the service URLs in one or more <uri>
elements.
   The URLs MUST be absolute URLs.  The ordering of the URLs has no
   particular significance.  Each URL scheme MUST only appear at most
   once, but it is permissible to include both secured and regular
   versions of a protocol, such as both 'http' and 'https' or 'sip'
and
   'sips'.


How to handle load balancing, or the fact two PSAPs might cover the
same area?

We had a long discussion on this early on. We have several mechanisms at the SIP layer to do load balancing and it seems unwise and unnecessary to add another one, which would likely have to replicate much of the NAPTR and SRV (weight/priority) mechanisms.

Also, as soon as you present multiple URIs with the same scheme, the client has to choose somehow, as presenting two URLs to the user and asking which one they like better is not too useful. If the two PSAPs are cooperating, they can easily define a record in the DNS to do randomization.

In extreme cases such as territorial disputes, returning two <mapping>s is probably a better option, although that still doesn't help the end user all that much.



Did this document not say earlier that all matching service areas
(and for me because of that srevice URLs) should be returned that
matches? This "one scheme only" to me say that the server must choose
"the best one", which seems weird. Or am I confused?


We generally do not try to address overlapping service areas for one service, for the reasons above. I don't see how a user can make a reasonable choice.




I don't know enough about XML to say whether this ordering is ok or
not. This is the first time ordering among elements exists in this
spec though.


Ordering in XML seems common. After all, the outcome of

<li>Boil water.
<li>Add noodles and simmer for 5 minutes.

is different from

<li>Add noodles and simmer for 5 minutes.
<li>Boil water.




   If a query is answered iteratively, the querier includes all
servers
   that it has already contacted.

   The example in Figure 5 indicates that the answer was given to the
   responding server by the LoST server at esgw.ueber-110.de.example,
   which got the answer from the LoST server at
   polizei.muenchen.de.example.


This is also sent in a request? How else can one prevent loops if a
server is acting as a client and do a recursive search, walking into
servers that the originator already have queried?

I don't understand exactly how this can help with loop prevention.
Just how it can help loop detection on the client side. If it is not
passed also in requests.



Yes, it is ("querier includes all servers it has already contacted"). If you have a hybrid iterative-recursive query, i.e,. that starts iteratively and then goes recursive, the initial query will have the list of servers already visited.





Does "lastUpdated" imply that it is correct from that point in time?
To me that is not crystal clear. One might update a record one month
ahead of a move for example.


We have not defined mappings that only become valid in the future. This is only used to indicate how long the mapping has been unchanged and is just an informational item. It is not strictly necessary for caching, so I'm happy to remove it.

Henning

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