Subject: [tsvwg] Murray Kucherawy's No Objection on draft-ietf-tsvwg-rfc4960-bis-17: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 15 Dec 2021 23:36:00 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-tsvwg-rfc4960-bis-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also relied largely on the diff to RFC 4960 for my review, and I only found a
couple of things to mention.

First, I'm also curious about the Internet Standard question raised by other
ADs.

Section 15.4, which is largely copied from RFC 4960's Section 14.3, defines a
Specification Required registry.  RFC 8126 says that advice for the designated
expert reviewing these should be provided.  I realize such was missing from the
original; should we take this opportunity to add some?

Section 15 as a whole is really big; the text in 15 (i.e., all the stuff before
15.1) could probably benefit from being broken into subsections.

---

From: [email-masked]
Date: Thu, 23 Dec 2021 10:53:46 +0100

> On 16. Dec 2021, at 08:36, Murray Kucherawy via Datatracker <[email-masked]> wrote:
> 
I guess this has been discussed and the outcome was that this document will
be PS, at least initially.
> original; should we take this opportunity to add some?
Martin already addressed this and asked for experts for the ERROR causes and
also for the SCTP AUTH HMAC registry. I don't think any change is needed in
this document.
> 15.1) could probably benefit from being broken into subsections.
I agree. This is due to an explicit list of changes where only the reference is
changed to this document. I did not want to distribute the text in the subsections,
because I wanted to keep the subsections as clean as possible to describe the
actions required to add an entry to the corresponding registry. Adding the new
subsection would change the numbering, which I also find suboptimal.
So I do know that it is not optimal, but, at least for me, it seems to be a
compromise...

Please let me know if you disagree and prefer a re-structuring.

Best regards
Michael