Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 14:26:58 +0100

Hiya,

On 19/04/16 15:16, The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Guidelines for Writing an IANA Considerations Section in RFCs'
>   <draft-leiba-cotton-iana-5226bis-12.txt> as Best Current Practice

I have a discuss on this document about one point where Barry and I
have different recollections of the outcome of a discussion from a
few years about about bis documents. As there were only a couple of
people who took part in that discussion we figured it might help to
get some more folks' opinions.

The discuss point in question is:

  "Section 8 says: "In no case is it reasonable to leave
   documentation pointers to the obsoleted document for any
   registries or registered items that are still in current
   use." We had a nice big discussion about this back a few
   years ago and there were two sides to the argument as I
   recall.  On what basis can the authors now say that this is
   quite so clear? The strong counter argument to this is that
   developers do not start from IANA, they start from RFCs."

The issue iirc is that if say RFCxxxx is obsoleting RFCyyyy
must the IANA considerations in RFCxxxx say that all the
registries that used point at RFCyyyy need to be updated to
point at RFCxxxx? I don't think that needs to be done (but
it can be done). I think Barry's position, and the text of
the 5226bis draft say that it has to be done.

What do you think?

Ta,
S.

---

From: Scott Bradner <[email-masked]>
Date: Fri, 3 Jun 2016 09:32:48 -0400

> On Jun 3, 2016, at 9:26 AM, Stephen Farrell <[email-masked]> wrote:

…

> the 5226bis draft say that it has to be done.

seems like a good make-work requirement with little actual benefit

of course, if the details of the registry changed with the replacement RFC that is a different case

Scott

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Jun 2016 10:31:15 -0400

> RFC that is a different case

Well, the point is that RFCyyyy defined the BANANA option for protocol
LMNOP, so it registered the BANANA option in the "LMNOP Options"
registry, with a reference that points to RFCyyyy.

Now we have a "yyyy-bis" that becomes RFCxxxx, and that is now the
current definition of the BANANA option -- RFCyyyy is now obsolete.

What is the point of having the reference in the registry?  If it's
needed at all, it should be kept current.  Is it OK that it's left to
point to the obsolete definition of the BANANA option?  Is it better
to change it to point to the current definition in RFCxxxx?  Is it
important to do that?  Is it necessary to do that?  What should BCP 26
say about that?

Barry

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 3 Jun 2016 13:13:25 -0400

It is also possible that a code point is being obsoleted by an RFC bis
document but is retained in the registry, in which case you want the
reference for that value to be to the obsolete RFC where it is
specified. Also, the IANA Considerations initially creating the
registry are not normally copied forward into a bis version, although
they can. So, the answer is that it depends. The only constant
principle, I think, is that the reference(s) for the registry and for
the code points in that registry should be the best references
reasonably available...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Jun 2016 14:45:02 -0400

Hi, Donald.

> specified.

Ooh, yes, that's certainly correct.  The current text handles that by
saying "for any registries or registered items that are still in
current use."

Would anyone object, and would this address your concern, Stephen, if
I should change the text like this:

OLD
   If information for registered items has been or is being moved to
   other documents, then, of course, the registration information should
   be changed to point to those other documents. In no case is it
   reasonable to leave documentation pointers to the obsoleted document
   for any registries or registered items that are still in current use.
NEW
   If information for registered items has been or is being moved to
   other documents, then the registration information should be changed
   to point to those other documents. In most cases, documentation
   references should not be left pointing to the obsoleted document
   for registries or registered items that are still in current use.
END

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 20:09:28 +0100

Hiya,

>    for registries or registered items that are still in current use.

That is better, but I'm still worried that it'd be used by well meaning
folk to force authors to do more work than is needed for no real gain.

My preferred OLD/NEW would be:

OLD
   If information for registered items has been or is being moved to
   other documents, then, of course, the registration information should
   be changed to point to those other documents. In no case is it
   reasonable to leave documentation pointers to the obsoleted document
   for any registries or registered items that are still in current use.
NEW
   If information for registered items has been or is being moved to
   other documents, then the registration information should be changed
   to point to those other documents. Ensuring that registry entries
   point to the most recent document as their definition is encouraged
   but not necessary as the RFC series meta-data documents the relevant
   relationships (OBSOLETED by etc) so readers will not be misled.
END

---

From: S Moonesamy <[email-masked]>
Date: Fri, 03 Jun 2016 12:34:01 -0700

Hi Stephen,
>the 5226bis draft say that it has to be done.

