Subject: [Rfcplusplus] labeling/experiments/ and ramifications

From: Eliot Lear <[email-masked]>
Date: Wed, 4 Jul 2018 10:10:44 +0200

Sorry for thinking aloud a bit here...

As Alissa as alluded, the debate has become a bit mixed up with the use
of experimental language.  It seems to me that we should be more
explicit about this:

  * Are we experimenting?  or
  * Are we taking a permanent action?  or
  * Are we taking a step toward a permanent action, with the option to
    revert?

Seems to me that we're really considering that latter choice.  The
question, then, is really whether bothering with labels is the right
approach.  As community veterans, we all recognize that relabeling the a
stream is likely to cause a serious reduction of publications precisely
because the RFC is a brand, and excluding access to that brand would put
alternatively labeled publications at a distinct disadvantage.  Why not
consider a less drawn out death?

Why not, indeed...

It's already a struggle to get academic participation in the IRTF. 
Removing incentives would risk further reducing such participation,
albeit marginally (RFCs' stature is improving, thanks to Heather
pursuing DOIs, for instance).  Do we run the risk of brand
exploitation/dilution in the IRTF series?  Perhaps, but maybe the risk
is worth it.  It's possible that the IRSG could be given guidance to
take care to avoid such problems.

Should we continue the ISE stream?  What is its value?  To me the value
in large part in providing input to the Internet community about ideas
that are not intended as standards and yet have value in their
consideration.  Those ideas include:

  * Documentation of protocols or algorithms that are used on the
    Internet.  IAX seems like a good example of this.  So do encryption
    algorithms.  WRT what EKR said, it seems better to have the
    algorithm documented than not, if it is being used.  The test: is it
    really being used?  This *is* protocol work, but doesn't really
    benefit that much from brand exploitation.
  * Commentary on the IETF processes or decisions.  Dave Crocker and I
    have both written such commentaries for reflection by the
    community.  This is a bit of an escape value, along the lines, of
    "Think about what you've done and its ramifications".  It's not a
    consensus document, but it can hardly be confused as a protocol
    work, and thus does not subject the RFC label to brand dilution. 
    These are also relatively rare pieces of work.  I wish there were more.
  * Other interesting mechanisms that are not widely deployed.  This is
    where brand exploitation becomes at least a marginal, if not real,
    possibility.  The question is whether we really care.  By way of
    example, there are a whole lot of Keynote documents published
    through the ISE.  Have they helped or harmed the Internet and have
    they helped or harmed the RFC brand?  (Maybe this is the wrong
    example; pick your own; Barry certainly did).

I believe the first two uses are valuable, and the third use has also
been of value, although there is some noise.  I wonder if we could
handle all of this by having the IAB provide some guidance to the ISE. 
Brand dilution is a risk, and if the community thinks it's a big enough
risk, then of course we should act on it.  But there are also risks of
acting.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 05:52:08 -0700

On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear <lear=[email-masked]>
wrote:

>   So do encryption algorithms.  WRT what EKR said, it seems better to have
> the algorithm documented than not, if it is being used.  The test: is it
> really being used?
>

I want to narrow my response to this point: what we've done in TLS is allow
code point registration with any stable reference, internal or external.
This includes an I-D. We didn't make this change primarily in order to
address the issues raised by this BOF, but I do think it was a good change.
Can you explain why you don't think that this suffices?

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 4 Jul 2018 15:22:06 +0200

Hi Eric,

On 04.07.18 14:52, Eric Rescorla wrote:
>
>
> On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear
> <lear=[email-masked]
> <mailto:lear=[email-masked]>> wrote:
>
>       So do encryption algorithms.  WRT what EKR said, it seems better
>     to have the algorithm documented than not, if it is being used. 
>     The test: is it really being used? 
>
>
> I want to narrow my response to this point: what we've done in TLS is
> allow code point registration with any stable reference, internal or
> external. This includes an I-D. We didn't make this change primarily
> in order to address the issues raised by this BOF, but I do think it
> was a good change. Can you explain why you don't think that this suffices?
>
I wasn't really thinking in terms of code points when I wrote that, but
since you asked: "Any stable reference" sounds fine.  Journal references
in the face of scribd and DOIs are pretty cool these days.   A nit: we
don't normally count I-Ds in that group, and the boiler plate explains why:

