Review of: draft-ietf-ecrit-lost-sync-01
I've provided a review of the lost-sync draft, with the following comments - mostly minor wording and grammatical. Assuming that the authors are Ok with the changes, I would encourage the chairs to put the (next) revised version draft into WGLC straight away.
List of (12) Comments:
C1. Abstract, rewording of how LoST works:
Change from:
" The LoST (Location-to-Service Translation) protocol is used to map
locations to service URLs."
Change to:
" The LoST (Location-to-Service Translation) protocol is used to map
locations and service URNs to service URIs."
C2. Introduction, rewording (same as above):
Change from:
" The LoST (Location-to-Service Translation) protocol [RFC5222] maps
geographic locations to service URLs. "
Change to:
" The LoST (Location-to-Service Translation) protocol [RFC5222] maps
geographic locations and service URNs to service URIs. "
C3. Introduction, pp1., minor rewording of sentence:
Change from:
"...there are a
variety of LoST servers that cooperate to provide a global, scalable
and resilient mapping service. "
Change to:
"...there are a
variety of LoST servers that cooperate to provide a ubiquietous, globally scalable
and resilient mapping service. "
C4 Section 2, Terminology, minor change to fix missing space:
Change from:
" ,"RECOMMENDED"
Change to:
" , "RECOMMENDED"
-----^-----
C5. Section 3, Distributing Mappings..., change wording for consistency:
Change from:
"If the querier
attempts to remove a non-existent mapping, the query is silently
ignored."
Change to:
""If the querier
attempts to delete a non-existent mapping, the query is silently
ignored."
C6. Section 3, pp4, minor wording changes throughout paragraph for readability:
Change from:
" The response to a <pushMappings> request is a <pushMappingsResponse>,
currently without additional elements, if the request was successful
or an <errors> response if the request failed. Only the
<badRequest>, <forbidden>, <internalError> or <serverTimeout> errors
defined in Section 13.1 of [RFC5222] are used. Neither the
<redirect> nor the <warnings> messages are used for this query."
Change to:
" The response to a <pushMappings> request is a <pushMappingsResponse> response message.
Currently, a successful response message returns no additional elements, whereas an <errors> response is
returned in the response message, if the request failed. Only the errors, <badRequest>, <forbidden>, <internalError> or <serverTimeout>,
defined in Section 13.1 of [RFC5222], are used. The <redirect> and <warnings> messages are not used for this query/response."
C7. Section 3, pp5, minor word correction::
Change from:
" ...giving the relatively low volume of data.)"
Change to:
" ...given the relatively low volume of data.)"
C8. Section 3, pp7, wording changes to clarify text:
Change from:
" An example is shown in Figure 1. In the example, the mappings with
sourceId 7e3f40b098c711dbb6060800200c9a66 sourceId
7e3f40b098c711dbb606011111111111 are added by the recipient. The
last mapping, with source 'nj.us.example' and sourceID 'englewood',
is removed."
Change to:
" An example is shown in Figure 1. In the example, both the mappings with
source 'nj.us.example' and sourceId's 7e3f40b098c711dbb6060800200c9a66, and
7e3f40b098c711dbb606011111111111, respectively, are added by the recipient. The
last mapping, with source 'nj.us.example' and sourceID 'englewood',
is deleted."
C9. Section 6.1., LoST Synchronization Namespace Registration
The example of xml seems to lack some explanatory text to go with it, e.g.,
what is this registory for?, etc.
C10. Figure 2., minor xml error, which causes validation error (extraneous close mark)
Change from:
"<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync" />
Change to:
"<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync">
C11. Figure 4., minor xml error, which causes validation error:
Comment:
"<mapping " element does not get a closed, ">", which should be added.
C12. Running the draft through the idnits 2.11.00 yielded the following comment, for which I couldn't resolve (nothing apparent to me that wasn't covered in RFC3979). Here's the output:
tmp/draft-ietf-ecrit-lost-sync-01.txt:
Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see http://trustee.ietf.org/license-info), which is required from
December 16, 2008. Version 1.34 of xml2rfc can be used to produce
documents with boilerplate according to the mentioned Trust License
Policy document.
/end of comments
-roger marshall.
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________ Ecrit mailing list Ecrit at ietf.org https://www.ietf.org/mailman/listinfo/ecrit