I usually read the IANA registry to find the reference for 
registration procedure.  It is less work if the reference is to a 
document which contains relevant information.

Quoting text from Section 8:

   'If the registrations specify the original document as a reference,
    those registrations should be updated to point to the current (not
    obsolete) documentation for those items.  Usually, that will mean
    changing the reference to be the "bis" document.'

Is it useful to point to RFCyyyy when the information about the code 
point in RFCxxxx?  I don't think so.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Jun 2016 15:47:31 -0400

>    relationships (OBSOLETED by etc) so readers will not be misled.

Well, and *that* is so fluffy that I strongly object to it.  I think
it's bizarre to directly say that it's unnecessary and you don't need
to worry about it.  I can't think of any other place where we so
casually accept stale references.  For example, we flag I-Ds that
point to obsolete references and ask for justification to leave them
in... otherwise, they're updated before or by the RFC Editor (usually
before).

I think the change I've already proposed is a reasonable compromise.
"In most cases" isn't "in all cases".

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 20:54:14 +0100

Hiya,

> in... otherwise, they're updated before or by the RFC Editor (usually

xml2rfc handles updated references. You're arguing for authors to do
a load of manual grunt work for IMO no benefit. So I do think those
are quite different.

> "In most cases" isn't "in all cases".

I accept that you think that:-)

Do you think "in most cases" would have meant you and the author
concerned would/would-not have had that discussion a couple of years
ago? If you would have had it anyway, then I don't think "in most
cases" is usefully different from the OLD text.

And to go back to the nub or the argument, I don't think we have IETF
consensus for that (but you do). I note that so far we only have people
disagreeing with the current draft text.

S.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Jun 2016 16:13:42 -0400

> cases" is usefully different from the OLD text.

I think I'd have had it even with your text, because I simply think
it's monstrously stupid to intentionally retain obsolete references
when we have a newer reference available and it's easy to correct (I
had even provided text).

> disagreeing with the current draft text.

I don't agree with that: Donald said this:
"The only constant
principle, I think, is that the reference(s) for the registry and for
the code points in that registry should be the best references
reasonably available..."

SM said this:
"Is it useful to point to RFCyyyy when the information about the code
point in RFCxxxx?  I don't think so."

Both of those seem to be arguing for updating the references to be current.

But let's put the specific options there and ask:

Community... which of these (or none) do you think reflects the best
practice that should be in BCP 26?:

OLD

NEW-1

NEW-2

