Subject: [Rfced-future] Proposed "Historical Properties"

From: "Martin Thomson" <[email-masked]>
Date: Fri, 03 Dec 2021 10:35:49 +1100

The text below attempts to capture a few things that I believe were the result of our discussions earlier today.

First, that the RSAB has the responsibility and authority to decide how much review is appropriate.  They are expected to exercise judgment in how they manage the public comment and review period, this just strengthens that requirement.

Second, that the RSAB judgment on this matter would benefit from a few guidelines so that things that have been put in place deliberately over the years are not removed without equal care, deliberation, and consultation.

Third, that this does not fundamentally change the process we apply.  We still follow the same basic processes that we've agreed to.  However, we highlight the need for additional care so that changes to important things are, as discussed, "very deliberate" and that the consequences of those changes are given due consideration.

For this, I took Brian's text and tweaked it.  The introductory piece here is mostly new, to capture the above points.  The detailed points are largely the same, concentrating as they did in Brian's formulation on being factual rather than prescriptive.  I have only edited some of these points down slightly to sharpen the focus.

---
# Historical Properties of the RFC Series

The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals.<!-- This paragraph might go elsewhere, with a reference this section; at Peter's discretion. -->

This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and that all of the consequences of a proposal have been carefully considered.

## Availability

Documents in the RFC Series have been available for more than 35 years, with no fee for access.

## Accessibility

RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight.

## Publication Language

All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages.

## Content Diversity

In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies.

## Document Quality

RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322].

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 2 Dec 2021 17:12:12 -0700

This is looking good. When I work on my part of the text, I'll likely 
place your first paragraph somewhere else in the document.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Dec 2021 13:41:43 +1300

This definitely works for me.

Regards
    Brian Carpenter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 2 Dec 2021 20:06:40 -0500

Thank you.  My first reaction is that I can live with this.  In 
particular, I can live with the formulation of the introductory 
material.  The details seem a good start, although i want to think about 
whether there is more we need.  (I hope not.  There is benefit in 
keeping this short.)

Yours,
Joel

---

From: Christian Huitema <[email-masked]>
Date: Thu, 2 Dec 2021 17:12:38 -0800

+1

On 12/2/2021 4:41 PM, Brian E Carpenter wrote:
>> The text below attempts to capture a few things that I believe were 
>> the result of our discussions earlier today.
>>
>> First, that the RSAB has the responsibility and authority to decide 
>> how much review is appropriate.  They are expected to exercise 
>> judgment in how they manage the public comment and review period, 
>> this just strengthens that requirement.
>>
>> Second, that the RSAB judgment on this matter would benefit from a 
>> few guidelines so that things that have been put in place 
>> deliberately over the years are not removed without equal care, 
>> deliberation, and consultation.
>>
>> Third, that this does not fundamentally change the process we apply.  
>> We still follow the same basic processes that we've agreed to.  
>> However, we highlight the need for additional care so that changes to 
>> important things are, as discussed, "very deliberate" and that the 
>> consequences of those changes are given due consideration.
>>
>> For this, I took Brian's text and tweaked it.  The introductory piece 
>> here is mostly new, to capture the above points.  The detailed points 
>> are largely the same, concentrating as they did in Brian's 
>> formulation on being factual rather than prescriptive.  I have only 
>> edited some of these points down slightly to sharpen the focus.
>>
>> ---
>> The RSAB has a duty to ensure that proposals from the RSWG receive 
>> appropriate levels of review. Proposals that, in the opinion of the 
>> RSAB, have significant impact on the series require additional 
>> outreach and review from a wider community. Additional time should be 
>> allowed for collecting feedback for such proposals.<!-- This 
>> paragraph might go elsewhere, with a reference this section; at 
>> Peter's discretion. -->
>>
>> This section lists some of the properties that have been historically 
>> regarded as important to the RFC Series. Proposals that affect these 
>> properties are possible within the processes defined in this 
>> document. However, the RSAB should seek broader review for proposals 
>> that might have a detrimental affect on these properties. The purpose 
>> of review is to ensure that all changes are deliberate and that all 
>> of the consequences of a proposal have been carefully considered.
>>
>> ## Availability
>>
>> RFC Series documents have been published in a format that was 
>> intended to be as accessible as possible to those with special needs, 
>> e.g., for those with impaired sight.
>>
>> ## Publication Language
>>
>> All existing RFC Series documents have been published in English. 
>> Documents have been licensed to explicitly permit translation into 
>> other languages.
>>
>> ## Content Diversity
>>
>> In addition to Internet standards, the RFC series has published 
>> procedural and informational documents, thought experiments, 
>> speculative ideas, research papers, histories, humor, and even eulogies.
>>
>> ## Document Quality
>>
>> RFC Series documents have been edited by professionals with a goal of 
>> ensuring that documents are clear, consistent, and readable [RFC7322].
>>
>

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 3 Dec 2021 18:18:04 +0900

