Subject: [Ecrit] [ecrit] review of: draft-ietf-ecrit-lost-sync-01

From: "Roger Marshall" <[email-masked]>
Date: Mon, 19 Jan 2009 13:08:25 -0800

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 24 Jan 2009 19:09:01 +0200

Hi Roger, 
 
thanks for your review. I have addressed your comments and uploaded a new
version of the document, see 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-02.txt

e.g., 
> what is this registory for?, etc.  

This is necessary for the Relax NG schema. 

Ciao
Hannes