>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."

They are not intended to be stable references.  One way we know this to
be the case is that they may not be normatively referenced, and most
notably, they're supposed to expire, and can be rev'd leading to some
amount of confusion if you then don't do another code point assignment.

What I was thinking about: I'm not sure that this is just about a code
point reference.  It's also about providing access to information by
which others can assess the value of the algorithm.  Yes, there are
other venues, but as you yourself pointed out, there really hasn't been
any harm in having the algorithm published as an RFC:
>
>     It does seem to me that for
>     national algorithms, they will be in the libraries anyway because
>     they will be mandatory procurement requirements. 
>
>
> That's certainly an understandable prediction, but I haven't found it
> to be true in practice.

Not a great demonstration of brand dilution, right?  Perhaps that brand
dilution took place in Russia?  I dunno.  (And yes, there was some hooha
in the press at the time the GOST RFCs were released.  I do see them
referenced here and there, by the way- not sure there's much difference
between that and an I-D; probably better spelling and grammar).

Also, a reminder of the context in which you quoted that text: if the
algorithm is used, that provides strong incentive for it to be properly
documented.  In fact, one of the earlier RFC authors and IETF
participants, Brian Kantor (NNTP co-author) made a very good point that
RFCs are often most valuable when they document existing practice. 
That's a very high bar these days.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 10:02:13 -0700

On Wed, Jul 4, 2018 at 6:22 AM, Eliot Lear <[email-masked]> wrote:

> On Wed, Jul 4, 2018 at 1:10 AM, Eliot Lear <lear=[email-masked].
> org> wrote:
>
>>   So do encryption algorithms.  WRT what EKR said, it seems better to
>> have the algorithm documented than not, if it is being used.  The test: is
>> it really being used?
>>
>
> external. This includes an I-D. We didn't make this change primarily in
> order to address the issues raised by this BOF, but I do think it was a
> good change. Can you explain why you don't think that this suffices?
>
> since you asked: "Any stable reference" sounds fine.  Journal references in
> the face of scribd and DOIs are pretty cool these days.   A nit: we don't
> normally count I-Ds in that group, and the boiler plate explains why:
>
> They are not intended to be stable references.  One way we know this to be
> the case is that they may not be normatively referenced, and most notably,
> they're supposed to expire, and can be rev'd leading to some amount of
> confusion if you then don't do another code point assignment.
>

I am aware of this boilerplate, but I don't think it comports well with the
way we actually handle IDs, which is that they stick around on the IETF
site forever. Remember, the only purpose here is that when you see the code
point on the Internet, you know what it means. As for the reving issue,
that's addressed by referring to a specific version.

I would note that
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
encodes this practice and it's currently in the RFC-Ed queue, so if you
object, you ought to do it soon.

> point reference.  It's also about providing access to information by which
> others can assess the value of the algorithm.  Yes, there are other venues,
> but as you yourself pointed out, there really hasn't been any harm in
> having the algorithm published as an RFC:
>
>
> That's certainly an understandable prediction, but I haven't found it to
> be true in practice.
>
>
> Not a great demonstration of brand dilution, right?
>

Well, maybe. We got requests to implement these, and the fact that they
were RFCs and in some cases standards track RFCs was, IIRC, used as an
argument. However, we also felt we could say "no". However, I've also seen
algorithms in libraries (including NSS) mostly because someone decided to
do as much as was in some set of RFCs, so practices differ, even within
projects.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 4 Jul 2018 19:32:53 +0200

Hi EKR,

On 04.07.18 19:02, Eric Rescorla wrote:
> encodes this practice and it's currently in the RFC-Ed queue, so if
> you object, you ought to do it soon.
>

That seems a bit late.  If ALL you're saying in that document is,
“specification required”, no reason to stall that draft if it's in the
RFC Editor queue. 

Still, I don't think Internet Drafts are what the authors of 8126 had in
mind when they wrote that text, and it would raise a concern about what
the registry would look like with such multiple entries, and how
interoperability would be affected.  A nice attribute of an RFC is that
it denotes at least a clear stop of specification development, and
that's not nothing.  This having been said, that would presumably also
be true of any other labeled thing we are talking about here (I hope).

