Suresh --
Thank you for the review. I agree these points needed clarification, have made some changes and just uploaded version 15.
My responses on each of your points are interspersed below.
On Wed, Jun 23, 2021 at 5:07 PM Suresh Krishnan via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Suresh Krishnan
Review result: Ready with Nits
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 treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-drip-reqs-??
Reviewer: Suresh Krishnan
Review Date: 2021-06-22
IETF LC End Date: 2021-06-07
IESG Telechat date: 2021-07-01
Summary:
It is a very interesting problem space and this document provides a good
overview along with the references.
Major issues:
Minor issues:
* The term RID is used to mean slightly different things in different locations
of the document. One very obvious example is in this sentence in Page 6
"However, applications of RID beyond RID itself"
probably need to be clarified a bit
SWC: done, and the related safety vs security text consolidated
* Section 4.1.1.
-> The following sentence fragment in GEN-3 is confusing
"UAS ID is in a registry and identification of which one"
Suggest rewording to
"UAS ID is in a registry and identification of the registry"
if my understanding of the intent is correct.
-> GEN-6: Not sure if "Finger" is a obvious description of this requirement for
somebody who has not read RFC742. Suggest rewording to something more broadly
understandable (e.g. "User Information")
as often it will be with a system rather than a user,
and enumerated those entities more specifically
-> It feels like Section 4.1.2. might be better placed before 4.1.1. as it
addressed some of the questions I had on the GEN-* requirements. The other
rationale sections were fine either way, but it may make sense to describe the
rationale consistently before the requirement.s
and 4.x.2 is only specific rationale for 4.x.1 requirements,
in answer to questions the reader won't even formulate
until after reading 4.x.1. Presenting the requirements first
makes ideas concrete, then they can be defended; trying to
justify them before presenting them fails to provide readers
with a clear notion of what is being justified. I conferred
with one of the co-authors and he agreed with this logic.
I can reverse this if there is consensus that most readers
would find it clearer that way?
Nits/editorial comments:
Again, thanks, and please look at revision 15 if you have time,
to verify whether I adequately addressed your concerns.
-- Stu
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
