Subject: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 01 Aug 2017 14:23:33 -0700

Adam Roach has entered the following ballot position for
draft-ietf-urnbis-ns-reg-transition-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Major comment:

Section 3 has suggested changes for RFC3188 for the next time it is revised.
It's not clear, outside of institutional knowledge (which is a very fragile
construct) how the indicated changes are going to be properly remembered when
such revision takes place. Is there a good reason this document doesn't simply
update RFC3188 by indicating an updated template directly? If this doesn't make
sense, I would think that we need at least an erratum associated with RFC3188
that indicates the nature of update that needs to be performed.

Minor comments:

The draft header indicates that this document obsoletes RFC3044 and RFC3187,
but the abstract doesn't mention this, which it should.

The document has at least nine places where external documents are mentioned
but which are not, themselves, reference citations (e.g., "RFC 8141"  rather
than "[RFC8141]" in section 2). This will interact poorly with some RFC-related
tooling. Please change these to references.

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Aug 2017 18:29:50 -0400

Adam,

While I disagree with your comments, thanks for the careful
reading.

Several comments and clarifications below, with the
understanding that these are my opinions only and that, if there
is evidence of WG or IETF consensus to the contrary, I'm happy
to make changes...

--On Tuesday, August 1, 2017 14:23 -0700 Adam Roach
<[email-masked]> wrote:

> When responding, please keep the subject line intact and reply
> to all email addresses included in the To and CC lines. (Feel
> free to cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for
> more information about IESG DISCUSS and COMMENT positions.
> 
> 
> --------------------------------------------------------------
> -------- COMMENT:
> Section 3 has suggested changes for RFC3188 for the next time
> it is revised. It's not clear, outside of institutional
> knowledge (which is a very fragile construct) how the
> indicated changes are going to be properly remembered when
> such revision takes place. Is there a good reason this
> document doesn't simply update RFC3188 by indicating an
> updated template directly? If this doesn't make sense, I would
> think that we need at least an erratum associated with RFC3188

The problem is this.  RFC 3188 was never an IETF WG document.
It will be replaced by a new RFC, most likely in the Independent
Stream unless you are one of your colleagues are interested in
sponsoring it as an Informational individual submission.  Juha
and I have been working intermittently on a draft; the hold-up
right now is mostly me, for which I apologize but I have been
tied up with other IETF-related work that seemed to be more
pressing.  There are twp reasons why an updated template is not
directly referenced: it isn't ready due to evolution in NBNs and
it seemed inappropriate for the WG to make promises about what
would be in it.  FWIW, the specific things that this draft calls
out have already been incorporated in the working draft for
3188bis.

> Minor comments:
> 
> The draft header indicates that this document obsoletes
> RFC3044 and RFC3187, but the abstract doesn't mention this,
> which it should.

Disagree.  Those are informational documents, not standards
track ones, the abstract correctly reflects what the document
does, and the relationships are carefully explained in Section
2.  Cluttering up the abstract by putting in those RFC numbers
seems neither desirable nor appropriate and this should
reasonably be an editorial matter under the control of the RFC
Editor, not something specified by the IESG.

> The document has at least nine places where external documents
> are mentioned but which are not, themselves, reference
> citations (e.g., "RFC 8141"  rather than "[RFC8141]" in
> section 2). This will interact poorly with some RFC-related

This, again, is an RFC Editor question and a stylistic issue.
As far as I know, each of those documents is cited correctly on
first appearance (including RFC 8141, which is cited in Section
1).  Repeating those citation anchors each time the RFC (or
other document) is referenced does not add to either readability
or provide useful information for the user.    I note that
neither the RFC Style Guide (RFC 7322) nor the plain text
requirements (RFC 7994) require a citation anchor each time a
document is mentioned.   If the IESG would like to impose such a
requirement (in spite of advice against it in several style
manuals), I believe it should be a topic for discussion between
the IESG and the RFC Editor, not an IESG review comment on
particular documents.

It may be worth mentioning that, despite the observation that
some RFC authors have adopted the convention and the RFC Editor,
in their wisdom, has chosen to let it go, the use of a citation
anchor as the subject of a sentence or predicate of a sentence,
object of a preposition, etc. (e.g., "as discussed in
[RFC8141]") is prohibited by every style manual for the English
language that I've been able to find except those who consider
the construction such a grave grammatical error as to not be
worth mentioning.  Perhaps the issue is most easily clarified by
assuming RFCs are pretty-printed and "[RFC8141]" above were
replaced by a superscript numeral.

Of course, if documents were referenced without being cited
properly at all, I'd be delighted to fix that when the problems
are identified unless the RFC Editor gets to it first.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Aug 2017 15:33:55 -0700

On Tue, Aug 1, 2017 at 3:29 PM, John C Klensin <[email-masked]> wrote:

> > --------

Speaking for myself, I would vastly prefer that when people cite RFCs by
number, those RFCs be actual citations. The reason for this is that those
can then be linkified.

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Tue, 1 Aug 2017 18:05:55 -0500

On 8/1/17 5:29 PM, John C Klensin wrote:
> sponsoring it as an Informational individual submission.

Have you asked?

> Juha

The fact that a document revision is actually underway does assuage my 
concern for the most part. Could you cite the 3188bis document as a work 
in progress? I think it would be useful for consumers of this document 
to know that a revision is actively in progress, and to have a document 
name to look for.

> Editor, not something specified by the IESG.

Rather than engaging on the broader topic of indicating Obsoletes and 
Updates in the abstract in general, I'll point out that *this* document 
is paired with a request to reclassify 3044 and 3187 as Historic. There 
is long-standing IESG guidance on this topic 
<https://www.ietf.org/iesg/statement/designating-rfcs-as-historic-2011-06-27.html>, 
which includes the provision "If authors wish to change the status of 
RFCs that are in the obsoletes header to Historic, then the authors must 
include an explicit statement for the RFC editor to do so; *preferably 
in the abstract and introduction*."

You may, of course, choose to ignore this officially stated IESG 
preference, but doing so would unnecessarily go against convention.

In terms of RFC Editor policy: while the RFC Style Guide does not 
explicitly require obsoleted RFCs to be listed in the abstract, I find 
it rather telling that it does, itself, do so. This is quite possibly 
because RFC Abstracts (according to said style guide) are required to 
give a "concise and comprehensive overview of the purpose and contents 
of the entire document," and some substantial portion of the purpose of 
*this* document is obsoleting existing RFCs -- thus failing the 
"comprehensive" portion of that requirement. So while it may well be 
outside my purview as a member of the IESG to require you to fix this 
defect, it seems quite probable that you'll have this conversation again 
with a member of the RPC in a short while.

/a

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Aug 2017 11:04:31 -0400

--On Tuesday, August 1, 2017 18:05 -0500 Adam Roach
<[email-masked]> wrote:

>>> updated template directly? If this doesn't make sense, I
>>> would think that we need at least an erratum associated with
>>> RFC3188 that indicates the nature of update that needs to be
>>> performed.

>> It will be replaced by a new RFC, most likely in the
>> Independent Stream unless you are one of your colleagues are
>> interested in sponsoring it as an Informational individual
>> submission.
> 
> Have you asked?

Not yet.  Figured it would be better to have a posted I-D first.

>> pressing.  There are twp reasons why an updated template is
>> not directly referenced: it isn't ready due to evolution in
>> NBNs and it seemed inappropriate for the WG to make promises
>> about what would be in it.  FWIW, the specific things that
>> this draft calls out have already been incorporated in the
>> working draft for 3188bis.
> 
> The fact that a document revision is actually underway does
> assuage my concern for the most part. Could you cite the
> 3188bis document as a work in progress? I think it would be
> useful for consumers of this document to know that a revision
> is actively in progress, and to have a document name to look
> for.

We had such a reference or something like it in an earlier
draft.  Barry asked us to take it out on the grounds that the WG
should not be making promises about a document that was not part
of its work program.  That made sense to me, so we removed it.
But I don't feel at all strongly about it so, if you, Barry and
others want such a placeholder reference, I'm happy with that.
 
> Rather than engaging on the broader topic of indicating
> Obsoletes and Updates in the abstract in general, I'll point
> out that *this* document is paired with a request to
> reclassify 3044 and 3187 as Historic. There is long-standing
> IESG guidance on this topic
> <https://www.ietf.org/iesg/statement/designating-rfcs-as-histo
> ric-2011-06-27.html>, which includes the provision "If authors
> wish to change the status of RFCs that are in the obsoletes
> header to Historic, then the authors must include an explicit
> statement for the RFC editor to do so; *preferably in the
> abstract and introduction*."

There is an explicit statement in the Introduction.  It does not
use the word "Historic" (that is in Section 2).  If you believe
the document would be improved by changing the relevant sentence
in the Introduction to say "Obsoletes the separate RFCs and
makes them Historic...", that change is easily made (and,
frankly, should be have long before this, but no one caught it).
I believe there are documents where there is good reason to
include RFC numbers in the abstract but this is not one of them.
I also note that RFC Editor rules against putting citation
anchors in abstracts causes every such included RFC number to
violate your preferred citation rule because those numbers not
only do not have citation numbers but are the first textual
references to those numbers in the document.   If "preferably"
is turning in "mandatory", we need to have two discussions, one
about the authority boundary between the IESG and the RFC Editor
and the other about where in RFC 2026 and its updates the IESG
is given authority to make policy by issuing statements rather
than determining and reflecting IETF community consensus.

> You may, of course, choose to ignore this officially stated
> IESG preference, but doing so would unnecessarily go against
> convention.

See above.  I am not ignoring it.  I have carefully considered
it and concluded that it is inappropriate for the abstract in
this case, a conclusion with which no one in the WG has
expressed disagreement.  As to "go[ing] against convention", I
believe that a careful survey of documents since that statement
was issued would not show that the "preference" has been
consistently enough followed to constitute normal behavior, nor
that this is a "preference" that the RFC Editor is enforcing.
If this were really close to a firm rule, I would expect the RFC
Editor to "correct" every deviation during their editorial
process, allowing any issues to be sorted out on AUTH48, just as
they enforce, e.g., references without citations.

> In terms of RFC Editor policy: while the RFC Style Guide does
> not explicitly require obsoleted RFCs to be listed in the
> abstract, I find it rather telling that it does, itself, do
> so. This is quite possibly because RFC Abstracts (according to
> said style guide) are required to give a "concise and
> comprehensive overview of the purpose and contents of the
> entire document," and some substantial portion of the purpose
> of *this* document is obsoleting existing RFCs -- thus failing
> the "comprehensive" portion of that requirement. So while it
> may well be outside my purview as a member of the IESG to
> require you to fix this defect, it seems quite probable that
> you'll have this conversation again with a member of the RPC
> in a short while.

The "comprehensive" part of that requirement is arguably a poor
choice of words (I will get an erratum filed later today), but
the paragraph that follows (RFC 7322, Section 4.3) makes this
perfectly clear (at least to me) that the Abstract is a matter
of professional and editorial judgment, not something that
should become long or confusing in the interest of covering all
aspects of the document completely.   The paragraph after that,
requiring that the Abstract be complete in itself, prohibits
citations, implying that people should not have to look at other
documents to understand the abstract.  However, a statement such
as "This document makes RFC 3044 Historic" is a citation (even
though it doesn't have an explicit anchor) and conveys no
information unless one knows what 3044 refers to (see below
about well-known numbers).

Again, I believe this is an editorial judgment call.   I believe
that, had I been editing the Style Guide, I would have included
the number of the previous one in the abstract and, since that
preference was announced and despite my misgivings about
citations in abstracts, I have generally included the numbers
when a new document completely replaces an old one (or more than
one) and/or when the previous spec is widely known by its
number.  However, those criteria identify both of the issues
that have caused me to make a different judgment in this case:

(1) Unless the previous document was widely known by its number,
as distinct from being known by a name or not being well-known
at all, I dislike, as an editorial matter, including RFC numbers
in abstracts without explanations.  The reason is closely linked
to the RFC Editor decision to not allow citation anchors in
abstracts (a decision that is supported by some, but not all,
more generally used style manuals).   If the goal of an abstract
is to provide information to the casual reader about what the
document is about, "clarifies the status of relevant older RFCs"
(or even "clarifies the status of relevant older RFCs. including
making the ones describing the ISBN and ISSN URNs historic", a
change I'd happily make if you felt it would improve things)
does that and fulfills  a reasonable interpretation of the
"comprehensive" requirement without folding the entire document
into the abstract (which might be required by another
interpretation of "comprehensive").  

(2) Under most circumstances in which one document replaces (and
obsoletes) another, the new document contains all of the
information in the old one and/or explains what it changes.  If
that type of relationship and explanation is present, there is a
strong argument for reflecting that (number or not) in the
abstract as part of being "comprehensive".    However, in this
case, the substantive replacements for the substantive parts of
RFCs 3044 and 3187 are not in the text in this document.  This
document describes the changes in general terms, but the
replacement specifications are the new templates.  Specifically,
I disagree with your conclusion that "some substantial portion
of the purpose of *this* document is obsoleting existing RFCs":
a substantial portion of the document explains why the templates
make the existing RFCs de facto obsolete, but the only sense in
which it obsoletes them is a narrow procedural one on which it
does not spend much text.  Noting that there is no procedure for
an IANA registration to obsolete an RFC, when we assumed that
this document would be published before those templates were
agreed-to and posted, there was some convoluted text in earlier
versions of this I-D about not obsoleting 3044 and 3187 until
the new templates were registered, text that presumably would
have made this conversation even more "interesting".

Situations in which a new document obsoletes all or part of an
older one as part of, e.g., defining a new strategy have always
been problematic in the IETF, with, e.g., frequent problems
about references, sometimes normative, to sections of the older
document that were not addressed anywhere.  In large measure,
this document was produced to avoid that problem for the
relevant URN namespaces, a goal I hope the IESG would welcome.

I note for purposes of comparison that RFC 8141 obsoletes RFCs
2141 and 3406 in the more traditional sense.  The new
specification covers all of the same ground as the older ones
and there is no substantively-interesting text in the older ones
that is not replaced or repeated by text in the new one.  In
addition, 2141 and 3406 are fairly widely known by their
numbers.   And the older documents are listed by number in the
abstract.

The above suggests another alternative, one that I would
recommend if the current preference of the IESG is to make more
work for the community and itself in the interest of favoring
form over function.  This document could be divided into two
parts, one of which would be a simple explanation of the changes
and relationships, that wouldn't obsolete anything (although it
would provide the motivation for doing so), and that could be
published as Informational.  The other would be a very short,
standards-track document that would obsolete the ISSN (3044) and
ISBN (3187) RFCs and make them Historic, reference the first one
and the templates informatively, contain the RFC numbers in the
abstract because that would be its main purpose, etc.   We
didn't do that because we believed it would be more confusing
for users, in part because we don't have a good way to link such
documents together and reflect current status (another decision
of a long-gone IESG), but it was a conscious decision.  Of
course, splitting things up at this point would require new
I-Ds, probably a new WG review/ LC, a pair of IETF Last Calls,
and then new IESG actions.    But, again, if that is what the
IESG, it its wisdom, wants and how the IESG believes the
community can best spend its time, I'm willing to break the
document apart so that it is possible.

regards,
    john

---

From: Adam Roach <[email-masked]>
Date: Wed, 2 Aug 2017 13:18:29 -0500

On 8/2/17 10:04, John C Klensin wrote:
> If "preferably"

Thanks for sending me down the path of determining authority here, as it 
has made me realize that I was confused about the basis for insisting 
that Obsoleted documents be explicitly listed in the Abstract.

It turns out that the 2011 IESG statement of "preferably" is a weak 
restating of a 2008 IETF-consensus decision to approve version 1.9 of 
the "ID-Checklist" document, which clearly states that the Abstract of a 
document needs to list obsoleted and/or updated documents (cf. 
<https://www.ietf.org/id-info/checklist.html#anchor6>; §3, 1.D, first 
bullet: "if your document obsoletes or updates a previous RFC, then... 
say so in the abstract").

And so I am forced to concede that my "No Objection" was made in error. 
Since the form of this document actively goes against IETF community 
consensus regarding the form of IETF-stream RFCs, I realize that this 
should have been a "Discuss." I will be adjusting my ballot accordingly. 
Thank you again for pointing me in the correct direction, and I 
apologize for the error.

> As to "go[ing] against convention", I

I've consulted with the RFC Editor, and received confirmation that their 
policy is (and has historically been) to "help enforce" this 
requirement, on the authority of ID-Checklist. You seem to be aware of 
documents for which this was overlooked. If you could identify them, I 
would appreciate it, as doing so would allow the proper errata to be filed.

/a

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Aug 2017 08:49:19 -0400

--On Wednesday, August 2, 2017 13:18 -0500 Adam Roach
<[email-masked]> wrote:

>> is turning in "mandatory", we need to have two discussions,
>> one about the authority boundary between the IESG and the RFC
>> Editor and the other about where in RFC 2026 and its updates
>> the IESG is given authority to make policy by issuing
>> statements rather than determining and reflecting IETF
>> community consensus.
> 
> 
> Thanks for sending me down the path of determining authority
> here, as it has made me realize that I was confused about the
> basis for insisting that Obsoleted documents be explicitly
> listed in the Abstract.
> 
> It turns out that the 2011 IESG statement of "preferably" is a
> weak restating of a 2008 IETF-consensus decision to approve
> version 1.9 of the "ID-Checklist" document, which clearly
> states that the Abstract of a document needs to list obsoleted
> and/or updated documents (cf.
> <https://www.ietf.org/id-info/checklist.html#anchor6>; §3,
> 1.D, first bullet: "if your document obsoletes or updates a
> previous RFC, then... say so in the abstract").
> 
> And so I am forced to concede that my "No Objection" was made
> in error. Since the form of this document actively goes
> against IETF community consensus regarding the form of
> IETF-stream RFCs, I realize that this should have been a
> "Discuss." I will be adjusting my ballot accordingly. Thank
> you again for pointing me in the correct direction, and I
> apologize for the error.
>...

Adam,

Silly me.  I was about to propose a compromise in this area --
one that I hoped would allow the document to move forward, for
me to be able to get back to RFC 3188bis and for you and the
IESG to get back to more important work --  and either didn't do
it soon enough or should have just kept my mouth shut and sorted
this out with the RFC Editor.  I was sufficiently appalled by
your decision that I needed to take overnight to raise my
confidence that I was not overreacting.

Sadly, I don't think I was overreacting.  Consequently, unless
this DISCUSS can be resolved in some other way today, I will
submit a formal appeal against your use of a blocking DISCUSS on
an essentially editorial matter that puts form over substance
and that is abusive of working group decisions and the Last Call
and IESG review processes.  

In addition to the narrow issues in this particular case, the
appeal is likely to raise the following issues:

(1) The need to clarify the boundary between the IESG's
authority, reflecting community consensus, over matters of
content for documents in the IETF Stream and the RFC Editor's
authority over editorial matters.  General guidance and
statements of preference notwithstanding, I believe that
existing documents and long-standing tradition make rules about
the editorial (as distinct from substantive) content and
structure the exclusive province of the RFC Editor, with the
only important exception being the provision for the IESG to
demand "as is" publication of IETF Stream documents.  The
requirement is 

(2) The pattern of migration of "guidance" or "recommendations"
into firm requirements ("rules") on which a blocking DISCUSS can
be based and publication of such requirements only in IESG
statements rather than archival documents of record.  I note
that Section 5 of RFC 3710 (the IESG Charter) makes a
distinction between "problems and how to avoid them" and
"commonly used guidelines" on the one hand and "rules" on the
other.  While that document says that the latter are "commonly
published as BCP RFCs", I suggest that substituting
poorly-indexed and non-archival "statements" or "checklists" for
such RFCs sets a trap for the inexperienced or unwary and is
hence inconsistent with a predictable and fair process.

(3) Imposition of specific blocking rules involving the use or
applicability of terms such as "obsolete[s]" and "historic" is
inappropriate when it is generally recognized in the community
that those terms are insufficiently defined and inconsistently
applied.  The way to solve those problems of definition and
application involves a proposal for what should be done,
community discussion and consensus, and RFC publication, not
dropping a DISCUSS on a single document that was either
arbitrarily chosen or that was singled out because one of the
author-editors chose to push back on an editorial "preference".
The observation that the IESG has not seen fit to initiate a
community-based effort (such as a WG) to clarify those
definitions makes a DISCUSS based on the use of those terms
particularly questionable.

(4) There are some specific issues with the checklist statement
you cite that make it subject to different interpretations and
highlight the issues identified in (2) above.  For example:

(4.1) As noted in erratum 5076, a statement similar to "this
document obsoletes RFC 4687" is a citation whether an anchor
appears there or not, yet C(1)(B) of the checklist prohibits
citations.  

(4.2) C(1)(C) references "section 4.5 in
https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt"
in a context that can only be interpreted as normative, yet that
link is dead (leads to a 404 error) and the document to which it
referred became obsolete (sic) when RFC 7322 was published if
not earlier.  To save you the time of checking, Section 4.5 of
RFC 7322 is not about abstracts.

(4.3) C(1)(D), which you have cited in support of the presumed
requirement, says "if your document obsoletes or updates a
previous RFC, then: say so in the abstract".  However, "say so"
appears to be general guidance, not a requirement for specific
language.  The abstract in
draft-ietf-urnbis-ns-reg-transition-08 includes "This document
clarifies the status of relevant older RFCs...", which I contend
is consistent with the checklist "say so" statement.  Had you
requested that statement be expanded to say "...document
clarifies the status of relevant older RFCs and formally makes
two of them historic...", I would have made a bad face but,
unless my co-author, the WG Chairs, or the WG disagreed, I would
have made the change and we would not be having this discussion.

If the IESG (or even a single AD) is going to treat a particular
document as a set of requirements that justifies a blocking
DISCUSS, then it is obligated to maintain them so that
statements are clear and normative references are usable.
Failure to do so makes application of the documents or
statements in that way fundamentally unfair.

(5) Even if none of the considerations outlined above applied,
it would be inappropriate to use a blocking DISCUSS because the
guidance in a particular document violates a "rule" or
"checklist item" when that guidance has existed for a long time
and has never been enforced consistently.

regards,
    john

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 4 Aug 2017 17:36:05 +0900

Hello John, Adam,

I'm currently on a plane heading for vacations, so I very much hope that 
by the time you get this email, things have cooled down a bit rather 
than escalating further.

I seriously think that exchanges like this are not worth the time of two 
busy people like you, not to speak of the rest of the IESG and the WG 
(or those in the WG who still read its mail).

It may seem like Adam is singling out this draft, but he only recently 
became an AD, and to support that claim, it would be necessary to show 
that he on-purpose ignored the same issue in other drafts that have 
recently come up to the IESG. Maybe he's just trying to do his best as a 
new AD. Or maybe he is just trying to give a bit more attention to an 
issue that is somewhat more important to him than to other IESG members; 
that's definitely not something that other ADs haven't done in the past.

As for RFC numbers in abstracts, how exactly to show them can be left to 
the RFC Editor. Every reader will know how to get more information by 
going to the references section of the main document even if the number 
isn't styled as a reference. The concept of 'well-known RFC number' is 
very relative; there may be RFC numbers that the potential readers of 
the document know quite well even though the 'average' RFC reader won't. 
Also, if I as a reader don't know an RFC number that's obsoleted, then 
that's a very good signal that I may not have to care. If we still want 
to help the reader more, an additional phrase giving the title may also 
help. I'm not saying that because I think that these RFC numbers need to 
be in the abstract, just to say that it won't be the end of the world if 
they are.

As for WG consensus, I'm not the one who judges that, but I'd think that 
questions like whether to put RFC numbers in the abstract or not haven't 
been discussed seriously, and the average WG member could care less 
about it either way.

I strongly suggest that John take down his threat of an appeal, and Adam 
take down the discuss, and that you both, if necessary with the help of 
others, figure this out with less heat.

Regards,   Martin.

On 2017/08/03 21:49, John C Klensin wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
> 

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Aug 2017 08:37:42 -0400

--On Friday, August 4, 2017 17:36 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

> Hello John, Adam,
> 
> I'm currently on a plane heading for vacations, so I very much
> hope that by the time you get this email, things have cooled
> down a bit rather than escalating further.

Martin,

Thanks for the wise and calming words.   If I were seeking to
recall Adam over this, they would be entirely appropriate, but I
am not.   This is a matter of an appeal from a particular AD
decision that I believe is out of line and that is _exactly_
what appeals are intended for: to ask the IESG, and, if
necessary, the IAB and ISOC to review a particular decision,
think about it a bit more, determine whether it was appropriate
and, if it is not, to  then take whatever actions are needed to
adjust and avoid unnecessary recurrences.

The bar for what seem to be blocking DISCUSS positions -- ones
that have the character of "unless the IESG overrides my
position, I am not going to let this go through until my
concerns are reflected by changes in the I-D" rather than "I
think this issue needs further consideration and discussion" is
critical to the efficient and effective functioning of the IETF.
I believe that its being set too low is one of the reasons
important work has been migrating away from the IETF.  More
important for this particular issue, the IESG has been asked
repeatedly to change names or procedures so that the intent that
separates those two very different DISCUSS procedures was made
clear.  I note that issue was included in at least one appeal
over 11 years ago and that, AFAICT, the IESG has, in the
subsequent decade, neither taken action on that issue or
explained why not -- itself, IMO, as significant violation of
the intent of the appeals model and a threat to fairness.

Because of that, I would feel obligated to produce a formal
appeal and carry it forward even if Adam changed his mind about
the DISCUSS.

> It may seem like Adam is singling out this draft, but he only
> recently became an AD, and to support that claim, it would be
> necessary to show that he on-purpose ignored the same issue in
> other drafts that have recently come up to the IESG. Maybe
> he's just trying to do his best as a new AD. Or maybe he is
> just trying to give a bit more attention to an issue that is
> somewhat more important to him than to other IESG members;

Again, if I were contemplating a recall, you would be absolutely
correct about a pattern of bad behavior.  I am not, although
whether I even have the right to contemplate such things raises
other issues.   No such pattern is required for an appeal of a
particular action.   You can legitimately question whether an
appeal in this case should simply say "this is a bad decision,
please reconsider it" or whether it is appropriate for me to
point out that, intentionally or not, the action raises other
questions including, in this case, the authority (as inviolable
rules rather than general guidance or preferences) of IESG
statements or positions (especially those not published in the
RFC Series), the question of whether general editorial decisions
and style-setting for the RFC Series lie with the IESG or the
RFC Editor, and those issues of the bar for blocking DISCUSSes
and the IESG's failure to adequately distinguish between the two
despite at least on earlier appeal.

One unfortunate, but I presume unavoidable, aspect of this is
that Adam was not on the Thursday IESG call when this draft was
on the agenda.  Because he was not available to participate in
the discussion and did not submit any clarifying material in
advance, the document, rather than being considered and probably
advanced or even specifically rescheduled, could not be
discussed and was dropped into an "AD followup" state with, so
far, no scheduled date for more of a discussion.

Whatever else you may think of my response to Adam's note
announcing the DISCUSS, it was an explicit indication to Adam
(and anyone else watching) that I intended to make this an
appeal issue and an outline of the issues I intended to raise.
That sort of indication, essentially a "please reconsider this,
if possible, before it gets out of hand" is a _requirement_ of
an appeal of an AD action.

> As for RFC numbers in abstracts, how exactly to show them can
> be left to the RFC Editor.
>...

But that is exactly the point.  Adam's position, as I understand
it, is that the IESG has set those rules and neither WGs nor the
RFC Editor has any discretion.

> Every reader will know how to get
> more information by going to the references section of the
> main document even if the number isn't styled as a reference.
> The concept of 'well-known RFC number' is very relative; there
> may be RFC numbers that the potential readers of the document
> know quite well even though the 'average' RFC reader won't.
> Also, if I as a reader don't know an RFC number that's
> obsoleted, then that's a very good signal that I may not have
> to care. If we still want to help the reader more, an
> additional phrase giving the title may also help. I'm not
> saying that because I think that these RFC numbers need to be
> in the abstract, just to say that it won't be the end of the
> world if they are.

I think the comments above would be excellent input to a
discussion about whether the RFC Editor should do and what the
guidelines should be.  The issue here is whether the RFC Editor
should even have that authority/ discretion of whether this type
of editorial content is not only specified by the IESG in some
materials I believe are imprecise and badly-worked as well as
illegitimate as rules (Adam presumably disagrees) and than an
appropriate basis for blocking documents until they conform with
an AD's interpretation of those IESG specifications (Adam
presumably disagrees with that too).
 
> I strongly suggest that John take down his threat of an
> appeal, and Adam take down the discuss, and that you both, if
> necessary with the help of others, figure this out with less
> heat.

Not a threat, but a promise.  If either the underlying issues
here did not go well beyond that particular action and that
particular editorial decision or if appeals were the heavyweight
action you seem to assume, I would not have written that note.

     best,
      john

---

From: Adam Roach <[email-masked]>
Date: Sat, 5 Aug 2017 16:15:34 -0500

> and IESG review processes.

John --

Thanks for sharing your rather extensive thoughts on this topic. I 
apologize that I was unable to meet your deadline of "today," as I was 
physically located in a part of the world that had limited to no data 
connectivity by the time you had sent it.

As Martin points out, I'm still rather junior at this position, and have 
been led to believe that the Discuss Criteria 
<https://www.ietf.org/iesg/statement/discuss-criteria.html> has some 
fundamental authority to it. You will note, for example, that the 
DISCUSS ballot I entered was carefully selected, in a word-for-word 
fashion, from that document. I'm also under the impression that the 
current version of the ID-Checklist 
<https://www.ietf.org/id-info/checklist.html>, having had extensive 
discussions on the IETF mailing list, is a reflection of IETF consensus 
regarding the form and format of documents to be turned over to the RFC 
editor. Interpreted that way, I have concerns that I would be derelict 
in my duties if I allowed an author to unilaterally ignore guidance that 
has received IETF-wide review. I'll return to this in a moment.

I do very much appreciate that you had already formulated a compromise 
proposal with the intention of sharing it at some point. I find your 
intended formulation (as hinted by the snippet you included) to satisfy 
both word and spirit of the ID-Checklist provision for abstracts to 
indicate document obsoletion.

At the same time, you have raised a host of collateral points of 
interest regarding the provenance and maintenance of Discuss Criteria 
and ID-Checklist. If we had a common understanding of their authority, 
then the path forward would be clear: if these documents are merely 
advisory and have no power to bind, then I'm free to concede the point 
and allow you to push forward with a document that does not conform to 
their contents -- and would likely do so at this point. Alternately, if 
they are expected by the IETF community to be binding, then it would 
seem my duty to assist in their enforcement. We could hold the 
publication of this document until we were able to resolve which of 
these two situations is true, but it seems a mild disservice to the 
URNBIS working group to do so.

In an attempt to avoid delaying this document unnecessarily, I propose 
the following path forward:

 1. You provide your aforementioned compromise text to Alexey (in his
    role as sponsoring AD) for inclusion as an RFC Editor Note, and I
    will clear my DISCUSS position.

 2. As a tactical matter, you propose to the IESG a set of
    administrative updates to the ID-Checklist document reflecting those
    areas you believe it has fallen out of maintenance (e.g., the
    reference to an older version of the RFC style manual).  I would
    expect these to be mechanical and uncontroversial to apply.

 3. As a strategic matter, you or we begin a conversation with the IETF
    community at large regarding the provenance and authority of the
    Discuss Criteria and ID-Checklist documents. I do not want to
    presuppose the outcome of those conversations, so I suggest no
    specific potential conclusions. I'm happy to help you with
    formulation of the question, if you'd like, but I don't feel
    compelled to insert myself in doing so if you'd prefer to ask in
    your own terms.

 4. Subsequent to conclusion of that conversation, and contingent on its
    outcome, we begin a conversation with the IETF community at large
    regarding the ambiguities you perceive as being present in the
    ID-Checklist so that we can more precisely reflect an IETF consensus
    position in its contents.

/a

---

From: Spencer Dawkins <[email-masked]>
Date: Sun, 6 Aug 2017 19:37:00 -0500

Dear All,

On 08/05/2017 04:15 PM, Adam Roach wrote:
> As Martin points out, I'm still rather junior at this position, and 
> have been led to believe that the Discuss Criteria 
> discussions on the IETF mailing list, is a reflection of IETF 
> consensus regarding the form and format of documents to be turned over 
> to the RFC editor. Interpreted that way, I have concerns that I would 
> be derelict in my duties if I allowed an author to unilaterally ignore 
> guidance that has received IETF-wide review. I'll return to this in a 
> moment.
>
> intended formulation (as hinted by the snippet you included) to 
> satisfy both word and spirit of the ID-Checklist provision for 
> abstracts to indicate document obsoletion.
>
> their contents -- and would likely do so at this point. Alternately, 
> if they are expected by the IETF community to be binding, then it 
> would seem my duty to assist in their enforcement. We could hold the 
>     administrative updates to the ID-Checklist document reflecting
>     those areas you believe it has fallen out of maintenance (e.g.,
>     the reference to an older version of the RFC style manual).  I
>     would expect these to be mechanical and uncontroversial to apply.
>
>  3. As a strategic matter, you or we begin a conversation with the
>     IETF community at large regarding the provenance and authority of
>     the Discuss Criteria and ID-Checklist documents. I do not want to
>  4. Subsequent to conclusion of that conversation, and contingent on
>     its outcome, we begin a conversation with the IETF community at
>     large regarding the ambiguities you perceive as being present in
>     the ID-Checklist so that we can more precisely reflect an IETF
>     consensus position in its contents.
>

It may be helpful to note that I would support this resolution, or 
something like it. There are other resolutions that I would also 
support, of course.

If I might offer what I hope is a friendly amendment to Adam's proposal, 
I wouldn't mind seeing a list of the updates named in (2) before asking 
people to develop actual update text.

And thanks for making that proposal.

Spencer

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Aug 2017 11:26:56 +0100

Hi,

On Sat, Aug 5, 2017, at 10:15 PM, Adam Roach wrote:
> the following path forward:>

>     will clear my DISCUSS position.
I just updated RFC Editor note based on text suggested by John:

Change the last sentence in the Abstract

OLD:
   This document clarifies the status of relevant older
   RFCs and confirms and documents advice to IANA about selected
   existing registrations.

NEW:

   This document clarifies the status of relevant older
   RFCs, including obsoleting two of them (RFC 3044 and RFC 3187)
   and making them historic, and confirms and documents advice to IANA
   about selected existing registrations.

 Please check and clear, if it looks reasonable to you.

Thank you,
Alexey