>
>     What I was thinking about: I'm not sure that this is just about a
>     code point reference.  It's also about providing access to
>     information by which others can assess the value of the
>     algorithm.  Yes, there are other venues, but as you yourself
>     pointed out, there really hasn't been any harm in having the
>     algorithm published as an RFC:
>>
>>     That's certainly an understandable prediction, but I haven't
>>     found it to be true in practice.
>
> Well, maybe. We got requests to implement these, and the fact that
> they were RFCs and in some cases standards track RFCs was, IIRC, used
> as an argument. However, we also felt we could say "no". However, I've
> also seen algorithms in libraries (including NSS) mostly because
> someone decided to do as much as was in some set of RFCs, so practices
> differ, even within projects.

You guys may be in a good position to say no.  I could EASILY imagine
(remember?) others who weren't in so good a position.

Eliot

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Jul 2018 12:37:03 -0500

> “specification required”, no reason to stall that draft if it's in the

Currently live at
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml :

Note
The role of the designated expert is described in 
[RFC-ietf-tls-iana-registry-updates-05]. The designated expert 
[RFC8126] ensures that the specification is publicly available.  An 
Internet Draft that is posted and never published or a standard in 
another standards body, industry consortium, university site, etc. 
suffices.  The expert may provide more in depth reviews, but their 
approval should not be taken as an endorsement of the extension.   

-Ben

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jul 2018 14:50:36 -0400

--On Wednesday, July 4, 2018 12:37 -0500 Benjamin Kaduk
<[email-masked]> wrote:

>> > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-regist
>> > ry-updates/ encodes this practice and it's currently in the
>> > RFC-Ed queue, so if you object, you ought to do it soon.
>> > 
>> 
>> That seems a bit late.  If ALL you're saying in that
>> document is, "specification required", no reason to stall
>> that draft if it's in the RFC Editor queue. 
> 
> Currently live at
> [RFC8126] ensures that the specification is publicly
> available.  An  Internet Draft that is posted and never
> published or a standard in  another standards body, industry
> consortium, university site, etc.  suffices.  The expert may
> provide more in depth reviews, but their  approval should not
> be taken as an endorsement of the extension.   

Ben,

The state of TLS may be that the above is entirely reasonable
and I certainly would not try to second-guess it.    As a
principle, when special circumstances exist, I think the IETF is
better off making sensible judgments that are specific to those
circumstances rather than consulting a one-size-fits-all rule
book.

However, for most cases, I think most of our references should
be not only publicly available but also stable and, with a nod
in the direction of those who are concerned about Internet
history, archival -- likely to be available and readable/
accessible for a very long time, even when the related protocols
or parameters have fallen into disuse.

I-Ds do not have those properties.  They can be updated at any
time, creating some ambiguity about whether the citation is
intended to be to the most current version (appropriate if the
updates are clarifications) or to the one at the time the
registry entry was created (possibly appropriate if there were
substantive changes).  While the IETF has decided to keep older
I-Ds accessible to the public rather than making them
inaccessible without special measures right after they expired,
we have had problems with bad links when the various web pages
are rearranged and there are no guarantees that the IETF will be
around forever and what will happen if it ceases being able to
support those archives.

So, again, if references to anything that is publicly available
at the time of registration is what the TLS community and the
IESG are convinced TLS needs, go for it.  But let's be careful
about moving more generally in that direction.

   john

p.s. If we are going to treat I-Ds as appropriate for stable and
archival references, we should probably be reviewing whether we
actually need the RFC Series and why (at least for more than a
source of labels and serial numbers).  I think the answer after
a careful examination would still be "yes", but going through
the exercise might allow us to focus on what we think is
necessary and thereby save some procedures and money.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 12:16:03 -0700

Hi John,

I think you're onto something important here: in the nearly 40 years
since the RFC series began, the economics of publishing stuff have
changed pretty radically.

In particular, it's become far cheaper to publish documents which:

- Are widely available
- Have a reasonable story about ongoing availability
- Are referentially stable; specifically, if the document is
  available in the future, you can be sure that you have
  the right document [0].

At the same time, it hasn't gotten much cheaper to produce documents
which have multistakeholder consensus (I assume some would argue it
has gotten more expensive, but I think we can all agree it hasn't
gotten cheaper at the rate that publishing has). So, I still think
there is real value in having a mechanism for ensuring that
documents have that level of review and consensus (leaving
aside how that mechanism works, though I'd be happy to get into
that in a separate note).

