Subject: [Gendispatch] towards a new series of non-standard documents

From: Michael Richardson <[email-masked]>
Date: Fri, 21 May 2021 18:53:16 -0400

I am watching the IETF110 GENDISPATCH recording.
I watched bits of it in conflict with another WG back in March.
I am responding to Klensin's "rant" about 2028.

As Keith and others said, RFCs aren't a great place to put some of this.
We've had many WGs say that really, they want a working document, and we now
have a small trend towards designating certain revisions of IDs as
"Implementation Documents"

We've had many rants, including Warren's latest, that Internet Drafts are not
RFCs, and that not all RFCs are standards.   So maybe it is really on us to
remove many of the things from our series that aren't even intended to ever
be standards.
[I will stand mute on topic of ISE, and I suggest you do too, as I think that
once we figure out what we should be doing, the topic of what to do with ISE
will become much easier to decide.]

I think it's time to create a new series of documents, which are slightly
more official than Internet Drafts (i.e. they represent some kind of consensus),
but which are not immutable like RFCs.
It should be physically possible to patch them easily via git pull request to
the official XML, but the approval of that pull request is probably an IESG
action.

In many ways, for protocols, these would be the "Proposed Standard" of
(very?) old.  But, let's not start with that.
Instead, lets start that for non-protocol documents (including specifically
process documents, but also use cases and requirements documents), this would
be the final resting place.  They would have versions.  "IETF2028.02", etc.

A reason that replacing 2028 is so hard, is because we would feel we have to
get it completely, and perfectly right, and the reason we have to get it
right is because it's so hard.  Recursive logic, yes.

We often go on about how stuff should be in web pages,  and that's true, but
we don't know how to effectively get consensus on a series of hyperlinked
concepts.  (Wikipedia works at best poorly)
At the same time, we don't want to do an IETF LC on a CSS fix.
The web site can easily normatively quote this new series, maybe even by
XPATH or some magic reference.

-- 
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 22 May 2021 22:59:45 +0000

> be the final resting place.  They would have versions.  "IETF2028.02", etc.

+1. Being able to keep an RFC number the same when providing an updated spec would be awesome.
And being able to provide timely updates (< 1 year) would be a dream. I'd love to see this idea gain traction.
Barbara

> gut [sic I think: s/get/gut] it completely, and perfectly right, and the reason we have to get it

---

From: Bob Hinden <[email-masked]>
Date: Sat, 22 May 2021 16:10:08 -0700

Barbara,

> On May 22, 2021, at 3:59 PM, STARK, BARBARA H <[email-masked]> wrote:
> 

I have mixed feeling, but as I understand what Michael is proposing, it would not be an RFC, hence no RFC number.

Bob

> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 22 May 2021 19:14:24 -0400

On Michael's proposal, I don't object, but I do not see much value in 
having a series of process documents that are not processed by the RFC 
Editor.  We would still need some sort of development process that leads 
to an IETF rough consensus and an IESG review.  So the benefit does not 
seem positive.

With regard to protocols, I do not want the number staying the same when 
the content changes.  (I dont care if the change is X->X.1->X.2 or 
X->Y->Z).  It is important that if a customer says to be that they want 
RFC X, I at least have a stable understanding of that.  (There is still 
the issue of exactly which features from something like the SRv6 Network 
Programming RFC the customer actually wants.  But being unclear about 
the base protocol behavior would be much more problematic.  Just because 
the IETF knows that the customer should want TLS 1.3 and not TLS 1.2 
does not mean that is what the customer wants.)

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 May 2021 16:14:45 -0700

If I may make a suggestion, perhaps we should defer the question of whether
this series should have RFC numbers per se.

Rather, it might be more useful to ask whether a series of the type Michael
is suggesting would be useful, with the properties that:

- It has a unique identifier that refers to the current state of the
document
- There is a way of some kind to refer to specific versions of the document
- There is some way to update the document "in place" that is lighter
weight than what it takes to publish an RFC.

If people think it's not, then it doesn't matter if it has an RFC #. If
people think the answer is "yes" (spoiler alert,
this is my view) then we could try to work out what would make sense with
the understanding that we could
address the "is it an RFC" question later.

-Ekr

On Sat, May 22, 2021 at 4:10 PM Bob Hinden <[email-masked]> wrote:

> I have mixed feeling, but as I understand what Michael is proposing, it
> would not be an RFC, hence no RFC number.
>
> Bob
>
>
> > Barbara
> >

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 May 2021 16:23:16 -0700

> does not mean that is what the customer wants.)

Hi Joel,

I agree with you that it's probably inadvisable to have a set of labels so
coarse
that, for instance, "IP" at one time pointed to RFC 791 and now it points
to RFC 8200.

Perhaps a more interesting question is not TLS 1.3 versus TLS 1.2 but rather
TLS 1.3 versus whatever we end up calling
https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-01,
which is sort of an erratta rollup. It advertises itself [0] as:

   TLS 1.3 was originally specified in [RFC8446].  This document is
   solely an editorial update.  It contains updated text in areas which
   were found to be unclear as well as other editorial improvements.  In
   addition, it removes the use of the term "master" as applied to
   secrets in favor of the term "main" or shorter names where no term
   was neccessary.

