Subject: [Last-Call] Genart last call review of draft-ietf-ecrit-similar-location-17

From: Russ Housley via Datatracker <[email-masked]>
Date: Sat, 29 Jan 2022 17:00:56 -0800

Reviewer: Russ Housley
Review result: Almost Ready

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/

---

From: Dan Banks <[email-masked]>
Date: Mon, 31 Jan 2022 17:10:58 +0000

>    Information using a location profile that was used by the

I would prefer to avoid this simplification.  Although I think the meaning is intended to be the same, it is actually not.  The query can contain multiple locations in different profiles (but that derive from the same baseline profile), so the first restriction given is more restrictive than the second, which only follows as a consequence of the first.  The suggested text eliminates the more important restriction.  This could be fixed simply enough, however I also wish to avoid any chance that someone could interpret it wrongly.  I've spent too much time arguing with people over the precise meaning of language in other specifications, and I believe the current language provides less opportunity for that.

My preference is to keep the original text.  But if we were to change it to a single MUST statement, I would word it as follows:

When a server includes Returned Location Information, that Information MUST use the same location profile as the location used to answer the query.

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

I'm not opposed to the idea of defining Valid Location, but we already do that in section 2.  This description is also in error - the location itself does not contain a <locationValidation> element; the response does.  If anything, we could refer the reader back to section 2, or even omit the explanation entirely:

  In a LoST <findServiceResponse>
  indicating a Valid Location, the LoST server can use this extension
  to include additional location information in a <locationValidation>
  element.

But I do think the reminder of what indicates a Valid Location is useful here, so I slightly prefer the original text.

Dan Banks

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 31 Jan 2022 14:59:12 -0800

(1) I'm fine with the Abstract as it is, I don't think it needs to be 
shortened, but if Russ' suggestion is taken, I'd want his new text "This 
extension is applicable when the location information in the 
<findService> request uses the Basic Civic profile as described in RFC 
5222" deleted, as the extension can potentially be used with future 
profiles.

(2) Regarding the suggestion to either delete the final paragraph of 
Section 1 or expand it to list all the sections, an alternative is to 
edit it down to list only what's most useful to a reader, e.g., change:

    The structure of this document includes terminology, Section 2,
    followed by a discussion of the basic elements involved in location
    validation.  The use of these elements, by way of example, is
    discussed in an overview section, Section 3, with accompanying
    rationale, and a brief discussion of the impacts to LoST, and its
    current schema.

To something such as:

    A discussion of the basic elements involved in location
    validation, along with definitions of certain terms used in this
    document, is in Section 2.  Usage, with examples, accompanying
    rationale, and a brief discussion of the impacts to LoST and its
    current schema, is in Section 3.

(3) Regarding the MUST NOT text in Section 3, I'm fine with Dan's 
suggestions, but if we are rewording it, I suggest:

    The location profile of Location Information returned by a server
    MUST be the same as the profile of the location used to answer
    the query. By extension, this means that the profile of Location
    Information returned by a server MUST be a location profile used
    by the client in the request.

(4) Regarding the suggestion to add a definition of Valid Location, the 
document currently defines it; perhaps the suggestion is to define a new 
term such as "Valid Location Response" or "Valid Location Indication"? 
At any rate, since the document already defines Valid Location, we can 
just delete the explanatory:

    i.e.,
    as invalid,

This also aligns with Dan's suggested rewording. I'm also fine with 
leaving the text as is.

--Randall