Re: [AVTCORE] Roman Danyliw's Abstain on draft-ietf-avtcore-rtp-scip-05: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Jul 26, 2023 at 11:18 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> I am abstaining on this document as it is unclear to me how to evaluate
> this
> document.  Unlike most of the other recent “RTP Payload Format” document I
> could find, the text here avoids making a normative reference to a document
> formally describing a payload. Colloquially, I’m not sure how one can
> describe
> the “payload format of _something_” without normatively citing that
> _something_.


In my own view, if any part of the payload format needs to be understood by
someone implementing this specification, then the document defining the
payload format has to be a normative reference.  On the other hand, if it's
completely opaque, and for all you know the payload could actually be a
blob of zeroes or random bytes and it wouldn't affect this specification at
all, then it's fine that it's informative.


> Furthermore, the security basis for this document comes from this
> informative reference.
>

But this is a problem.  If all of the security properties of this document
are in that one, then I would imagine that one has to be a normative
reference, and at least the Security ADs have reason to ask questions.

In either case, once it's a normative reference, I think it's reasonable to
expect that it's available or can be made available to reviewers that feel
they need it to complete their review responsibilities.  "Reviewers" here
includes anyone that wants to or is asked to review the document, from the
working group, through the sponsoring AD, the directorate reviewers, and
the IESG.  That's not to say we can only produce standards that are built
atop other open specifications, but it does mean we can't do a complete
review of something that depends on something else that we can't access.

The IESG has been discussing revising guidance around normative external
references, because this exact issue has come up several times and it's a
problem each time.  After this week, I'll breathe life into that work again
now that we have a current case to use as an example.

In the 117 meeting just now, there was a claim that an Area Director (I
presume, or maybe some other reviewer) insisted that the missing reference
be made freely available with a deadline measured in hours.  Does anyone
have a copy of that demand?  That seems like something that deserves
followup.  I would expect, instead, that a reviewer making such a request
would say simply "I need that to review this", without imposing any kind of
deadline, much less an unreasonable one.

There's a separate message from Dan Hanson that holds RFC 8817 as an
example of where the IESG tolerated this.  I would note that Ben Kaduk (who
was on the IESG for that document) also had a DISCUSS position that noted
he "couldn't get my hands on my copy, at least on short notice".  I didn't
unearth the discussion that followed, but I note that his DISCUSS took over
six months to clear.  I think most of his other points are good, but they
don't overcome the desire to have the key references available to reviewers
when the document is being prepared for publication.

To Spencer's point, the current document shepherd writeup template at
https://datatracker.ietf.org/doc/shepherdwriteup-template/individual
includes this question, since last summer:  "List any normative references
that are not freely available to anyone. Did the community have sufficient
access to review any such normative references?"

So I like the idea discussed in the meeting of preparing a package for
reviewers when this issue might arise, to avoid this problem for future
documents.

Happy to discuss any of this further.

-MSK