I think we *do* want people who are interested in "TLS 1.3" to go to this
new document.
Do you disagree? If so, perhaps we can draw some policy that distinguishes
the
inadvisable "IP" case above from this one?

WRT to naming and X->X.1 -> X.2, what I've usually had in my head is that:

X would always point to the latest version
X.1, X.2, etc. would point to specific versions.

-Ekr

Yours,

---

From: Rob Sayre <[email-masked]>
Date: Sat, 22 May 2021 17:51:34 -0700

On Sat, May 22, 2021 at 4:24 PM Eric Rescorla <[email-masked]> wrote:

> which is sort of an erratta rollup. [...]
>

Agree that RFC 8200 was a bit aspirational for 2017, but I've also found
that a lot of traffic is running on IPv6 as I've tested various TLS 1.3
extensions this year. So, you can't really read RFC 791 and have an
up-to-date understanding (although it will often work...).

Perhaps it would help to maintain web pages that show evolutions of various
technologies (like IP, TLS, etc). For example, it's difficult to understand
TLS 1.3 without knowledge of at least a few earlier TLS versions.

This would mean maintaining more meaningful records of updates/obsoletes
relations, after giving new standards some time for adoption.

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 May 2021 16:00:52 +1200

On 23-May-21 12:51, Rob Sayre wrote:
...
> Agree that RFC 8200 was a bit aspirational for 2017, but I've also 
found that a lot of traffic is running on IPv6 as I've tested various TLS 
1.3 extensions this year. So, you can't really read RFC 791 and have 
an up-to-date understanding (although it will often work...).
> 
> Perhaps it would help to maintain web pages that show evolutions of various technologies (like IP, TLS, etc). For example, it's difficult to understand TLS 1.3 without knowledge of at least a few earlier TLS versions.
> 
> This would mean maintaining more meaningful records of updates/obsoletes relations, after giving new standards some time for adoption.

Whether it's a web page or a more traditional type of document, the problem for this has always been the large effort needed to (a) create and (b) 
maintain such resources.

Look at the "IPv6 Node Requirements" series for example. It *needs* updating every few months as new IPv6 RFCs and operational experiences accumulate. It actually gets updated every 6 years on average, and is currently 2 years out of date.

Look at "Requirements for IP Version 4 Routers". Never been completely updated since 1995. (Two small updates in 1999 and 2012.)

No doubt there are both better and worse examples, but can we figure out how we would find and fund the sustained effort to do such work? If we can solve that, I think the questions of format and document numbering would be easy to decide.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 May 2021 16:39:58 -0400

Let me combine answers to a number of comments.
Let me also say that none of these suggestions are new.
NEWTRK and others flattened the grass on these trails long ago.

I think that this could be an RFC3933 (BCP93) process experiment,
although it suggests "1 year", and I think that we'd need about 3-4 months to
get the DT changes made, and we'd need to let it run for about three years,
and we'd have to decide for each document, what to do in the case that the
experiment failed.
My gut instinct is that there are about three weeks of DT work that needs to be
done, and then 2-3 days of tweaking every 3-4 months.

I think that we could probably get RFC2028 respun (maybe into 2-3
cross-referencing documents) into such a new series in a matter of a few
months.  The first respun would be less than perfect, but incrementally
better than what we had.  Some of the win would be that the holder of the pen
wouldn't be facing a three year effort to get it across a distant finish line.

STARK, BARBARA H <[email-masked]> wrote:
    >> (very?) old.  But, let's not start with that.  Instead, lets start
    >> that for non-protocol documents (including specifically process
    >> documents, but also use cases and requirements documents), this would

    > +1. Being able to keep an RFC number the same when providing an updated
    > spec would be awesome.  And being able to provide timely updates (< 1
    > year) would be a dream. I'd love to see this idea gain traction.

Well, I don't propose for them to be RFCnumbers, but a new series.
I think it would be reasonable for this new series to be able to pidgin
against RFCnumbers though, but not replacing them.

Joel M. Halpern <[email-masked]> wrote:
    > Editor.  We would still need some sort of development process that
    > leads to an IETF rough consensus and an IESG review.  So the benefit
    > does not seem positive.

I would would this series to involve the RFC-editor/RPC.
It would still represent IETF rough consensus and go through an IESG review.
We would need to establish referencing rules.

Clearly it could make normative references to RFCs (and other external entities).
This series of documents would *certainly* be able to make normative
references to other such documents in the same WG, possibly always referring
to the latest such document.   To me, this obvious situation would be that
our current clusters would then become visible in the WG.

I think that this would let us realize that we have clusters that might be
too "atomic" (like the webrtc) cluster, and permit the WG(s) to split or
refactor documents to allow incremental movement to RFC.

