On 12-May-24 20:44, Adrian Farrel wrote:
[top post]
I think, Brian, we agree that there is a line to be drawn.
We are debating where to draw that line.
At one end of the scale we have only "open standards may be referrnced," and at the other end is "any reference can be made."
In between, we are debating who needs what access and when. (Also with a dimension added by whether the reference is normative or not -- assuming the proper use of "normative".)
I can see the view that "key reviewers" can be claimed to need access. But who is a key reviewer? We have a consensus process: How can someone in a working group support a draft unless they can review it? How can an IETF last call be considered to form consensus if a normative reference is "hidden"?
Taking that a step further, what is the purpose of IETF standards work? If it is to make open standards that are free access and open to implement, then what does it mean if you have to pay to access a normative reference?
So, I think I am saying that you need to move the line a whole lot further over. And I am saying that it is not the IESG's job to tweak this per document: we should set IETF-wide "rules".
We did, in RFC 2026. This whole discussion is only a gloss on RFC 2026. When the IESG reaches a decision whether to advance a document, they have to judge whether the rules have been followed. I really don't see that the draft changes the rules in any fundamental way. It makes it harder to cite a paywalled draft, which is a good thing, but it doesn't forbid it, which would be self-defeating.
[The RFC 2026 rule is that "open standards" may be referenced, but its definition of "open standards" doesn't mention cost.]
Note that I observe two behaviours in working groups to get around all of this.
1. Inclusion of an (often very detailed) Appendix "explaining for the convenience of the reader" the referenced material. My principal concerns of this well-meaning approach are that it is not the IETF's job to re-interpret the work of other standards bodies, and that this interpretation may be (accidentally) inconsistent with the referenced external standard because it is not reviewed and cross-checked by the source standards body.
True. But if it's the best we can do, then it's the best we can do.
2. Transfer of references to external/paywalled documents to be Informative references even when they are used in a Normative way. This is, of course, plain wrong.
Agreed, that would just be cheating ourselves.
Brian
Cheers,
Adrian
On 11/05/2024 21:48 BST Brian E Carpenter <brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>> wrote:
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 <mailto:iesg-secretary@xxxxxxxx> <iesg-secretary@xxxxxxxx <mailto:iesg-secretary@xxxxxxxx>>
Sent: 10 May 2024 16:51
To: IETF-Announce <ietf-announce@xxxxxxxx <mailto:ietf-announce@xxxxxxxx>>
Cc: draft-kucherawy-bcp97bis@xxxxxxxx <mailto: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 <mailto:last-call@xxxxxxxx> mailing lists by 2024-06-07. Exceptionally, comments may
be sent to iesg@xxxxxxxx <mailto: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/ <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
