Re: [Ecrit] Genart last call review of draft-ietf-ecrit-similar-location-17

[Randall Gellens <[e-mail]>]

(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.,
    containing the <locationValidation> element with no elements listed
    as invalid,

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

--Randall

On 29 Jan 2022, at 17:00, Russ Housley via Datatracker 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/