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 On Tue, Apr 15, 2025 at 11:23 AM Michael Richardson <mcr+i...@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> . 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