Narrowing this to the question of code point registration: Many
protocols have large code point spaces so there's no need to restrict
code point assignments in order to conserve space. In at least some of
these protocols, we've come to the conclusion that restricting code
point assignment in order to prevent people from making ill-advised
extensions doesn't work well (people just squat and you get a mess).

We could deal with this by just allowing registrations to be FCFS,
but there was a general feeling that it wasn't great to have code
points exist with no way for people to know what they meant, so
we concluded that there ought to be some reference to a document
describing the meaning of the extension, and that one ought to be
able to have a good chance of finding the document. I take this
to be the spirit of RFC 8126 specification required. Specifically:

   The intention behind "permanent and readily available" is that a
   document can reasonably be expected to be findable and retrievable
   long after IANA assignment of the requested value.  Publication of an
   RFC is an ideal means of achieving this requirement, but
   Specification Required is intended to also cover the case of a
   document published outside of the RFC path, including informal
   documentation.

I think it's clear that this definition would encompass a link to
a blog or a github repository ("informal publication") as long as
that was referentially stable. I agree that that the text we
use to describe I-Ds suggests that these properties don't apply
to I-Ds, but I would submit that as a practical matter, I-Ds
(as long as they are referenced by version) do have these properties
at least as much as a blog entry or Github link does. It's for
that reason that we opted to allow this in TLS (and, I expect,
in other groups going forward).

>From your email, I take it that you don't think this is generally
a good idea. Can you explain a bit more why in light of the comments
above?

-Ekr

[0] It's also much easier to publish documents which are referentially
unstable in the sense that you get the most up-to-date version, which
is a source of confusion.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 Jul 2018 20:30:58 +0100

Well, I am not that bothered, but it looks like you should have used "Expert Review" with the strictures and guidance to the Designated Experts, rather than "Specification Required" with an (implicit) alteration of 8126 and the I-D boilerplate.

> -----Original Message-----
> From: Rfcplusplus [mailto:[email-masked]] On Behalf Of Benjamin
> Kaduk
> Sent: 04 July 2018 18:37
> To: Eliot Lear
> Cc: Eric Rescorla; [email-masked]
> Subject: Re: [Rfcplusplus] labeling/experiments/ and ramifications
> 
> _______________________________________________
> Rfcplusplus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfcplusplus

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Jul 2018 16:54:27 +1200

Adrian,

IMHO that's for the TLS WG to decide and the IESG (and IANA) to agree to.
If the result is somewhat fewer Independent Submissions, that seems
like a win-win in the end (and somewhat irrelevant to the BOF topic).

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 21:55:57 -0700

FWIW, I wouldn't have objected to Expert Review here. I just didn't object
to Spec Required :)

-Ekr

On Wed, Jul 4, 2018 at 9:54 PM, Brian E Carpenter <
[email-masked]> wrote:

> > Well, I am not that bothered, but it looks like you should have used
> "Expert Review" with the strictures and guidance to the Designated Experts,
> rather than "Specification Required" with an (implicit) alteration of 8126
> and the I-D boilerplate.
> >
> >> https://www.iana.org/assignments/tls-extensiontype-
> values/tls-extensiontype-
> >> values.xhtml :
> >>
> >> Note

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Jul 2018 17:12:42 +1200

On 04/07/2018 20:10, Eliot Lear wrote:
... 
> handle all of this by having the IAB provide some guidance to the ISE. 

The IAB is chartered very narrowly on this:

"The IAB must approve the appointment of an organization to
act as RFC Editor and the general policy followed by the RFC Editor."
[BCP39]

The general policy and scope of the Independent series is defined
in [RFC4846].

These documents were written before the ISE was a separate job,
but that change [RFC6548] doesn't really change anything fundamental,
except by splitting the ISE job out from the RSE job. So, if there
are issues in RFC4846, it's for the ISE to propose any changes
for IAB approval (after community review, of course).

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Jul 2018 15:46:59 -0400

Eric,

I don't think we are going to agree on many of these things.
This note, responding to yours of several days ago, is an
attempt to explore some of the places where or perspectives
differ (whether that leads to actual disagreement or not) in the
hope of informing the conversation a bit.  I don't know that
turning it into a lengthy discussion is worth either of our
efforts, but I'm prepared to be convinced otherwise.

