On Mon, Oct 28, 2024, at 15:11, Dave Crocker wrote: > If the w/g says the Security Section is fine, isn't the burden to claim > otherwise on the reviewer, rather than the reviewer issuing general > requirements? The onus is always on the working group. The working group has a responsibility to put up a document that will achieve consensus for publication. I don't think that meeting the requirements in RFC 3552 is a stretch. Perhaps the original wasn't up to code, but slid by because 3552 was only 5 years old at the time. We're 20 years in now. > huh? An A/S is supposed to be about using one or a collection of > specification. That's why it is weird to include the security treatment, not a reason to push back on a request to document the security considerations. Ekr was only being generous by suggesting that it would be OK for a supplementary document to include both applicability and security information. FWIW, I think that this a case where draft-roach-bis-documents does not apply, even if I'm otherwise a proponent of that. The general form of the revision appears to be maintenance; documenting the state of the protocol as it relates to the transport is a pretty serious hole, even just from the perspective of interoperability[1]. [1] I mean, it's not even clear that this uses TCP directly. I'd have expected Section 3.1 to mention it at least once, but despite direction mention of TCP in the introduction, the protocol doesn't ever say "the client establishes a TCP connection". That it could also maybe say TLS there too seems like it wouldn't be too much of a stretch. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