(And, Stephen, for what it's worth I'd be OK with a variant of your
version if the last sentence said, simply, "Ensuring that registry
entries point to the most recent document as their definition is
encouraged but not required.")

-- 
Barry

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jun 2016 21:25:59 +0100

> encouraged but not required.")

Me too. So if nobody else cares we can land on that I guess.

Cheers,
S.

PS: I hadn't seen SM's mail when I sent my last.

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jun 2016 13:50:19 -0700

FWIW, IMO this is all make-work.

IANA pointers to the old doc should turn up "obsoleted by" notices. That
ought to be enough to trigger the user to follow the right path.

Otherwise, IMO, this doc should basically say "IANA pointers should be
updated as deemed useful". In some cases, there's a benefit, but not in
all cases. E.g., we have docs that obsolete protocols but IANA still
keeps a pointer to the codepoint. I don't want the new pointer to be to
the doc that obsoletes them; I would want the pointer to be to the
original spec.

I.e., remember that "obsoleted by" can also effectively mean "moved to
Historic by". I.e., nobody looking at TCP-MD5 should necessarily get the
RFC to TCP-AO. And there's no way to know what's in active use *somewhere*.

I'd prefer to trust the author to do the right thing that to engineer
this document with an algorithm.

Joe

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Jun 2016 17:13:52 -0400

> the doc that obsoletes them; I would want the pointer to be to the

Of course, yes, and I think the doc does say that: the pointer should
be to the most current definition, and the sentences in question here
do talk about registries and entries that are in current use.  I, too,
would be dismayed if we started pointing references away from the
definition of the code point and toward something that says, "This
isn't used any more."

> this document with an algorithm.

I agree, though we have ample evidence that authors don't always.
This is aiming to give guidance, not to provide any mechanical "do
this and it'll work" algorithm.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jun 2016 11:35:02 +1200

> FWIW, IMO this is all make-work.

Disagree. Misleading pointers on the IANA site will mislead some
junior programmer sometime in the future, by a simple application
of Murphy's law.

> ought to be enough to trigger the user to follow the right path.

That's not realistic. If IANA refers to RFC822, and the programmer has a
copy of RFC822 on her disk, that's what she will follow, because RFC text
never changes and does not say "I am obsolete".

I'm for Barry's last proposed text.

(BTW, this could be semi-automated. It shouldn't be hard to do a scan of
the entire IANA registry to flag obsoleted RFCs; then it's a human job to
decide which references need to be updated.)

   Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jun 2016 16:40:06 -0700

> never changes and does not say "I am obsolete".

If someone has a copy of IANA ports on their disk, no amount of updating
will fix the fact that it points to the wrong place.

We either expect people to use fresh information or not. Anyone who uses
RFCs should be accustomed to using the version that flags obsoleted docs.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 4 Jun 2016 01:13:24 +0100

> never changes and does not say "I am obsolete".

I don't get how that applies.

Do we think there's a programmer who will start from IANA and
not notice that there are references to 5322 and 2822? If
there is such a peculiarly myopic programmer, their code will
likely be crap anyway won't it?

Or do we think there's a programmer who'll start from RFC822
and not think "hey, this thing's 43 years old - I wonder did
anything happen in the meantime?" ;-)

And anyway the current facts are that folks will much more
likely depend on stack overflow, not IANA, so the entire question
of the best reference is pretty much close to moot.

IMO the only reason any of this matters is when there's a subtle
difference between the RFCyyyy and RFCxxxx versions of the same
registered thing and where there's significantly improved text in
RFCxxxx. In which case... we don't have a problem - RFCxxxx has
solved it for us by definition.

All that's to say that there is no need to, and only a downside
to, forcing document authors to jump through more useless hoops.

Cheers,
S.

---

From: Gmail <[email-masked]>
Date: Sat, 4 Jun 2016 07:30:47 +0100

Perhaps the registry should hold the history of the code point?

If the code point was created by RFCabc, then any equipment that correctly implemented RFCabc will always be a correct implementation of that specification, even if the definition changes as a result of RFCxyz.

This will hopefully cause Brian's programmer to look at both RFCs and if necessary ask which of these behaviours the product is supposed to implement.

Stewart

Sent from my iPad

> On 4 Jun 2016, at 00:35, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Barry Leiba <[email-masked]>
Date: Sat, 4 Jun 2016 14:42:48 -0400

I just find it fascinating and disturbing that at least two respected
IETF participants think it's perfectly fine to leave stale references
around, especially when it's trivially easy to fix them -- in the vast
majority of cases taking but one sentence in the IANA Considerations.
I'm simply flabbergasted.  This isn't "useless hoops"; it's simple and
sensible updates that rarely take any effort.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Jun 2016 09:02:56 +1200

> sensible updates that rarely take any effort.

Yes. I find stackoverflow as useful as anyone, but the people who provide
correct answers there ultimately depend on RFCs and the IANA registry, so the
latter just needs to be consistent with the former.

   Brian

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 04 Jun 2016 17:59:21 -0500

> sensible updates that rarely take any effort.

I have to agree with Barry on this one.

RFCs and IANA registries are for the _readers_, not the authors. I don't 
understand the objection to asking the author to do a little more work, 
to save work for the reader.  Typically there are many more readers than 
authors (one hopes). And readers commonly don't pay attention to all 
that "updated by" and "obsoleted by" stuff at the top of the RFC. In 
general, it's in the best interest of readers for IANA to point to the 
most up-to-date specification for a code point.

I'm okay if that guidance is not strict, that is along the lines of  
"it's a good idea..."  or "It is helpful to readers if..."

If people think that readers don't use the registries to find the specs, 
that opens up much bigger questions about required author hoop-jumping.

Ben.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 5 Jun 2016 00:22:35 +0100

> that opens up much bigger questions about required author hoop-jumping.

That was the assertion in the earlier discussion.

And I'd not be surprised if starting from an IANA registry were very
rare.

S.

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 04 Jun 2016 18:53:38 -0500

> And I'd not be surprised if starting from an IANA registry were very

I have personally done that considerably more than once. In the SIP 
world, there are _lots_ of extensions, so it's not all that rare to do 
the "what's this tag about?" dance

---

From: Gmail <[email-masked]>
Date: Sun, 5 Jun 2016 08:47:13 +0100

I do it quite a lot as well, it a good common point to find all of the RFCs, and current extensions that apply to a protocol.

That is one reason why I like the idea of including the history of the code point in the registry.

S

Sent from my iPad

> On 5 Jun 2016, at 00:53, Ben Campbell <[email-masked]> wrote:
> 
> I have personally done that considerably more than once. In the SIP world, there are lots of extensions, so it's not all that rare to do the "what's this tag about?" dance
> 
> S.

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Jun 2016 08:25:06 -0400

--On Saturday, June 04, 2016 11:35 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> Disagree. Misleading pointers on the IANA site will mislead
> some junior programmer sometime in the future, by a simple
> application of Murphy's law.
> 
>> IANA pointers to the old doc should turn up "obsoleted by"
>> notices. That ought to be enough to trigger the user to
>> follow the right path.
> 
> That's not realistic. If IANA refers to RFC822, and the
> programmer has a copy of RFC822 on her disk, that's what she
> will follow, because RFC text never changes and does not say
> "I am obsolete".

Fairly arbitrarily choosing Brian's message to which to respond,
I see this a little differently.  I think the fundamentals of
the disagreement between Stephen and Barry are surrogates for
the long-standing one of what we mean by "obsolete" and
"obsoletes".  We have a shortage of clear definitions, the only
thing 2026 says is in Section 4.2.4, which clearly links
"obsolete" (and hence, presumably, "obsoleted") to Historic
status.  It even implies that classification is automatic, which
is certainly not current practice.

It seems to me that we should be citing obsolete documents only
for historical purposes.  If a parameter value is still in
active use, then the most recent definition should be cited for
multiple reasons.  Brian's example is certainly one of them, but
the whole idea of a normative dependency (and pointers to
definitions from IANA registries are, in most cases (see below),
certainly that) to part of an obsolete document should just not
be acceptable.

This is not "make work", it is running a standards and parameter
registry system professionally and for maximum utility by the
use audience.  I think I'm agreeing with Barry and Ben about
this.  And, especially when the RFCs contain information that is
not in the registry (see below), I'm someone else who has quite
often tracked down RFCs by starting from the registries. 

Those who want to avoid the burden of updating registries should
be more careful about listing documents as obsolete rather than
updating them.  "Obsoletes all material in RFCxxxx except for
the parameter registry value discussion in Sections N and M"
should be an easy statement to make.  If it is not, that
document is probably badly organized and the community would
benefit from an updated reference to an updated document.

The other issue is that there are two kinds of "reference"
pointers from IANA registries even though IANA has, AFAIK, never
explicitly made the distinction.  In one case, the registry is
self-contained and the reference provides "where did this come
from" or "what authorized this" information.  In that case, the
user of the registry should not need (or want) to consult an RFC
except as part of historical research and reference to the
document that actually created (or most recently changed) the
registry entry is probably the correct one.  In the other case,
the reference is actually to information that actually provides
a definition of, or important information about, the parameter
value.  In that case, the pointer should be up to date (and
should not point to anything Obsoleted or Historic).  

As I read this thread (circa 23 messages at the time of this
writing), it seems to me that different assumptions about what a
pointer from a registry means underlie parts of the
disagreement.  If that is really the case, the fix is to adjust
the registries so that each one is clear about what the pointers
mean, rather than trying to water text down enough to
accommodate both cases.

    john

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 5 Jun 2016 13:43:44 +0100

> I have personally done that considerably more than once. In the SIP world, there are lots of extensions, so it's not all that rare to do the "what's this tag about?" dance

Me too (for IMAP and other things). Maybe IANA is a starting point for "advanced" users, but I think it does serve a very useful purpose for developers.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 05 Jun 2016 23:16:43 +1000

In message <[email-masked]>, Alexey Melnikov wr
ites:
> world, there are lots of extensions, so it's not all that rare to do the
> "what's this tag about?" dance
> >
>
> Me too (for IMAP and other things). Maybe IANA is a starting point for
> "advanced" users, but I think it does serve a very useful purpose for
> developers.

And same here for DNS types.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2016 14:33:42 -0000

>And same here for DNS types.

Yes, indeed.  There's no other reasonable way to figure out what some
random rrtype is supposed to do.  (Grepping the RFC collection, while
possible, is not reasonable.)

I'd say I look at IANA protocol registries a couple of times a month
both for DNS and other stuff.  No doubt there are programmers and
designers who never look at the registries, but there are also plenty
of them who never look at RFCs either.  Let's not go down that rat
hole.

R's,
John

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 5 Jun 2016 19:36:59 +0100

> On 5 Jun 2016, at 13:43, Alexey Melnikov <[email-masked]> wrote:
> 
> 

Isn't it also a starting point for some people doing network debug. I.e. People trying to figure out what is happening by looking at a packet trace.

Stewart

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jun 2016 13:37:15 -0700

> sensible updates that rarely take any effort.

Consider that RFC6335 specifically limits changes to at least one IANA
registry to the assignee. IMO, that's the right answer for all
registries with assignees. If the ISOC/IETF are the assignee, then they
can do whatever they want.

Further, producing an updated RFC does not immediately update the
deployed codebase. It might be appropriate to include the new RFC too,
but not in all cases.

Case in point: TCP MD5. This was obsoleted by TCP-AO, but the TCP option
number for TCP MD5 should not be changed to point to AO. It might be
appropriate to add a note that this codepoint represents an obsoleted
protocol or even to point to the new one - or not. It depends on the
codepoint.

Overall, the point is that "it depends". Setting a single rule to
"update" is an algorithm. I repeat my previous advice:

"I'd prefer to trust the author to do the right thing that to engineer
this document with an algorithm."

Joe

---

From: Barry Leiba <[email-masked]>
Date: Sun, 5 Jun 2016 17:10:01 -0400

> protocol or even to point to the new one - or not. It depends on the

Sure, this is a very different situation.  The most current
documentation for the code point for TCP MD5 is the obsolete document.
So that's fine.  TCP AO will have a new code point, with a current
reference.  As I've said before, the "in current use" clause is what
applies here: It's not just that the documentation for TCP MD5 has
been updated and we're thinking about whether we should point the
reference to the new document.  It's that TCP MD5 itself has been made
obsolete.

Yes, as you say (and as I say), the point is to do what's right.  I
contend that in most cases, the right thing is to update the reference
*when we produce a more current reference*.  If we have not done that,
then we should not do that.

And also as you say (and as I say), we always want to leave
flexibility to use our heads and do the right thing.  That's why I'm
very happy to move away from the "in no case" phrase, to something
such as "in most cases."  I pretty much *always* want to allow people
to make sensible judgments, and not to stand behind firm, inflexible
rules.

Barry

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 6 Jun 2016 10:18:44 +0000

>to make sensible judgments, and not to stand behind firm, inflexible

Phwew!

I think there is consensus on this: The authors are expected to do the right thing. In most cases, but not all, the right thing to do is to update a reference when the previous reference is obsoleted. One size does not fit all.

Barry, do you have updated text to capture the outcome of this long thread?

	Tony Hansen

---

From: tom p. <[email-masked]>
Date: Mon, 6 Jun 2016 11:20:16 +0100

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: "IETF discussion list" <[email-masked]>
Sent: Sunday, June 05, 2016 10:10 PM

> to make sensible judgments, and not to stand behind firm, inflexible

At the risk of making an abstract discussion concrete, RFC7001 provides
an example of how not to do it.  It caused IANA to update the pointers
to RFC7001 in many places but RFC7001 did not contain the relevant
information on the registries, their fields, policies etc.  Nor did
the RFC that RFC7001 obsoleted.  You had to go back to the RFC that were
superseded by the RFC that were obsoleted by RFC7001, add in the
updates,
and piece together the information you needed.  Hence RFC7601 (which
used the then current draft-leiba-cotton as its guide).  Compare the
IANA Considerations in RFC7601 with those in RFC7001 and you can see
what an expert author might come up without further, careful
consideration, such as that provided by APPSAWG in March 2015:-)