--On Wednesday, July 4, 2018 12:16 -0700 Eric Rescorla
<[email-masked]> wrote:

> Hi John,
> 
> I think you're onto something important here: in the nearly 40
> years since the RFC series began, the economics of publishing
> stuff have changed pretty radically.
> 

Yes, although our criteria "ongoing availability" may well be
different.  In particular, if a document is intended to provide
information for implementation on the Internet, ten or fifteen
years is typically more than enough, even though there are
exceptions (SMTP, with which I have some experience, is fairly
clearly one of them despite predictions that IM, Twitter, etc.,
will replace it soon).  

Even then, there are some oddities.  Picking an example that has
almost nothing to do with the IETF, if I were trying to write a
program to determine if a new files, as they arrive, were
identical to ones I already had in a repository (that mostly
contained fairly large files), I'd look to find a hash with a
good many information bits and a generation algorithm that was
hard to fake (for reasons and with details you can certainly
explain better than I can).   However, I ran into a program a
few weeks ago that is support just that sort of duplication
detection and it is quite a bit faster than those that use
contemporary hashes.  Turns out that it is relying on simple
additive-digit checksums.  Now I know what those are and you are
probably old enough that you do too, but I'd lay good odds that
there are people around the IETF who would need to look the
algorithm up in order to figure out  if they are really adequate
and why not.   I just did a Google search on "checksum" and, on
the first page, found several definitions that were wrong of
misleading in different ways as well as one correct answer.
Unless one already knows the answer, picking which of those is
authoritative is hard.   So, while it clearly isn't the IETF's
fault, that one flunks "ongoing availability".

More important to me (but not necessarily others reading this),
some of us are concerned about the historical record in which
the issue may be decades or even centuries rather than a few
years.   Every time someone claims the Web is the most important
invention, at least to knowledge dissemination, since Gutenberg,
some of us start thinking about a need to preserve things at
least as long, i.e., for a minimum of five or six centuries and
maybe for times comparable to ink on sheepskin or papyrus under
good storage conditions.

>       [0] It's also much easier to publish documents which are
>       referentially unstable in the sense that you get the
>       most up-to-date version, which is a source of confusion.

Yes.  The RFC Series has been rather good at the first (in part
because there has been an "archival" requirement since before
there was an IETF).   Things like STD numbers are intended to
solve the latter requirement if that is what one wants, even
though they have not worked well for reasons that have been
discussed elsewhere.  It is not clear where new sets of number
series would leave us except that, if we were to create a new
numbering series, put documents in it (without RFC numbers) and
then abandoned the experiment, went back to RFC numbers, and
dropped the new system (or connected it to links that eventually
stopped working, we would have lost on both referential
approaches).   I hope we can also agree that, in the general
case, whatever URLs are, they don't provide much in the way of
referential stability (with the IETF web site as, IMO, a sad
example).

