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 <rg+ietf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
