[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Review of LoST-04, part 1
Hi Tom,
thanks for your review and your text proposals. Please find my response
below:
Tom-PT Taylor wrote:
I've hardly started to put out comments, but given the contentious
nature of definitions, I figured this should hit the list now. I'm not
wedded to the proposed definitions, but I think they capture the usage
within LoST-04.
1. Organization of the document
-------------------------------
I find that the presentation in lost-03 has a few things out of place:
-- Section 3 is specific to usage of the <findService> message, so it
really belongs in the introduction to section 7.
You are right.
I, however, think that we should extend Section 3 by including the other
message exchanges to give an overview what will be described later.
-- Section 5 is specific to the <findServiceResponse> message, so it
belongs in section 7.4, immediately after section 7.4.1. A high-level
understanding of the intent of <mapping> is all that is needed up to
that point.
That's certainly possible. When we decided to move the <mapping> element
section we thought that it would be useful since it is one of the core
building blocks.
Bearing these comments in mind, please note that subsequent comments
use the existing section numbering in LoST-04. In the case of proposed
text, that numbering may have to be changed if these comments are
accepted. This possibility is flagged by enclosing section numbers in
proposed text in quotes.
Section 1
---------
para 3: LoST doesn't cache -- it supports caching.
Fixed.
", para 4: Delete "The relationship between", so that the sentence
starts "Other functions ...". Not sure I'd call architecture a
function, but I can't think of another word at the moment.
Fixed.
Section 2
---------
Little terminology from [18] is really used in this document. For
instance, "mapping" is more general in this document than in [18], and
should likely be defined explicitly here. Here is a stab at some text:
<proposed text>
Mapping
Mapping is a process that takes a location and a service identifier as
inputs and returns one or more URIs that point to a host providing
that service or acting as an intermediary to establish communication
with the serving entity. This definition is a generalization of the
term "mapping" as used in [18], because of the potential for LoST to
be used for non-emergency services.
Mapping is performed in LoST through exchange of the <findService> and
<findServiceResponse> messages as defined in section "7".
LoST Client and Server
"LoST client" is the role played by a host that sends LoST query
messages and receives LoST response messages. "LoST server" is the
role played by a host that receives LoST query messages and sends LoST
response messages. In recursive operation, the same host may play both
roles. This document also uses the term "authoritative server" to
designate a host that acts in the LoST server role only and
successfully resolves the input location and service identifier to a
URI or set of URIs.
Service Boundary
A service boundary is the boundary or set of boundaries of a
geographic region, respectively set of geographic regions, within
which all locations will map to the same URI or set of URIs for a
given service.
In LoST, service boundaries are expressed using ...
Validation
The term "validation" as used in this document is a concrete
realization of the term "location validation" as defined in section
3.5 of [18].
</proposed text>
Thanks for the text. Looks good to me (with some minor modifications).
By including these terms into the LoST draft we have a bit of repetition
but it could improve the readability of the draft.
Ciao
Hannes
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit