On 15/04/2025 16:52, Deb Cooley wrote:
Having done this once myself....
And just as a clarification for how the 'sausage is made'. There is
a choice of sending or not sending comments (classically if I'm only
thanking a secdir reviewer, I'll spare the list and not send the
comments.). To send comments is a two step process, and if you miss
the second step, then possibly they don't get sent. They *should*
still be in the history for the draft...
I fully expect to make this mistake again myself, so I won't cast stones.
Deb
Thanks for noting this: Yes, I was half-way through entering stuff and
discovered I would very soon loose connectivity, so pressed save.
I don't of course plan to change my comments - and I see someone has
already picked-up, so I'll simply follow-on from where we now are.
Sorry for any confusion,
Gorry
On Tue, Apr 15, 2025 at 11:23 AM Michael Richardson
<mcr+i...@sandelman.ca <mailto:mcr%2bi...@sandelman.ca>> wrote:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/ballot/
The comments from Gorry did not get to the mailing list and are
not in the archives.
We were confused by this, until we saw that it says "Not sent" in
the upper
corner. I didn't know that was an option, or a thing, and I'm
guessing maybe
Gorry didn't either. I wondered perhaps if the plumbing failed,
but I guess
intentional.
Here they are for the purposes "of the tape" (archive) his comments:
----
Thank you for preparing this document. I have the following four
questions
where I'd appreciate more clarity in the text:
1. The text says: “SHOULD NOT provide information beneficial to an
attacker”.
I don’t understand the RFC 2119 SHOULD recommendation. To me, the
current
text does not say what actually has to be done, or what ought not
to be done
(e.g. citing some suitable RFCs to help clarify what is needed).
Also I do
wonder whether this be a “MUST”? (i.e., under what conditions is it
considered good to provide information to benefit an attacker?).
Could this
just be wisdom - e.g.”needs to avoid”, rather than a protocol
requirement?
2. “TLS 1.2 MAY be used”, please could you explain why this is
only "MAY"
rather than being stronger, noting draft-ietf-uta-require-tls13
and RFC 9325,
which asserts that TLS 1.3 is in widespread use.
3. I could not understand the protocol action of the “MUST”
requirement below
(i.e. what does “available” mean for a RFC2119 requirement?:
“if the certificate chain
is not included in the x5c Header Parameter, it MUST be
available
at the domain registrar for verification”
Please consider changing this text, for instance text like the
following could be helpful:
“if the certificate chain is available at the domain registrar for
verification, it MAY be omitted from the x5c Header Parameter“.
4. Please update the text to explain/clarify:
“The registrar MAY consider ignoring any but the newest PER
artifact from the same pledge in case the registrar has at any
point
in time more than one pending PER from the pledge?"
I don't understand the requirement from the text, please explain: For
example, could this perhaps be a RFC2119 requirememnt: "MAY
ignore" .. and
then add text to describe when this is allowed (or not).
Comment (2025-04-10) Not sent
1. There appears to be some slight format problem with the bullets
I saw
listed in my rendering:
“such as: * Avoid
logging personally identifiable information unless unavoidable. *
Anonymize or pseudonymize data where possible.”
2. I did not understand the list of three security considerations
at the
start of section 12. At least, it would be very helpful to explain
these in
sufficient detail to understand each, and also helpful to
understand the
implications for users of each. Some words to clarify would be
very helpful.
3. Please could you add text to explain “no transport layer
security between
Registrar-Agent and pledge..” e.g., please explain: Is this
something that
users ought to add to a design? how? why? is it a desirable
property? Why?
... or is this intended to be explained more in the next subsections?
... Especially since 7.1 speaks of optional use of TLS.
4. Please update the text to clarify what is intended by: “Pledges MAY
support both initiator and responder mode.” Is this MAY intended
to permit
*both* of the modes, or *either* of the modes, or something else?
5. Please consider updating the text:
“503 Service Unavailable: if a simple retry of the
Registrar-Agent
request might lead to a successful response; this error response
SHOULD include the Retry-After response header field with an
appropriate value”
- Why is this not a MUST, if there is a reason, please explain the
alternative and when this is a suitable response.
--
Michael Richardson <mcr+i...@sandelman.ca
<mailto:mcr%2bi...@sandelman.ca>> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
