Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol
RFC 6739

Note: This ballot was opened for revision 17 and is now closed.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-04-25 for -17)
No email
send info
I see from the charter that this I-D was planned as Experimental.
Although it is in no way a requirement for publication, I would really
like this document to provide some explanation as to why it is targeted
as Experimental. I would also like to see some parameters of the 
"experiment" - what is the scope? how does the experiment need to be
contained? what feedback are the authors/WG looking for from 
experimenters? how will the experiment be judged a success?

(Stephen Farrell) No Objection

Comment (2012-04-25 for -17)
No email
send info
- typo: singed mappings

- what TLS authentication is required if any? Are anon 
ciphersuites ok or not? Is TLS mutual auth required or
not? Be good to say either way.

- Is there any requirement that the TLS server/client 
certs map to anything associated with the service (e.g.
its DNS name) or with anything in the payload? Again
be good to say either way.

- Maybe this is my ignorance of LoST and Relax NG, but
where do the <Signature> elements go in this protocol
and what elements are required to be signed?

(Brian Haberman) No Objection

Comment (2012-04-24 for -17)
No email
send info
I agree with Pete's feedback that there is a significant amount of fluff in this document that is not needed.

Other comments:

1. The second paragraph of section 4.2 states: "A newly received mapping MUST update an existing one having the same 'source' and 'sourceID' and a more recent time in 'lastUpdated'.  That seems rather confusing sentence structure, so I would recommend something like: "If a newly received mapping has a more recent time in its 'lastUpdated' attribute, it MUST update an existing mapping that has matching 'source' and 'sourceID' attributes.".

2. In section 4.1 (2nd paragraph) : s/SHOULD keep track to/SHOULD keep track of/.

3. Second sentence of section 4.3 should start with "Imagine" rather than "Image".

(Russ Housley) No Objection

Comment (2012-04-25 for -17)
No email
send info
  Please consider the editorial comments from the Gen-ART Review by
  Wassim Haddad on 24-Apr-2012:
  - Perhaps I missed it somewhere in the document, but I could not find
    the meaning of "ESRPs" (page 5)
  - Suggest re-writing the last paragraph on page 8 
  - Suggest re-writing the 3-line paragraph on page 9

Barry Leiba No Objection

Comment (2012-04-25 for -17)
No email
send info
Some minor, non-blocking comments:

-- Section 7 --

Are there any ways to encounter or avoid synchronization loops other than what you say in the first two paragraphs here?  What happens if a buggy node always modifies "last updated" to the current time before relaying a mapping?  Would there be any way to stop a loop?

It's more than a typo that singes things; this sentence is hard to read:
   digitially singed mappings mappings cannot be modified by
   intermediate LoST servers.
   mappings are digitially signed, they cannot be modified by
   intermediate LoST servers.

-- Section 8 --

Just noting that the second paragraph seems oddly familiar......

-- Section 9.1 --

The title and the first sentence each use different terms for what we now prefer to call "Media Type".  It's not a big deal, but you might please switch to that term.

-- Sections 9.2 and 9.3 --

IANA probably knows where you're registering these, but I don't, and I'm always worried about registration errors.  I suppose as long as it's clear to IANA, it's OK... but can you specify exactly what registries (using the exact names and perhaps URLs, from ) you mean?

(Pete Resnick) (was Discuss) No Objection

Comment (2012-07-10)
No email
send info
Thanks for the changes. Still outstanding, and again, it is between you, the WG, and the AD whether to make these changes, but I strongly recommend:

Section 3: I do not find this section useful. Perhaps as an appendix, but even there, I think it should be removed.

Section 5.1:

   The LoST Sync source SHOULD keep track to which LoST Sync destination
   it has pushed mapping elements.  If it does not keep state
   information then it always has to push the complete data set.

In the first two sentences, do you really mean:

   The LoST Sync source SHOULD only push new mapping elements which it
   has not previously pushed to the LoST Sync destination.

Your current text is making a requirement about internal state of the implementation. What I have above is a protocol requirement. I think that's what you meant.

   A <pushMappings> request sent by a LoST Sync source MUST containing
   one or more <mapping> elements.

Do you mean, "A <pushMappings> request sent by a LoST Sync source MUST contain at least one or more <mapping> elements" or "MUST NOT be empty" or something like that? What is the requirement here? What are you trying to prevent?

Section 5.2:

   A newly received mapping MUST update an existing one having the same
   'source' and 'sourceId' and a more recent time in 'lastUpdated'.

Again, what's the protocol requirement here that requires the 2119 imperatives? Don't you really mean, "A newly received mapping that has the same 'source' and 'sourceID' as a previous mapping with a more recent 'lastUpdated' time is an update to the existing mapping."?


   If the received mapping does not match with any existing mapping
   based on the 'source' and 'sourceId' then it MUST be added to the
   local cache as an independent mapping.

"Otherwise, it is a new independent mapping." Again, what bad behavior are you trying to prevent with the "MUST"?

Section 6:

   This document uses HTTPS as a transport to exchange XML documents.

No it doesn't. There is nothing in this document concerning the use of HTTPS or any other transport protocol. I don't even think the document "assumes" the use of HTTPS. I think this section can be struck from the document without any harm.

Section 10.1:

The ietf-types review pointed out specific language from RFC 3023 section 7.1 that should be used in the registration of application/lostsync+xml.

   Encoding considerations:  Identical to those of "application/xml" as
      described in [RFC3023], Section 3.2.

Not that it makes a real difference, but you might as well replace with "Same as encoding considerations of application/xml as specified in RFC 3023" to keep it consistent with the precise language of 3023.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2012-04-25 for -17)
No email
send info
I echo Stephen's comments.

s5: Not sure if it's worth it but maybe mentioning that only offering HTTPS is different than RFC 5222 because it offers HTTP as well.  Maybe saying because this is exchanging authoritative data it's inappropriate to use HTTP?  Maybe you could do this in the 1st paragraph of the security considerations:

  Hence, the protocol operations described in
  this document require authentication of neighboring nodes,
  which is why HTTPS is required.