Many thanks to those who attended the meeting (sorry, way too early for 
me), and to Martin for the proposal below. I could definitely live with 
this direction, but I have a minor comment below.

> This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in th…

I'm a bit wary of "all", in particular in "and that all of the 
consequences of a proposal have been carefully considered". I think the 
intent is very clear, but unfortunately, we never can be sure we really 
are aware of all the possible consequences.

So what about something like
"and that the consequences of a 
proposal, as far as they are identifiable, have been carefully 
considered" or so.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 03 Dec 2021 20:40:25 +1100

> proposal, as far as they are identifiable, have been carefully 

That's a reasonable amendment.  Thanks.

I'm maintaining the text here: https://notes.ietf.org/BrrKxlvGRrOKVdNFjCUung?view in case you want to follow along.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Dec 2021 10:52:01 +0100

Hi Martin T, and thanks for this, and thanks Martin D for your comments.

Can everyone comment on Martin's text?

Eliot

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Dec 2021 12:06:30 +0100

> RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322].

I don’t have a chance to follow the stream of comments here.

I believe I have attempted to point out that the objectives for this and other aspects of professionalism in handling the RFC series went significantly beyond that.

https://mailarchive.ietf.org/arch/msg/rfced-future/rE0swA9xR6FZ9Th9X8J8UapuLJo/
https://mailarchive.ietf.org/arch/msg/rfced-future/3EmXWQwKufE2MM5hFY4k-IDLoHw/

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Dec 2021 13:16:26 +0100

Carsten,

I could interpret your point to be one change and one add:

## Document Quality

RFC Series documents have undergone review for subject matter quality and have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322].

## Stable References

Once issued, an the text of an RFC would remain unchanged, so that anyone implementing a particular RFC correctly could enjoy consistent and interoperable behavior, and that the RFC could be properly referenced in literature.

??

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Dec 2021 14:05:58 +0000

Can you make Availability, Accessibility, etc., as bullets?  A series of one-sentence sections is jarring, and I think the *slight* de-emphasis by moving to bullets is good. And change the intro of the second paragraph to

	The list below identifies, in no particular order, some of the properties ...

For parallel structure, I'd also like to see "Language" and "Diversity" as one-word items. And under Language, s/have been licensed/are licensed/

These are nits

---

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Dec 2021 10:58:03 -0800

On 12/3/2021 4:16 AM, Eliot Lear wrote:
> RFC Series documents have undergone review for subject matter quality 
> and have been edited by professionals with a goal of ensuring that 
> documents are clear, consistent, and readable [RFC7322].
>
> ## Stable References
>
> Once issued, an the text of an RFC would remain unchanged, so that 
> anyone implementing a particular RFC correctly could enjoy consistent 
> and interoperable behavior, and that the RFC could be properly 
> referenced in literature.

That particular sentence is mixing a fact and a hope. The fact, indeed 
the historical property, is that once issued the text of an RFC remains 
unchanged and the RFC could be properly referenced in literature. The 
hope is that this leads to compatible implementations, but I would 
certainly not call that a historical property. For many of our most 
popular protocols, including TCP or DNS, implementing the nominal RFC 
does not result in implementations compatible with current deployments.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Dec 2021 11:51:57 -0800

Perhaps just stop after "unchanged"? That seems factual.

On Fri, Dec 3, 2021 at 10:58 AM Christian Huitema <[email-masked]>
wrote:

> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Dec 2021 22:03:17 +0100

Anything is ok with me. Christian's right- it's... aspirational at best.

On 03.12.21 20:51, Eric Rescorla wrote:
> On Fri, Dec 3, 2021 at 10:58 AM Christian Huitema 
> <[email-masked]> wrote:
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Dec 2021 21:04:38 +0000

I had planned to listen to the recording before posting this
(and didn't manage that) but in any case...

I think Martin's done a great job with that text. From my POV
it only lacks one important thing: that RFCs are, by design,
intended to have longevity in the sense of being easily
rendered for a human being for extended periods. IMO that's
a different property and worth stating. So I'd suggest
adding:

"# Longevity

RFCs have always been intended to be easily legible to humans
even decades after having been written."

To be clear: with that (or similar) included, I'd be fine
with the document overall.

Cheers,
S.

On 02/12/2021 23:35, Martin Thomson wrote:
> --- # Historical Properties of the RFC Series
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Dec 2021 13:21:36 -0800

This seems like a reasonable addition to me.

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Dec 2021 16:26:36 -0600

As a general comment, I am okay with the direction the text has taken. I 
have no objections to Stephen's text about format longevity, nor to the 
(shortened version of the) "Stable References" text that you propose.

/a

On 12/3/21 03:52, Eliot Lear wrote:
>> I'm maintaining the text here: 
>> https://notes.ietf.org/BrrKxlvGRrOKVdNFjCUung?view in case you want 
>> to follow along.
>>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 Dec 2021 10:11:44 +1100

Thanks to everyone contributing friendly amendments. I now have:

The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals.<!-- This paragraph might go elsewhere, with a reference this section. -->

This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and and that the consequences of a proposal, as far as they are identifiable, have been carefully considered.

## Availability

## Accessibility

## Language

## Diversity

## Quality

RFC Series documents have been reviewed for subject matter quality and edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322].

