(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