Whether we allow normative references to other WGs would, I think, be an AD
perogative choice, probably in consultation with all the WG chairs.  Or
some simpler rules.   The goal here is conscious awareness.

    > With regard to protocols, I do not want the number staying the same
    > when the content changes.  (I dont care if the change is X->X.1->X.2 or
    > RFC X, I at least have a stable understanding of that.

I wouldn't start with protocols for the reason that I think that we have to
get some experience.  That might mean that this new series of documents wouldn't
be able to create new IANA registries.  Updating existing ones would
depend upon the rules for that registry, and these documents would count as
IETF Actions, etc. so in most cases that wouldn't be a serious problem.
But, getting this exactly right needs a bit of finess, and so I'd want to do
these document last, or maybe never.

Again, think about this series as being a step between "living documents" in
the form of wiki or web pages (which never seem to actually be very live),
and written in stone documents like RFCs.

Eric Rescorla <[email-masked]> wrote:
    > Perhaps a more interesting question is not TLS 1.3 versus TLS 1.2 but
    > rather TLS 1.3 versus whatever we end up calling

    > addition, it removes the use of the term "master" as applied to secrets
    > in favor of the term "main" or shorter names where no term was
    > neccessary.

    > I think we *do* want people who are interested in "TLS 1.3" to go to
    > this new document.  Do you disagree? If so, perhaps we can draw some
    > policy that distinguishes the inadvisable "IP" case above from this
    > one?

    > X would always point to the latest version X.1, X.2, etc. would point
    > to specific versions.

I think that "STD" has all the properties here that you want, but the problem
is that getting to STD remains very difficult, and the industry does not
recognize it.
Again, I recognize your needs here, and I have them too.
But, I want to start with lower hanging fruit.

Eric Rescorla <[email-masked]> wrote:
    > If I may make a suggestion, perhaps we should defer the question of
    > whether this series should have RFC numbers per se.

No, they would not have RFC number.
I suggest "IETFxxxx" or some such moniker.  We can bikeshed that later.
Would we call RFC8446bis, "IETF8446.02" or not, is another question.
Maybe IETF.TLS.8446.02. or non-numbers.

    > Rather, it might be more useful to ask whether a series of the type
    > Michael is suggesting would be useful, with the properties that:

    > - There is some way to update the document "in place" that
    > is lighter weight than what it takes to publish an RFC.

Yes, these are properties that I'm suggesting.

    > people think the answer is "yes" (spoiler alert, this is my view) then
    > we could try to work out what would make sense with the understanding
    > that we could address the "is it an RFC" question later.

"NYARxxxx"  === Not Yet An RFC

My primary aim is to remove our process documents from being so hard to update.

While I think that we want the mechanics of updating them could be as trivial
to update as a git pull request (against "gitoris.ietf.org" or some such),
approval of the pull request would be an IESG action representing IETF
consensus.  (with subsequent edits from an RPC review...)

I think that our other not-to-be-published as Informational RFCs:
architectural stuff, use cases, perhaps cryptographic vectors, should go here
too.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 May 2021 11:05:34 -0400

Michael and I have been chatting about his proposal.  I am trying to 
understand the benefit, as from where I sit the hard part of process 
changes is getting sufficient (even if rough) agreement.  Michael 
suggests (if I understand him) that making the change process easier may 
make it easier for folks to accept less than perfect results (which we 
need.)  Conversely, if it is not seen as making it enough easier, I have 
trouble seeing how this cuts the perpetual process discussion logjams 
(we bifurcate on most of them.)

I believe that Michael and I agree that a related problem is that there 
is no way to actually work on these things, whatever the publication means.

Last message from Michael to me below for additional context with 
Michael's permission.

Yours,
Joel

On 5/27/2021 11:00 AM, Michael Richardson wrote:
>      > At the moment, we do not even have a process that can sensibly work on
>      > process changes.  The only way gendispatch can dispatch your request is
>      > as AD sponsored.
> 
> Well, I haven't gotten to the point of writing a document that could be
> dispatched :-)
> 
>      > Whcih seems wrong to me.  I understand why IETF
>      > chairs do not want a standing IETF process WG. But without a place to
>      > work on these things, and thus to figure out what the rough community
>      > consensus actually is, I do not see a path forward.
> 
> I think that maybe this is maybe one of the huge bugs.
> 
>      > PS: I have a process item I am working int he background that will need
>      > rough community consensus (in my view, the particular thing I am trying
>      > to fix should not be done by edict from the LLC or IESG.)  I am more
>      > worried about what process we will use to determine rough consensus
>      > than I am about getting it through the RPC.
> 
> So I'm picking on process documents because I think that:
>    a) we have immediate need
>    b) we have great group anxiety about getting all the words *exactly* correct.
>       (I point to nomcom changes in 2020, mtgvenue, shmoo documents)
>    c) it removes discussion about IANA actions, and external SDO references.
> 
> It doesn't alleviate the need for having a WG to do work, and probably even a
> charter.   Actually, I'd like to use charter documents as examples of these
> new types of documents.
> 
> {feel free to reply publically}
>