## Stability

Once published, RFC Series documents have not changed.

## Longevity

RFC Series documents have been published in a form intended to be easily legible to humans for decades or longer.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Dec 2021 07:25:51 +0100

Thanks, Martin.  A reminder: we asked Peter to work to put together a 
proposal on the procedural aspects, which will need to change a bit.  He 
is working to develop that text, which is related to your first paragraph.

In the meantime, I'd ask Peter to create a PR for this text in a section 
that he deems appropriate.  That doesn't mean that things can't be 
tweaked based on further discussion, but I'd like the group to see one 
more version of the doc before we all break for holidays.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 6 Dec 2021 16:46:51 -0700

Martin's text is now in a pull request:

https://github.com/intarchboard/program-rfced-future/pull/140

The related text about community calls for comment and RSWG/RSAB review 
is in a separate PR:

https://github.com/intarchboard/program-rfced-future/pull/141

On 12/5/21 11:25 PM, Eliot Lear wrote:
>> allowed for collecting feedback for such proposals.<!-- This paragraph 
>> might go elsewhere, with a reference this section. -->
>>
>> properties are possible within the processes defined in this document. 
>> However, the RSAB should seek broader review for proposals that might 
>> have a detrimental affect on these properties. The purpose of review 
>> is to ensure that all changes are deliberate and and that the 
>> consequences of a proposal, as far as they are identifiable, have been 
>> carefully considered.
>>
>> ## Availability
>>
>> RFC Series documents have been published in a format that was intended 
>> to be as accessible as possible to those with special needs, e.g., for 
>> those with impaired sight.
>>
>> ## Language
>>
>> RFC Series documents have been reviewed for subject matter quality and 
>> edited by professionals with a goal of ensuring that documents are 
>> clear, consistent, and readable [RFC7322].
>>
>> ## Stability
>>
>> RFC Series documents have been published in a form intended to be 
>> easily legible to humans for decades or longer.
>>

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Dec 2021 23:22:52 -0500

Peter, Martin,

Some (I hope small) suggestions / changes:

> https://github.com/intarchboard/program-rfced-future/pull/140

    ------

Current:
	proposals that might have a detrimental effect

Comment: 
  "detrimental" would be appropriate if we were talking about
principles, but I gather that is what people are trying to avoid
("principles" would still be my personal preference).  In this
context, it implies a judgment call by the RSAG, with no
guidance other than whatever they are thinking at the moment as
to whether a particular change meets that bar and hence should
get the more extensive review.   Example, deliberately chosen as
probably the least likely of the list to become an issue or
generate a proposed change.  Suppose the RSWG/RSAG concluded
that the Series would be considerably improved with more intense
technical editing and that the only way to get there would be to
charge a fee for at least some of the documents in the series.
If the goal were to improve quality, nothing "detrimental"
there.  But we'd certainly want very wide and careful review.

   -----

Current:
     "heightened scrutiny" (and the new calls for comment, etc.,
text)

Comment:
     I actually like this term as an alternate to "enhanced
review" or similar phrases.  But my intent, as discussed during
the call and in earlier messages, was an expanded review, not
just extra care in the discussions among the usual group of RSWG
participants and RSAB members.   The current text seems to imply
the latter.  What I, at least, was after was additional outreach
to, e.g., the academic research and historical communities of
readers and to those who use RFCs in procurement and/or
regulatory specifications.  I continue to believe that we do not
need to specify how that outreach is done or to spend energy on
what to do if it fails to produce any input.  But I do expect
the RSAG to make a good-faith effort, using the best advice they
can get, to get reviews and input from people in those
communities that are unlikely to be well-represented in the RSWG
and unlikely to follow the mailing lists or social media venues
called out in the current text and to pay careful attention to
what they have to say.

     That seems to have been entirely lost from the current
formulation, I hope not intentionally.

   -----

Current:
      more than 35 years,

Comment: 
      RFC 8700 says "50" and that was two years ago.  Those who
are especially concerned about privacy might also want it noted
that, for most of that period, no identification of the person
obtaining the document has been necessary.

     Also, under "Accessibility", "Availability", "Longevity",
or some other topic, we have paid careful attention to the issue
of making documents available without the need to use software
to interpret documents that might fall out of use or require
unusual tools or processing in the future.  That has been
mentioned, in different forms, several times on the list, only
sometimes as part of the "archival" topic.

   -----

Current:
		licensed to explicitly permit translation

Comment:
		I'll defer to others on this if they have better information,