> At the same time, it hasn't gotten much cheaper to produce
> documents which have multistakeholder consensus (I assume some
> would argue it has gotten more expensive, but I think we can
> all agree it hasn't gotten cheaper at the rate that publishing
> has). So, I still think there is real value in having a
> mechanism for ensuring that documents have that level of
> review and consensus (leaving aside how that mechanism works,
> though I'd be happy to get into that in a separate note).

It also hasn't gotten much cheaper to produce documents that are
of high quality editorially, including checks for ambiguous
language and, where that is important, easy translatability.  I
think that has been a goal for the RFC Series.  It is certainly
a goal for, e.g., ISO Standards even when there is agreement to
publish in only one language.  How well we have been doing is a
separate question, of course.

> protocols have large code point spaces so there's no need to
> restrict code point assignments in order to conserve space. In
> at least some of these protocols, we've come to the conclusion
> that restricting code point assignment in order to prevent
> people from making ill-advised extensions doesn't work well
> (people just squat and you get a mess).

Indeed.  Having made the argument that excessive restrictions
and complex procedures just lead to squatting and less-available
documentation several times in cases when the IETF has moved
from a requirement for IETF approval to much more flexible
procedures that focus more on quality of descriptions, I'd be in
bad trouble if I didn't agree.

Where we may disagree is about what "extension" means in terms
of the base protocol specification.  We use that term for at
least two different kinds of situations.  In one the
extension(s) change, or might change, the semantics of the base
protocol, particularly in a way that might be confusing or
harmful to those who are not opting to use that extension
itself.   In the other, they are just add-ons: additional
parameters, values, options, etc., that can be used with the
base specification but don't need to be and that have no effect
on the unextended base protocol (or syntax, or whatever) if not
used.    If the base protocol is an IETF specification, I
suggest that the review process has failed, perhaps seriously,
if that distinction is not clear from the text, usually in the
IANA Considerations Section and that, if that section says
"specification required" or "FCFS", we had better be dealing
with one of the second set of cases.

> We could deal with this by just allowing registrations to be
> FCFS, but there was a general feeling that it wasn't great to
> have code points exist with no way for people to know what
> they meant, so we concluded that there ought to be some
> reference to a document describing the meaning of the
> extension, and that one ought to be able to have a good chance
> of finding the document. I take this to be the spirit of RFC
> 8126 specification required. Specifically:
> 
>    The intention behind "permanent and readily available" is
> that a    document can reasonably be expected to be findable
> and retrievable    long after IANA assignment of the requested
> value.  Publication of an    RFC is an ideal means of
> achieving this requirement, but    Specification Required is
> intended to also cover the case of a    document published
> outside of the RFC path, including informal    documentation.

See above.  And...

> I think it's clear that this definition would encompass a link
> to a blog or a github repository ("informal publication") as
> long as that was referentially stable. I agree that that the
> text we use to describe I-Ds suggests that these properties
> don't apply to I-Ds, but I would submit that as a practical
> matter, I-Ds (as long as they are referenced by version) do
> have these properties at least as much as a blog entry or
> Github link does. It's for that reason that we opted to allow
> this in TLS (and, I expect, in other groups going forward).

Again, my criteria for referential stability and accessibility
may be different from yours (and probably are).    I don't think
a link to a github repository is acceptable because there are no
long-term stability guarantees there and in particular, whomever
has write access on the particular repository can (and, in my
experience, often do) change the document out from under the
link.   In most case, those changes are for the better, but no
guarantees.  Blogs depend on the blog and the repository; I
don't think it is possible to make a general statement.  I-Ds
are actually better than either from that point of view because,
at least so far, once an I-D is posted with a particular name
and version number, we don't do back an alter them (although
they can be removed from the archive even though I don't think
we have done that for some years.

But that is where the historical perspective comes back in.  For
the RFC Series, we've made "archival" promises, something that
the current RSE has extended by making some specific
arrangements with depository libraries.  If, e.g., the IETF and
the earthquake-prone coast of the US vanish from the face of the
earth, the RFC Series will still be available in an organized
and accessible form.  If there are any similar guarantees about
Internet-Drafts, I'm not aware of them.  I hope I'm wrong, but
my guess is that the IETF's agreement with its current cloud
provider doesn't specify preservation of the I-D archives
significantly beyond when we stop paying the bills.  And I'm
pessimistic enough about these sorts of things to not have high
confidence that the IETF will be around forever or even for
another few decades.

> From your email, I take it that you don't think this is
> generally a good idea. Can you explain a bit more why in light
> of the comments above?

See if the above helps.  And, again, if the TLS WG decided that
referencing I-Ds was the right thing to do and the IESG, after
due consideration, agreed, I have no inclination to second-guess
the decision.  But not, in the general case, I don't think it is
a good idea.

best,
     john

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 8 Jul 2018 13:21:03 -0700

John,

Thanks for your response. It does clarify your thinking. Ultimately, I
think it comes down to our respective views of the required level of
temporal stability for standards documents, so it's probably not worth
going into much more depth here. With that said, I do want to bring out one
point.

On Sun, Jul 8, 2018 at 12:46 PM, John C Klensin <[email-masked]> wrote:

> link.

Well, sort of. It's quite straightforward to produce links to Github
repositories that have a higher guarantee of referential stability than
RFCs do: you simply reference the commit-id which is a hash. So, the repo
might be removed but it's not practical (as long as SHA-1 remains strong)
to change the contents.

   In most case, those changes are for the better, but no
> we have done that for some years.

This is certainly a reasonable perspective, but I don't really see how to
square it with the 8126 language of "reasonably be expected" and "informal
publication". So if your position is that I-Ds don't meet the Specification
Required bar, I'm left wondering what sorts of "informal publication" do.
Can you elaborate?

-Ekr