On 11-May-24 12:29, Mark Nottingham wrote:
On 11 May 2024, at 10:04, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
Mark,
On 11-May-24 11:42, Mark Nottingham wrote:
I'm sure that this has been discussed somewhere already, but I object to this text in the draft:
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.
But there is no way the IETF can impose anything on another SDO.
I did not suggest that; I suggested we be more careful in our choices of what to reference -- in particular, assuring that when we do make a normative reference to something that isn't free, we assure that it available on reasonable and non-discriminatory terms.
This is presumably why the draft says:
"Authors and editors should try to avoid such references due to the challenges they present, as they affect the IETF's ability to ensure the quality of its output. However, such references are not always avoidable."
and empowers the IESG to impose certain requirements.
Where does it do that?
The very next sentence:
"Authors/editors of source documents may be required by the IESG..."
The draft doesn't use BCP14 terminology, since RFC2026 itself doesn't, so "should" means what it says. I don't think there's any realistic alternative when such cases arise, much as I agree with the principle of freely available open standards.
The current text is vague and open to interpretation, and so falls short of our OpenStand commitments.
I don't see how we can be more precise, since every case is a bit different.
In my experience, the IESG has (rightly) always been very wary of reliance on paywalled standards; in fact that was at the origin of the original ISO and ITU liaison agreements way back. This is hardly a new problem.
But if it's a choice between (a) an open IETF standard for IP-over-foo, citing a paywalled layer 2 standard, or (b) a paywalled IP-over-foo standard from the Foo Consortium, surely the world is better off with (a)? We've seen alarmingly bad non-IETF IP-over-foo documents in the past.
That's the sort of case I'm most familiar with, but I assume similar issues can arise at any level in the protocol stack.
Brian
Cheers,
--
Mark Nottingham https://www.mnot.net/
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