but my impression is that, at least for the first 30 or so years
of the series, translations were explicitly permitted without
any requirement for specific licensing.  The above, in context,
seems to imply that licenses are required and, at least unless
they are guaranteed or blanket licenses exist, that would
contradict the history we are trying to record.  That is
important in part because, unlike other SDOs, we have never
tried to have, or designated, official translators or
translations, much less guaranteed their accuracy.  Any moves in
those directions would also be inconsistent with the history.

   -----

Current:
		to Internet standards, the RFC series has

Comment:
    Historically, we should not lose track of the facts that it
was many years before the term "standard" was used for RFCs.
Among the earliest documents identified as "standard for the
Internet community" were documents that we would identify as
procedural, rather than standard track, today.  And this goes to
the historical observation that the RFC Series predates the IETF
and that the IETF came into being without the notion of
"standards body".  

Suggestion: 
     Can we just drop that bit, which implies that Internet
standards (also a term of art, especially if "Standards" is used
rather than "standards", that means something rather different.
We should also try to avoid statements that get tangled up with
"who is the publisher of the series".  Instead, try, e.g.,

	"The RFC series has included many types of documents
	including standards for the Internet, procedural and
	informational documents, thought experiments,
	speculative ideas, research papers, histories, humor,
	and even eulogies."

   -----

Current:
     easily legible to humans

Comment:
     And least where I come from "legible" means that the text
is not presented in a form that people have trouble reading,
e.g., my handwriting or a highly decorated, neo-calligraphic,
type style.  I think something more like "accessible and usable"
is intended.  See above.

   -----

best,
   john

---

From: Adam Roach <[email-masked]>
Date: Mon, 6 Dec 2021 22:58:13 -0600

On 12/6/2021 10:22 PM, John C Klensin wrote:
> get the more extensive review.

No matter how we slice this, it's going to rely on the RSAG exhibiting 
good judgement. I think the point here is that, e.g., deciding that we 
want to add some kind of accessibility markup to the HTML output format 
has a positive effect on Accessibility, while deciding that we want to 
replace all HTML elements with styled <span> elements would have a 
detrimental effect. So while it would be incumbent on the RSAG to cast a 
wider net for the latter change, I don't think we want to require the 
same level of scrutiny for the former.

> Example, deliberately chosen as

That would have a clearly detrimental effect on the properties described 
under "Availability," thereby resulting in wider consultation.

On the other hand, if some deep-pocketed nonprofit stood up and offered 
US$2.5M worth of editorial assistance per year, no strings attached, it 
wouldn't have the clear detrimental effect that you hypothesize; and I 
think we agree that it wouldn't require the wider community review as a 
consequence.

So I'm pretty sure your triggering condition here isn't to the attempt 
to improve Quality, as much as it is the detrimental impact on Availability.

I think we also need to have a baseline assumption that the RSWG and 
RSAG will not, en masse, go batdung bonkers.

> the latter.

That's because you're looking at the wrong section. The key phrase in 
*this* section is "As described under... {{cfc}}..." The key phrase in 
{{cfc}} is:

"In cases where a proposal has the potential to significantly modify
   policies of long standing or historical characteristics of the
   Series, the RSAB should take extra care to reach out to even broader
   communities that make use of RFCs, such as scholarly researchers,
   procurement managers, and standards development organizations."

> formulation, I hope not intentionally.

John.

> contradict the history we are trying to record.

Ah, I think you're onto something here. Perhaps: "Documents have been 
made available under terms that explicitly allow anyone to translate 
them into other languages without asking for permission to do so."

Your other comments have concrete suggestions, and I have no issue with 
those suggestions.

/a

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 00:50:08 -0500

--On Monday, December 6, 2021 22:58 -0600 Adam Roach
<[email-masked]> wrote:

>> principles, but I gather that is what people are trying to
>> avoid ("principles" would still be my personal preference).
>> In this context, it implies a judgment call by the RSAG, with
>> no guidance other than whatever they are thinking at the
>> moment as to whether a particular change meets that bar and
>> hence should get the more extensive review.

> No matter how we slice this, it's going to rely on the RSAG
> exhibiting good judgement. I think the point here is that,
> e.g., deciding that we want to add some kind of accessibility
> markup to the HTML output format has a positive effect on
> Accessibility, while deciding that we want to replace all HTML
> elements with styled <span> elements would have a detrimental
> effect. So while it would be incumbent on the RSAG to cast a
> wider net for the latter change, I don't think we want to
> require the same level of scrutiny for the former.

Agreed, I think.  Just having a bit of a problem with
terminology and wanting to provide some meaningful guidance,
guidance that should probably include, at least implicitly,
something equivalent to "if in doubt, do the wider review".

>> that the Series would be considerably improved with more
>> intense technical editing and that the only way to get there
>> would be to charge a fee for at least some of the documents
>> in the series.
> 
> 
> That would have a clearly detrimental effect on the properties
> described under "Availability," thereby resulting in wider
> consultation.
> 
> On the other hand, if some deep-pocketed nonprofit stood up
> and offered US$2.5M worth of editorial assistance per year, no
> strings attached, it wouldn't have the clear detrimental
> effect that you hypothesize; and I think we agree that it
> wouldn't require the wider community review as a consequence.

I'm actually not sure about that.  Example:  The idea of
shifting to a pre-Last Call editing pass so that the community
would be reviewing a document very close to what would be
published has been raised/proposed several times.  It would
largely eliminate the problem of post-Last Call negotiations
among the the RPC, IESG, ADs, and authors that has occasionally
resulted in documents being published that are barely
recognizable to the WGs that produced them.  That idea has
always been rejected because we simply do not have the resources
to edit a given document multiple times and because such editing
(given the available resources) would introduce unacceptable
delays.  A big injection of money could presumably eliminate
both of those obstacles.  So, completely positive, right?  But
it would also reduce the ability of the RPC to work as a small
team in close intra-team communications, possibly change the
role of the RSCE somewhat (in practice if not in theory), and
create different risks about technical errors being introduced
in the editorial process that a WG would then need to sort out.
I'd suggest that, at the risk of looking gift horses in the
mouth, such an offer would deserve exceptional scrutiny.

> So I'm pretty sure your triggering condition here isn't to the
> attempt to improve Quality, as much as it is the detrimental
> impact on Availability.
> 
> I think we also need to have a baseline assumption that the
> RSWG and RSAG will not, en masse, go batdung bonkers.

I am making that assumption.  I am also making an assumption,
having only watched the IETF community on and off for nearly 35
years and the ARPANET/Internet development community for a
decade and a half longer, that people who have discovered a
whizbang new idea and agreed on it will sometimes get impatient
to see it deployed, sometimes being inclined to take shortcuts
because their solution or approach seems too obvious to
question.  I am not too concerned about "bonkers", batdung or
otherwise.  I am concerned with impatience and wanting to get on
with things and therefore seeing heightened scrutiny and
outreach --a process that could easily add a month or two to the
"normal" methods-- as an unattractive impediment to be avoided
if that is plausible.  Examples where it is clearly and
unambiguously not plausible are easy to find and we have both
identified them.  It is the "well, maybe, this does not
_really_, _absolutely_, need wider review" cases I'm concerned
about.

I need to stop there for tonight; will try to get back to your
other comments tomorrow.

   john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 7 Dec 2021 07:16:16 +0100

Hi!

>   procurement managers, and standards development organizations."

Yes.  The resolution we came to last week requires changes in multiple 
places in the document.  We will need one or two more tweaks here or 
there to bring the procedure in line with all of that.  For example, we 
should reiterate the text Peter added in grounds for concern (as it 
stands that old text conflict with what Peter added elsewhere).

In particular, we should probably reiterate the criteria for CONCERNs in 
the procedural section (grounds for raising a concern); as it stands 
there is a conflict between old and new text.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 07 Dec 2021 17:28:42 +1100

Hi John,

Thanks for this input; the changes do seem small and constructive.

I've taken those suggestions from you and those from Adam's response - all of those seem reasonable to me - and made suggestions against Peter's text.  I think that the only things we might be missing is the connection between the two sets of changes Peter has shared (where the "wider review" piece moved from this section to the other) and your point about the "archival" topic.

Personally, I'm happy to accept any of the changes as proposed.  I will defer to Peter on the document organization piece.  As for the the "archival" topic, my view is that we've captured the points on which we will agree to already, so I'd prefer to leave that matter undisturbed.

---

From: Adam Roach <[email-masked]>
Date: Tue, 7 Dec 2021 00:29:25 -0600

On 12/6/2021 11:50 PM, John C Klensin wrote:
> Just having a bit of a problem with

Sure. More formally, one might phrase this in the document as "When in 
doubt about whether a proposal qualifies, the RSAG should err on the 
side of wider consultation." That's more for the text in PR 141 than PR 
140, though.

/a

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 7 Dec 2021 15:56:41 +0900

Hello John, others

> those directions would also be inconsistent with the history.

IANAL, and what I'm writing here is mostly based on my experience with 
'handling' translations at the W3C over 15 years ago.

Translations are derivative works, and so unless they are done for 
personal use, a license *is* needed under most if not all copyright 
regimes. Whether this license is given explicitly (as is the case now, 
and as you mention was the case earlier) or implicitly (as may have been 
the case in the very early parts of RFC history) is a secondary issue.

A 'license' doesn't mean there has to be a written contract between 
licensee and licensor. If you say they "were *explicitly* permitted 
without any requirement for specific licensing", that would mean that 
there was something somewhere in a relevant location that in some form 
said that they were permitted. This would be enough for a license, and 
would be essentially the same as now, where this is, with a lot of 
legalese, written down in the IETF Trust Legal Provisions (see 
https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or 
did you mean to write 'implicitly'?

And we don't know how often e.g. Jon Postel was asked by somebody 
whether it was okay to translate an RFC, and just said something like 
"sure, go ahead". That would have been an oral license, which in the 
general case should be fine. I'd still expect that e.g. a publisher 
wanting to publish a translation of (parts of) an RFC in a book would 
have tried to get something in writing, e.g. by sending Jon a release 
form with the necessary details.

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Dec 2021 13:50:34 +0000

Hiya,

Just on this bit...

> type style.  I think something more like "accessible and usable"

I'm fine if some synonym of legible is used but did pick
that deliberately and don't think "accessible and usable"
is a great replacement because "accessible" is covered
elsewhere, and "usable" implies understanding of the content
which wasn't what I wanted to say. As it's the "decades
later" that's the meat of this point though, it wouldn't
be the end of the world to make that change.

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 09:03:50 -0500

--On Tuesday, December 7, 2021 13:50 +0000 Stephen Farrell
<[email-masked]> wrote:

>>       And least where I come from "legible" means that the
>>       text is not presented in a form that people have
>> trouble reading, e.g., my handwriting or a highly decorated,
>> neo-calligraphic, type style.  I think something more like
>> "accessible and usable" is intended.  See above.
> 

As you say "decades later" (I'd actually prefer "a century or
more later") is the point and I agree that my proposed
substitution is not ideal.  So, if someone else cannot come up
with a better replacement for "legible", let's treat this is
"editor discretion" or, if Peter cannot do better, maybe call
the RPC's attention to this in the hope that they can find
better vocabulary.

Not important enough, IMO, to justifying a wordsmithing thread
on the list.

   best,
    john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 Dec 2021 09:18:30 -0500

For purposes of clarifying what the historical practice on translation 
of RFCs is, the FAQ page for the IETF Trust says:
     Since the beginning of the RFC series, reproduction of whole
     RFCs (including translation into a language other than English)
     has been allowed and encouraged. The IETF Trust and the RFC Editor
     place no restrictions on this. Most RFCs include the standard phrase
     “Distribution of this memo is unlimited” to indicate this.

Yours,
Joel

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 7 Dec 2021 15:27:10 +0100

Let just steal this text (or is there a copyright issue? ;-) )

> On 7. Dec 2021, at 15:18, Joel M. Halpern <[email-masked]> wrote:
> 
> For purposes of clarifying what the historical practice on translation of RFCs is, the FAQ page for the IETF Trust says:
>> IANAL, and what I'm writing here is mostly based on my experience with 'handling' translations at the W3C over 15 years ago.
>> Translations are derivative works, and so unless they are done for personal use, a license *is* needed under most if not all copyright regimes. Whether this license is given explicitly (as is the case now, and as you mention was the case earlier) or implicitly (as may have been the case in the very early parts of RFC history) is a secondary issue.
>> A 'license' doesn't mean there has to be a written contract between licensee and licensor. If you say they "were *explicitly* permitted without any requirement for specific licensing", that would mean that there was something somewhere in a relevant location that in some form said that they were permitted. This would be enough for a license, and would be essentially the same as now, where this is, with a lot of legalese, written down in the IETF Trust Legal Provisions (see https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or did you mean to write 'implicitly'?
>> And we don't know how often e.g. Jon Postel was asked by somebody whether it was okay to translate an RFC, and just said something like "sure, go ahead". That would have been an oral license, which in the general case should be fine. I'd still expect that e.g. a publisher wanting to publish a translation of (parts of) an RFC in a book would have tried to get something in writing, e.g. by sending Jon a release form with the necessary details.
>> Regards,   Martin.
> 
> --

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 Dec 2021 09:39:08 -0500

:-)
For IETF purposes, we can steal it with no trouble.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 10:03:40 -0500

+1 (and shared amusement)

--On Tuesday, December 7, 2021 15:27 +0100 Mirja Kuehlewind
<[email-masked]> wrote:

>> For purposes of clarifying what the historical practice on
>> translation of RFCs is, the FAQ page for the IETF Trust says:
>>    Since the beginning of the RFC series, reproduction of
>>    whole RFCs (including translation into a language other
>>    than English) has been allowed and encouraged. The IETF
>>    Trust and the RFC Editor place no restrictions on this.
>>    Most RFCs include the standard phrase "Distribution of
>>    this memo is unlimited" to indicate this.
>> 
>> Yours,
>> Joel
>> 
>>>>         I'll defer to others on this if they have better
>>>>         information, but my impression is that, at least
>>>> for the first 30 or so years of the series, translations
>>>> were explicitly permitted without any requirement for
>>>> specific licensing.  The above, in context, seems to imply
>>>> that licenses are required and, at least unless they are
>>>> guaranteed or blanket licenses exist, that would contradict
>>>> the history we are trying to record.  That is important in
>>>> part because, unlike other SDOs, we have never tried to
>>>> have, or designated, official translators or translations,
>>>> much less guaranteed their accuracy.  Any moves in those
>>>> directions would also be inconsistent with the history.
>>> IANAL, and what I'm writing here is mostly based on my
>>> experience with 'handling' translations at the W3C over 15
>>> years ago. Translations are derivative works, and so unless
>>> they are done for personal use, a license *is* needed under
>>> most if not all copyright regimes. Whether this license is
>>> given explicitly (as is the case now, and as you mention was
>>> the case earlier) or implicitly (as may have been the case
>>> in the very early parts of RFC history) is a secondary issue.
>>> A 'license' doesn't mean there has to be a written contract
>>> between licensee and licensor. If you say they "were
>>> *explicitly* permitted without any requirement for specific
>>> licensing", that would mean that there was something
>>> somewhere in a relevant location that in some form said that
>>> they were permitted. This would be enough for a license, and
>>> would be essentially the same as now, where this is, with a
>>> lot of legalese, written down in the IETF Trust Legal
>>> Provisions (see
>>> https://trustee.ietf.org/documents/trust-legal-provisions/tl
>>> p-5/). Or did you mean to write 'implicitly'? And we don't
>>> know how often e.g. Jon Postel was asked by somebody whether
>>> it was okay to translate an RFC, and just said something
>>> like "sure, go ahead". That would have been an oral license,
>>> which in the general case should be fine. I'd still expect
>>> that e.g. a publisher wanting to publish a translation of
>>> (parts of) an RFC in a book would have tried to get
>>> something in writing, e.g. by sending Jon a release form
>>> with the necessary details. Regards,   Martin.
>> 
>> --

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 7 Dec 2021 14:33:57 -0700

Thanks, Martin. After we merge in the open pull requests, I'll take a 
closer look at the document organization.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 08 Dec 2021 09:46:05 +1100

I took another look and have some tiny suggestions, informed by the discussion:

On accessible and usable vs. legible, another word choice:
- accessible and usable to humans for decades or longer.
+ comprehensible to humans for decades or longer.

On translation, I don't think that we need this:
- The IETF Trust and the RFC Editor place no restrictions on this. 

Joel's text mentioned redistribution, which might be worth considering:
- with no fee for access.
+ with no constraints on access or (re)distribution.

All of these are offered as suggestions on the pull request, to be taken or left as you see fit.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Dec 2021 22:58:09 +0000

> + comprehensible to humans for decades or longer.

heh:-) I thought of that one too (and it could be ok)
but then I consider whether or not I comprehend NFSv4...

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 08 Dec 2021 10:07:43 +1100

