Last Call Review of draft-ietf-ecrit-similar-location-17
review-ietf-ecrit-similar-location-17-genart-lc-housley-2022-01-29-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ecrit-similar-location-17
Reviewer: Russ Housley
Review Date: 2022-01-29
IETF LC End Date: 2022-02-09
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:  None


Minor Concerns:

The Abstract could be much shorter.  I suggest:

   This document describes an extension to the LoST protocol that is
   specified in RFC 5222 that allows additional civic location
   information to be returned in the <locationValidation> element of a
   <findServiceResponse>.  This extension supports two use cases. First,
   when the input location is incomplete, the LoST server can provide a
   complete intended unique address.  Second, when the input location is
   invalid, the LoST server can identify one or more feasible locations.
   This extension is applicable when the location information in the
   <findService> request uses the Basic Civic profile as described in
   RFC 5222.

Section 1 says:

   ...  Use of this
   enhancement increases the likelihood that the correct and/or complete
   form of a civic location becomes known in those cases where it is
   incomplete or incorrect.

I think it would be more clear to turn the sentence around:

   ...  When incomplete or incorrect civic location information
   is provided, use of this enhancement increases the likelihood
   that correct and complete civic location can be learned.

Section 1 ends with a discussion about what the document contains, but
it is incomplete.  Either drop the paragraph, or tell what is coming in
all of the coming sections.

Section 3 says:

   ...  A server MUST NOT include Returned Location
   Information using a location profile that differs from the profile of
   the location used to answer the query and, by extension, MUST NOT
   include Returned Location Information using a location profile that
   was not used by the client in the request.

Can this be turned into a simple MUST statement?  Perhaps:

   ...  A server MUST include only Returned Location
   Information using a location profile that was used by the
   client in the request.

Section 3 says:

   In a LoST <findServiceResponse> indicating a Valid Location i.e.,
   containing the <locationValidation> element with no elements listed
   as invalid, the LoST server can use this extension to include
   additional location information in a <locationValidation> element.

I think this would be more clear if it defined a Valid Location, and
then use this definition:

   A Valid Location contains a <locationValidation> element without any
   elements listed as invalid.  In a LoST <findServiceResponse>
   indicating a Valid Location, the LoST server can use this extension
   to include additional location information in a <locationValidation>
   element.


Nits:

Section 2: s/here.  ./here./

Section 2: Some definitions end with a period, but one does not.
Please add the missing period.

Section 3: s/end-user/end user/

Section 3: s/intended by the user/intended by the end user/

Section 4: s/defined in RFC5222/defined in [RFC5222]/

Section 7: s/new threat/new security concern/