I think that the pointer should be to where the information about the
registry is held, the fields, policy etc and if that is not reproduced
in an obsoleting document, then the reference should stay to the
obsoleted document.  It is easy to check for updates against a document
via rfc-index and, like checking for errata, it is something you have to
do before you can rely on an RFC; going in the opposite direction, back
in time, is harder.

Of course, present day ADs do not regard the addition of an entry to a
registry as a document update to the RFC that is the current definition
of the registry so it is crucial that IANA separate references for new
values in a registry from the reference for the registry as a whole -
which IANA well understands.

If the information about the registry is carried forward, then there is
no
problem and that is the best solution; but not all authors do that (see
above).

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Jun 2016 07:35:56 -0400

--On Monday, June 06, 2016 10:18 +0000 "HANSEN, TONY L"
<[email-masked]> wrote:

> I think there is consensus on this: The authors are expected
> to do the right thing. In most cases, but not all, the right
> thing to do is to update a reference when the previous
> reference is obsoleted. One size does not fit all.

Yes, but I think two other questions have been raised that now
should be addressed:

(1) Should advice to IANA about registry creation and content
include a recommendation as to whether citations from a registry
should be just "as designated by authors/registrants" (typically
"most recent") or should also contain a historical back-thread?

(2) Should registries be explicit as to whether the information
in them is self-contained (i.e., that citations from them are
for historical or contextual interest only) or abbreviated
pointers to definitional documents (i.e., those looking up a
parameter as expected to consult cited documents in order to
understand it and its use)?

    john

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Jun 2016 13:00:43 -0700