> but then I consider whether or not I comprehend NFSv4...

Strike "easily" then and I think we're good.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 19:33:38 -0500

--On Tuesday, December 7, 2021 14:33 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> Thanks, Martin. After we merge in the open pull requests, I'll
> take a closer look at the document organization.

Peter, thanks.  Please pick up the suggestion that you just pick
up the translation text Joel supplied from the official Trust
statement and review the exchange between Stephen and myself
about "legible".  For the latter, as I said there and having
raised the issue, I'm personally happy to trust your discretion
about the term and maybe suggest that, if you leave it, you call
the attention of the RPC to the term when the document goes over
the wall and see what (if anything) they want to do on final
editing.

A bit more below.

>> I've taken those suggestions from you and those from Adam's
>> response - all of those seem reasonable to me - and made
>> suggestions against Peter's text.  I think that the only
>> things we might be missing is the connection between the two
>> sets of changes Peter has shared (where the "wider review"
>> piece moved from this section to the other) and your point
>> about the "archival" topic.

Yes.  However you organize things, the two seem to me closely
enough connected that explicit explanatory cross-references are
probably in order.

>> Personally, I'm happy to accept any of the changes as
>> proposed.  I will defer to Peter on the document organization
>> piece.  As for the the "archival" topic, my view is that
>> we've captured the points on which we will agree to already,
>> so I'd prefer to leave that matter undisturbed.

