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

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Mar 2022 14:37:33 +0100

Russ, thank you for your review. I have entered a No Objection ballot for this document.

Lars

> On 2022-1-30, at 2:00, Russ Housley via Datatracker <[email-masked]> wrote:
> 
> 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/
> 
> 
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call