Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol
draft-ietf-ecrit-lost-sync-18

[Ballot comment]
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  request sent by a LoST Sync source MUST containing
  one or more  elements.

Do you mean, "A  request sent by a LoST Sync source MUST contain at least one or more  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."?

Similarly:

  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.

[Ballot comment]

  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

[Ballot comment]
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:
OLD
  With
  digitially singed mappings mappings cannot be modified by
  intermediate LoST servers.
NEW
  When
  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 https://www.iana.org/protocols/ ) you mean?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
- 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  elements go in this protocol
and what elements are required to be signed?

[Ballot comment]
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".

[Ballot discuss]
Section 9.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. Please fix:

  Optional parameters:  charset

      Indicates the character encoding of enclosed XML.

Replace with "Same as charset parameter of application/xml as specified in RFC 3023."

[Ballot comment]
[Just a reminder: None of the following cause me as an AD to hold up publication of the document. They are just the (sometimes strongly held and expressed) beliefs of yet another bozo in the IETF community. Take them as such.]

Section 1:

This is supposed to be a technical specification, not an academic paper. I find the 6 pages of fluff in the introduction to be useless and distracting to the reader. It is poorly written and never actually describes the purpose of the document. I have to wait until the first full paragraph of page 8 to see:

  This document defines two types of exchanges and those are best
  described by the exchange between two nodes as shown in Figure 5 and
  Figure 6.

Don't explain by pointing me to diagrams and examples. Explain in words. I think this section should be completely rewritten and reduced to 2 paragraphs. The current introduction diminishes the document.

Section 4.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. You continue:

  As discussed in Section 5.1 of [RFC5222], mapping elements are
  identified by the 'source', 'sourceID' and 'lastUpdated' attributes.
  A mapping is considered the same if these three attributes match.  It
  is RECOMMENDED not to push the same information to the same peer more
  than once.

So, I must ask why is RECOMMENDED not to push the same information to the same peer? Is it simply bandwidth considerations? Or processing on the peer? Why the 2119 imperative?

  A  request sent by a LoST Sync source MUST containing
  one or more  elements.

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

Section 4.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."?

Similarly:

  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 5:

  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 9.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.

IESG:

IANA has reviewed draft-ietf-ecrit-lost-sync-17.txt and has
the following comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are three IANA
Actions that need to be completed.

First, in the Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new media type will be registered as follows:

lostsync+xml

the registration details are located in Section 9.1 of the document.

IANA Question --> Has Expert Review taken place for this media type registration?

Second, in the Schema registry of the IANA XML Registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new schema will be registered as follows:

ID: lostsync1
URI: urn:ietf:params:xml:schema:lostsync1
Filename: [ As provided in Section 6 of the approved document ]
Reference: [ RFC-to-be ]

Third, in the Namespaces registry of the IANA XML Registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new namespace will be registered as follows:

ID: lostsync1
URI: urn:ietf:params:xml:ns:lostsync1
Registration Template: [ As provided in Section 9.3 of the approved document ]
Reference: [ RFC-to-be ]

IANA understands that these are the only actions IANA must complete upon
approval of the document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements) to Experimental RFC





The IESG has received a request from the Emergency Context Resolution

with Internet Technologies WG (ecrit) to consider the following document:

- 'Synchronizing Location-to-Service Translation (LoST) Protocol based

  Service Boundaries and Mapping Elements'

  as an Experimental RFC



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-18. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  The Location-to-Service Translation (LoST) protocol is an XML-based

  protocol for mapping service identifiers and geodetic or civic

  location information to service URIs and service boundaries.  In

  particular, it can be used to determine the location-appropriate

  Public Safety Answering Point (PSAP) for emergency services.



  The main data structure, the  element, used for

  encapsulating information about service boundaries is defined in the

  LoST protocol specification and circumscribes the region within which

  all locations map to the same service Uniform Resource Identifier

  (URI) or set of URIs for a given service.



  This document defines an XML protocol to exchange these mappings

  between two nodes.  This mechanism is designed for the exchange of

  authoritative  elements between two entities.  Exchanging

  cached  elements, i.e. non-authoritative elements, is

  possible but not envisioned.  In any case, this document can also be

  used without the LoST protocol even though the format of the

    element is re-used from the LoST specification.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/ballot/





The following IPR Declarations may be related to this I-D:



  http://datatracker.ietf.org/ipr/1257/

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding to
the IESG for publication?

Marc Linsner (mlinsner@cisco.com  )

Yes, this document is ready for publication.

(1.b) Has the document had adequate review both from key WG members and from
key non-WG members? Does the Document Shepherd have any concerns about the
depth or breadth of the reviews that have been performed?

The document has gone through repeated wg reviews and a review by the XML
directorate.

(1.c) Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization or XML?

No, the document is ready for publication.

(1.d) Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts
of the document, or has concerns whether there really is a need for it. In
any event, if the WG has discussed those issues and has indicated that it
still wishes to advance the document, detail those concerns here. Has an IPR
disclosure related to this document been filed? If so, please include a
reference to the disclosure and summarize the WG discussion and conclusion
on this issue.

IPR 1257 was announced to the wg on 2/8/10
(http://www.ietf.org/mail-archive/web/ecrit/current/msg07012.html
) with no
ensuing discussion. The protocol in this document is an extension of RFC
5222 where the identical IPR claims were filed (IPR 877 & 880).

(1.e) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

