1) The definition of the LocationURI format in section 2.3 says that the definition
of each LuriType field value will define the unit of measurement for the LuriLength
field. The two LuriTypes defined in this document don't provide that definition.
2) It's not clear if a response containing a LuriType=2 frame, but no LuriType=1 frame
is valid, and what a client should do if it recieves one.
3) The registration policy of section 4.3 is not clear. Are you aiming for one of the
well-known policies in section 4.1 of RFC 5226?
4) That said, why is the registry in section 4.3 necessary at all? Prose in the RFC, rather
than a registry, is going to be more useful to the implementer - the approach that
sipcore-location-conveyance takes just under the BNF for Geolocation-header in section
4.1 of that document would work here just as well.
5) Should the refresh recommendation in section 2.3 include some randomization? Without it,
do we have all of the elements that got their location URI from this option at the same
time during an avalance-restart attempting to refresh at the same time?
6) I can't parse the sentence in 2.3 that starts "A Location URI refresh SHOULD be done during
the normal DHCP refresh rate,...". In particular, extracting the expected normative behavior
out of that sentence is difficult. Here's an attempt at a rewrite - does it say what was
intended?:
A client will update is Location URI either as part of the normal DHCP lease renewal, or
through a renewal request sent due to the Valid-For timer reaching the value described
in this document. Note that in the second case, the request could ask only for the LocationURI
option.
7) In section 3.2's first bullet, why is this a SHOULD NOT and not a MUST NOT? Would it be
better if the sentence said "be automatically sent" rather than "be sent"? Similarly, why
is the SHOULD NOT in the second bullet not a MUST NOT?
8) Why does section 3.3 rule out the use of XMPP with pres: URIs?
It looks like -03 was the last version of this document reviewed by DHC. I'm requesting
an updated review.
Nits:
* The one-sentence Abstract needs editing. Currently it talks about "a client's URI of a client".
Please simplify the structure. Breaking it into multiple sentences would help.
* First paragraph of the introduction: Suggest s/associated by/associated with/
* In section 3, instead of "location URIs such as <...> are to be done, ... rather than <...>"
I suggest "For example, creating a location URI such as <sips:...> is better than a location
URI such as <sips:aliceisat...>. The username portion of the first example URI provides no
direct identiy information."
* In section 3, I suggest either deleting the sentence that starts "The entity= discussion",
or replacing it with something like "The considerations for populating the entity attribute
value in a PIDF-LO document are independent from the considerations for avoiding exposing
identification information in the username part of a location URI."
* The end of Section 3.3 points forward to section 4.2, but it should point to 4.3 if we keep
that registry.
* I suggest deleting the sentence that starts "Penetrating an LS is supposed to be hard". Its
a good sentiment, but it's captured in the documents that define an LS, and it doesn't help
the implementer of this document.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