Fair enough. As long as there's enough wiggle room and it's the party
assigned the codepoint and updating the spec that has the responsibility
to work things out, I'm fine with it.

Please let's not dump this on IANA though. They (we) have enough on
their (our) plate.

Joe

---

From: Sean Turner <[email-masked]>
Date: Mon, 6 Jun 2016 14:01:44 -0400

draft-ietf-tls-tls1.3 is going to widow/orphan some registries and obsolete RFC 5246.  What I’m hoping to do is not update the references for these widowed/orphaned registries and include a Note in the IANA registries that says something along the lines of “These registries are for TLS 1.2, 1.1, and 1.0”.  Assuming the words in the draft-leiba-cotton-iana-5226bis allow me to do that I’ll be happy.

spt

---

From: Sean Turner <[email-masked]>
Date: Mon, 6 Jun 2016 14:01:54 -0400

spt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 6 Jun 2016 19:34:05 -0400

> draft-ietf-tls-tls1.3 is going to widow/orphan some registries and
> obsolete RFC 5246.  What I’m hoping to do is not update the references
> for these widowed/orphaned registries and include a Note in the IANA
> registries that says something along the lines of “These registries are for
> TLS 1.2, 1.1, and 1.0”.  Assuming the words in the
> draft-leiba-cotton-iana-5226bis allow me to do that I’ll be happy.