I will probably try to periodically and gently push on that, as
well as on "expertise", but I do not see it as catastrophic if
the final result is not much different from what we have
today... at least as long as text does not creep in the
deprecates the principle.  Put differently, I'm ok with
"archival" and little or no explanation or even a statement that
it seems impossible to get a definition that is at once clear
and comprehensive and that will get consensus.  I would have
serious problems with anything that implies that, because we
cannot agree on a comprehensive definition, the term and
whatever it might imply is meaningless and should therefore not
be considered relevant.

    best,
     john

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 19:57:54 -0500

> but then I consider whether or not I comprehend NFSv4...

Yeah.  "Comprehensible" implies that one can actually understand
the text. One could say "readable": that does not necessarily
imply comprehension but might not be much better.   That not
only interacts with Stephen's comprehension of NFSv4 and my
ability to comprehend a detailed description of some encryption
algorithm (I assume either of us could, but it would involve a
level of work that we'd find hard to get sufficiently motivated
about) but, adding in what I've learned from a recent (and
unrelated) discussion about our standards for review of
technical documents that are heavily dependent on information in
other, earlier, ones for comprehension, maybe we cannot easily
get much further.

"Legible" at least implies the ability to physically read the
characters without implying the ability to understand their
meaning.  If we were translating RFCs into the Chinese of many
centuries ago and then chiseling the results into the proverbial
stone tablets, they would be legible but comprehensible (or even
readable) only to specialists.  If we used the wrong sort of
stone and left it exposed to the elements for long enough, the
characters might not even be legible.

