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

[Russ Housley <[e-mail]>]

Randall:

This direction seem fine to me, but I think you misunderstood my suggestion (4).  I am just suggesting a change in ordering,  State the definition, and then use the defined term.

Russ


> On Jan 31, 2022, at 5:59 PM, Randall Gellens <[e-mail]> wrote:
> 
> (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/
> 
> -- 
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call