Hi Adrian,
Without disparaging your other comments, I think this is the one that needs
discussion:
4. Why do you limit access to reviewers of the document. Surely all
implementers and operators will need access for all time. Otherwise,
what is the value of the document? Thus, you can say "All readers,"
or "All users," and lose the second paragraph.
Consider that we have an irresistible force (the IETF) meeting immovable
objects (the IEEE and the IEC, to continue with Carsten's example).
If we want to write an IETF standard that explicitly depends on an
IEEE/IEC standard, we basically have no realistic alternative to citing
a paywalled document. Requiring that the IETF protagonists ensure that
reviewers have access to the paywalled document seems to be a reasonable
compromise between the dream world where all standards are freely available
and the world we actually live in.
Whether implementers or operators are willing to pay for access, or risk
going to court, really isn't the IETF's call. As already mentioned, there's
an analogy with other IPR issues. We *prefer* unencumbered technology and
unencumbered citations, but this can never be 100% achievable.
Regards
Brian
On 12-May-24 01:37, Adrian Farrel wrote:
Hi,
I appreciate the effort to make incremental changes to process. That is
the right way to do things.
However, I'm not convinced about the need for this draft, and I have a
few comments.
Cheers,
Adrian
===
Section 1
Since the publication of BCP 9, such external references have become
more common.
I don't doubt you, but since this statement is unsubstantiated, it made
me wonder, whether it matters. I think it doesn't and could be omitted.
---
Section 1
Some of these external references, however, present a
challenge, as they may not be freely available.
Why "however"?
---
Section 1
BCP 9 also discusses references from standards track specifications
to those of lower maturity levels. Updated guidance on this matter,
and the first definition of the notion of "normative" versus
"informative" references, can be found in BCP 97. BCP 97 also
defines the terms "source" and "target" documents.
This document presents a procedure to be used when evaluating
standards track IETF documents that make normative references to
external specifications.
Given the second paragraph, what is the purpose of the first paragraph?
It's true and interesting, but not relevant to this document. Although
the definitions of "source document" and "target document" are used in
this document.
---
Section 2
Authors/editors of source documents may be required by the IESG to
secure freely available copies of the target documents for use by all
anticipated reviewers during the source document's life cycle, which
includes working group participants, any member of the community that
chooses to participate in Last Call discussions, area review teams,
IANA expert reviewers, and members of the IESG. The mechanism for
acquiring access to those documents is to be specified in the
shepherd writeup.
Note that there is no requirement for a freely available copy of the
reference after the publication of the draft as an RFC, nor is there
any requirement that the copies be provided to the general public.
As others have noted, this gives the IESG power to require action. I
have issues:
1. Authors/editors only serve the working group. Don't require them to
do stuff.
2. The IESG serves the community and steers. If the community has
consensus to do otherwise, why is the IESG making this requirement?
Maybe request or suggest? (Note that even a Discuss is not a
requirement.)
3. Following on from the previous, if you want to set a rule, set a
rule. Don't leave it to the variations in IESG membership to
determine what has to be done, but give a clear set of instructions
to the producers of all documents. If your problem is that sometimes
it's OK to have a reference and sometimes it isn't, can you give any
guidance on when to do what?
4. Why do you limit access to reviewers of the document. Surely all
implementers and operators will need access for all time. Otherwise,
what is the value of the document? Thus, you can say "All readers,"
or "All users," and lose the second paragraph.
5. The shepherd write-up comes late in the process: certainly after the
working group has written the document, after "early" Directorate
reviews, and working group last call. So, doesn't the mechanism need
to be documented somewhere else? Probably in the reference in the
document.
---
Section 2
Another path forward may be to generate an RFC of appropriate status
that captures the important parts of the intended target document.
Sure, but...
- Copyright of the source material (in the target document)
- Inherited IPR
- Accidental divergence from the target document
- Determination of accuracy through review by the originators of the
target document
-----Original Message-----
From: iesg-secretary@xxxxxxxx <iesg-secretary@xxxxxxxx>
Sent: 10 May 2024 16:51
To: IETF-Announce <ietf-announce@xxxxxxxx>
Cc: draft-kucherawy-bcp97bis@xxxxxxxx
Subject: Last Call: <draft-kucherawy-bcp97bis-05.txt> (Procedure for Standards Track Documents to Refer Normatively to External Documents) to Best Current Practice
The IESG has received a request from an individual submitter to consider the
following document: - 'Procedure for Standards Track Documents to Refer
Normatively to External Documents'
<draft-kucherawy-bcp97bis-05.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2024-06-07. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
This document specifies a procedure for referencing external
standards and specifications from IETF-produced documents on the
Standards Track. In doing so, it updates BCP 9 (RFC 2026).
The file can be obtained via
https://datatracker.ietf.org/doc/draft-kucherawy-bcp97bis/
No IPR declarations have been submitted directly on this I-D.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