The document has a solid support base. There were 2 working group last
calls (1-24-09 -
(http://www.ietf.org/mail-archive/web/ecrit/current/msg05851.html) & 3-11-09
- (http://www.ietf.org/mail-archive/web/ecrit/current/msg06116.html
)). All
issues with this document were resolved to the consensus of the wg.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See the Internet-Drafts Checklist
and
http://tools.ietf.org/tools/idnits/  ).
Boilerplate checks are not enough; this check needs to be thorough. Has the
document met all formal review criteria it needs to, such as the MIB Doctor,
media type and URI type reviews?

As mentioned earlier, this document was reviewed by the XML Directorate and
passed the idnits tool.

(1.h) Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the strategy for their completion? Are there
normative references that are downward references, as described in
[RFC3967]? If so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, this document has references split between normative and informative.
All references are completed documents.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries clearly
identified? If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a reasonable name for
the new registry? See [RFC5226]. If the document describes an Expert Review
process has Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are clear and concise.

(1.j) Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

This document has validated correctly.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up? Recent
examples can be found in the "Action" announcements for approved documents.
The approval announcement contains the following sections:

Technical Summary

The Location-to-Service Translation (LoST) protocol (RFC5222) is an
XML-based protocol for mapping service identifiers and geodetic or civic
location information to service URIs and service boundaries. In particular,
it can be used to determine the location-appropriate Public Safety Answering
Point (PSAP) for emergency services.

The main data structure, the  element, used for encapsulating
information about service boundaries is defined in the LoST protocol
specification and circumscribes the region within which all locations map to
the same service Uniform Resource Identifier (URI) or set of URIs for a
given service.

This document defines an XML protocol to exchange these mappings
between two nodes. This mechanism is designed for the exchange of
authoritative  elements between two entities. Exchanging cached
elements, i.e. non-authoritative elements, is possible but not
envisioned. In any case, this document can also be used without the LoST
protocol even though the format of the  element is re-used from the
LoST specification.

Working Group Summary

There is consensus in the WG to publish this document.

Document Quality

The LoST Sync protocol was implemented during the development of RFC 5222
specification. This extension has been tested in various company-internal
implementations, as reported to the wg chairs. Two open source
implementations
were made available by Columbia University and by Goettingen University.
Interoperability tests between them have been made. The code produced by
Goettingen University is still available at:
http://sourceforge.net/projects/heldandlost/files/
The LoST specification has experienced extensive review, including reviews
by
other SDOs.

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding to
the IESG for publication?



Marc Linsner (mlinsner@cisco.com  )

Yes, this document is ready for publication.





(1.b) Has the document had adequate review both from key WG members and from
key non-WG members? Does the Document Shepherd have any concerns about the
depth or breadth of the reviews that have been performed?



The document has gone through repeated wg reviews and a review by the XML
directorate.



(1.c) Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization or XML?



No, the document is ready for publication.



(1.d) Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts
of the document, or has concerns whether there really is a need for it. In
any event, if the WG has discussed those issues and has indicated that it
still wishes to advance the document, detail those concerns here. Has an IPR
disclosure related to this document been filed? If so, please include a
reference to the disclosure and summarize the WG discussion and conclusion
on this issue.



IPR 1257 was announced to the wg on 2/8/10
(http://www.ietf.org/mail-archive/web/ecrit/current/msg07012.html
) with no
ensuing discussion. The protocol in this document is an extension of RFC
5222 where the identical IPR claims were filed (IPR 877 & 880).



(1.e) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?



The document has a solid support base. There were 2 working group last
calls (1-24-09 -
(http://www.ietf.org/mail-archive/web/ecrit/current/msg05851.html) & 3-11-09
- (http://www.ietf.org/mail-archive/web/ecrit/current/msg06116.html
)). All
issues with this document were resolved to the consensus of the wg.



(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is entered into the ID Tracker.)



No.



(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See the Internet-Drafts Checklist
and
http://tools.ietf.org/tools/idnits/  ).
Boilerplate checks are not enough; this check needs to be thorough. Has the
document met all formal review criteria it needs to, such as the MIB Doctor,
media type and URI type reviews?



As mentioned earlier, this document was reviewed by the XML Directorate and
passed the idnits tool.



(1.h) Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the strategy for their completion? Are there
normative references that are downward references, as described in
[RFC3967]? If so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].



Yes, this document has references split between normative and informative.
All references are completed documents.



(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries clearly
identified? If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a reasonable name for
the new registry? See [RFC5226]. If the document describes an Expert Review
process has Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during the IESG Evaluation?



The IANA considerations are clear and concise.



(1.j) Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?



This document has validated correctly.



(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up? Recent
examples can be found in the "Action" announcements for approved documents.
The approval announcement contains the following sections:



Technical Summary

The Location-to-Service Translation (LoST) protocol (RFC5222) is an
XML-based protocol for mapping service identifiers and geodetic or civic
location information to service URIs and service boundaries. In particular,
it can be used to determine the location-appropriate Public Safety Answering
Point (PSAP) for emergency services.



The main data structure, the  element, used for encapsulating
information about service boundaries is defined in the LoST protocol
specification and circumscribes the region within which all locations map to
the same service Uniform Resource Identifier (URI) or set of URIs for a
given service.



This document defines an XML protocol to exchange these mappings

between two nodes. This mechanism is designed for the exchange of
authoritative  elements between two entities. Exchanging cached
elements, i.e. non-authoritative elements, is possible but not
envisioned. In any case, this document can also be used without the LoST
protocol even though the format of the  element is re-used from the
LoST specification.



Working Group Summary

There is consensus in the WG to publish this document.



Document Quality

The LoST protocol was implemented during the development of RFC5222
specification. This extension has been tested in various company-internal
implementations, as reported to the wg chairs. The LoST specification has
experienced extensive review, including reviews by other SDOs. The protocol
extension is an important building block in the NENA i3 architecture.