It absolutely should.  First, if the registries are not for TLS 1.3,
there's certainly no reason to change the references.  The issue we're
talking about isn't just that the reference document has become
obsolete, but that there is a more current reference now -- which
won't be the case for what you're talking about.  Second, anything
that makes sense to do with a reason behind it should always be
acceptable.  I'll make sure the final text makes that point clear.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 6 Jun 2016 21:22:58 -0400

OK, I have new text to propose for the paragraph in question (sorry:
it makes it a bit longer) as a result of this discussion.  Thanks,
everyone, for putting in your comments.

Stephen, and all, how does this work?:

NEW
   If information for registered items has been or is being moved to
   other documents, then the registration information should be changed
   to point to those other documents. In most cases, documentation
   references should not be left pointing to the obsoleted document
   for registries or registered items that are still in current use.
   For registries or registered items that are no longer in current
   use, it will usually make sense to leave the references pointing
   to the old document -- the last current reference for the obsolete
   items.  The main point is to make sure that the reference pointers
   are as useful and current as is reasonable, and authors should
   consider that as they write the IANA Considerations for the new
   document.  As always: do the right thing, and there is flexibility
   to allow for that.
END

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Jun 2016 09:13:34 +0100

> Stephen, and all, how does this work?:

Still not my fav thing but I agree it matches the discussion
so I'll clear that discuss point based on this or similar
text.

S

---

From: [email-masked] (Martin Rex)
Date: Tue, 7 Jun 2016 10:40:25 +0200 (CEST)

Sean Turner wrote:
>
> draft-ietf-tls-tls1.3 is going to widow/orphan some registries
> and obsolete RFC 5246.

TLSv1.3 is *NOT* going to obsolete in the original/true sense of
obsoletion as it was defined and meant for RFC documents & IETF specifications.

Please remove any such bogus Obsoletion meta-data from the TLSv1.3 draft,
that is erroneously present in rfc4346 and rfc5246, and your perceived
problem vanishes completely.

>
> What I'm hoping to do is not update the references for these
> widowed/orphaned registries and include a Note in the IANA registries
> that says something along the lines of "These registries are for TLS 1.2,
> 1.1, and 1.0".
> Assuming the words in the draft-leiba-cotton-iana-5226bis allow me
> to do that I'll be happy.

Retaining the history of documents in the IANA registry (not deleting
older references to older documents) will also avoid confusion.

-Martin

PS: your MUA seems to be erroneously configured to send HTML-only EMail