This is, at least for me, a really interesting side-discussion
because I'm now fascinated by what the right word might be
(sadly, it is a bit tied up with one of the meanings of
"archival") but maybe we need to resist it and, having raised
the issue and probed it a bit, delegate the problem to Peter.

best,
   john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Dec 2021 01:28:06 +0000

We're approaching angels on heads of pins but anyway...

On 08/12/2021 00:57, John C Klensin wrote:
> imply comprehension but might not be much better.

I preferred legible to readable as (for me) the former
is more human-oriented whereas one could argue that a
wordstar file is still entirely readable via fgetc()
even if not possessing the property we're trying to
describe.

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 20:56:33 -0500

--On Wednesday, December 8, 2021 01:28 +0000 Stephen Farrell
<[email-masked]> wrote:

>> Yeah.  "Comprehensible" implies that one can actually
>> understand the text. One could say "readable": that does not
>> necessarily imply comprehension but might not be much better.
> 

At the risk of increasing the angel count, the same comment
about "readable" could be made about an XML2RFC v3 source file.
Without studying the vocabulary, a typical one is not much more
comprehensible than, e.g., one of those NSFv4 specs and, without
the interpreter, not much better for "readable" than that
WordStar file (maybe worse).  So, yes, "legible" has much more
to do with human visual perception and that is sort of the
minimum condition, but it is not quite enough, just as knowing
that an 8" floppy or a LaserDisc is "readable" (for a different
definition of that term than you are using) but not easily by
most of us.  Methinks that the aforementioned angel-populated
pin may occupy  the bottom of a rathole.  At the risk of
encouraging an extended tour of such a rathole, I note that
there are a series of ISO Standards about the archival (sic)
properties of assorted media, including storage conditions, etc.

