Subject: [tsvwg] [Editorial Errata Reported] RFC7605 (4437)

From: RFC Errata System <[email-masked]>
Date: Fri, 7 Aug 2015 11:21:04 -0700 (PDT)

The following errata report has been submitted for RFC7605,
"Recommendations on Using Assigned Transport Port Numbers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7605&eid=4437

--------------------------------------
Type: Editorial
Reported by: John Klensin <[email-masked]>

Section: Abstract

Original Text
-------------
It provides designer guidance to requesters or users of port numbers on
how to interact with IANA using the processes defined in RFC 6335;
thus, this document complements (but does not update) that document.
It provides guidelines for designers regarding how to interact with
the IANA processes defined in RFC 6335, thus serving to complement
(but not update) that document.

Corrected Text
--------------
It provides designer guidance to requesters or users of port numbers on
how to interact with IANA using the processes defined in RFC 6335;
thus, this document complements (but does not update) that document.

Notes
-----
I think those two sentences say exactly the same thing and that the presence of both indicates that someone wasn't paying quite enough attention during AUTH48 or earlier.  If they are intended to communicate different information, it isn't clear what that is and the result is massively confusing.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7605 (draft-ietf-tsvwg-port-use-11)
--------------------------------------
Title               : Recommendations on Using Assigned Transport Port Numbers
Publication Date    : August 2015
Author(s)           : J. Touch
Category            : BEST CURRENT PRACTICE
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 11:28:12 -0700

FWIW - I've contact the RFC-Editor about this; it isn't being ignored.
I'll report back when I hear back.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 17:18:34 -0700

On 8/12/2015 5:14 PM, John C Klensin wrote:
> 
> Joe,
> 
> Thanks for the update.  In your discussions with the RFC Editor,
> note that there are also two blank lines in the middle of the
> first paragraph of the Introduction.  Not worth a separate
> erratum, but another indication that something went wrong during
> final review and/or formatting.

Yeah - I'm not sure I can say whether I missed it during AUTH48 per se,
but it certainly crept back in after we had converged on the abstract
(which shouldn't happen).

IMO, the content of these two issues ought to allow a change in-place
rather than an errata. The two sentences aren't as much in conflict as
it's confusing that they're both there.

I'll see what they say when they respond.

Joe

> 
>    john
> 
> 
> --On Wednesday, August 12, 2015 11:28 -0700 Joe Touch
> <[email-masked]> wrote:
> 
>> FWIW - I've contact the RFC-Editor about this; it isn't being
>> ignored. I'll report back when I hear back.
>>
>> Joe
>>
>>> It provides designer guidance to requesters or users of port
>>> numbers on how to interact with IANA using the processes
>>> defined in RFC 6335; thus, this document complements (but
>>> does not update) that document. It provides guidelines for
>>> designers regarding how to interact with the IANA processes
>>> defined in RFC 6335, thus serving to complement (but not
>>> update) that document.
>>>
>>> Corrected Text
>>> --------------
>>> It provides designer guidance to requesters or users of port
>>> numbers on how to interact with IANA using the processes
>>> defined in RFC 6335; thus, this document complements (but
>>> does not update) that document.
>>>
>>> Notes
>>> -----
>>> I think those two sentences say exactly the same thing and
>>> that the presence of both indicates that someone wasn't
>>> paying quite enough attention during AUTH48 or earlier.  If
>>> they are intended to communicate different information, it
>>> isn't clear what that is and the result is massively
>>> confusing.
>>>
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary,
>>> please use "Reply All" to discuss whether it should be
>>> verified or rejected. When a decision is reached, the
>>> verifying party (IESG) can log in to change the status and
>>> edit the report, if necessary. 
>>>
>>> Title               : Recommendations on Using Assigned
>>> Transport Port Numbers Publication Date    : August 2015
>>> Author(s)           : J. Touch

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 20:14:55 -0400

Joe,

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 21:19:24 -0400

--On Wednesday, August 12, 2015 17:18 -0700 Joe Touch
<[email-masked]> wrote:

>> Thanks for the update.  In your discussions with the RFC
>> Editor, note that there are also two blank lines in the
>> middle of the first paragraph of the Introduction.  Not worth
>> a separate erratum, but another indication that something
>> went wrong during final review and/or formatting.
> 
> Yeah - I'm not sure I can say whether I missed it during
> AUTH48 per se, but it certainly crept back in after we had
> converged on the abstract (which shouldn't happen).
> 
> IMO, the content of these two issues ought to allow a change
> in-place rather than an errata. The two sentences aren't as
> much in conflict as it's confusing that they're both there.

We haven't done a change in place for a long time, almost
certainly not since Jon passed away, and I'm pretty sure one can
count the total number of times that they've been done on the
fingers of one hand.  On the other hand, there is more precedent
for issuing a new RFC that obsoletes the old one and doing it
with a minimum of fuss and as an RFC Editor administrate option
(e.g., no new IETF LC).

> I'll see what they say when they respond.

What is discomfiting about this is that we are supposedly in the
middle of a renewal of the Production Center Contract and
starting a transition to what, IMO, is a much more complex RFC
production and formatting system.  A screwup like this, no
matter how trivial substantively, just seems like either
extremely bad timing or a warning sign.

Anyway, no hurry from my point of view and, again, thanks for
keeping me informed.

    john

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 14:43:38 -0700

Hi, all,

I finally heard back from Heather after pinging her directly.

Heather indicated that the RFC Editor approved the errata below. They
failed to answer any of my questions as to how this happened or where in
the process it happened. IMO, if they want to accept this errata, then
they are taking responsibility for it.

I consider their handling of this issue sub-par, and encourage the
chairs to bring it up as appropriate.

Regardless, that's where things are and where they are likely to remain.

Joe

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Aug 2015 18:44:14 -0400

Can someone directly involved (such as you, Joe, or Spencer as
the relevant AD) bring this directly to the attention of the
RSOC and/or IAB?  I agree about sub-par and believe there should
be an explanation to the community as to what happened.  The IAB
and RSOC are supposed to be our accountability mechanism.

best,
   john

--On Friday, August 21, 2015 14:43 -0700 Joe Touch
<[email-masked]> wrote:

> Heather indicated that the RFC Editor approved the errata
> below. They failed to answer any of my questions as to how
> this happened or where in the process it happened. IMO, if
> they want to accept this errata, then they are taking
> responsibility for it.
> 
> I consider their handling of this issue sub-par, and encourage
> the chairs to bring it up as appropriate.
> 
>>> This erratum is currently posted as "Reported". If
>>> necessary, please use "Reply All" to discuss whether it
>>> should be verified or rejected. When a decision is reached,
>>> the verifying party (IESG) can log in to change the status
>>> and edit the report, if necessary. 
>>>

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Aug 2015 15:49:02 -0700

Hi, John,

My primary issue at this point is their taking 2 weeks to respond AND
not involving me in confirming the errata.

Additionally, the idea that we can't fix silly production errors like
this within a few days seems ridiculous in this day and age. Some errors
won't be found until there are many eyes, and some corrections don't
change content. We ought to be able to do better.

I've already asked the ADs to raise this.

Joe