Re: BCP97bis and "freely available"

Michael StJohns <mstjohns@comcast.net> Mon, 18 October 2021 22:39 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF53A0937 for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 15:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weLbF-QeY03C for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 15:39:50 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC0C3A093B for <ietf@ietf.org>; Mon, 18 Oct 2021 15:39:50 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id cb8KmeurGzQhpcbILmWPPq; Mon, 18 Oct 2021 22:39:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1634596789; bh=jS1qB4qd23FxaUuauL9SrAv8VcKP/FBTKoNJumyNJhc=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type; b=buOBwWbNjIPc9yuLhkZCOpbKfXgxnW1AjBOr8NeKp1d/KI8DByfEHhu8hmjhHl/Ra Pfd+1jfin3tIse5uKOl6iGP5Qqnw6AVGGawOzb+4IGDNzXo8E3ZMy2WoOXpjJGMrwv QAXs9Jw325PvKG1F6xHvYEZx1+oGTVn0lHPENciuDB4MNWKrJ3One2TwCssMW3HzeX CcsC6CujtDYp921ItqoJV2TvMTlheBzXfBWtv1OeCmRuWka/2dHAqDK43KA2TlRJqQ F2tcuR9brVY0vWujaDofhsgHcvlWS11jNy1TzszpW0xQ6VJZfcmHGGCsiqO3xvOIqS YpIP3KF8WrkRg==
Received: from [192.168.1.23] ([108.51.200.187]) by resomta-ch2-03v.sys.comcast.net with ESMTPSA id cbI3mpXOK5h2zcbIEmj0pf; Mon, 18 Oct 2021 22:39:47 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvuddguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefoihgthhgrvghlucfuthflohhhnhhsuceomhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeejgeekjefgffeuveelffefveeutedviedvleefgfevvedviefgudevgfefhfetveenucfkphepuddtkedrhedurddvtddtrddukeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddvfegnpdhinhgvthepuddtkedrhedurddvtddtrddukeejpdhmrghilhhfrhhomhepmhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtpdhrtghpthhtohepihgvthhfsehivghtfhdrohhrgh
X-Xfinity-VMeta: sc=0.00;st=legit
Message-ID: <1cf0e986-9c0a-388b-a280-62d24c641148@comcast.net>
Date: Mon, 18 Oct 2021 18:39:31 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0
Subject: Re: BCP97bis and "freely available"
Content-Language: en-US
To: ietf@ietf.org
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.c om> <CAL0qLwa4ChOsuMkmoP_sAGv3Wn2AcSz1OkijmxZzP+MGvnwviA@mail.gmail.com> <849D7F9E-8AD4-4CE8-A66C-358FB1F2E6AE@tzi.org> <8E6C9FDEA828F341AA36F39C@PSB> <58bb1659-97c7-6a44-b833-27fe4c5702ed@gmail.com>
From: Michael StJohns <mstjohns@comcast.net>
In-Reply-To: <58bb1659-97c7-6a44-b833-27fe4c5702ed@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cL3-jqqSvXrfnAmRm4L40DWd34U>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2021 22:39:54 -0000

On 10/18/2021 4:04 PM, Brian E Carpenter wrote:
> I think the original concern was indeed standards that (for
> proprietary or other reasons) were actually kept secret.
> So "freely" didn't imply "free of charge"; it meant available
> to the general public. In that sense it's closely related
> to "open standards". Those are standards that are open to
> the general public. I think that's what we insist on, and
> "free of charge" is desirable, but not essential.
>
> "Open standards that are openly developed" means standards
> whose development process is open to the general public.
> We don't insist on that for external references.

It's possible I missed someone else referencing this, but RFC6852 is 
probably a good reference for this discussion.

We have "freely available" which really means "accessible to all" not 
"available free of charge".

We have open standards which may (or may not) mean "processes are open 
to all interested and informed parties"  but generally does mean 
"non-proprietary" and "implementable by all" and probably means 
"collectively created by parties with varying goals".  All standards 
organizations - including the IETF - have barriers to entry by 
individuals.  For us it's just that the barriers are more cultural than 
formal or even financial. Compare and contrast with the ITU that votes 
by country, or OASIS which has both organizational and personal 
memberships, but votes by individual. I find it hard to say where the 
line would be drawn between a common understand of what open and 
non-open standards organization processes are.

We have "voluntary adoption" which contrasts with things like NIST FIPS 
documents which are directive on the US government, can be directive on 
US government contractors, and in many cases tend to be voluntarily 
adopted by other groups and organizations.

Nuances are important here I think.  For the purpose of this discussion, 
the fact that some documents may need to be paid for by the general 
public shouldn't disqualify them as references. That said, leaving it to 
the document authors to negotiate with the external standards 
organizations for access, or worse to pay for access,  is probably not 
in our best interests.

Perhaps an updated version of 6852 where we can get MOAs with various 
organizations that we're willing to do external references to and an 
agreement that they will provide copies of the referenced standards for 
our processes might  be in order.   As would an agreement for stable 
references for archival retrieval of referenced documents.  That would 
be a change to what Murray has currently drafted for section 6 of the 
document.

Later, Mike



>
> Regards
>     Brian Carpenter
>
> On 19-Oct-21 02:33, John C Klensin wrote:
>> Hi.
>>
>> In looking through the new -01 draft (even though this text has
>> not changed) I noticed something that I sort of hinted at
>> yesterday in responding to other comments.
>>
>> You need to define "freely available" and do so precisely.
>>
>> We have historically considered printed books and articles in
>> established journals to be suitable for normative references
>> from the RFC Series ("down" really has nothing to do with that
>> criterion) even if buying the book or obtaining the journal was
>> expensive.  In theory, there was always a trip to the library.
>> Some of the standards from other SDOs have the same property:
>> they are often very expensive unless one's organization is a
>> member that gets them for free, but many libraries and other
>> repositories do have them available.
>>
>> Of course, some of us have access to better technical libraries
>> than others. That is an economic and cultural problem I don't
>> know how to fix, but I'm fairly sure that pushing in the
>> direction of "must be available online, with no restrictions and
>> no cost" would be quite self-destructive for the IETF.
>>
>> "Freely available" does not necessarily imply "free" (zero cost).
>>
>> By contrast, one can imagine a reference to a restricted
>> corporate document, some types of prepublication drafts, and, if
>> the world continues to fragment, even the detailed description
>> of how some equipment operates.  In those cases, the document
>> may just not be "available" to many IETF participants even
>> though, if someone were allowed to access it, it would be at no
>> cost.
>>
>> So the I-D should be very clear about what it is talking about.
>> Then, if needed, we can have a better discussion about the
>> requirements.
>>
>> best,
>>      john
>>
>>
>>