Equally important at least in the context of some of my recent
obsessions, if I present a well-formatted, carefully printed,
document to you in, e.g,. Vedic period Sanskrit or Song Dynasty
Chinese, would you consider it "legible" and/or "readable" and
why.  I am guessing to the answer to "comprehensible", but,
either way, it wouldn't have much to do with the sort of
technical issues that cause your comments about NSFv4 or mine
about some crypto algorithms.

I think we know, and are more or less in agreement, about what
we are trying to say here.  It is somewhat difficult to believe
that there is no word in English that describes it fairly
precisely, but I think that may be the conclusion we are
reaching.  I'd encourage Peter to explain rather than trying to
summarize in a single term but am nervous that we might then
discover that we don't agree about the boundary cases after all.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Dec 2021 16:23:10 +1300

For your further amusement, Alexa (the person, not the robot) informed
me this morning that my name is still on the NZ trademark registration
for "IETF". Not because I live in NZ, but because I was one of the IETF
Trustees when the registration was made. Sadly, I've now signed away my
rights to the current Trustees, but at least for the next few days
anybody who uses the mark "IETF" in New Zealand owes me. Jay, I'm
looking at you :-).

Regards
    Brian Carpenter

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 8 Dec 2021 14:25:49 +0900

> Let just steal this text (or is there a copyright issue? ;-) )

Well, if there's a copyright issue, then it's stealing. But if there's 
no copyright issue, then we don't have to steal it, we can just copy it. :-)

> .

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Dec 2021 00:30:28 -0500

Picking up where I left off...

--On Monday, December 6, 2021 22:58 -0600 Adam Roach
<[email-masked]> wrote:

>...
>>       "heightened scrutiny" (and the new calls for comment,
>>       etc., text)
>> 
>> Comment:
>> review" or similar phrases.  But my intent, as discussed
>> during the call and in earlier messages, was an expanded
>> review, not just extra care in the discussions among the
>> usual group of RSWG participants and RSAB members.   The
>> current text seems to imply the latter.
> 
> 
> That's because you're looking at the wrong section. The key
> phrase in *this* section is "As described under... {{cfc}}..."
> The key phrase in {{cfc}} is:
> 

I did indeed miss that.  I was trying to work from the GitHub
posting and, perhaps because I was tired, found it a bit hard to
navigate.

>...
>> 		information, but my impression is that, at least for the
>> first 30 or so years of the series, translations were
>> explicitly permitted without any requirement for specific
>> licensing.  The above, in context, seems to imply that
>> licenses are required and, at least unless they are
>> the history we are trying to record.

> Ah, I think you're onto something here. Perhaps: "Documents
> have been made available under terms that explicitly allow
> anyone to translate them into other languages without asking
> for permission to do so."

That would make me much happier.  Thanks.

> Your other comments have concrete suggestions, and I have no
> issue with those suggestions.

Again, thanks.
    john