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 <noreply@xxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
