[Ecrit] Comments/Questions on draft-ietf-ecrit-lost-02

["Reese, Theresa E" <treese at telcordia.com>]

I have spent some time going through the latest draft of the LoST
document, and had the following questions for clarification:
 

1.	Is the 'recursive' attribute mandatory in all <findService>
queries?
Is the 'recursive' attribute mandatory only in <findService> civic
queries?
Is the 'recursive' attribute optional in <findService> queries?

Currently, the 'recursive' attribute is not shown in Figure 2
(<findService> geodetic query), but is included in Figure 4
(<findService> civic query).


2.	If a 'recursive' attribute is included in a <findService> query,
must a <via> always be present in the associated response?

Figure 4 includes a 'recursive' attribute in the query, but Figure 5,
which shows the associated response does not include a <via> element.
Also, the text in Section 6.4.1 specifies that responses to iterative
queries contain one <via> element, while responses to recursive queries
will have a <via> element for each server that was used in the
resolution.


3.	If the query originator sets the 'recursive' attribute in a
<findService> query message to "true," and the LoST server cannot answer
the query and has nowhere to forward the query to (i.e., the LoST server
does not have any arrangements with any other LoST servers to provide
assistance under this type of failure scenario), should the LoST server
treat the query as an iterative query (i.e., return an
<iterativeSearchExhausted> message)?

 
4.	The <findServiceResponse> message in Figure 6 includes some
elements that were not identified in the 'include' attribute of the
<findService> query (e.g., displayName, serviceBoundary). Is this a
typo?  Also, this example includes a 'recursive' attribute in the query,
but there is not via in the response.  Should the <via> element be
present in the response?


5.	There seem to be some inconsistencies in Figure 12 between the
information being requested in the <findService> query and the
information provided in the <findServiceResponse> message.  The query
requests the uri and serviceNumber.  The response provides
<displayName>, <service>, and <serviceBoundary>, and does not provide
<serviceNumber>.  I assume the author intended the query to include a
request for serviceBoundary, but this raises a question.  If the query
originator did not request serviceBoundary information, and provided
location using two different profiles (as is illustrated in Figure 12),
and the server did not understand the non-baseline profile, would the
server still communicate the locationProfileError, even if it was not
returning location information (in the form of a serviceBoundary)
itself?


6.	There seems to be text missing from the last sentence of the
first paragraph in Section 10.  The text begins to talk about errors
that are labeled as fatal, but then the text just stops.  The sentence
fragment either needs to be completed or deleted.

Also, the text in Section 10.2 says that the errors described in this
section "may be generated by referent LoST serve[r]s queried on behalf
of seekers by a resolving LoST server."  This seems to imply that these
would be error indications that would be received by the resolving LoST
server.  I assume that these would be passed back to the query
originator by the resolving LoST server.  Also, I assume that if the
LoST server is both the resolving and the responding LoST server, that
it would generate these error messages and pass them back to the query
originator (possibly with the exception of the serverError element which
seems to only apply to an error indication that a resolving LoST server
would receive from a responding LoST server).  Is this correct?


Thanks, in advance, for any clarification that can be provided.


Terry Reese
Telcordia Technologies

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