Re: [AVTCORE] Zaheduzzaman Sarker's Discuss on draft-ietf-payload-rtp-jpegxs-16: (with DISCUSS)

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

Stephan,

Thanks for your comments.  My language ("usable") may have been a bit
broad; I agree with your assessment.  The problem is the basic notion of
how a reviewer, particularly an IESG member, is supposed to evaluate a
document when some of its normative references are not freely available, as
you described.

I imagine until we have some kind of automatic process in place where the
referenced ISO specification is made available to the IESG or other
reviewers during the normal processing cycle of the document, we're going
to continue to hit snags like this.  Another problem is consistency.  I
checked with the RFC Editor and found that there have been other recent
I-Ds passed through the IESG that had an external normative reference
behind a paywall and it seems on cursory review of the final ballot
positions that nobody noticed or thought to raise it; the fact that an IESG
member would actually like to see the content of the referenced document is
the reason it matters this time.

At any rate, I think the outcome of Tim's inquiry to ISO will inform our
next step hre.

-MSK

On Fri, Jun 18, 2021 at 9:01 AM Stephan Wenger <[e-mail]> wrote:

> Murray,
>
> First, it’s not that the 21122 is not publicly available.  It is, please
> see here: https://www.iso.org/standard/74535.html  I think the issue at
> hand is that the document is not available **for free**.  AFAIK, the IETF
> does not have a written requirement for normative reference to be free, but
> requiring every interested WG/IESG member to pay a CHF 178 fee for a
> license to enable a review is also not easily palatable.
>
> Second, there are many examples where the IETF normatively references ISO
> documents that are equally not available for free.  You can go back to RFC
> 2250, or, for a more recent one, you can look at RFC 6416.
>
> Stephan
>
>
>
> *From: *avt <[e-mail]> on behalf of "Murray S. Kucherawy" <
> [e-mail]>
> *Date: *Friday, June 18, 2021 at 08:50
> *To: *Tim Bruylants <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> The IESG <[e-mail]>
> *Subject: *Re: [AVTCORE] Zaheduzzaman Sarker's Discuss on
> draft-ietf-payload-rtp-jpegxs-16: (with DISCUSS)
>
>
>
> On Thu, Jun 17, 2021 at 12:10 PM Tim Bruylants <[e-mail]> wrote:
>
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > This memo is defining a RTP payload for JPEG XS that is not publicly
> available.
> > This hampers the review of the memo, specially when it is defining
> terminologies which ask me to look at the specifications.
> >
> > This concerns has also been raised by other ADs.
> >
> > Was this document made available during the work in the working group?
>
>
> This is a valid comment. We are unsure how to resolve this. ISO is very
> strict about distribution of documents outside of the working groups (i.e.
> it is not allowed at all).
> The ISO 21122 standards were written by some of the same authors as this
> RTP Payload spec (like myself and Thomas Richter), but the ISO documents
> were (to my knowledge) not shared.
>
> In order to resolve this issue, we need to know how IESG handled this with
> other ISO standards that are not open? Or is 21122 the first? Please advise.
>
>
>
> This is the first one like it in my time on the IESG, and I must admit I
> didn't even think to check that this external reference was usable.  I'm
> glad Zaheduzzaman caught it.
>
>
>
> It might alleviate the problem to reduce this to an informative reference,
> but it doesn't look to me like you could make the argument that you don't
> need the ISO standards to implement this.  You're not simply wrapping their
> protocol as-is; you need some header details, for example.
>
>
>
> I've asked the RFC Editor if they know of any documents that proceeded
> with closed references to ISO documents.  If there are any, I'll review
> their processing history and see if I can find a path forward here.
>
>
>
> -MSK
>