Subject: [Ecrit] AD review draft-ietf-ecrit-lost-sync-12

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Sep 2011 13:22:14 -0500

AD review: draft-ietf-ecrit-lost-sync-12

Summary: There are some issues to address before moving this draft 
         to IETF LC for Experimental.

1) The last sentence of 4.1 (the section of sync source behavior) seems
   to talk about sync destination behavior, indicating that an attempt
   to delete a non-existent mapping will be silently ignored. That 
   is contradicted by the procedures specified in section 4.2.
   Which was intended?
   
2) I don't find the types review requests for application/lostsync+xml
   in the archive. If it's been requested, please send me a link.
   Otherwise, please request that review now.

3) Does the <include href="lost.rng"/> in the RelaxNG definition
   stand alone, or should the document call out what lost.rng is
   and how to find it?

4) Julian's Sep2010 review asked the working group to consider
   using GET for fetches instead of POST. Was there any subsequent
   discussion?

5) That review also suggested an update for the xmldsig-core
   reference that's not reflected here.

6) Has someone verified the XML for this version of the document?
   Julian explicitly noted in his review that he did not verify
   the examples.

NITS:

Section 1 Paragraph 4: s/expect for/except for/

Section 1 just after figure 5 and figure 6: 
     s/issuing the first/issues the first/

Please expand or provide pointers to the definition for PSAP and ESRP
on first use.

The examples use domain names (particulary in the "source" attribute
value) that end in lost-example.com. Can you change those to use
lost.example.com to better align with 2606? 

Section 5 2nd paragraph: s/to HTTP-level/to disable HTTP-level/
(That one is slightly more than a nit - the paragraph does not
parse correctly when it is missing that word.)

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 17 Sep 2011 21:00:57 +0300

Hi Robert, 

thank you for your review. 

>   is contradicted by the procedures specified in section 4.2.

Good catch.

I suggest to change the text in Section 4.1 

FROM:

   To delete a mapping, the content of the mapping is left empty.  The
   node can delete the mapping from its internal mapping database, but
   has to remember which peers it has distributed this update to.  The
   'expires' attribute is required, but ignored.  If an attempt is made
   to delete a non-existent mapping, the request is silently ignored.

TO:

To delete a mapping, the content of the mapping is left empty, i.e. the <mapping> element only contains the 'source', 'sourceID', 'lastUpdated', and 'expires" attribute. Figure 10 shows an example request where the mapping with the source="nj.us.example", sourceId="123", lastUpdated="2008-11-01T01:00:00Z", expires="2008-11-01T01:00:00Z" is requested to be deleted. Note that the 'expires' attribute is required per schema definition but will be ignored in processing the request on the receiving side. A sync source may want to delete the mapping from its internal mapping database, but has to remember which peers it has distributed this update to unless it has other ways to ensure that databases do not get out of sync. 

>   Otherwise, please request that review now.

We may have forgotten to send a request. I will do this right now. 

>   stand alone, or should the document call out what lost.rng is

lost.rng refers to the Relax NG schema from RFC 5222. Of course it does not say so anywhere in the document. 
It seems that we had made the mistake already in http://tools.ietf.org/html/rfc6197

I believe we have two choices here: 

1) We replace the string "lost.rng" with http://www.iana.org/assignments/xml-registry/schema/lost1.xsd
or
2) We add the following text somewhere: 

"
   In order to avoid copying pattern definitions from the LoST Relax NG schema (RFC 5222)
   to this document we include it as "lost.rng"  (XML syntax), or "lost.rnc"  (compact
   syntax) in the Relax NG schema defined in this document. 
"

What would you prefer? 

>   using GET for fetches instead of POST. Was there any subsequent

Hmmm. I believe we missed this remark. 

FYI: I have no problem using GET but I will ask the group whether there are any objections about changing it to GET. 

>   reference that's not reflected here.

I could definitely replace the current reference 
   [W3C.REC-xmldsig-core-20020212]
              Solo, D., Eastlake, D., and J. Reagle, "XML-Signature
              Syntax and Processing", World Wide Web Consortium
              FirstEdition REC-xmldsig-core-20020212, February 2002,
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212.

with this one:

   [W3C.REC-xmldsig-core-20020212]
              Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T. Roessler, "XML-Signature
              Syntax and Processing", World Wide Web Consortium
              Second Edition, W3C Recommendation, 10. June 2008,
http://www.w3.org/TR/xmldsig-core/.

>   Julian explicitly noted in his review that he did not verify

I have asked Andy Newton to do such a review. He did it earlier this year and spotted a couple of bugs. 

> parse correctly when it is missing that word.)

Will make these changes. 

Ciao
Hannes