Discussion:
Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
(too old to reply)
John C Klensin
2008-06-14 01:14:38 UTC
Permalink
Executive Summary

draft-klensin-rfc2821bis completed IETF Last Call for approval
as Draft Standard and was placed in "IESG Evaluation" state on
May 1st. IESG positions about it were first recorded on May
5th. Several minor technical issues were quickly resolved.
However, an AD has entered a DISCUSS on the basis that examples
used in the document contain domain names which are not among
those reserved in RFC 2606 (BCP32). The text of that document
does not require the use of those names; it only reserves them
and makes them available for use. There is no requirement to
use RFC 2606 names in any other BCP or even in any
IESG-published statement (the relevant statements and textual
details are included in the detailed discussion below).
Attempts to discuss the issues with the AD, including efforts
to offer explanations as to why the editor and developing group
selected the names that are in use, have been unsuccessful; the
AD has made it clear that the DISCUSS is blocking and that the
only choices are to revise the document to match his
preferences, to appeal, or, presumably, to withdraw the
document entirely.

Use of a DISCUSS in this way unnecessarily and unreasonably
blocks document progress, discourages efforts to advance work
in the IETF, and is inconsistent with the IESG's own statements
on the appropriate use of DISCUSS positions. It is not
mandated or supported by any IETF or IESG documentation and
represents an abuse of AD authority for which there is no
effective remedy within current normal procedures. The
existence of this situation demonstrates that those normal
procedures are inadequate or insufficient to protect the rights
of all parties in a fair and open Internet Standards Process.

This appeal seeks relief both for the specific situation and
for the procedural inadequacies that enable it.

This document is somewhat more detailed than appeals in the
past because most of the issues involved are consistent with
those covered in RFC 2026, Section 6.5.3, i.e., that the IETF's
procedures appear to be inadequate or insufficient to protect
rights to a fair and open Standards process.

Remedies Requested

(1) The blocking DISCUSS must be removed.

No one objects to a reasoned discussion on the issues.
However, a blocking DISCUSS in this type of situation is
more than inappropriate; it is harmful to the IETF.

(2) Either by developing separate terms or through some other
mechanism, the IESG must clearly differentiate, at the time
positions are registered, between a DISCUSS intended to raise a
question or initiate discussion and one that is intended to
block the document if not resolved to the AD's satisfaction.

Although "DISCUSS" has been in use, with slight variations
in definition, since the IESG assumed responsibility for
approving IETF documents, the DISCUSS construct is purely
an IESG creation. There is no consensus document which
specifies IESG voting procedures or categories or that
otherwise requires a DISCUSS or prohibits more nuanced
positions. Distinctions between blocking positions and
those representing questions, comments, or advice should be
made clear in the document tracker and other appropriate
mechanisms.

(3) To protect the rights of all parties to a fair and open
Internet Standards Process that is free of abusive behavior, of
unnecessary and inappropriate "late surprises", and of
imposition of novel requirements during the review process, the
IESG should modify its rules to prohibit the use of a blocking
DISCUSS on a specification for any editorial or other
non-technical reason unless the requirement is clearly
documented, either in (i) a BCP or (ii) a formal position or
procedural statement that is subject to appeal at the time of
publication.

The IESG's current "DISCUSS Criteria" prohibit the use of a
DISCUSS to block a document for an editorial or stylistic
reason, but that rule is not being followed. In either
case, the document that specifies the stylistic or
editorial rules must be published and widely available
prior to the time the specification enters Last Call.

(4) The IESG should explicitly recognize that the interests of
the IETF and the Internet community are served by encouraging
the advancement of documents in maturity level on the standards
track.

To that end, while authors, editors, working groups, and
the community should welcome suggestions for improvements
in the editorial quality of documents proposed for
advancement, the IESG should be prohibited from requiring
changes that are not tied to substantive technical issues
with the original document, clarifications (including
improvements to readability and comprehensibility), or
interoperability. Specifically the goal for revising
documents seeking advancement along the standards track is
to preserve as much community experience with the earlier
version(s) as possible consistent with accuracy and
clarity. Hence, no changes should be sought except those
deemed essential to the utility of the document.

As will be discussed in detail below, simply removing the
DISCUSS on the document will not satisfy this appeal. This
appeal raises questions of applicable procedure and the
openness and fairness of the Standards Process which must
be addressed as part of the response to it.


Background and Details

draft-klensin-rfc2821bis (referred to just as "2821bis" below)
is a revision, intended for Draft Standard, of RFC 2821 which
is, in turn, a consolidation and update of the Internet's base
standards for email transport (collectively known as "SMTP")
and first documented in RFC 821, more than 25 years ago. The
examples in question in the current draft were in the original
specifications or are minimal changes to those original
examples approved by a WG and published more than seven years
ago. The original examples have apparently caused no problems
for a quarter of a century. RFC 2821, and consensus about its
content, wording, and organization, was the result a diligent,
multi-year effort by the DRUMS Working Group. 2821bis differs
from RFC 2821 only by incorporating a series of clarifications
and corrections of errors. With both RFC 2821 and 2821bis,
great care was exercised to avoid unnecessary changes lest they
have unanticipated and disruptive side-effects on the installed
base or introduce new forms of confusion. While 2821bis is not
the product of a formal WG, it results from extensive mailing
list discussions of substantially every change. These
discussions included many long-term contributors to Internet
email technology and standards as well as most other active
DRUMS participants, and further including several people who
have more recently become involved in IETF processes and email
activities.

It is worth noting that, aside from ongoing discussions about
whether SMTP and email generally work too well --well enough to
enable spammers and other abusive behavior-- the continuing use
of Internet mail by perhaps one billion people, based on many
different implementations of each functional component of the
mail service's architecture means that the existing
Standardized specifications are obviously sufficient to enable
conforming interoperability.

There is now an impasse about how, or whether, to proceed with
2821bis. An AD has generated a DISCUSS about changing all of
the examples that do not use RFC 2606 names (e.g.,
"example.com" and equivalent) to use that convention, with the
possible exception of those that point to ISI or USC. He has
indicated that he does not intend to remove the DISCUSS until
the examples are changed (the exact statement, in a note sent
05 June 2008 09:50 -0400, was:

"As I said in the second paragraph of the previous response.
The IESG has been enforcing the BCP for at least five
years. I await a revised document or an appeal. That
choice is yours.").

The IESG has not chosen to use the override procedure specified
in its specifications for handling DISCUSS ballots.

The DISCUSS does not, in practice, appear to be a request for
an actual discussion. There has been fairly extensive
correspondence on this subject, but editor explanations as to
why it is, on balance, inappropriate to change the examples
have been rejected without any substantive comment, although
there have been a few statements of the AD's beliefs.

The key to this appeal is that neither RFC 2606, nor the
IESG-produced "Guidelines for Authors of Internet Drafts"
[http://www.ietf.org/ietf/1id-guidelines.html], nor even the
IESG-produced "Internet Draft Checklist" ("IDNits")
[http://www.ietf.org/ID-Checklist.html] require use of the 2606
names. RFC 2026 (BCP 9), the defining document for IETF
Procedures for advancement of specifications on the Standards
Track, is silent about this type of issue, focusing on
technical maturity and interoperation. RFC 2606, which is the
only consensus document on the subject, says things like "can
be used" about these names. It does not even express an
explicit preference for their use.

There are three IESG position statements that might bear on the
issue. There is apparent community consensus that the IESG can
use its discretion to specify details of document handling that
are not explicit in RFC 2026 and the documents that update or
modify it. In recent years, the IESG has, with considerable
community encouragement, chosen to write its current procedures
and criteria down in IESG Statements and other documents. When
the IESG has done so, and conformed to its own statements and
criteria, there has been an overall improvement in the
efficiency of the overall IETF process, both reducing the
chances of last-minute delays to documents resulting from
surprising authors with new rules late in the process and
reducing the community perception that the IESG behaves
capriciously. The present appeal responds to an IESG action
that appears to counter both of those positive trends.

(1) The "Guidelines to Authors of Internet Drafts"
(http://www.ietf.org/ietf/1id-guidelines.html) does not mention
the issue of examples at all.

(2) The I-D Checklist (IDnits,
http://www.ietf.org/ID-Checklist.html), Section 6, says

"Addresses used in examples SHOULD preferably use
fully qualified domain names instead of literal IP
addresses, and preferably use example fqdn's such as
foo.example.com instead of real-world fqdn's."

"SHOULD preferably" and "preferably" are, I believe obviously,
statements of preference, not firm requirements. That is
especially true of the second one, which doesn't even contain
the word "SHOULD".

(3) The DISCUSS Criteria document
(http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
does not list the use of non-2606 names as an item on the list
of criteria in Section 3.1. Indeed, it explicitly prohibits,
in its section 3.2, DISCUSSion for "Pedantic corrections to
non-normative text" and "Stylistic issues of any kind".

The AD holding the DISCUSS has indicated that he doesn't like
these names and considers their use "rude". His other
justification is that he states that the IESG has been
enforcing the use of RFC 2606 names as a firm rule for "at
least five years".

The position taken by this appeal, which we hope will be
upheld, is that, in general,

(i) It is not appropriate or permissible for the IESG to
invent rules that are then used to block progression of a
document without consulting the community.

(ii) It is inappropriate, and a violation of the principles
that ensure a fair and open process, for the IESG to make a
clear statement of the conditions under which it will block
a document (as it has done in "DISCUSS Criteria") and then
to apply rules on final review that are at variance with
those conditions. Put differently, the obvious purpose of
IESG statements about the rules it will follow is to inform
the community about what should be done to avoid having
documents blocked whenever possible. When the IESG does
not follow its own stated rules, a fair and open Internet
Standards is compromised.

(iii) Given the pressure on authors --especially WG
Chairs and document editors-- to simply go along with AD
demands and preferences, reasonable or not, in order to
get documents published rather than permanently stalled,
it is not plausible to assume that "the IESG has been
doing this for years" constitutes evidence that the
community has approved of the IESG's doing so.

(iv) Even if one were to concede that the IESG has the
authority to make the use of the 2606 reserved names a
requirement, it is abusive --an example of a completely
unnecessary and very late review "gotcha" surprise-- for
the IESG to impose it without documenting it in any of the
criteria statement documents identified above. If the IESG
wants to impose rules like this, it should move to revise
one of more of the procedural documents (presumably the I-D
Checklist) to specify the requirement. It should publish
that revised form and see if the community accepts that
additional rule once it is written down. Of course, the
IESG could also initiate an update to RFC 2606 that changes
"can be used" into "MUST be used unless the IESG grants a
waiver". Both of those suggestions were made during
attempts to actually discuss the "DISCUSS" position. There
has been no response to either suggestion.

(iv) Since this blocking DISCUSS is inconsistent with the
IESG's published statements about conditions for such
actions (in the absence of a mandate from a consensus
document, it appears to be an "editorial preference") and
there seems to be no practical way to un-block it, it is a
case in which, excerpting from RFC 2026, Section 6.5.3,
"the procedures themselves ... are ... inadequate or
insufficient to the protection of the rights of all parties
in a fair and open Internet Standards Process". Even were
the IESG to withdraw the DISCUSS during the appeal process,
the question of whether the use of a DISCUSS in this way is
consistent with a fair and open process would remain and
would be fundamental to the appeal.

(v) There have been many discussions over the years about
why the IETF advances so few documents past Proposed
Standard. This incident has made it clear that one of the
many reasons is IESG behavior: the more obstacles that are
placed in the path of advancing documents, the fewer
attempts will be made to advance them. It is obvious that
making revisions to a document to improve its quality risks
introducing new errors or new confusing text and that each
such change introduces more burdensome requirements for
review to be sure that problems are not introduced.
Consequently, once the IESG has already approved a document
(even at Proposed Standard, but especially when documents
at Full Standard covering much of the same material always
exist), it should not introduce requirements for new
changes unless those the requirements are either clearly
documented or are motivated by technical considerations
that are clearly problematic. Put differently, when a
document is being revised and updated, imposition of
stylistic, organizational, or presentation requirements
that were not in effect when the original document was
approved should require strong and substantive
justification that balances the advantages of change
against the costs and risks of delay and disruption, not
merely a preference or statement about what is done with
new documents.

Quoting from one of the comments made when the issue was
discussed on the mailing list: "When revising a document,
the cost of the revision should be commensurate with the
community need for the changes. RFC2821bis is a very small
effort to make minimal changes to a successful document.
It is simply not reasonable to start imposing more recent
requirements -- assuming they really are valid requirements
-- absent a compelling demonstration of damage that will
accrue without the change."

Slightly recasting another on-list comment, if the IETF is to
make effective progress on standards, it must operate without
having the personal, non-technical preferences and perspectives
of IESG members used to dominate IESG decision-making. To
permit these preferences to hold sway deprives the community of
a stable, fair and open process. Consistently, the IESG seems
to choose DISCUSS over the other available choices, and DISCUSS
serves to seriously delay documents, while the other choices
allow it to continue through the process. The present DISCUSS
is an example of this. Instead of sending a comment back to the
author saying, "The IESG believes that the examples should use
the 2606 recommendations" and let the document progress while
the author works that out (or decides not to), the IESG felt
that publication of this document as-is would be so harmful
that it deserves to be stopped in its tracks. "That's just
nonsense."

I note that, while the present situation and 2821bis constitute
particularly glaring examples of these misplaced priorities and
abuses, none of the issues above is unique to 2821bis. They
are really about how the IESG manages and expresses its
authority and discretion.

There is one more general issue: which is clarity about what
changes are reasonably demanded of a document being progressed
from one
maturity level to the next. RFC 2026 is not specific about
this, but I believe that its language is consistent with a
presumed general belief in the community that we should put as
few blocks in the path of advancing documents as is practical.
Put differently, it is in the community's interest to encourage
the advancement of specifications in maturity level and to
discourage changes, especially cosmetic or stylistic ones, that
might add confusion without adding value.

The one issue that _is_ specific to 2821bis (and RFC 2821
itself) is that DRUMS explicitly considered the question of
what to do about the RFC 821 examples. The conclusion was to
eliminate the references to .ARPA (because they were
distracting and clearly impossible given the current role of
that domain) but otherwise to preserve Jon Postel's examples
(not just the ones that used USC or ISI domains) to the extent
possible. DRUMS reached consensus on what became RFC 2821 and
the IESG signed off on it, presumably with knowledge of RFC
2606 which was completed well before 2821 was published. So
this DISCUSS within the IESG now effectively overrides, not
only discussions and conclusions on the mailing list that
reviewed 2821bis and the consensus decision that 2821bis should
contain only those changes needed to correct error or add
clarity, but the presumably-informed discussions of the
original WG.

The question of whether to pursue an appeal on the DISCUSS, and
the general practices of which it is an example, was raised on
the SMTP mailing list. The consensus among most of those who
commented was that an appeal was appropriate; this appeal is
being filed on that basis.
Lakshminath Dondeti
2008-06-14 06:01:17 UTC
Permalink
On 6/13/2008 6:14 PM, John C Klensin wrote:

>
> I note that, while the present situation and 2821bis constitute
> particularly glaring examples of these misplaced priorities and
> abuses, none of the issues above is unique to 2821bis. They
> are really about how the IESG manages and expresses its
> authority and discretion.
>

John,

I applaud your decision to appeal an IESG DISCUSS (I have read far
enough to understand that the basis of the appeal was consensus among
folks who are closely following this matter and chose to comment on the
matter of whether to file an appeal).

I do not have a strong opinion about this specific case (I may even be
in disagreement with some of the specifics stated in the appeal), but I
believe it is necessary for the community to exercise their right to
appeal to let the IESG know that their predisposition to use DISCUSS for
imposing personal preferences, biases or undocumented norms is
inappropriate at best. I strongly agree with the conclusion that we
cannot rely on norms supposedly established based on instances of
compliance under duress (ok, I agree that is a bit of hyperbole).

I have also been disappointed by the IESG not once invoking the override
procedures even when a DISCUSS is clearly inappropriate.

An appeal crossed my mind a few times in the recent past and I have
seriously considered appealing a couple of times, but due to time
constraints chose to pursue the path of least resistance. I thank you
for taking the time and energy to appeal.

best regards,
Lakshminath
David Kessens
2008-06-17 13:02:56 UTC
Permalink
Lakshminath,

On Fri, Jun 13, 2008 at 11:01:17PM -0700, Lakshminath Dondeti wrote:
>
> I have also been disappointed by the IESG not once invoking the override
> procedures even when a DISCUSS is clearly inappropriate.

For the record, during my time in the IESG, we have had at least two
cases where override procedures were requested. One vote was requested
by me to clear a document that I was the shepherd for that got stuck
in the IESG for a very long period and where the DISCUSSing AD was not
responsive while trying to resolve a DISCUSS.

In another case, I asked the shepherding AD to request an override vote
as I had fundamental issues with a document that was not likely to be
resolved in a timely matter due to the nature of my problems with the
document. Therefore, instead of me holding a DISCUSS forever and
leaving the document in limbo, I proposed that an override vote could
help us to force a decision early.

If my memory serves me correctly, we didn't have to do a formal
override vote in both cases as the request of an override vote was
enough to get the first case moving, while in the second case I
decided that an informal strawpoll was enough to decide that I didn't
have enough support for my opinion so I switched to an ABSTAIN.

David Kessens
---
Lakshminath Dondeti
2008-06-17 16:25:56 UTC
Permalink
Hi David,

Thank you for sharing this information. Now that the community knows
this, perhaps this will be an option when there are snags in the process
in future.

regards,
Lakshminath

On 6/17/2008 6:02 AM, David Kessens wrote:
> Lakshminath,
>
> On Fri, Jun 13, 2008 at 11:01:17PM -0700, Lakshminath Dondeti wrote:
>> I have also been disappointed by the IESG not once invoking the override
>> procedures even when a DISCUSS is clearly inappropriate.
>
> For the record, during my time in the IESG, we have had at least two
> cases where override procedures were requested. One vote was requested
> by me to clear a document that I was the shepherd for that got stuck
> in the IESG for a very long period and where the DISCUSSing AD was not
> responsive while trying to resolve a DISCUSS.
>
> In another case, I asked the shepherding AD to request an override vote
> as I had fundamental issues with a document that was not likely to be
> resolved in a timely matter due to the nature of my problems with the
> document. Therefore, instead of me holding a DISCUSS forever and
> leaving the document in limbo, I proposed that an override vote could
> help us to force a decision early.
>
> If my memory serves me correctly, we didn't have to do a formal
> override vote in both cases as the request of an override vote was
> enough to get the first case moving, while in the second case I
> decided that an informal strawpoll was enough to decide that I didn't
> have enough support for my opinion so I switched to an ABSTAIN.
>
> David Kessens
> ---
>
Lakshminath Dondeti
2008-06-17 17:08:14 UTC
Permalink
On 6/17/2008 9:45 AM, Dave Crocker wrote:
>
>
> Lakshminath Dondeti wrote:
>> Hi David,
>>
>> Thank you for sharing this information. Now that the community knows
>> this, perhaps this will be an option when there are snags in the
>> process in future.
>
>
> Folks keep missing the point: The current situation is not about
> lacking creativity or options. It is about having rules but failing to
> follow them or inventing them on the fly.

I am not claiming that not having precedence (which is now corrected to
widely-known precedence) is the only problem. However, there is a point
here in that if one or two ADs are "failing to follow [rules] or
inventing them on the fly," what are the rest of the IESG members doing?

I have received a few responses, offline and in this thread to that
question.

regards,
Lakshminath

>
> What David's note underscores is that it is entirely possible to take
> even a difficult Discuss and attempt to pursue it actively and
> constructively.
>
> His seeking to assess consensus within the IESG is an exemplary case of
> trying to work as a team rather than an 'expert' individual.
>
> d/
>
Fred Baker
2008-06-17 16:49:28 UTC
Permalink
On Jun 17, 2008, at 6:02 AM, David Kessens wrote:
> If my memory serves me correctly, we didn't have to do a formal
> override vote in both cases as the request of an override vote was
> enough to get the first case moving, while in the second case I
> decided that an informal strawpoll was enough to decide that I
> didn't have enough support for my opinion so I switched to an ABSTAIN.

In my experience, which is now dated, that has been the norm. During
my tenure, we had at least two cases where an AD said "'discuss' and
I'm not going to remove it no matter what". The first resulted in the
crafting of the override procedure; the second had us drawing that
sword. But the threat of its use resulted in the desired behavior, so
it was never actually used. There was a third that one could mention;
it resulted in the working group rewriting the document completely.
The rewrite was a dramatic improvement; the "discuss" was removed as
a result.
Spencer Dawkins
2008-06-17 19:27:47 UTC
Permalink
For what it's worth, I thought I remembered which document David was talking
about in his second case, and confirmed that it was
draft-ietf-geopriv-dhcp-civil-09.txt.

There are narrative minutes from the telechat where David's DISCUSS position
was discussed, at
http://www.ietf.org/IESG/Narrative/iesg-narrative-minutes-02-16-2006.html,
in case anyone wants to see what an IESG chat about ABSTAIN and override
voting might look like...

See "2.1.2 Returning Item".

Thanks,

Spencer

From: "Fred Baker" <***@cisco.com>

> On Jun 17, 2008, at 6:02 AM, David Kessens wrote:
>> If my memory serves me correctly, we didn't have to do a formal
>> override vote in both cases as the request of an override vote was
>> enough to get the first case moving, while in the second case I
>> decided that an informal strawpoll was enough to decide that I
>> didn't have enough support for my opinion so I switched to an ABSTAIN.
>
> In my experience, which is now dated, that has been the norm. During
> my tenure, we had at least two cases where an AD said "'discuss' and
> I'm not going to remove it no matter what". The first resulted in the
> crafting of the override procedure; the second had us drawing that
> sword. But the threat of its use resulted in the desired behavior, so
> it was never actually used. There was a third that one could mention;
> it resulted in the working group rewriting the document completely.
> The rewrite was a dramatic improvement; the "discuss" was removed as
> a result.
Eastlake III Donald-LDE008
2008-06-14 14:44:06 UTC
Permalink
Standards track RFC 4343 was issued within the past five years (January
2006 to be precise). It contains some example domain names that do not
follow the suggestions in RFC 2606 as well as some that do. As the
author of both RFC 2606 and RFC 4343, I believe the domain names
reserved in RFC 2606 were intended to be encouraged but not mandatory.

Donald
John C Klensin
2008-06-14 17:05:01 UTC
Permalink
--On Saturday, 14 June, 2008 10:44 -0400 Eastlake III
Donald-LDE008 <***@motorola.com> wrote:

> Standards track RFC 4343 was issued within the past five years
> (January 2006 to be precise). It contains some example domain
> names that do not follow the suggestions in RFC 2606 as well
> as some that do. As the author of both RFC 2606 and RFC 4343,
> I believe the domain names reserved in RFC 2606 were intended
> to be encouraged but not mandatory.

Donald,

Thanks. The fact that those recommendations have not been
consistently been treated as mandatory doesn't really affect the
core of the appeal, but it further weakens any claim that this
behavior is ok based on a consistent (even if unpublicized)
pattern of prior IESG behavior and decision-making.

best,
john

p.s. while I appreciate the comments I've received expressing
support for this appeal, I'm generally not going to respond to
them on-list lest the IESG interpret the comments as part of a
lobbying effort. The procedures say that appeals go to the
IESG and the IESG decides (then they may go elsewhere). I don't
believe that there is any prohibition on the IESG's asking for
community input if they want it, but they are certainly under no
obligation to do so or to consider such input as part of
considering the appeal. This note is an exception only because
it identified a fact I didn't have available when I wrote the
appeal text.
John C Klensin
2008-06-14 17:11:09 UTC
Permalink
--On Saturday, 14 June, 2008 10:44 -0400 Eastlake III
Donald-LDE008 <***@motorola.com> wrote:

> Standards track RFC 4343 was issued within the past five years
> (January 2006 to be precise). It contains some example domain
> names that do not follow the suggestions in RFC 2606 as well
> as some that do. As the author of both RFC 2606 and RFC 4343,
> I believe the domain names reserved in RFC 2606 were intended
> to be encouraged but not mandatory.

Donald,

Thanks. The fact that those recommendations have not been
consistently been treated as mandatory doesn't really affect the
core of the appeal, but it further weakens any claim that this
behavior is ok based on a consistent (even if unpublicized)
pattern of prior IESG behavior and decision-making.

best,
john

p.s. while I appreciate the comments I've received expressing
support for this appeal, I'm generally not going to respond to
them on-list lest the IESG interpret the comments as part of a
lobbying effort. The procedures say that appeals go to the
IESG and the IESG decides (then they may go elsewhere). I don't
believe that there is any prohibition on the IESG's asking for
community input if they want it, but they are certainly under no
obligation to do so or to consider such input as part of
considering the appeal. This note is an exception only because
it identified a fact I didn't have available when I wrote the
appeal text.
Brian E Carpenter
2008-06-15 22:00:02 UTC
Permalink
Regardless of John's P.S., I'd like to make some comments
that the IESG may wish to consider:

On 2008-06-15 05:11, John C Klensin wrote:
>
> --On Saturday, 14 June, 2008 10:44 -0400 Eastlake III
> Donald-LDE008 <***@motorola.com> wrote:
>
>> Standards track RFC 4343 was issued within the past five years
>> (January 2006 to be precise). It contains some example domain
>> names that do not follow the suggestions in RFC 2606 as well
>> as some that do. As the author of both RFC 2606 and RFC 4343,
>> I believe the domain names reserved in RFC 2606 were intended
>> to be encouraged but not mandatory.
>
> Donald,
>
> Thanks. The fact that those recommendations have not been
> consistently been treated as mandatory doesn't really affect the
> core of the appeal, but it further weakens any claim that this
> behavior is ok based on a consistent (even if unpublicized)
> pattern of prior IESG behavior and decision-making.

I think one can make a case that in some documents, use of non-RFC2606
names as examples is a purely stylistic matter, and that in others,
it would potentially cause technical confusion. I'm not asserting which
applies to 2821bis, but I do assert that there is scope here for
a judgement call and therefore the inconsistency is understandable.

In the evaluation record for what became RFC4343
(https://datatracker.ietf.org/idtracker/ballot/1612/) we find:

"Editorial issues:

- the document uses a number of non-example.com/192.0.2.0
addresses/names, but in this case this seems justifiable"

In other words this *was* a judgement call. [For the record:
I ballotted NO OBJECTION on RFC4343.] I regard the DISCUSS
that John is appealing against as a judgement call. It isn't clear
to me that it's a stylistic or editorial comment by construction.

To the underlying process issue, a DISCUSS based on a judgement call
is always a little tricky. However, if the document shepherd can show
that the call made in the draft was an explicit rough consensus, it
does seem like the sort of case where the DISCUSSing AD might choose
to switch to an ABSTAIN.

I strongly agree with John's suggestion that ADs should clearly distinguish
a comment where they really want discussion from something that they view
as a sticking point. One of the cleared DISCUSSes on 2821bis starts thus:
"This is a discuss discuss question....". Is that clear enough?

Brian

>
> best,
> john
>
> p.s. while I appreciate the comments I've received expressing
> support for this appeal, I'm generally not going to respond to
> them on-list lest the IESG interpret the comments as part of a
> lobbying effort. The procedures say that appeals go to the
> IESG and the IESG decides (then they may go elsewhere). I don't
> believe that there is any prohibition on the IESG's asking for
> community input if they want it, but they are certainly under no
> obligation to do so or to consider such input as part of
> considering the appeal. This note is an exception only because
> it identified a fact I didn't have available when I wrote the
> appeal text.
>
>
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Brian E Carpenter
2008-06-16 01:23:28 UTC
Permalink
Dave,

On 2008-06-16 11:44, Dave Crocker wrote:
>
>
> Brian E Carpenter wrote:
>> I think one can make a case that in some documents, use of non-RFC2606
>> names as examples is a purely stylistic matter, and that in others,
>> it would potentially cause technical confusion. I'm not asserting which
>> applies to 2821bis, but I do assert that there is scope here for
>> a judgement call and therefore the inconsistency is understandable.
>
>
> Actually, Brian, scope is exactly what this judgment call is out of.
>
> The underlying question is whether rules matter in the IETF or whether
> the IETF is subject to whatever ADs feel like declaring at the moment.
>
I doubt if anyone would disagree.

> If rules do matter, then the IESG needs to follow them. In very
> concrete terms, the IESG needs to be constrained it its application of a
> Discuss to matters of serious import and to document the basis for an
> application of a Discuss.

Which, in fairness, the IESG has documented, in the DISCUSS criteria
document and generally in practice, over the last several years.
The question surely is whether the IESG failed to do so in this case.
>
> The current case has an AD asserting a Discuss by claiming a rule that
> does not exist. That's not judgment call, that's invention.

I haven't seen all the email in this case, so I don't know exactly
what has and hasn't been claimed as a rule. However, I'm arguing that
there is scope on this particular point for concluding that there is
a *technical* issue (a source of confusion, i.e. a lack of clarity).
That may or may not be a valid conclusion. However, one of the two
DISCUSS comments points out that at least 3 of the domains used are
real ones. So the issue of confusion is a real one. What I am
saying is: these DISCUSSes are about a technical issue. They may or
may not be reasonable, but I object to the suggestion that they are
stylistic or editorial (which would automatically make them out of
scope under the IESG's own document).

> Even better is that application of this invented rule on a revision to
> an established standard represents an orientation towards change that is
> de-stabliling rather than helpful.

I don't think that changing foo.com to foo.example.com would
destabilise the email system too much.

Brian

>
> With that combination, you can't get much more out of scope.
>
> d/
TSG
2008-06-16 22:38:14 UTC
Permalink
FYI - ALL of the commentary submitted to the IESG must be done so through a
process which includes it in the archive of that IP initiative or the IETF
will see itself in a world of hurt the first time it is litigated against
and it cannot produce documentation showing all of that material happened in
the open.

Todd Glassey

----- Original Message -----
From: "Brian E Carpenter" <***@gmail.com>
To: <***@bbiw.net>
Cc: "John C Klensin" <john-***@jck.com>; <***@ietf.org>; <***@ietf.org>
Sent: Sunday, June 15, 2008 5:23 PM
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis


> Dave,
>
> On 2008-06-16 11:44, Dave Crocker wrote:
>>
>>
>> Brian E Carpenter wrote:
>>> I think one can make a case that in some documents, use of non-RFC2606
>>> names as examples is a purely stylistic matter, and that in others,
>>> it would potentially cause technical confusion. I'm not asserting which
>>> applies to 2821bis, but I do assert that there is scope here for
>>> a judgement call and therefore the inconsistency is understandable.
>>
>>
>> Actually, Brian, scope is exactly what this judgment call is out of.
>>
>> The underlying question is whether rules matter in the IETF or whether
>> the IETF is subject to whatever ADs feel like declaring at the moment.
>>
> I doubt if anyone would disagree.
>
>> If rules do matter, then the IESG needs to follow them. In very
>> concrete terms, the IESG needs to be constrained it its application of a
>> Discuss to matters of serious import and to document the basis for an
>> application of a Discuss.
>
> Which, in fairness, the IESG has documented, in the DISCUSS criteria
> document and generally in practice, over the last several years.
> The question surely is whether the IESG failed to do so in this case.
>>
>> The current case has an AD asserting a Discuss by claiming a rule that
>> does not exist. That's not judgment call, that's invention.
>
> I haven't seen all the email in this case, so I don't know exactly
> what has and hasn't been claimed as a rule. However, I'm arguing that
> there is scope on this particular point for concluding that there is
> a *technical* issue (a source of confusion, i.e. a lack of clarity).
> That may or may not be a valid conclusion. However, one of the two
> DISCUSS comments points out that at least 3 of the domains used are
> real ones. So the issue of confusion is a real one. What I am
> saying is: these DISCUSSes are about a technical issue. They may or
> may not be reasonable, but I object to the suggestion that they are
> stylistic or editorial (which would automatically make them out of
> scope under the IESG's own document).
>
>> Even better is that application of this invented rule on a revision to
>> an established standard represents an orientation towards change that is
>> de-stabliling rather than helpful.
>
> I don't think that changing foo.com to foo.example.com would
> destabilise the email system too much.
>
> Brian
>
>>
>> With that combination, you can't get much more out of scope.
>>
>> d/
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Dave Crocker
2008-06-16 07:05:47 UTC
Permalink
Brian E Carpenter wrote:
> However, I'm arguing that
> there is scope on this particular point for concluding that there is
> a *technical* issue (a source of confusion, i.e. a lack of clarity).

If would be fascinating to see someone attempt to defend such a claim
seriously and with pragmatic substance, rather than detached theory.

That is, to try to prove the claim with facts.


> That may or may not be a valid conclusion.

And that's one of the issues that is that the meat of the appeal, as I read
it: The serious basis for the Discuss has not been documented, nevermind
defended. So we can debate all sorts of hypotheses about whether their might
or might not have been a legitimate basis for this Discuss, and we would
thereby miss the underlying issue.


> However, one of the two
> DISCUSS comments points out that at least 3 of the domains used are
> real ones. So the issue of confusion is a real one.

1. Where is the rule prohibiting the use of real domain names?

2. This particular spec began life 25+ years ago using those names, so we
ought to have solid data showing that that particular document's use of those
names is a problem. Where is it?

3. Where is the empirical substantiation that use of a real domain name in an
RFC spec causes problems with the development of interoperable implementations?

4. If you want to focus on a judgement call, how about focusing on the
judgement that keeping specification documents stable, as much as possible,
across their life, is important?


> What I am
> saying is: these DISCUSSes are about a technical issue. They may or
> may not be reasonable, but I object to the suggestion that they are
> stylistic or editorial (which would automatically make them out of
> scope under the IESG's own document).

Like any good technical issue, I'm sure you can document the real-world
demonstrations of this as a problem and for this document?

Mostly what you are doing, Brian, is demonstrating that one can claim that
anything is a technical issue.


>> Even better is that application of this invented rule on a revision to
>> an established standard represents an orientation towards change that is
>> de-stabliling rather than helpful.
>
> I don't think that changing foo.com to foo.example.com would
> destabilise the email system too much.

Perhaps you are missing the point.

I guess that's a judgement call, too.

d/
--

Dave Crocker
Brandenburg InternetWorking
bbiw.net
Ned Freed
2008-06-18 21:11:06 UTC
Permalink
> > However, I'm arguing that
> > there is scope on this particular point for concluding that there is
> > a *technical* issue (a source of confusion, i.e. a lack of clarity).

> If would be fascinating to see someone attempt to defend such a claim
> seriously and with pragmatic substance, rather than detached theory.

> That is, to try to prove the claim with facts.

Exactly so. Isn't it sort of the point of that whole "running code" thing to
prefer operational experience to finespun theorizing?

And in that vein, I have a few small data points to offer. I'm the author or
coauthor of quite a number of RFCs as well as various other documents, and up
until recently I have not only used whatever domain names I felt like in these
documents, I've also used actual valid email addresses. In particular, I've
used a lot of addresses in the innosoft.com domain, some valid, others invalid,
as well as the domain itself. I also served as postmaster for the domain for 15
years or so, which gives me a pretty good idea of the consequence of its usage.

Based on this experience, I've found that domain usage in documents basically
breaks down into three categories:

(1) Example objects, dialogs, and transactions
(2) Test objects and vectors.
(3) Sample configuration information

Despite having used innosoft.com extensively in example objects and dialogs,
including but not limited to widely implemented full standards like RFC 2920
and even more widely implemented draft standards like RFC 2049, I cannot recall
a single instance where this has caused a noticeable problem or generated a
complaint. This was true even before email became inundated with spam, and now
that spam is so prevalent it is difficult for me to imagine a scenario where
type (1) usage in a specification would actually matter.

Test objects and vectors have been more of an issue, but only slightly. The
example I have here is the set of MIME messages Nathaniel Borenstein assembled
back when MIME first came out. This corpus was never published in an RFC but
was widely disseminated in tarball form. Quite a number of these messages had
my address in a To: or Cc: field, with the result that I used to receive copies
of the messages from time to time from various random places performing
testing. All things being equal I would have preferred not to have gotten those
copies (although in some case it was amusing to see who was testing MIME
capabilities), but seeing as the spam I now get in a single day is probably an
order of magnitude greater than all the copies of these messages I ever
received put together, it is difficult to care very much.

Sample configurations are another matter entirely. We made the mistake of using
our domain in one or two such examples in product documentation, with the
result in one case that we were hit with quite a number of queries. This was
sufficiently annoying and we took note and never did that again.

My conclusion based on my own experience is that use of "proper" example
domains in sample configurations definitely rises to the level of a strong
SHOULD. Test objects and vectors warrant a weak SHOULD at most, in the email
subcase at least. But random sample email messages and dialogs have been a
nonissue and there warrant no special compliance.

Just a little data in support of evidence-based engineering.

Ned

P.S. Based on the ongoing misunderstanding of the situation apparent in several
recent postings I feel compelled to reiterate that the appeal is almost
entirely about the nature of our process, not about the resolution of domain
usage in 2821bis. As for the process part of this, I've been trying very hard
to stay away, mostly because i find the fact that it was necessary for John to
file this appeal to be so utterly appalling that I don't entirely trust myself
to be able to engage in civil discourse about it.
Eric Gray
2008-06-16 14:27:27 UTC
Permalink
Brian,

As a matter of personal preference, I would very much
prefer not to see process constructions that require repeated
use of the status in order to disambiguate the meaning of the
status. In other words, having to clarify that a DISCUSS is
(really) a discuss (and presumably not something else) is not
the way to clear things up - not even "clear enough."

Either DISCUSS means what it implies (maybe we add some
separate status for BLOCK), or we change the state name to an
intentionally more ambiguous name (like HOLD, or PENDING).

--
Eric Gray
Principal Engineer
Ericsson

> -----Original Message-----
> From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On
> Behalf Of Brian E Carpenter
> Sent: Sunday, June 15, 2008 6:00 PM
> To: John C Klensin
> Cc: ***@ietf.org; ***@ietf.org
> Subject: Re: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> Regardless of John's P.S., I'd like to make some comments
> that the IESG may wish to consider:
>
> On 2008-06-15 05:11, John C Klensin wrote:
> >
> > --On Saturday, 14 June, 2008 10:44 -0400 Eastlake III
> > Donald-LDE008 <***@motorola.com> wrote:
> >
> >> Standards track RFC 4343 was issued within the past five years
> >> (January 2006 to be precise). It contains some example domain
> >> names that do not follow the suggestions in RFC 2606 as well
> >> as some that do. As the author of both RFC 2606 and RFC 4343,
> >> I believe the domain names reserved in RFC 2606 were intended
> >> to be encouraged but not mandatory.
> >
> > Donald,
> >
> > Thanks. The fact that those recommendations have not been
> > consistently been treated as mandatory doesn't really affect the
> > core of the appeal, but it further weakens any claim that this
> > behavior is ok based on a consistent (even if unpublicized)
> > pattern of prior IESG behavior and decision-making.
>
> I think one can make a case that in some documents, use of non-RFC2606
> names as examples is a purely stylistic matter, and that in others,
> it would potentially cause technical confusion. I'm not
> asserting which
> applies to 2821bis, but I do assert that there is scope here for
> a judgement call and therefore the inconsistency is understandable.
>
> In the evaluation record for what became RFC4343
> (https://datatracker.ietf.org/idtracker/ballot/1612/) we find:
>
> "Editorial issues:
>
> - the document uses a number of non-example.com/192.0.2.0
> addresses/names, but in this case this seems justifiable"
>
> In other words this *was* a judgement call. [For the record:
> I ballotted NO OBJECTION on RFC4343.] I regard the DISCUSS
> that John is appealing against as a judgement call. It isn't clear
> to me that it's a stylistic or editorial comment by construction.
>
> To the underlying process issue, a DISCUSS based on a judgement call
> is always a little tricky. However, if the document shepherd can show
> that the call made in the draft was an explicit rough consensus, it
> does seem like the sort of case where the DISCUSSing AD might choose
> to switch to an ABSTAIN.
>
> I strongly agree with John's suggestion that ADs should
> clearly distinguish
> a comment where they really want discussion from something
> that they view
> as a sticking point. One of the cleared DISCUSSes on 2821bis
> starts thus:
> "This is a discuss discuss question....". Is that clear enough?
>
> Brian
>
> >
> > best,
> > john
> >
> > p.s. while I appreciate the comments I've received expressing
> > support for this appeal, I'm generally not going to respond to
> > them on-list lest the IESG interpret the comments as part of a
> > lobbying effort. The procedures say that appeals go to the
> > IESG and the IESG decides (then they may go elsewhere). I don't
> > believe that there is any prohibition on the IESG's asking for
> > community input if they want it, but they are certainly under no
> > obligation to do so or to consider such input as part of
> > considering the appeal. This note is an exception only because
> > it identified a fact I didn't have available when I wrote the
> > appeal text.
> >
> >
> >
> > _______________________________________________
> > IETF mailing list
> > ***@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> >
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Tony Hansen
2008-06-16 15:32:20 UTC
Permalink
+1. Does "this is a discuss discuss question" mean that "I just want to
discuss this, it's a nit, don't worry" or does it mean "we ABSOLUTELY
MUST DISCUSS this and nothing's moving until we do!" Without other
context, you don't know.

Tony Hansen
***@att.com

Eric Gray wrote:
> Brian,
>
> As a matter of personal preference, I would very much
> prefer not to see process constructions that require repeated
> use of the status in order to disambiguate the meaning of the
> status. In other words, having to clarify that a DISCUSS is
> (really) a discuss (and presumably not something else) is not
> the way to clear things up - not even "clear enough."
>
> Either DISCUSS means what it implies (maybe we add some
> separate status for BLOCK), or we change the state name to an
> intentionally more ambiguous name (like HOLD, or PENDING).
>
>>
>> I strongly agree with John's suggestion that ADs should clearly
>> distinguish a comment where they really want discussion from
>> something that they view as a sticking point. One of the cleared
>> DISCUSSes on 2821bis starts thus: "This is a discuss discuss
>> question....". Is that clear enough?
Pete Resnick
2008-06-16 15:20:44 UTC
Permalink
On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:

>I think one can make a case that in some documents, use of
>non-RFC2606 names as examples is a purely stylistic matter, and that
>in others, it would potentially cause technical confusion.

Please make that case if you would, because the example you give:

>
>In the evaluation record for what became RFC4343
>(https://datatracker.ietf.org/idtracker/ballot/1612/) we find:
>
>"Editorial issues:
>
> - the document uses a number of non-example.com/192.0.2.0
> addresses/names, but in this case this seems justifiable"
>
>In other words this *was* a judgement call.

...quite specifically said it was an "Editorial issue". Please
explain the circumstance in which it would not be an editorial issue.

Of course, the ballot in this particular case
<https://datatracker.ietf.org/idtracker/ballot/2471/> makes no claims
about "technical confusion". I assume that when no "technical
confusion" exists, you *would* consider such things "an editorial
issue"? (A misplaced comma or the use of the passive *may* cause
"technical confusion", but unless this is called out, the assumption
is always that such things are "editorial issues".)

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated
Brian E Carpenter
2008-06-16 21:42:18 UTC
Permalink
Pete (and Dave Crocker),

On 2008-06-17 03:20, Pete Resnick wrote:
> On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
>
>> I think one can make a case that in some documents, use of non-RFC2606
>> names as examples is a purely stylistic matter, and that in others, it
>> would potentially cause technical confusion.
>
> Please make that case if you would, because the example you give:
>
>>
>> In the evaluation record for what became RFC4343
>> (https://datatracker.ietf.org/idtracker/ballot/1612/) we find:
>>
>> "Editorial issues:
>>
>> - the document uses a number of non-example.com/192.0.2.0
>> addresses/names, but in this case this seems justifiable"
>>
>> In other words this *was* a judgement call.
>
> ...quite specifically said it was an "Editorial issue". Please explain
> the circumstance in which it would not be an editorial issue.

Well, I've seen *many* cases of disagreement whether a particular
issue was editorial or substantative, so I wouldn't claim that there
is any absolute standard here. And I've been trying not to comment
on the specific issue of 2821bis, because I have not reviewed
it in detail and make no claim to expertise. Nor am I commenting
on whether the specific DISCUSS comments in this case are reasonable
or not and whether they are well-formulated or not.

If a real domain name, or a real IP address, or a real IP prefix,
is used as an example in code, pseudo-code, or in the description
of a configuration mechanism, there's a good chance that it will
end up in an actual implementation or in an actual configuration
file one day (far from the IETF). In my opinion that is a source
of technical confusion and possibly of unwanted traffic. So I think
there is a strong argument that RFC 2606 values SHOULD be used
whenever reasonably possible.

That's my opinion; I'm not asserting that it's an IETF consensus
or that it necessarily applies to 2821bis. But I do assert that
it's a technical argument and not an editorial one.

Brian

>
> Of course, the ballot in this particular case
> <https://datatracker.ietf.org/idtracker/ballot/2471/> makes no claims
> about "technical confusion". I assume that when no "technical confusion"
> exists, you *would* consider such things "an editorial issue"? (A
> misplaced comma or the use of the passive *may* cause "technical
> confusion", but unless this is called out, the assumption is always that
> such things are "editorial issues".)
>
> pr
Frank Ellermann
2008-06-16 22:57:55 UTC
Permalink
Brian E Carpenter wrote:

> That's my opinion; I'm not asserting that it's an IETF
> consensus or that it necessarily applies to 2821bis.

+1

Some things I'd consider:

RFC 821 used foo.arpa and similar examples, and it won't
surprise me if the author knew precisely why this can
never have any undesirable side-effects.

As explained by John RFC 2821 switched to foo.com. All
address harvesters looking for strings with an "@" have
found it years ago, nothing 2821bis will do can fix it.

Or the opposite effect, the RFCs listed in RFC 3092 might
have contributed to a better page rank of foo.com, maybe
the current owner has no problem with the overall effect.

Whatever 2821bis does, it cannot change the good or bad
caused by RFC 2821 and other RFCs. Therefore the issue
is at first glance purely editorial.

*BUT* 2821bis will be one of the most important RFCs for
many years - assuming it goes "as is" to STD - and many
readers, who will take it as gospel. They will see the
foo.com examples, and use similar constructs for their
own examples. They won't know or read RFC 2606, and if
they get push back they can say "but 5821 also does it".

Of course I'd ignore red lights when there's no traffic,
and I just want to cross the street. And I'd be upset
if some "authority" tells me that I shouldn't do this.
But is it really necessary to ignore red lights in the
presence of kids who have no clue what can go wrong ?

Frank
Brian Dickson
2008-06-17 06:36:46 UTC
Permalink
Frank Ellermann wrote:
> Brian E Carpenter wrote:
>
>
>> That's my opinion; I'm not asserting that it's an IETF
>> consensus or that it necessarily applies to 2821bis.
>>
>
> +1
>
> Some things I'd consider:
>
> RFC 821 used foo.arpa and similar examples, and it won't
> surprise me if the author knew precisely why this can
> never have any undesirable side-effects.
>
> As explained by John RFC 2821 switched to foo.com. All
> address harvesters looking for strings with an "@" have
> found it years ago, nothing 2821bis will do can fix it.
>
> Or the opposite effect, the RFCs listed in RFC 3092 might
> have contributed to a better page rank of foo.com, maybe
> the current owner has no problem with the overall effect.
>
> Whatever 2821bis does, it cannot change the good or bad
> caused by RFC 2821 and other RFCs. Therefore the issue
> is at first glance purely editorial.
>
> *BUT* 2821bis will be one of the most important RFCs for
> many years - assuming it goes "as is" to STD - and many
> readers, who will take it as gospel. They will see the
> foo.com examples, and use similar constructs for their
> own examples. They won't know or read RFC 2606, and if
> they get push back they can say "but 5821 also does it".
>
> Of course I'd ignore red lights when there's no traffic,
> and I just want to cross the street. And I'd be upset
> if some "authority" tells me that I shouldn't do this.
> But is it really necessary to ignore red lights in the
> presence of kids who have no clue what can go wrong ?
>

The issue at hand (the DISCUSS and appeal) is at odds with the AD's view,
regarding updating names used in examples versus RFC2606.

In the interests of resolving the issue while respecting both the desire
to preserve
the text between 2821 and 2821bis, and to acknowledge that the examples used
aren't 2606-compliant and preserved only to avoid making too many changes to
a document with a long history/ancestry, what about a minor compromise by
both parties?


Here's my suggestion:

List 2606 in the informative references, and footnote the examples used
to indicate
that they are "grandfathered" non-2606 examples.

So, in text that previously read "not-example.com", it might read
"not-example.com [*]",
with the references section having "[*] Note - non-RFC2606 examples
used. Please read RFC2606."

Something along those lines, should hopefully be enough to keep both
sides happy, and resolve the DISCUSS,
and hopefully both set a suitable precedent *and* make moot the appeal.

YMMV.

Brian Dickson
Simon Josefsson
2008-06-17 09:30:05 UTC
Permalink
Brian Dickson <***@ca.afilias.info> writes:

> Here's my suggestion:
>
> List 2606 in the informative references, and footnote the examples used
> to indicate
> that they are "grandfathered" non-2606 examples.
>
> So, in text that previously read "not-example.com", it might read
> "not-example.com [*]",
> with the references section having "[*] Note - non-RFC2606 examples
> used. Please read RFC2606."
>
> Something along those lines, should hopefully be enough to keep both
> sides happy, and resolve the DISCUSS,
> and hopefully both set a suitable precedent *and* make moot the appeal.

I think this sounds like a good compromise, and it does improve the
document quality IMHO. John, would this be an acceptable addition to
the document?

Thanks,
Simon
e***@standardstrack.com
2008-06-17 12:26:30 UTC
Permalink
Sounds like a lot of work to me. In the era of xml2rfc, that could be error-prone as well. For the particular issue, having a notice in the Conventions section might do (it may be there already...). However, it doesn't address the fundamental issue raised by the appeal.

I don't think the IETF wants to go the path of U.N.-sponsored treaty organization SDO's [if you have no clue what I am referring to, just ask Tom Taylor or Rich Shockey who would love to earn beers for telling about their experiences]. The goal is not just to negotiate a "settlement", but to fix the problem. We are engineers, after alll.

Moreover, I do not think the "problem" is an individual, where the fix is "fixing" the individual. I would encourage everyone to re-read John's original post. The fundamental problem of not knowing what is critical and what isn't needs to be made clear, and via the IETF's accepted processes.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Simon Josefsson <***@josefsson.org>

Date: Tue, 17 Jun 2008 11:30:05
To:Brian Dickson <***@ca.afilias.info>
Cc:Frank Ellermann <***@gmail.com>, ***@ietf.org
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis


Brian Dickson <***@ca.afilias.info> writes:

> Here's my suggestion:
>
> List 2606 in the informative references, and footnote the examples used
> to indicate
> that they are "grandfathered" non-2606 examples.
>
> So, in text that previously read "not-example.com", it might read
> "not-example.com [*]",
> with the references section having "[*] Note - non-RFC2606 examples
> used. Please read RFC2606."
>
> Something along those lines, should hopefully be enough to keep both
> sides happy, and resolve the DISCUSS,
> and hopefully both set a suitable precedent *and* make moot the appeal.

I think this sounds like a good compromise, and it does improve the
document quality IMHO. John, would this be an acceptable addition to
the document?

Thanks,
Simon
John C Klensin
2008-06-17 19:31:35 UTC
Permalink
--On Tuesday, 17 June, 2008 11:30 +0200 Simon Josefsson
<***@josefsson.org> wrote:

> Brian Dickson <***@ca.afilias.info> writes:
>
>> Here's my suggestion:
>>
>> List 2606 in the informative references, and footnote the
>> examples used to indicate
>> that they are "grandfathered" non-2606 examples.
>>
>> So, in text that previously read "not-example.com", it might
>> read "not-example.com [*]",
>> with the references section having "[*] Note - non-RFC2606
>> examples used. Please read RFC2606."
>>
>> Something along those lines, should hopefully be enough to
>> keep both sides happy, and resolve the DISCUSS,
>> and hopefully both set a suitable precedent *and* make moot
>> the appeal.
>
> I think this sounds like a good compromise, and it does
> improve the document quality IMHO. John, would this be an
> acceptable addition to the document?

Simon,

I've responded to Brian off-list and continue in my
determination to not engage in a debate about the appeal itself:
under the procedures as I read them and as they have been
applied in the past, the IESG will decide however it decides.
However, unless they make it one by composing a statement or
appeal response and issuing a Last Call on it (I believe they
have the right to do that, but certainly not any obligation, and
it would be unprecedented), the appeal itself is neither a
community popularity contest nor a consensus call. Remember
that 2026 does not even require that appeals be made public when
they are submitted.

Without endorsing them (the authors speak for themselves and
have written clearly), you might want to re-read any of several
recent notes and the appeal text: the core issue that motivated
the appeal was not whether or not these examples were to be
changed.

Changing the examples (or not) has _never_ been the core
question. If it were, I would have included a discussion of
compromise positions and counter-suggestions that had already
been offered. Even with such a discussion, the appeal text
would have been much shorter. The core issue has to do with how
the IESG manages document reviews, whether the community likes
late surprises that could easily be avoided, how rules are
formulated and applied in the IETF, how AD judgments relate to
consensus in the IETF Community or applicable subgroups, and so
on.

As to Brian's suggestion, please consider the following, derived
from RFC3501 and hypothesize that, at some point, an RFC 2606bis
might be created (and go through the consensus process to BCP)
that offers special reserved names for newsgroups or mailing
lists as well as domain names (many of the arguments offered for
using only reserved domain names, including "rude to the
owners", would probably apply to newsgroups and other sorts of
network entities as well) and that included a form of Brian's
suggestion as normative.

RFC3501 now includes:

> Example: C: A002 LSUB "#news." "comp.mail.*"
> S: * LSUB () "." #news.comp.mail.mime
> S: * LSUB () "." #news.comp.mail.misc
> S: A002 OK LSUB completed

Now, suppose, per Brian's suggestion, that were changed to

Example: C: A002 LSUB "#news." "comp.mail.*" *
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
or

Example: C: A002 LSUB "#news." "comp.mail.*" [Foobar]
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
or

Example: C: A002 LSUB "#news." "comp.mail.*" [1]
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed

any of which would be consistent with what I interpret as the
spirit of Brian's suggestion, with the "*", "[Foobar]", or "[1]"
being anchors for a reference or footnote.

Now _that_, folks, is confusing, since a reasonable reader might
have trouble figuring out whether the footnote/reference anchor
was part of the IMAP syntax and example or not. It would be so
confusing that I'd argue that it involved a substantive issue,
rather than an editorial/stylistic one as Brian Carpenter
suggests sometimes occurs. I'd expect people to notice it
during Last Call and complain, and I'd think an AD would be
entirely justified in asking hard questions and forcing
discussions.

Whether the examples in 2821bis are like that case simply
because they fail to use 2606 names is something that you should
judge for yourselves. But, because of possibilities that the
examples above illustrate, be careful what you wish for.

john
Frank Ellermann
2008-06-17 20:43:33 UTC
Permalink
John C Klensin wrote:

> hypothesize that, at some point, an RFC 2606bis might be created
> (and go through the consensus process to BCP) that offers special
> reserved names for newsgroups or mailing lists as well as domain
> names

JFTR, with respect to newsgroups that is already specified in
http://tools.ietf.org/html/draft-ietf-usefor-usefor-12#section-3.1.4

| The following <newsgroup-name>s are reserved and MUST NOT be used as
| the name of a newsgroup:
|
| o Groups whose first (or only) <component> is "example"

The (unnumbered) NetNews standard does not go into details for
which purpose the "example"-names are reserved, but I think it
is obvious. The plan was to discuss such details in a separate
NetNews BCP later if needed.

> a reasonable reader might have trouble figuring out whether
> the footnote/reference anchor was part of the IMAP syntax
> and example or not.

+1 A consistent footnote style can be fine in Web pages, PDFs,
and similar document formats, but it is unsuited for the ASCII
text/plain xml2rfc output format(s).

In the case of ABNF a single space could turn a clear concept into incomprehensible gibberish if the RFC line length limits
don't agree with adding this space.

Frank
Simon Josefsson
2008-06-18 11:19:13 UTC
Permalink
John C Klensin <john-***@jck.com> writes:

> Changing the examples (or not) has _never_ been the core
> question.

I understand that, but I think the reason behind the DISCUSS can lead to
a better document. I sympathize with your effort to make the IESG
decision process better documented, or at least consistent, and I'll
follow the result of this appeal with interest.

However, that is, as you seem to agree, not strongly related to the
document contents.

I think we can have two useful discussions at the same time: one about
the appeal/process issue and one about the document content. My
thoughts here are more about the latter, as my time and energy to
participate in the discussion about the former is too restricted.

> As to Brian's suggestion, please consider the following, derived
> from RFC3501 and hypothesize that, at some point, an RFC 2606bis
> might be created (and go through the consensus process to BCP)
> that offers special reserved names for newsgroups or mailing
> lists as well as domain names (many of the arguments offered for
> using only reserved domain names, including "rude to the
> owners", would probably apply to newsgroups and other sorts of
> network entities as well) and that included a form of Brian's
> suggestion as normative.
>
> RFC3501 now includes:
>
>> Example: C: A002 LSUB "#news." "comp.mail.*"
>> S: * LSUB () "." #news.comp.mail.mime
>> S: * LSUB () "." #news.comp.mail.misc
>> S: A002 OK LSUB completed
>
> Now, suppose, per Brian's suggestion, that were changed to
>
> Example: C: A002 LSUB "#news." "comp.mail.*" *
> S: * LSUB () "." #news.comp.mail.mime
> S: * LSUB () "." #news.comp.mail.misc
> S: A002 OK LSUB completed
> or
>
> Example: C: A002 LSUB "#news." "comp.mail.*" [Foobar]
> S: * LSUB () "." #news.comp.mail.mime
> S: * LSUB () "." #news.comp.mail.misc
> S: A002 OK LSUB completed
> or
>
> Example: C: A002 LSUB "#news." "comp.mail.*" [1]
> S: * LSUB () "." #news.comp.mail.mime
> S: * LSUB () "." #news.comp.mail.misc
> S: A002 OK LSUB completed
>
> any of which would be consistent with what I interpret as the
> spirit of Brian's suggestion, with the "*", "[Foobar]", or "[1]"
> being anchors for a reference or footnote.
>
> Now _that_, folks, is confusing, since a reasonable reader might
> have trouble figuring out whether the footnote/reference anchor
> was part of the IMAP syntax and example or not. It would be so
> confusing that I'd argue that it involved a substantive issue,
> rather than an editorial/stylistic one as Brian Carpenter
> suggests sometimes occurs. I'd expect people to notice it
> during Last Call and complain, and I'd think an AD would be
> entirely justified in asking hard questions and forcing
> discussions.
>
> Whether the examples in 2821bis are like that case simply
> because they fail to use 2606 names is something that you should
> judge for yourselves. But, because of possibilities that the
> examples above illustrate, be careful what you wish for.

That is a good and valid point.

There is one important part of what Brian Dickson suggested: that the
'[*]' (or similar markup) reference is added to "text". Presumably it
would only be added to the first occurrence. Adding the reference to
examples intended to illustrate the protocol is obviously a silly thing
to do.

With this elaboration regarding Brian's proposal, I would still be in
favor of making his change to the document, unrelated to the outcome of
the appeal. The justification is that it results in a better and more
complete document.

/Simon
Harald Alvestrand
2008-06-18 07:05:41 UTC
Permalink
Simon Josefsson wrote:
> Brian Dickson <***@ca.afilias.info> writes:
>
>
>> Here's my suggestion:
>>
>> List 2606 in the informative references, and footnote the examples used
>> to indicate
>> that they are "grandfathered" non-2606 examples.
>>
>> So, in text that previously read "not-example.com", it might read
>> "not-example.com [*]",
>> with the references section having "[*] Note - non-RFC2606 examples
>> used. Please read RFC2606."
>>
>> Something along those lines, should hopefully be enough to keep both
>> sides happy, and resolve the DISCUSS,
>> and hopefully both set a suitable precedent *and* make moot the appeal.
>>
>
> I think this sounds like a good compromise, and it does improve the
> document quality IMHO. John, would this be an acceptable addition to
> the document?
I do not want a compromise on whether or not the IESG documents the
rules it's enforcing.
BEFORE trying to enforce them "consistently", and using the
"consistency" as an argument that what looks like a recommendation in a
BCP is "really" a MUST.

Harald
Fred Baker
2008-06-17 16:43:00 UTC
Permalink
On Jun 16, 2008, at 11:36 PM, Brian Dickson wrote:

> List 2606 in the informative references, and footnote the examples
> used to indicate that they are "grandfathered" non-2606 examples.

It seems that this gives 2606 more weight than it claims. What it
claims is, quoting its abstract:

To reduce the likelihood of conflict and confusion, a few top level
domain names are reserved for use in private testing, as examples in
documentation, and the like. In addition, a few second level domain
names reserved for use as examples are documented.

in other words, the names are reserved, but there is no statement (on
either page of the RFC) that the naming is exclusive. One *may* use
such names, but one is not *required* to.

Footnoting and saying that they have been "grandfathered" asserts
that there is such an exclusionary rule and this is an exception to it.

To my way of thinking, if you want to put something into the
document, you want something like:

The names in this document are consistent with RFC 2820/2821 and
RFC 820/821.
Debbie Garside
2008-06-17 14:50:02 UTC
Permalink
Not being a expert on this but having briefly read the documents in
question, I agree with Brian. This is not editorial. I would also add that
to go against an IETF BCP on the grounds of "well we have done so already
historically" does not make an argument for continuing to do so; errors
should be corrected when found, not endorsed. If we are to pick and choose
which RFC's/BCP's we will take notice of what is the point of
standardization? On the face of things, and with my little knowledge, I
would say that the person within the IESG who has invoked the DISCUSS is
quite correct.

Feel free to try to change my mind.

Best regards

Debbie Garside

> -----Original Message-----
> From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On
> Behalf Of Brian E Carpenter
> Sent: 16 June 2008 22:42
> To: Pete Resnick
> Cc: John C Klensin; ***@ietf.org; ***@ietf.org
> Subject: Re: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> Pete (and Dave Crocker),
>
> On 2008-06-17 03:20, Pete Resnick wrote:
> > On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
> >
> >> I think one can make a case that in some documents, use of
> >> non-RFC2606 names as examples is a purely stylistic
> matter, and that
> >> in others, it would potentially cause technical confusion.
> >
> > Please make that case if you would, because the example you give:
> >
> >>
> >> In the evaluation record for what became RFC4343
> >> (https://datatracker.ietf.org/idtracker/ballot/1612/) we find:
> >>
> >> "Editorial issues:
> >>
> >> - the document uses a number of non-example.com/192.0.2.0
> >> addresses/names, but in this case this seems justifiable"
> >>
> >> In other words this *was* a judgement call.
> >
> > ...quite specifically said it was an "Editorial issue".
> Please explain
> > the circumstance in which it would not be an editorial issue.
>
> Well, I've seen *many* cases of disagreement whether a
> particular issue was editorial or substantative, so I
> wouldn't claim that there is any absolute standard here. And
> I've been trying not to comment on the specific issue of
> 2821bis, because I have not reviewed it in detail and make no
> claim to expertise. Nor am I commenting on whether the
> specific DISCUSS comments in this case are reasonable or not
> and whether they are well-formulated or not.
>
> If a real domain name, or a real IP address, or a real IP
> prefix, is used as an example in code, pseudo-code, or in the
> description of a configuration mechanism, there's a good
> chance that it will end up in an actual implementation or in
> an actual configuration file one day (far from the IETF). In
> my opinion that is a source of technical confusion and
> possibly of unwanted traffic. So I think there is a strong
> argument that RFC 2606 values SHOULD be used whenever
> reasonably possible.
>
> That's my opinion; I'm not asserting that it's an IETF
> consensus or that it necessarily applies to 2821bis. But I do
> assert that it's a technical argument and not an editorial one.
>
> Brian
>
> >
> > Of course, the ballot in this particular case
> > <https://datatracker.ietf.org/idtracker/ballot/2471/> makes
> no claims
> > about "technical confusion". I assume that when no
> "technical confusion"
> > exists, you *would* consider such things "an editorial issue"? (A
> > misplaced comma or the use of the passive *may* cause "technical
> > confusion", but unless this is called out, the assumption is always
> > that such things are "editorial issues".)
> >
> > pr
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
>
>
>
Marshall Eubanks
2008-06-17 18:44:33 UTC
Permalink
I fully agree with Debbie here.

Human experience teaches us that examples will
be used, over time. Foo.com is a commercial site. If the IETF uses
foo.com in email examples,
it is reasonable to assume that foo.com will get unwanted traffic
because of that. I think that
the IETF should not put itself in the position of causing avoidable
pain to others, even if the likelihood of serious harm is small. Since
there is a remedy, and it could be adopted readily, I think that the
discuss was reasonable and do not support the appeal.

Regards
Marshall


On Jun 17, 2008, at 10:50 AM, Debbie Garside wrote:

> Not being a expert on this but having briefly read the documents in
> question, I agree with Brian. This is not editorial. I would also
> add that
> to go against an IETF BCP on the grounds of "well we have done so
> already
> historically" does not make an argument for continuing to do so;
> errors
> should be corrected when found, not endorsed. If we are to pick and
> choose
> which RFC's/BCP's we will take notice of what is the point of
> standardization? On the face of things, and with my little
> knowledge, I
> would say that the person within the IESG who has invoked the
> DISCUSS is
> quite correct.
>
> Feel free to try to change my mind.
>
> Best regards
>
> Debbie Garside
>
>> -----Original Message-----
>> From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On
>> Behalf Of Brian E Carpenter
>> Sent: 16 June 2008 22:42
>> To: Pete Resnick
>> Cc: John C Klensin; ***@ietf.org; ***@ietf.org
>> Subject: Re: Appeal against IESG blocking DISCUSS on
>> draft-klensin-rfc2821bis
>>
>> Pete (and Dave Crocker),
>>
>> On 2008-06-17 03:20, Pete Resnick wrote:
>>> On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:
>>>
>>>> I think one can make a case that in some documents, use of
>>>> non-RFC2606 names as examples is a purely stylistic
>> matter, and that
>>>> in others, it would potentially cause technical confusion.
>>>
>>> Please make that case if you would, because the example you give:
>>>
>>>>
>>>> In the evaluation record for what became RFC4343
>>>> (https://datatracker.ietf.org/idtracker/ballot/1612/) we find:
>>>>
>>>> "Editorial issues:
>>>>
>>>> - the document uses a number of non-example.com/192.0.2.0
>>>> addresses/names, but in this case this seems justifiable"
>>>>
>>>> In other words this *was* a judgement call.
>>>
>>> ...quite specifically said it was an "Editorial issue".
>> Please explain
>>> the circumstance in which it would not be an editorial issue.
>>
>> Well, I've seen *many* cases of disagreement whether a
>> particular issue was editorial or substantative, so I
>> wouldn't claim that there is any absolute standard here. And
>> I've been trying not to comment on the specific issue of
>> 2821bis, because I have not reviewed it in detail and make no
>> claim to expertise. Nor am I commenting on whether the
>> specific DISCUSS comments in this case are reasonable or not
>> and whether they are well-formulated or not.
>>
>> If a real domain name, or a real IP address, or a real IP
>> prefix, is used as an example in code, pseudo-code, or in the
>> description of a configuration mechanism, there's a good
>> chance that it will end up in an actual implementation or in
>> an actual configuration file one day (far from the IETF). In
>> my opinion that is a source of technical confusion and
>> possibly of unwanted traffic. So I think there is a strong
>> argument that RFC 2606 values SHOULD be used whenever
>> reasonably possible.
>>
>> That's my opinion; I'm not asserting that it's an IETF
>> consensus or that it necessarily applies to 2821bis. But I do
>> assert that it's a technical argument and not an editorial one.
>>
>> Brian
>>
>>>
>>> Of course, the ballot in this particular case
>>> <https://datatracker.ietf.org/idtracker/ballot/2471/> makes
>> no claims
>>> about "technical confusion". I assume that when no
>> "technical confusion"
>>> exists, you *would* consider such things "an editorial issue"? (A
>>> misplaced comma or the use of the passive *may* cause "technical
>>> confusion", but unless this is called out, the assumption is always
>>> that such things are "editorial issues".)
>>>
>>> pr
>> _______________________________________________
>> IETF mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>>
>>
>>
>
>
>
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Steven M. Bellovin
2008-06-17 18:54:43 UTC
Permalink
On Tue, 17 Jun 2008 14:44:33 -0400
Marshall Eubanks <***@multicasttech.com> wrote:

> I fully agree with Debbie here.
>
> Human experience teaches us that examples will
> be used, over time. Foo.com is a commercial site. If the IETF uses
> foo.com in email examples,
> it is reasonable to assume that foo.com will get unwanted traffic
> because of that. I think that
> the IETF should not put itself in the position of causing avoidable
> pain to others, even if the likelihood of serious harm is small.
> Since there is a remedy, and it could be adopted readily, I think
> that the discuss was reasonable and do not support the appeal.

Yes -- and there's certainly case law to support the IESG's
position; the IESG has been insisting on this for years.

Now -- there are times when the stated policy just doesn't work. I
recall one IPsec document where the example had to show several
different networks. John's appeal stated that the WG considered and
rejected using the 2606 names; perhaps this is another case. (I
haven't read the draft in question.) Hoping the reader will notice the
difference between example.com and example.net, or even
bad-dog.example.com and good-cat.example.net, is just asking for
trouble.

So -- in general, I think the IESG's position is a good one, and
well-supported by custom; however, there are exceptions.


--Steve Bellovin, http://www.cs.columbia.edu/~smb
Pete Resnick
2008-06-17 19:32:10 UTC
Permalink
I first want to re-iterate what Eric posted earlier: Please read the
appeal. The *very minor* issue of the appeal is whether or not to use
2606 names. It is the use of the DISCUSS in this case that is at
issue. That said:

On 6/17/08 at 2:54 PM -0400, Steven M. Bellovin wrote:

>On Tue, 17 Jun 2008 14:44:33 -0400 Marshall Eubanks
><***@multicasttech.com> wrote:
>
>>On 6/17/08 at 3:50 PM +0100, Debbie Garside wrote:
>>
>>>Not being a expert on this but having briefly read the documents
>>>in question, I agree with Brian. This is not editorial.
>>
>>I fully agree with Debbie here.

Either Marshall or Debbie is going to have to explain this to me:
Why, IN THIS DOCUMENT, is this not an "editorial issue". Nothing said
so far that we can attribute to the IESG says anything like, "there's
a technical issue here". Please, someone give any indication that IN
THIS DOCUMENT, there is any hint of technical mistake that will be
made because a domain name other than "example.com" or "example.org"
is being used.

And for the record:

>>>I would also add that to go against an IETF BCP on the grounds of
>>>"well we have done so already historically" does not make an
>>>argument for continuing to do so; errors should be corrected when
>>>found, not endorsed.

John did not "go against an IETF BCP". This is not an "error" to be
"corrected". The BCP in question gives *an option* to use particular
names, not a requirement. There are plenty of BCPs that make all
kinds of suggestions, and some we take and some we don't. There is no
"MUST" in 2606; it is up to the discretion of the user whether using
2606 domain names suits a particular purpose. And in this case, the
DRUMS working group made an explicit decision back in 2001 to choose
something different in this document.

>>Human experience teaches us that examples will be used, over time.
>>Foo.com is a commercial site. If the IETF uses foo.com in email
>>examples, it is reasonable to assume that foo.com will get unwanted
>>traffic because of that.

There has been no evidence, in 7 years of 2821 being available, that
such has been the case. I don't see why you would say that it is
"reasonable to assume" that. This is not a MIB or the like, where
people will be copying this info into configuration files.

But let me repeat, this is not the major issue:

>>Since there is a remedy, and it could be adopted readily, I think
>>that the discuss was reasonable and do not support the appeal.
>
>Yes -- and there's certainly case law to support the IESG's
>position; the IESG has been insisting on this for years.

Let's assume you're both right. Let's assume that it's better (for
some values of "better") to use 2606 domain names in 2821. Let's
assume that it is easy (for some values of "easy") to put those names
into 2821bis. Let's assume that "the IESG has been insisting on this
for years." None of that matters:

The DRUMS working group (which produced 2821 *after* 2606 came out)
made a conscious decision at the time not to use those names. (It is
documented in the archive.) The original document passed the IESG at
the time without those names (while 2606 was out), and one must
assume that the IESG at that time made the conscious decision that
the working group consensus on this point was sufficient to leave
those names in 2821. To STOP the document now (and that is what the
AD in question has said about the effect of the DISCUSS) with *no
technical justification* of why an explicit working group decision
should be reversed (there has been none given) is a clear process
violation.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated
Eliot Lear
2008-06-17 20:17:11 UTC
Permalink
Pete,
> I first want to re-iterate what Eric posted earlier: Please read the
> appeal. The *very minor* issue of the appeal is whether or not to use
> 2606 names. It is the use of the DISCUSS in this case that is at
> issue. That said:
>

I am uncomfortable ham-stringing the IESG (or having them do it to
themselves) by requiring them to be excessively prescriptive about when
they can and cannot use a DISCUSS. It should be good enough for them to
state their reasoning behind it, with the understanding that if someone
doesn't like the reasoning they can appeal to the IAB. If enough people
disagree with the person or persons making the DISCUSS we have a recall
function at our disposal.

I happen to tepidly agree with the DISCUSS on the grounds that Marshall
Eubanks cited, but only tepidly because the likelihood of injury in this
case is vanishingly small. That having been said, the reason I agree is
that we should strive to improve our documents over time. SMTP should
not be an exception but instead an example.(.com ;-).

Eliot
Marshall Eubanks
2008-06-17 19:39:14 UTC
Permalink
Dear Steve;

On Jun 17, 2008, at 2:54 PM, Steven M. Bellovin wrote:

> On Tue, 17 Jun 2008 14:44:33 -0400
> Marshall Eubanks <***@multicasttech.com> wrote:
>
>> I fully agree with Debbie here.
>>
>> Human experience teaches us that examples will
>> be used, over time. Foo.com is a commercial site. If the IETF uses
>> foo.com in email examples,
>> it is reasonable to assume that foo.com will get unwanted traffic
>> because of that. I think that
>> the IETF should not put itself in the position of causing avoidable
>> pain to others, even if the likelihood of serious harm is small.
>> Since there is a remedy, and it could be adopted readily, I think
>> that the discuss was reasonable and do not support the appeal.
>
> Yes -- and there's certainly case law to support the IESG's
> position; the IESG has been insisting on this for years.
>
> Now -- there are times when the stated policy just doesn't work. I
> recall one IPsec document where the example had to show several
> different networks. John's appeal stated that the WG considered and
> rejected using the 2606 names; perhaps this is another case. (I
> haven't read the draft in question.)

I have skimmed through it, and did not see any such problems in this
case. Of course,
I could be wrong and would be gladly educated as to the error of my
ways.

From your description, it may be that 2606 needs a bis too.

Regards
Marshall


> Hoping the reader will notice the
> difference between example.com and example.net, or even
> bad-dog.example.com and good-cat.example.net, is just asking for
> trouble.
>
> So -- in general, I think the IESG's position is a good one, and
> well-supported by custom; however, there are exceptions.
>
>
> --Steve Bellovin, http://www.cs.columbia.edu/~smb
LB
2008-06-17 21:09:41 UTC
Permalink
Dear Colleagues,
I'm reading the proceedings of the IETF for the past few months. They
surprise me very much. I thought that the IETF was a serious
institution seriously publishing serious standards. I realized that
his organization is not made for that and I wonder how it can publish
something serious : I believe that the Dratf John is serious, but it
should not be a new document for us @large to read. It should be an
update of SMTP Page in the IETF Internet reference wiki.

I also read in detail the appeal of John Klensin. Most of the things
he asks seem obvious. And yet he's losing time to document them, and
many intelligent minds waste time on it, while the appeal relates
solely to the IESG. The real debate will be after the IESG response
and before a possible appeal to the IAB. Why not to wait for it. Or is
this some kind of pressure ? If I understood correctly, this appeal
is not asking to IESG judge, but to document its defence.

Would not it be easier to create a WG-IETF, which would be mandated to
rebuild a IETF for today where a method, procedures, a logic of work
would be automated, with human decision points well documented? This
would allow the brains of engineers to worry about the Internet and
its users, rather than about internal disputes and the IESG? The
appeal would then simply concern the review of the three lines
defining the DISCUSS decision point in the IESG page.

My idea is it so stupid?
--
LB
Marshall Eubanks
2008-06-17 23:59:49 UTC
Permalink
Dear Dave;

On Jun 17, 2008, at 3:36 PM, Dave Crocker wrote:

>
>
> Marshall Eubanks wrote:
>> I fully agree with Debbie here.
>> Human experience teaches us that examples will
>> be used, over time.
>
> Seems like 25+ years is a pretty solid sample size of experience, to
> test such a theory.*
>
> So you won't have any trouble providing data to support your
> conclusion that, indeed, there is a problem?
>

I don't know - I do not own generic.com, foo.com, foo.org, bar.org or
bar.com. Has anyone asked these companies (at least foo.com and
bar.com are actual companies) or the domain holders for their opinion
and experience in this matter ? For that matter, has anyone asked
Jorge Contreras for his opinion as our counsel on the legal liability
we might be incurring by using their names ?

I do know that if I did own one of those companies, I would request
that this document be changed.

Regards
Marshall

> [Once again: Not that that is the core issue being appealed.]
>
> d/
>
> * In theory, there isn't much difference between theory and
> practice. In practice...
>
>
> --
>
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
Debbie Garside
2008-06-18 11:02:44 UTC
Permalink
Dave wrote:

> Even on Wednesdays.

Or for purple documents... ;-)

I see your point. I do think, assuming it is not already documented and
further assuming this is the whole point of the appeal, that the IESG could
create a general policy wrt BCP's. Shouldn't be too onerous. That way
everyone knows in advance that they should follow a BCP unless they can show
reasonable cause not to (in which case the BCP in question probably needs
updating). The IETF uses terms such as MAY, MUST and SHOULD extensively
during the creation of an RFC and invariably a MAY or SHOULD is used in
order not to constrain future development (wise decisions in most cases) -
but doesn't mean that they SHOULD NOT be followed where it is reasonably
possible :-)

Best regards

Debbie

> -----Original Message-----
> From: Dave Cridland [mailto:***@cridland.net]
> Sent: 18 June 2008 11:39
> To: ***@ictmarketing.co.uk
> Cc: 'John C Klensin'; ***@ietf.org; ***@ietf.org; 'Brian E
> Carpenter'; 'Pete Resnick'
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> On Tue Jun 17 15:50:02 2008, Debbie Garside wrote:
> > Not being a expert on this but having briefly read the documents in
> > question, I agree with Brian. This is not editorial.
>
> Well, people have commented that changing the examples will
> hardly break the Internet mail system, so it seems reasonable
> to assert that the counter-argument is also true. In other
> words, NOT changing the examples will also not break Internet
> mail. However, I couldn't really care what the examples say,
> as long as they're good, clear examples, and I think they are.
>
> > I would also add that
> > to go against an IETF BCP
>
> Ah, wait - the document in question is not a missive from the
> mount stating "Thou SHALT use example.net everywhere", it
> says "The IETF said, 'Let there be reserved domain names for
> examples'; and there were."
>
> (I'm translating the documents into language more suitable
> for the religious tracts some people appear to think they are
> - at this rate, I'm fully expecting future editions to
> include marginalia comencing "Once, a student asked the Postel ...")
>
> But the facts are that nobody is "going against" the BCP. The
> examples in the document don't take advantage of the
> facilities provided by the BCP, but that's different.
>
> > on the grounds of "well we have done so already historically" does
> > not make an argument for continuing to do so;
>
> Perhaps your implication that, irrespective of the past
> behaviour, we should create such a rule is sensible...
>
> > errors
> > should be corrected when found, not endorsed.
>
> ... but until we do, it is not an error, and - crucially - we
> should not expect nor allow the IESG to decide on a whim what
> is and is not an error.
>
> > If we are to pick and choose
> > which RFC's/BCP's we will take notice of what is the point of
> > standardization?
>
> Well, indeed, bravo, and well spoken - that's what John's
> appeal is about - what's the point of having procedures and
> policies at all if the IESG can say "I must reject your
> document; it is purple. No purple documents on Wednesdays,
> for lo, I have spoken."
>
> You may think I'm making light of this - and I am, because I
> think it's a remarkably silly stance from the IESG - but if
> you can explain the difference between rejecting all purple
> documents on Wednesdays and rejecting documents that do not
> use RFC 2606, I'll be most grateful.
>
> > On the face of things, and with my little knowledge, I
> would say that
> > the person within the IESG who has invoked the DISCUSS is quite
> > correct.
> >
> >
> And I reckon they're talking bananas.
>
> It doesn't matter, incidentally, whether you consider the use
> of example.com to be a good idea or not. I do, although I
> note that the XSF's tradition of using a fictional ".lit" TLD
> with example domains taken from Shakespeare's plays is
> actually considerably more readable, but anyway, I'd be
> perfectly happy if the IESG made a statement that as of now,
> documents which use domains other than those present in RFC
> 2606 will not be acceptable.
>
> But I note that there is no such statement from the IESG, so
> I'm personally not clear about whether there even is such a
> policy, or upon which days of the week it applies - for all I
> know, given the lack of statements made by the IESG on RFC
> 2606 names, these may be mandated only for purple documents
> submitted on Wednesdays. And those aren't allowed, as
> previously discussed. (And yeah, I know, but consider this -
> if I say that the IESG say that purple documents are not
> allowed on Wednesdays, that gives that equal weight with the
> alledged RFC 2606 rule - the IESG has not made any statement,
> we've only heard about this informally via third parties).
>
> What matters here is whether the IESG is allowed to introduce
> and enforce a rule with the same action. I do not believe
> they should be allowed to.
>
> Even on Wednesdays.
>
> Dave.
> --
> Dave Cridland - mailto:***@cridland.net - xmpp:***@dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
>
>
>
Dave Cridland
2008-06-18 11:28:10 UTC
Permalink
On Wed Jun 18 12:02:44 2008, Debbie Garside wrote:
> Dave wrote:
>
> > Even on Wednesdays.
>
> Or for purple documents... ;-)
>
> I see your point. I do think, assuming it is not already
> documented and
> further assuming this is the whole point of the appeal, that the
> IESG could
> create a general policy wrt BCP's.

Well, that is indeed a possibility, but RFC 2606 - the BCP involved
in this specific case - does not state anywhere that people MUST use
the domains it reserves in examples.

Therefore, to cover this particular case, such a blanket policy would
have to be stated such that even vague recommendations in BCPs MUST
be followed religiously, even if the document's author not only
doesn't think that was the purpose of the document, but clearly
states that wasn't the reason it's a BCP anyway.

Maybe the policy could also state a Doctrine Of IESG Infallibility,
and just bypass the entire issue.

Dave.
--
Dave Cridland - mailto:***@cridland.net - xmpp:***@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Dave Cridland
2008-06-18 12:34:02 UTC
Permalink
On Wed Jun 18 12:28:10 2008, Dave Cridland wrote:
> Therefore, to cover this particular case, such a blanket policy
> would have to be stated such that even vague recommendations in
> BCPs

I received a private comment which appeared to suggest I'm being
unclear here. So let me clarify:

The BCP, RFC 2606, as a whole is not a vague recommendation, and I
certainly didn't say that - the BCP states that the domains are
reserved, and, by its status as a BCP, it therefore reserves them.
(Donald Eastlake said elsewhere in the thread that the reason it's a
BCP at all was because the reservation of the domains needed the kind
of solid consensus that BCP status provides).

What is very much a vague recommendation is whether these domains
should be used.

The document says:

Depending on the nature of
the test or example, it might be best for it to be referencing a
TLD
permanently reserved for such purposes.

Yes, folks, that's "might be best" - hardly the eleventh commandment,
here.

And:

".example" is recommended for use in documentation or as
examples.

Note that both these, the latter of which is by far the strongest
recommendation in the document, refer to the rarely used ".example"
TLD.

On the subject of the more traditionally used second-level domains,
it says only this:

The Internet Assigned Numbers Authority (IANA) also currently has
the
following second level domain names reserved which can be used as
examples.

So to summarize, if the IESG were saying that this phrasing forms a
policy that all technical specifications MUST only use the domains
from RFC 2606 - not that it is, but if it were, it would seem odd
that the outcome would be that the IESG would recommend the second
level domains in Section 3, rather than the TLD which seems to have
been more strongly recommended in the consensus backed document that
the IESG would be citing.

But that's not the point here, really - there is no such documented
policy, and the policy we don't have is quite clearly not specified
in the BCP that doesn't define it. At best, the BCP which does not
define the policy we don't have suggests a different policy we don't
have either would be a better policy to have, yet this alternate
policy is not, as far as I can tell, what the community would
generally want - so it's actually quite lucky that neither policy the
BCP doesn't define actually exists.

I hope that's clearer now.

Dave.
--
Dave Cridland - mailto:***@cridland.net - xmpp:***@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Debbie Garside
2008-06-18 20:53:18 UTC
Permalink
Maybe I and a few others thought a BCP was worth something. Apparently not.
Unlike the authors of these documents I am not privy to the reasoning behind
them I am just privy to the document itself. Neither are countless other
people who observe IETF BCP's. Perhaps I should not bother recommending BCP
47 (full of MAY's and SHOULD's) anymore or indeed contributing to the IETF
LTRU process. It obviously is not worth the digital paper it is printed on.

A sad day for IETF in my book.

My last word.

Best regards

Debbie

> -----Original Message-----
> From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On
> Behalf Of Dave Cridland
> Sent: 18 June 2008 12:28
> To: ***@ictmarketing.co.uk
> Cc: 'John C Klensin'; 'Pete Resnick'; ***@ietf.org; ***@ietf.org
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> On Wed Jun 18 12:02:44 2008, Debbie Garside wrote:
> > Dave wrote:
> >
> > > Even on Wednesdays.
> >
> > Or for purple documents... ;-)
> >
> > I see your point. I do think, assuming it is not already
> documented
> > and further assuming this is the whole point of the appeal,
> that the
> > IESG could create a general policy wrt BCP's.
>
> Well, that is indeed a possibility, but RFC 2606 - the BCP
> involved in this specific case - does not state anywhere that
> people MUST use the domains it reserves in examples.
>
> Therefore, to cover this particular case, such a blanket
> policy would have to be stated such that even vague
> recommendations in BCPs MUST be followed religiously, even if
> the document's author not only doesn't think that was the
> purpose of the document, but clearly states that wasn't the
> reason it's a BCP anyway.
>
> Maybe the policy could also state a Doctrine Of IESG
> Infallibility, and just bypass the entire issue.
>
> Dave.
> --
> Dave Cridland - mailto:***@cridland.net - xmpp:***@dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
>
>
>
John C Klensin
2008-06-19 18:23:47 UTC
Permalink
--On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
<***@ictmarketing.co.uk> wrote:

> Maybe I and a few others thought a BCP was worth something.
> Apparently not. Unlike the authors of these documents I am not
> privy to the reasoning behind them I am just privy to the
> document itself. Neither are countless other people who
> observe IETF BCP's. Perhaps I should not bother recommending
> BCP 47 (full of MAY's and SHOULD's) anymore or indeed
> contributing to the IETF LTRU process. It obviously is not
> worth the digital paper it is printed on.

Debbie,

Please take the time to read the relevant documents, starting
with the full text of the appeal and then the text of "the BCP"
before making comments like this. RFC 2606/BCP32 very clearly
makes the names available for use where authors find them
useful. It does not require them, specify that they SHOULD be
used, or call for a community consensus process to determine the
cases in which they might or might not be used. The author of
that document has commented on this list that nothing else,
especially an implicit requirement, was intended. And no one
else has been able to cite text in RFC2606/BCP32 that imposes a
requirement. But you apparently did not read those notes
either (in addition to not reading the document to which you
claim to be "privy").

The only published requirement for the use of these names is in
the "ID Checklist" (IDNits). That document is not a BCP. It is
not even an IETF consensus documents. It is an IESG statement
about what the IESG intends to look at. And it says "SHOULD
preferably". Traditionally in the IETF, "SHOULD preferably"
is a WG (or author and editor) decision as to whether there are
grounds for doing something other than what the SHOULD
recommends. For the IESG to block a document on that basis
turns a SHOULD into a "MUST unless we choose to grant an
exception". And, in any event, IDNits is not a BCP of any
flavor - there is no evidence of community consensus for
applying IDNits this way.

> A sad day for IETF in my book.

They are always sad days for the IETF when people comment
passionately on documents they haven't read and clearly don't
understand and when they fail to read and consider other
comments in a discussion thread before posting remarks of their
own that could have been informed by those comments.

john
Pete Resnick
2008-06-19 19:22:19 UTC
Permalink
On 6/19/08 at 7:54 PM +0100, Debbie Garside wrote:

>I am more for going with standards rather than finding ways around
>them with MAYs and SHOULDs. If there is a recommendation within a
>standard IMHO it should be followed.
>[...]
>I don't see what the problem is with following BCP's

Please identify ANYWHERE in this BCP (RFC 2606) that says that
anybody MUST, SHOULD, ought to, might want to think about, or
otherwise really really needs to, use these domain names.

Anywhere. Please quote text.

Your repeated statements that you think there is something in that
BCP that "should be followed" indicate that you have not read the BCP.

The BCP registers names so that they can be used if one wants to. It
does not say that they must be used in RFCs. It does not even
recommend their use. It only registers the names.

Perhaps the ISO is different and they don't actually say what they
mean when they write a document. That has not been my experience
reading ISO documents, but perhaps it's because I work in the IETF.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Debbie Garside
2008-06-19 23:26:43 UTC
Permalink
Hi Pete

You should read my original message (17th June) where I talk about BCP's in
general. I am not aware of quoting MAY's and SHOULD's wrt RFC2606 but
rather in general terms - if I have, I apologise for the error. I have been
speaking very generally about BCP's and what I consider to be good practice.

It has been (and still is) my opinion that a BCP should be followed unless
good cause and reasoning is shown to the contrary. Please do not
misinterpret the word "follow" but rather read my view (below) on BCP's
(which is, after all, only my view).

Should we decide for each RFC when, where and if we will follow BCP's?

Perhaps you and John are right... perhaps I don't understand what is going
on. I just follow (and write) standards and for me a BCP is a standard that
should be followed where possible whether the wording is: IT MIGHT BE BEST,
MUST, SHOULD, MAY, or ONLY ON WEDNESDAYS! (I have a great sense of humour
Frank but not on Thursdays or when using my pink mouse ;-)).

Extract of BCP37

2. TLDs for Testing, & Documentation Examples

There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.

It is my understanding that the DISCUSS was put in place because John's RFC
does not follow this BCP for Documentation Examples. Maybe I am wrong but
this is my understanding. The fact that this is a BCP means (for me) that
it does not need a MUST or SHOULD. It *IS* Best Current Practice for
examples in IETF documentation by title alone. Just my humble opinion.


Extract of BCP 9

5. BEST CURRENT PRACTICE (BCP) RFCs

The BCP subseries of the RFC series is designed to be a way to
standardize practices and the results of community deliberations. A
BCP document is subject to the same basic set of procedures as
standards track documents and thus is a vehicle by which the IETF
community can define and ratify the community's best current thinking
on a statement of principle or on what is believed to be the best way
to perform some operations or IETF process function.

The IESG is surely following BCP 9 (and thus not making up their own rules)
and my interpretation of this section on BCP's is that a BCP is the best way
forward (and thus should be "followed") for the use of whatever it documents
- whether it be example domains within RFCs and BCPs or language tags (which
is more my field). Maybe I am wrong on this too. I hope not as I have
spent several years following and contributing to one.

If I was writing an RFC I would follow any damn BCP that the IESG/IETF cares
to put in front of me and I really do not see the problem with that unless
it gets in the way of technical development within the IETF - in which case
I would be highlighting said BCP for an update and informing IESG and ADs
etc. as to why it cannot be followed. This is not the case here IMHO. This
BCP does not infringe upon any technical development and thus there is no
right to appeal (I may have this bit wrong but I am sure I read it somewhere
- doubtless someone will correct me if I have). However, IMHO the case for
a DISCUSS is considered technical because the document does not follow "the
best way to perform" this operation according to a BCP which according to
BCP 9 - which documents the Internet Standards process - is as ratified by
the IETF community and not just the WG and the Author in question.

This is my final final word as I think you have all heard enough on my views
and whilst I am very open to other people's opinions, I have not heard
anything here to change my mind. As my opinion seems to differ from yours
and John's substantially, I obviously have not read the documents properly,
have completely misinterpreted them and completely failed to understand them
for which I, of course, apologise :-)

Best regards

Debbie Garside






> -----Original Message-----
> From: Pete Resnick [mailto:***@qualcomm.com]
> Sent: 19 June 2008 20:22
> To: ***@ictmarketing.co.uk
> Cc: 'John C Klensin'; 'Dave Cridland'; ***@ietf.org; ***@ietf.org
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> <x-flowed>On 6/19/08 at 7:54 PM +0100, Debbie Garside wrote:
>
> >I am more for going with standards rather than finding ways
> around them
> >with MAYs and SHOULDs. If there is a recommendation within
> a standard
> >IMHO it should be followed.
> >[...]
> >I don't see what the problem is with following BCP's
>
> Please identify ANYWHERE in this BCP (RFC 2606) that says
> that anybody MUST, SHOULD, ought to, might want to think
> about, or otherwise really really needs to, use these domain names.
>
> Anywhere. Please quote text.
>
> Your repeated statements that you think there is something in
> that BCP that "should be followed" indicate that you have not
> read the BCP.
>
> The BCP registers names so that they can be used if one wants
> to. It does not say that they must be used in RFCs. It does
> not even recommend their use. It only registers the names.
>
> Perhaps the ISO is different and they don't actually say what
> they mean when they write a document. That has not been my
> experience reading ISO documents, but perhaps it's because I
> work in the IETF.
>
> pr
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax:
> (858)651-1102
>
>
>
>
Debbie Garside
2008-06-19 18:54:19 UTC
Permalink
John

I have read the documents (all of them). I know you have been around a long
time and have a good deal of experience but I have been within IETF
processes for some 5 years now (or maybe more - seems like an eternity) and
am fairly familiar with it.

I still come out on the side of the IESG.

Sorry but we have to agree to differ on this. Nothing personal but probably
due to my ISO experience, I am more for going with standards rather than
finding ways around them with MAYs and SHOULDs. If there is a
recommendation within a standard IMHO it should be followed. This is just
my humble opinion - you are welcome to yours.

I don't see what the problem is with following BCP's or with the IESG
putting a simple DISCUSS (albeit temporarily blocking) on your document
because you have not followed one - whether or not you seem to think it
fits. And, yes, I know that is not what your appeal is about but it does
play a fairly large part nevertheless. You have taken umbridge at a last
minute decision made by the IESG for an aspect that you think is irrelevant
to the document as a whole - editorial in otherwords.

You state that the IESG has provided a statement as to what they intend to
look at and yet you are now arguing the semantics of that statement.

I think as the IESG Chair has just stated, you should trust in your top
level management. I would add, you should tell them when they have been
inconsistent in order that they may learn from the experience and revise
their statements as necessary.

Wrt the author's intention for publishing BCP32, it is irrelevant unless
documented within the BCP itself. We cannot go back to the author for each
BCP or RFC and ask what was the intended use. The document, as with any
standard, has to stand alone.



Best regards

Debbie





> -----Original Message-----
> From: John C Klensin [mailto:john-***@jck.com]
> Sent: 19 June 2008 19:24
> To: ***@ictmarketing.co.uk; 'Dave Cridland'
> Cc: 'Pete Resnick'; ***@ietf.org; ***@ietf.org
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
>
>
> --On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
> <***@ictmarketing.co.uk> wrote:
>
> > Maybe I and a few others thought a BCP was worth something.
> > Apparently not. Unlike the authors of these documents I am
> not privy
> > to the reasoning behind them I am just privy to the
> document itself.
> > Neither are countless other people who observe IETF BCP's.
> Perhaps I
> > should not bother recommending BCP 47 (full of MAY's and SHOULD's)
> > anymore or indeed contributing to the IETF LTRU process.
> It obviously
> > is not worth the digital paper it is printed on.
>
> Debbie,
>
> Please take the time to read the relevant documents, starting
> with the full text of the appeal and then the text of "the BCP"
> before making comments like this. RFC 2606/BCP32 very clearly
> makes the names available for use where authors find them
> useful. It does not require them, specify that they SHOULD
> be used, or call for a community consensus process to
> determine the cases in which they might or might not be used.
> The author of that document has commented on this list that
> nothing else, especially an implicit requirement, was
> intended. And no one else has been able to cite text in
> RFC2606/BCP32 that imposes a
> requirement. But you apparently did not read those notes
> either (in addition to not reading the document to which you
> claim to be "privy").
>
> The only published requirement for the use of these names is
> in the "ID Checklist" (IDNits). That document is not a BCP.
> It is not even an IETF consensus documents. It is an IESG
> statement about what the IESG intends to look at. And it says "SHOULD
> preferably". Traditionally in the IETF, "SHOULD preferably"
> is a WG (or author and editor) decision as to whether there
> are grounds for doing something other than what the SHOULD
> recommends. For the IESG to block a document on that basis
> turns a SHOULD into a "MUST unless we choose to grant an
> exception". And, in any event, IDNits is not a BCP of any
> flavor - there is no evidence of community consensus for
> applying IDNits this way.
>
> > A sad day for IETF in my book.
>
> They are always sad days for the IETF when people comment
> passionately on documents they haven't read and clearly don't
> understand and when they fail to read and consider other
> comments in a discussion thread before posting remarks of
> their own that could have been informed by those comments.
>
> john
>
>
>
>
>
Randy Presuhn
2008-06-20 19:06:41 UTC
Permalink
Hi -

> From: "Debbie Garside" <***@ictmarketing.co.uk>
> To: "'John C Klensin'" <john-***@jck.com>; "'Dave Cridland'" <***@cridland.net>
> Cc: "'Pete Resnick'" <***@qualcomm.com>; <***@ietf.org>; <***@ietf.org>
> Sent: Thursday, June 19, 2008 11:54 AM
> Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
...
> Sorry but we have to agree to differ on this. Nothing personal but probably
> due to my ISO experience, I am more for going with standards rather than
> finding ways around them with MAYs and SHOULDs. If there is a
> recommendation within a standard IMHO it should be followed. This is just
> my humble opinion - you are welcome to yours.
...
> Wrt the author's intention for publishing BCP32, it is irrelevant unless
> documented within the BCP itself. We cannot go back to the author for each
> BCP or RFC and ask what was the intended use. The document, as with any
> standard, has to stand alone.
...

Both these arguments get back to the question of the applicability of
a standard or BCP. Although we are sometimes rather clear on the
scope of applicability for a particular specification, more often things
are more or less deliberately left open ended. Whether it makes
sense to use SNMPv3 as a file transfer protocol (as in RFC 2592)
is left to the user's judgement. The existence of a potentially applicable
BCP or standard doesn't imply that it MUST be used - the WG needs to
investigate it, and then make the engineering decision whether
that specification is the right tool for the job at hand.

Randy
Frank Ellermann
2008-06-19 19:53:31 UTC
Permalink
Debbie Garside wrote:

> I and a few others thought a BCP was worth something. Apparently not.

Please don't panic, nobody said that RFC 2606 or 4646 are "worthless".

This discussion is mainly about some bugs in the DISCUSS "protocol",
and the somewhat unclear status of the IDNITS "specification". That's
about BCP 9 (RFC 2026), not about BCP 32 (RFC 2606), let alone BCP 47.

> BCP 47 (full of MAY's and SHOULD's)

Arguably tons of BCP 14 (RFC 2119) key words might obscure the really
important points, but that's another topic - it is difficult enough to
keep 2026 vs. 2606 apart in this discussion. BTW, working on 2606bis
I stumbled over <http://rfc-editor.org/errata_search.php?rfc=3406>.

> A sad day for IETF in my book.

Well, I thought Dave's jokes were funny, but that's a matter of taste.

The serious question is to what degree the IESG or individual ADs can
de jure or de facto force authors to jump through hoops.

Frank
Robert Elz
2008-06-18 17:59:59 UTC
Permalink
Date: Wed, 18 Jun 2008 12:02:44 +0100
From: "Debbie Garside" <***@ictmarketing.co.uk>
Message-ID: <059901c8d132$d65df170$***@CPQ86763045110>

| I see your point.

I doubt that you do.

| I do think, assuming it is not already documented and
| further assuming this is the whole point of the appeal, that the IESG could
| create a general policy wrt BCP's.

No, you totally fail to understand. The IESG's job is not to create
policies. It is to implement the policies created by the IETF as
a whole. That's kind of the point here, the IESG (or at least one
member of it) seems to want to create a new policy, or is somehow assuming
such a policy has already been created (by someone, it isn't clear who or
how.) That's what I believe John's appeal is really about - the IESG
should not (not now, not ever) be attempting this kind of thing.

| Shouldn't be too onerous. That way
| everyone knows in advance that they should follow a BCP unless they can show
| reasonable cause not to

Not true in general. You also clearly don't know what a BCP is all about.

If you're inferring things from the name, I'd suggest you go back to the
poised/poised95/poisson (whenever it was that these things were created)
mailing list archives, and observe all the discussions about the name, and
what people might incorrectly read into it. We ended up with BCP as a name
largely because no-one was able to suggest anything better.

What those documents are however, is anything for which the IETF desires to
express that there is community consensus behind what is written (whatever
that is), but for which the standards process does not work (in that the
latter requires interoperable implementations, several of them, and some
things - like reserving a domain name - simply do not allow multiple
interoperable implementations.)

In this case, 2606 is a BCP merely to show (as its author stated a few days
ago) that there was community consensus to remove from allocation to "normal"
people/organisations a few particular domain names - that is, to convince
IANA to make that reservation.

That's it.

Having achieved that objective, I guess 2606 could now be made historic.

There neither is, was, or ever should be, any implication that anyone
necessarily should ever use those names for anything. Of course,
in many situations using them makes sense. In some it is a very very
intelligent thing to do (for example if you're distributing a sample
configuration file and you need to show the configuration to attach to
a particular (end user supplied) server, using server.example.com as the
domain name in the sample configuration would be a very wise choice.)
In other cases using those domain names is of no benefit at all, and worse,
may actually create confusion.

Which is the case here isn't really the point - that's already been decided
by both the working group, the previous standard (2881 to which this doc is
a fairly minor revision, if I understand it all correctly) and the IETF
last call processes for both 2881 and 2821bis. The issue is why the IESG
is ignoring the demonstrated will of the IETF.

kre
Frank Ellermann
2008-06-18 18:35:54 UTC
Permalink
Robert Elz wrote:

> The issue is why the IESG is ignoring the demonstrated
> will of the IETF.

Figuring out what the "demonstrated will of the IETF" is
is the job of the IESG, and in the case of an individual
submission such as 2821bis it can be rather tricky.

Somebody *deciding* that using foo.com in 2821bis is "the
demonstrated will of the IETF" needs to be a Chair or the
IESG, and I'd consider to appeal the decision.

Frank
Robert Elz
2008-06-18 18:55:55 UTC
Permalink
Date: Wed, 18 Jun 2008 20:35:54 +0200
From: "Frank Ellermann" <***@xyzzy.claranet.de>
Message-ID: <g3bkep$fjd$***@ger.gmane.org>

| Figuring out what the "demonstrated will of the IETF" is
| is the job of the IESG,

Agreed, that is part of their role.

| and in the case of an individual
| submission such as 2821bis it can be rather tricky.

It can be tricky in any case, I don't really think individual
submissions are that different - in either case, there's a last
call, and the results need to be evaluated.

If, in this case, the reason for the IESG's objection were something
along the lines of "there seems to be a disputed about whether the
domain names used in examples are the correct ones to use, so we
don't see consensus to publish it", that would be fine (it may or
not be debatable, but procedurally fine), and the IETF as a whole would
need to make a decision (using the IESG as arbiter).

But that is not what happened here.

| Somebody *deciding* that using foo.com in 2821bis is "the
| demonstrated will of the IETF"

That was already done for 2821, wasn't it? It is published already
(years ago). This is just a minor update. Only a fool would go
making unnecessary changes to a document meant as a minor update of
an existing doc.

Further, there already was a list call on 2821 bis, wasn't there (I'm
pretty sure I remember seeing it). I don't recall seeing any objections
lodged to the examples.

kre
Frank Ellermann
2008-06-18 21:01:44 UTC
Permalink
Robert Elz wrote:

[general procedural considerations:]
> It can be tricky in any case, I don't really think individual
> submissions are that different - in either case, there's a
> last call, and the results need to be evaluated.

A WG is an additional layer to sort out conflicts, with Chairs
deciding what the WG "consensus" is, with a WGLC, and editors
expected to mirror the "consensus" in WG drafts. Most issues
are solved before the short two weeks IETF Last Call.

An individual draft has authors, not editors, it reflects what
the authors think. Backed by a sponsoring AD when it goes to
a long four weeks IETF Last Call. There was no opportunity to
appeal controversial WG Chair decisions for non-WG drafts, it
is an informal procedure until somebody triggers the "PubReq".

>From my POV that is a rather important procedural difference -
"if" there are controversial points. But there are always nits
where some folks (including the authors) are not exactly happy
with the outcome.

[for the specific 2821bis case:]
> "there seems to be a disputed about whether the domain names
> used in examples are the correct ones to use, so we don't
> see consensus to publish it", that would be fine (it may or
> not be debatable, but procedurally fine), and the IETF as a
> whole would need to make a decision (using the IESG as
> arbiter).

The topic was debated at different times in the making of 5821,
back in 2005, and again in 2007. I expected that this might
hit a wall when 2821bis reaches the IESG, it's a known point
in the idnits "specification". Admittedly this text is no BCP,
but what can we expect, we have a semi-obsolete RFC 2026, an
expired semi-official 2231bis, an old IETF marauders map still
talking about the old Tao, etc. Most IETF procedures are in
constant flux and different states of decay.

[decision about foo.com]
> That was already done for 2821, wasn't it?

Seven years ago for 2821, time moves on. There wouldn't be a
2821bis if 2821 was perfect (it wasn't, the errata are rather
incomplete, nobody bothered to update them after the work on
2821bis started, and besides the errata procedure didn't work
as it should in 2005..2006).

It is no secret that RFC 2821 kind of missed some points wrt
spam by the diameter of the universe.

> This is just a minor update.

This will be one of the top ten RFCs in any decent list I care
about. I never supported "minor update" theories for 2821bis.

And the post-2nd Last Call 2821bis debate consisted of about
as much messages as fifty ordinary IETF Last Calls together.
None of them about "example addresses", in relation to other
SMTP questions this is just too irrelevant.

Frank
Dave Cridland
2008-06-18 10:39:01 UTC
Permalink
On Tue Jun 17 15:50:02 2008, Debbie Garside wrote:
> Not being a expert on this but having briefly read the documents in
> question, I agree with Brian. This is not editorial.

Well, people have commented that changing the examples will hardly
break the Internet mail system, so it seems reasonable to assert that
the counter-argument is also true. In other words, NOT changing the
examples will also not break Internet mail. However, I couldn't
really care what the examples say, as long as they're good, clear
examples, and I think they are.

> I would also add that
> to go against an IETF BCP

Ah, wait - the document in question is not a missive from the mount
stating "Thou SHALT use example.net everywhere", it says "The IETF
said, 'Let there be reserved domain names for examples'; and there
were."

(I'm translating the documents into language more suitable for the
religious tracts some people appear to think they are - at this rate,
I'm fully expecting future editions to include marginalia comencing
"Once, a student asked the Postel ...")

But the facts are that nobody is "going against" the BCP. The
examples in the document don't take advantage of the facilities
provided by the BCP, but that's different.

> on the grounds of "well we have done so already
> historically" does not make an argument for continuing to do so;

Perhaps your implication that, irrespective of the past behaviour, we
should create such a rule is sensible...

> errors
> should be corrected when found, not endorsed.

... but until we do, it is not an error, and - crucially - we should
not expect nor allow the IESG to decide on a whim what is and is not
an error.

> If we are to pick and choose
> which RFC's/BCP's we will take notice of what is the point of
> standardization?

Well, indeed, bravo, and well spoken - that's what John's appeal is
about - what's the point of having procedures and policies at all if
the IESG can say "I must reject your document; it is purple. No
purple documents on Wednesdays, for lo, I have spoken."

You may think I'm making light of this - and I am, because I think
it's a remarkably silly stance from the IESG - but if you can explain
the difference between rejecting all purple documents on Wednesdays
and rejecting documents that do not use RFC 2606, I'll be most
grateful.

> On the face of things, and with my little knowledge, I
> would say that the person within the IESG who has invoked the
> DISCUSS is
> quite correct.
>
>
And I reckon they're talking bananas.

It doesn't matter, incidentally, whether you consider the use of
example.com to be a good idea or not. I do, although I note that the
XSF's tradition of using a fictional ".lit" TLD with example domains
taken from Shakespeare's plays is actually considerably more
readable, but anyway, I'd be perfectly happy if the IESG made a
statement that as of now, documents which use domains other than
those present in RFC 2606 will not be acceptable.

But I note that there is no such statement from the IESG, so I'm
personally not clear about whether there even is such a policy, or
upon which days of the week it applies - for all I know, given the
lack of statements made by the IESG on RFC 2606 names, these may be
mandated only for purple documents submitted on Wednesdays. And those
aren't allowed, as previously discussed. (And yeah, I know, but
consider this - if I say that the IESG say that purple documents are
not allowed on Wednesdays, that gives that equal weight with the
alledged RFC 2606 rule - the IESG has not made any statement, we've
only heard about this informally via third parties).

What matters here is whether the IESG is allowed to introduce and
enforce a rule with the same action. I do not believe they should be
allowed to.

Even on Wednesdays.

Dave.
--
Dave Cridland - mailto:***@cridland.net - xmpp:***@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Robert Elz
2008-06-17 18:49:42 UTC
Permalink
Date: Tue, 17 Jun 2008 15:50:02 +0100
From: "Debbie Garside" <***@ictmarketing.co.uk>
Message-ID: <049b01c8d089$6c901ce0$***@CPQ86763045110>

| I would also add that to go against an IETF BCP

Huh? The BCP in question says (in a bit more eloquent form)
"Here are some domain names that are reserved from all normal use,
and so are suitable for use in places where something with the
syntax of a valid domain names is required, but no real domain
name should be used - use them where applicable".

It does not say "you must use these domain names" (for any purpose
at all).

Where's the "go against an IETF BCP" here?

kre
Eastlake III Donald-LDE008
2008-06-17 19:08:25 UTC
Permalink
The reason that RFC 2606 was made a BCP was that, at the time, it was
felt that a document with that level or approval was needed to reserve
domain names in the global Internet. Alternatively, it could have been
done with a standards track document, but that seemed inappropriate.

As has been stated, there is nothing in RFC 2606 constraining IETF
documents.

Donald
Author of RFC 2602

-----Original Message-----
From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On Behalf Of
Robert Elz
Sent: Tuesday, June 17, 2008 2:50 PM
To: ***@ictmarketing.co.uk
Cc: ***@ietf.org; ***@ietf.org
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis

Date: Tue, 17 Jun 2008 15:50:02 +0100
From: "Debbie Garside" <***@ictmarketing.co.uk>
Message-ID: <049b01c8d089$6c901ce0$***@CPQ86763045110>

| I would also add that to go against an IETF BCP

Huh? The BCP in question says (in a bit more eloquent form)
"Here are some domain names that are reserved from all normal use,
and so are suitable for use in places where something with the
syntax of a valid domain names is required, but no real domain
name should be used - use them where applicable".

It does not say "you must use these domain names" (for any purpose
at all).

Where's the "go against an IETF BCP" here?

kre
TSG
2008-06-17 21:29:05 UTC
Permalink
Uh, Folks
DOMAIN NAMES cannot be reserved in that manner and this lawsuit from the US
District Court says so.
http://www.domainnamenews.com/wp-content/uploads/2008/06/express-media-express-corp-nd-ca.pdf

That's not going to fly. DOMAIN NAMES are IP and need to be registered as
TM's to protect them. If you want these domains to be protected and reserved
then register them and pay the filing and maintenance fees on them.

Todd Glassey
----- Original Message -----
From: "Robert Elz" <***@munnari.OZ.AU>
To: <***@ictmarketing.co.uk>
Cc: <***@ietf.org>; <***@ietf.org>
Sent: Tuesday, June 17, 2008 10:49 AM
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis


> Date: Tue, 17 Jun 2008 15:50:02 +0100
> From: "Debbie Garside" <***@ictmarketing.co.uk>
> Message-ID: <049b01c8d089$6c901ce0$***@CPQ86763045110>
>
> | I would also add that to go against an IETF BCP
>
> Huh? The BCP in question says (in a bit more eloquent form)
> "Here are some domain names that are reserved from all normal use,
> and so are suitable for use in places where something with the
> syntax of a valid domain names is required, but no real domain
> name should be used - use them where applicable".
>
> It does not say "you must use these domain names" (for any purpose
> at all).
>
> Where's the "go against an IETF BCP" here?
>
> kre
>
>
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Debbie Garside
2008-06-17 19:23:54 UTC
Permalink
It is a matter of interpretation. What does BCP stand for within IETF? ;-)

But seriously, Best Common Practise, IMHO, means, follow this unless you
have a damn good reason not to and if you have that damn good reason then
ask for the BCP to be updated. Just my interpretation.

Best regards

Debbie

> -----Original Message-----
> From: ***@munnari.OZ.AU [mailto:***@munnari.OZ.AU]
> Sent: 17 June 2008 19:50
> To: ***@ictmarketing.co.uk
> Cc: ***@ietf.org; ***@ietf.org
> Subject: Re: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> Date: Tue, 17 Jun 2008 15:50:02 +0100
> From: "Debbie Garside" <***@ictmarketing.co.uk>
> Message-ID: <049b01c8d089$6c901ce0$***@CPQ86763045110>
>
> | I would also add that to go against an IETF BCP
>
> Huh? The BCP in question says (in a bit more eloquent form)
> "Here are some domain names that are reserved from all normal
> use, and so are suitable for use in places where something
> with the syntax of a valid domain names is required, but no
> real domain name should be used - use them where applicable".
>
> It does not say "you must use these domain names" (for any
> purpose at all).
>
> Where's the "go against an IETF BCP" here?
>
> kre
>
>
>
>
>
>
>
Stephane Bortzmeyer
2008-06-18 14:00:53 UTC
Permalink
[The main issue, in its discussion, and rightly so, is the "futile"
uses of DISCUSS - my favorite example being 2929bis « Domain Name
System (DNS) IANA Considerations », blocked for many months by
iana.org vs. ietf.org. But my message is about the "examples" RFC such
as 2606, 3330, 3849 or 4735.]

On Tue, Jun 17, 2008 at 09:42:18AM +1200,
Brian E Carpenter <***@gmail.com> wrote
a message of 62 lines which said:

> In my opinion that is a source of technical confusion and possibly
> of unwanted traffic.

Yes.

> So I think there is a strong argument that RFC 2606 values SHOULD be
> used whenever reasonably possible.

However, there are many cases where it is not reasonably
possible. Steve Bellovin gave good examples for RFC 2606. RFC 3330 has
similar problems. Only a /24 is reserved which means that, for BGP
tutorials, you need to announce /25s and /26s, with a long prefix in
common, which is pedagogically bad. RFC 3849 has a similar problem,
without even the excuse of address scarcity.

Many people who use IP addresses in documentations do not use RFC 3330
because it is too much to ask the readers to see at a glance the
difference between 192.0.2.1 and 192.0.2.129. They are too similar.

So, I agree with you, a RFC 2119 "SHOULD" is OK, and therefore should
not block the RFC, just trigger a discuss (lowercase, a real discuss,
not a blocking vote).
Frank Ellermann
2008-06-18 18:09:14 UTC
Permalink
Stephane Bortzmeyer wrote:

> my message is about the "examples" RFC such as 2606,
> 3330, 3849 or 4735.

I don't see a plausible way to reference RFC 4735
in 2606bis. The "examples" zoo should get its own
section in Brian's next IETF marauders map - adding
TLH example in the Usefor RFC for NetNews.

> RFC 3330 has similar problems.

There's a 3330bis draft, if you want more example
IPs we could in theory reserve parts of the former
"class E" for this purpose. In practice I think
we're better off with "unreserving" these IPs excl.
255.255.255.255 covered by RFC 1122 (STD 3). See
<http://tools.ietf.org/html/draft-iana-33330bis> +
<http://tools.ietf.org/html/draft-fuller-240space>
+ the RFC 3330 errata for the state of the art.

> I agree with you, a RFC 2119 "SHOULD" is OK

+1 MUST makes no sense, an RFC 2119 RECOMMENDED
matches what "we" (TINW) want. But I think that
boils down to a "judgement call" for all involved
parties (editors, authors, community, Chairs, ADs),
it won't fix the bug(s) in the DISCUSS-"protocol".

Frank
Bob Hinden
2008-06-18 16:44:28 UTC
Permalink
Hi,

Let me see if I understand this.

- This is the specification for SMTP. It's was first used on the
Arpanet.

- It is probably as widely deployed as IP and TCP. Maybe more so.

- It works (e.g., the email discussing this thread was sent via SMTP).

- The IETF is now advancing it to Draft Standard. I assume this means
that we now have enough implementation experience.

- Now the IESG doesn't want to approve it for Draft Standard because
it is using a different set of example domains instead of the official
IETF ones.

Am I the only one who sees the insanity here?

Bob
Ralph Droms
2008-06-18 21:27:46 UTC
Permalink
No, you're not the only one seeing insanity.

- Ralph

On Jun 18, 2008, at Jun 18, 2008,12:44 PM, Bob Hinden wrote:

> Hi,
>
> Let me see if I understand this.
>
> - This is the specification for SMTP. It's was first used on the
> Arpanet.
>
> - It is probably as widely deployed as IP and TCP. Maybe more so.
>
> - It works (e.g., the email discussing this thread was sent via SMTP).
>
> - The IETF is now advancing it to Draft Standard. I assume this means
> that we now have enough implementation experience.
>
> - Now the IESG doesn't want to approve it for Draft Standard because
> it is using a different set of example domains instead of the official
> IETF ones.
>
> Am I the only one who sees the insanity here?
>
> Bob
>
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Spencer Dawkins
2008-06-18 21:48:30 UTC
Permalink
By now, I'm hoping that the IESG has enough public and private feedback on
this topic to do the right thing (whatever that is, and yes, I also have an
opinion about what the IESG should be doing, which I'm not including here).

Do we need to say more? If not, perhaps we could wait for the IESG to
respond, and then do the right thing from our end, if needed.

If we do need to say more, by all means, keep typing...

Thanks,

Spencer


> No, you're not the only one seeing insanity.
>
> - Ralph
>
> On Jun 18, 2008, at Jun 18, 2008,12:44 PM, Bob Hinden wrote:
>
>> Hi,
>>
>> Let me see if I understand this.
>>
>> - This is the specification for SMTP. It's was first used on the
>> Arpanet.
>>
>> - It is probably as widely deployed as IP and TCP. Maybe more so.
>>
>> - It works (e.g., the email discussing this thread was sent via SMTP).
>>
>> - The IETF is now advancing it to Draft Standard. I assume this means
>> that we now have enough implementation experience.
>>
>> - Now the IESG doesn't want to approve it for Draft Standard because
>> it is using a different set of example domains instead of the official
>> IETF ones.
>>
>> Am I the only one who sees the insanity here?
>>
>> Bob
>>
>>
>> _______________________________________________
>> IETF mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Russ Housley
2008-06-19 02:35:59 UTC
Permalink
Bob:

Insanity? I think not. Maybe you made the comment to get me post to
this thread. If so, it worked.

You are missing a few things that I consider to be relevant and important.

- We're talking about rfc2821bis (not RFC 2821 or RFC 821).

- The examples in RFC 821 use different domains from the ones in RFC 2821.

If the document were being advanced to Draft Standard with no changes
at all, then I think it would be unreasonable to anyone ask for a
change to address this issue. However, other changes were deemed
necessary. Given that situation, it seems appropriate to consider
current guidance. This guidance is referenced in the appeal. The I-D
Checklist (IDnits, http://www.ietf.org/ID-Checklist.html), Section 6, says:

Addresses used in examples SHOULD preferably use
fully qualified domain names instead of literal IP
addresses, and preferably use example fqdn's such as
foo.example.com instead of real-world fqdn's.

RFC 2119 has a pretty clear definition of "SHOULD". It says:

This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

This document uses "isif.usc.edu" and "***@isi.edu" as
examples. The authors want to leave these as a tribute to
Jon. Fine. I think the implications of these are well understood.

This document also uses "foo.com", "foo.org", "bar.org", "foo-u.edu",
and "generic.com" in examples. I have not heard anyone offer "valid
reasons" for using them instead of the ones in BCP 37. I have heard
people say that they are not causing harm. That is not the same. We
have seen examples that use real IP addresses and domain names cause
harm. The excessive traffic sent to one NTP server comes to mind.

The IESG has been using DISCUSS positions since before 2003 to remove
real domain names. I'm sure that some have slipped through. A
couple have been pointed out in this thread.

So, Bob, the situation is not as simple as your message might indicate.

Russ

At 12:44 PM 6/18/2008, Bob Hinden wrote:
>Hi,
>
>Let me see if I understand this.
>
>- This is the specification for SMTP. It's was first used on the
>Arpanet.
>
>- It is probably as widely deployed as IP and TCP. Maybe more so.
>
>- It works (e.g., the email discussing this thread was sent via SMTP).
>
>- The IETF is now advancing it to Draft Standard. I assume this means
>that we now have enough implementation experience.
>
>- Now the IESG doesn't want to approve it for Draft Standard because
>it is using a different set of example domains instead of the official
>IETF ones.
>
>Am I the only one who sees the insanity here?
>
>Bob
Russ Housley
2008-06-19 17:50:45 UTC
Permalink
Dave:

I'm not sure I did a wise thing by joining the discussion, but in for
a penny, in for a pound ...

>>- The examples in RFC 821 use different domains from the ones in RFC 2821.
>
>Where are the reports of problems with with that aspect of RFC 2821?
>
>Changes from Proposed to Draft are expected to be for fixing minor,
>actual problems with the specification, and they are quite clearly
>*not* for revisting old issues or playing around with new preferences.

The first hint of this issue surfaces during Last Call. It was one
small paragraph in the SecDir Review, but a casual observation might
have missed it due to the volume of discussion around A and AAAA DNS
records. The SecDir Review said:

- "isif.usc.edu" is used as an example in section 4.3.1. Some of the
examples in the appendices also use non-example hostnames.
Personally, I don't care, the meaning is obvious and inoffensive,
but since some of the examples have been rewritten in terms of
example.com etc, this may have been an oversight.

When I highlighted this paragraph, the document PROTO shepherd
pointed out that the "isif.usc.edu" and "***@isi.edu" were left in
the document as a tribute to Jon. No one has objected to this. This
lead to a discussion of the domain names in the rest of the document.

>>If the document were being advanced to Draft Standard with no
>>changes at all, then I think it would be unreasonable to anyone ask
>>for a change to address this issue. However, other changes were
>>deemed necessary. Given that situation, it seems appropriate to
>>consider current guidance. This guidance is referenced in the
>>appeal. The I-D Checklist (IDnits,
>>http://www.ietf.org/ID-Checklist.html), Section 6, says:
>> Addresses used in examples SHOULD preferably use
>> fully qualified domain names instead of literal IP
>> addresses, and preferably use example fqdn's such as
>> foo.example.com instead of real-world fqdn's.
>
>
>1. When did the nits list gain authoritative control as a source
>directive for normative detail of IETF specification content? I was
>under the impression that it was strictly a compendium of
>requirements from elsewhere.
>
>2. You parsed the sentence incorrectly. The SHOULD applies only to
>the first clause. The second clause notably repeats the
>"preferably" but without the SHOULD. This type of parallel
>constructive is used quite explicitly to set a different context
>between clauses. Hence the second clause is not normative. (The
>term "SHOULD preferably" also suggests some problematic -- or at
>least odd -- writing, given the semantics of the SHOULD.")

Upon detailed study, I see that the paragraph could be more
clear. I've asked the author if he is willing to propose revised
text. Vacation schedules will keep this from happening in the next few days.

>>RFC 2119 has a pretty clear definition of "SHOULD". It says:
>> This word, or the adjective "RECOMMENDED", mean that there
>> may exist valid reasons in particular circumstances to ignore a
>> particular item, but the full implications must be understood and
>> carefully weighed before choosing a different course.
>
>Absent any explanation from you, you appear to be treating SHOULD
>the same as MUST.

I think I provided my thinking in the previous message.

>As John noted, there was extensive Drums wg consideration of this
>topic. This means that your requirement for changing the examples
>seeks to override the explicit considerations of an IETF working group.
>
>If you feel that group was rogue, please explain. If you do not,
>what is the basis for your view that its considerations were
>sufficiently faulty to warrant being overridden?

Prior to the appeal, this aspect of John's rationale was not
raised. It was not raised by John, the document PROTO shepherd, or
the IESG member sponsoring the document.

>And most importantly, why is not of this explanation already
>documented in the tracker?

Since this issue has been use in DISCUSS ballot positions for more
than 5 years, it seems to me like there is adequate context to not
document every step in the though process.

>>This document also uses "foo.com", "foo.org", "bar.org",
>>"foo-u.edu", and "generic.com" in examples. I have not heard
>>anyone offer "valid reasons" for using them instead of the ones in
>>BCP 37. I have heard people say that they are not causing
>>harm. That is not the same. We have seen examples that use real
>>IP addresses and domain names cause harm. The excessive traffic
>>sent to one NTP server comes to mind.
>
>First is the use of "valid", which implies there are arguments
>deemed invalid. Which arguments are you dismissing and why? Since
>the ietf list discussion has seen serious arguments put forward by
>serious and experienced contributors, my question is not merely pro forma.
>
>Second is the logic error that some examples of harm elsewhere are a
>sufficient basis for requiring the current change, independent of
>the *absence* of problems with this heavily-used specification. The
>direct absence of problems constitutes positive data in favor of
>retaining the current text in rfc2821bis.
>
>Why should your indirect negative data override the direct positive data?

You misunderstand my point. RFC 2119 uses "valid" in the definition
of "SHOULD." That is the reason for quote marks in my text.

Prior to the discussion of the appeal on this thread, lack of harm in
this context was not raised. It was not raised by John or the
document PROTO shepherd. This might be a reason to ignore the
"SHOULD." That is a discussion could have happened, but it didn't.

>>The IESG has been using DISCUSS positions since before 2003 to
>>remove real domain names. I'm sure that some have slipped
>>through. A couple have been pointed out in this thread.
>
>Yet, for all of the IETF's formal documentation of technical and
>stylistic requirements, we do not seem to have any community
>consensus document -- and not even an IESG document -- that
>justifies asserting this as a requirement.

That seems to be the crux of the appeal. Does every possible thing
upon which an AD can raise a DISCUSS position need to align with a
written rule? Don't we select leaders because we have some
confidence in their judgement?

Russ
Ted Hardie
2008-06-19 18:33:54 UTC
Permalink
At 10:50 AM -0700 6/19/08, Russ Housley wrote:
>
>That seems to be the crux of the appeal. Does every possible thing
>upon which an AD can raise a DISCUSS position need to align with a
>written rule? Don't we select leaders because we have some
>confidence in their judgement?
>
>Russ

Russ,
This is casting the problem in ways that continue to miss
the point. Of course we expect individual Area Directors to exercise
judgement, and we expect the IESG as a body to do the same.

But we also expect them to exercise due care in listening
to the folks actually doing the work, and not over-rule them when they
clearly have considered the issues. In this case, John's appeal makes
clear that the folks writing the document considered the issue
and made a decision to value continuity. A DISCUSS position
to reconfirm that in light of an Area Director's concerns would
be valid (and probably welcome); once confirmed though, it
should get dropped. Otherwise, it over-rules a community decision
with the individual technical judgement of the Area Director.

There are very few cases where that is okay. It applies when
there is a documented, larger community consensus that the WG or
submission group decision ignores (a working group decision that
congestion control wasn't important would get pushback on this
front, for example). It applies when the Area Director can demonstrate
harm to the Internet as a result of the decision; the "can demonstrate"
there, though, is to the *community* not just to himself or the IESG.
It applies when the Area Director can demonstrate that the proposal
simply *does not work* to the satisfaction of the larger community, no
matter what the proposers believe.

Most DISCUSS don't need to meet any of those tests because
the WGs or proposers agree that the issues need to be addressed, so
there is no over-ride present. That's good, because over-riding the
considered technical judgement of the folks doing the work doesn't
just generate appeals, it drives folks away. The extent to which
the current IESG is sliding back into substituting its technical
judgement for the WGs' is a worrying trend that I've already pointed
out. This appeal may seem to be on a small point in a single
document, but the issue is quite fundamental. The IETF can drive
itself into irrelevance very quickly by appearing to be driven by
ex cathedra pronouncements; even the Pope has done that only
once since his infallibility was declared doctrine. Doing so constantly
over things where the AD's opinion is not backed by community
consensus is currently getting you an appeal. The next step could
well be reformation.

I hope the IESG considers John's appeal in this light
and responds promptly to the issues he has raised.

Ted Hardie
Eliot Lear
2008-06-19 20:32:59 UTC
Permalink
Ted Hardie wrote:
> There are very few cases where that is okay. It applies when
> there is a documented, larger community consensus that the WG or
> submission group decision ignores (a working group decision that
> congestion control wasn't important would get pushback on this
> front, for example). It applies when the Area Director can demonstrate
> harm to the Internet as a result of the decision; the "can demonstrate"
> there, though, is to the *community* not just to himself or the IESG.
> It applies when the Area Director can demonstrate that the proposal
> simply *does not work* to the satisfaction of the larger community, no
> matter what the proposers believe.
>

Isn't the IESG is meant to serve two roles? The first is to be the
arbiter of community consensus. The second is to be a judge on the
quality of the work before them, as to whether it is ready to move
forward. The threat of the IESG saying, "jeez what a {dumb|complex|...}
approach" separates us from other standards organizations (or at least
it did). The most famous example of all of this is still the
ETHERNET-MIB WG where they were upset that Jon Postel reset a counter
size in the final copy of the MIB to match the IEEE specification, and
those folks were rip roaring upset that he did so. I don't want the
IESG to author the docs like Jon did but I do want them to stand in the
way of dumb ideas.

In this case they should be there to apply our *evolving* standards. To
hogtie those folk to me just begs for others to attempt to make use of
those knots to get their dumb standards.

Shouldn't the response to John's appeal demonstrate the balance between
their two roles?

Eliot
Ted Hardie
2008-06-19 21:57:47 UTC
Permalink
At 1:32 PM -0700 6/19/08, Eliot Lear wrote:
>
>Isn't the IESG is meant to serve two roles? The first is to be the
>arbiter of community consensus. The second is to be a judge on the
>quality of the work before them, as to whether it is ready to move
>forward.

The IESG is not meant to over-ride the community consensus for
specific technical choices without reason. It needs to show *why*
it is over-riding a specific technical choice in a way that references
existing consensus, technical correctness, or the health of the
Internet. Saying "I don't like the way you have done it, do it
my way" is not their job, and the existing "discuss criteria" document
tries to make that clear.

This is not about an overall judgement that a doc is not ready;
this is about over-riding the informed technical judgement of
the people who are doing the work.



> The threat of the IESG saying, "jeez what a {dumb|complex|...}
>approach" separates us from other standards organizations (or at least
>it did). The most famous example of all of this is still the
>ETHERNET-MIB WG where they were upset that Jon Postel reset a counter
>size in the final copy of the MIB to match the IEEE specification, and
>those folks were rip roaring upset that he did so. I don't want the
>IESG to author the docs like Jon did but I do want them to stand in the
>way of dumb ideas.
>
>In this case they should be there to apply our *evolving* standards. To
>hogtie those folk to me just begs for others to attempt to make use of
>those knots to get their dumb standards.
>
>Shouldn't the response to John's appeal demonstrate the balance between
>their two roles?

I look forward to seeing what it demonstrates.
Ted



>Eliot
Robert Elz
2008-06-19 22:13:15 UTC
Permalink
Date: Thu, 19 Jun 2008 22:32:59 +0200
From: Eliot Lear <***@cisco.com>
Message-ID: <***@cisco.com>

| Isn't the IESG is meant to serve two roles?

Yes, but not the two you enumerated. The first, and far and away
most important, is to cause the work to get done - to coordinate the
working groups, help keep out (unwanted) duplicated effort, and somehow
try to cajole people into actually getting things done (etc.)

The second ...

| The first is to be the arbiter of community consensus.

is that one - which really ought to be done by something different, as
asking #1 to do the work, then #2 to judge if the work is done correctly
really is a conflict of interest. But that's not germane to any
current discussion.

| The second is to be a judge on the
| quality of the work before them, as to whether it is ready to move
| forward.

In the sense of whether the WG has reached consensus, yes, but that's
all a part of #1.

In the sense you mean it, no, that's the job of the whole community.

Of course, the IESG members are a part of the community, and are just
as entitled to an opinion as anyone else. Their opinions also carry
the same weight as anyone else's (or anyone else with similar reputation
and experience anyway - there's no expectation that necessarily everyone's
ability is equal).

| I don't want the IESG to author the docs like Jon did but I do
| want them to stand in the way of dumb ideas.

I don't, I want the community as a whole to do that. It is just fine for
an IESG member (or anyone else) to point out that they think a proposal is
deficient in some way, but then the community get to judge whether it
should go forward anyway (whether the objection matters).

The IESG do get to judge the community's opinion (figure out what we're all
saying), but when doing that, they need to do so absent any personal
biases one way or the other.

It always appeals to have someone else we can blame when dumb things happen,
"anyone but me", but that's unreasonable. If poor ideas become codified,
its our fault, not the IESGs, nor is it their responsibility to prevent it.

kre
Russ Housley
2008-06-20 17:14:33 UTC
Permalink
Ted:

First, looking at a diff of RFC 2821 and draft-klensin-rfc2821bis, I
do not find the argument about continuity very questionable. This
document does include some clarification and lessons learned, and it
includes much more too.

RFC 2821 Outline for Sections 1 and 2:

1. Introduction
2. The SMTP Model
2.1 Basic Structure
2.2 The Extension Model
2.2.1 Background
2.2.2 Definition and Registration of Extensions
2.3 Terminology
2.3.1 Mail Objects
2.3.2 Senders and Receivers
2.3.3 Mail Agents and Message Stores
2.3.4 Host
2.3.5 Domain
2.3.6 Buffer and State Table
2.3.7 Lines
2.3.8 Originator, Delivery, Relay, and Gateway Systems
2.3.9 Message Content and Mail Data
2.3.10 Mailbox and Address
2.3.11 Reply
2.4 General Syntax Principles and Transaction Model

draft-klensin-rfc2821bis-10 Outline for Sections 1 and 2:

1 Introduction
1.1 Context and Notes for this Draft
1.2 Mailing List
1.3 Transport of electronic mail
1.4 History and context for this document
2 The SMTP Model
2.1 Basic Structure
2.2 The Extension Model
2.2.1 Background
2.2.2 Definition and Registration of Extensions
2.2.3 Special Issues with Extensions
2.3 Terminology
2.3.1 Mail Objects
2.3.2 Senders and Receivers
2.3.3 Mail Agents and Message Stores
2.3.4 Host
2.3.5 Domain Names
2.3.6 Buffer and State Table
2.3.7 Commands and Replies
2.3.8 Lines
2.3.9 Message Content and Mail Data
2.3.10 Originator, Delivery, Relay, and Gateway Systems
2.3.11 Mailbox and Address
2.4. General Syntax Principles and Transaction Model

Note: Sections 1.1 and 1.2 are to be deleted prior to publication of
the document as an RFC.

I am not saying that any of the changes are inappropriate, but that
it is hard to claim that the changes are minimal.

Second, from my perspective, the dialogue about this document did not
happen as you suggest.

The issue was first raised in the SecDir Review during IETF Last
Call. The text from that SecDir Review was included in my note on
this thread in response to Dave Crocker. When I highlighted this
paragraph, the document PROTO shepherd pointed out that the
"isif.usc.edu" and "***@isi.edu" were left in the document as a
tribute to Jon. No one has objected to this. This lead to a
discussion of the domain names in the rest of the document.

At least three ADs believe that the examples should be changed, and
they have comments in the Data Tracker that clearly indicate this
position. Others feel that the examples out to be changed, but do
not consider it important enough to delay the document.

We are no having a debate to determine the community consensus on
this topic. In addition to the people that are speaking publicly on
this thread, I am receiving a fair number of private messages. Some
are supportive of the appeal position and others are not. Judging
community consensus in such a situation is somewhat difficult. I
have suggested to the IESG a way to determine the community consensus
in this case, and I am waiting to hear if other ADs think it is a
good idea or not.

Russ

At 02:33 PM 6/19/2008, Ted Hardie wrote:
>At 10:50 AM -0700 6/19/08, Russ Housley wrote:
> >
> >That seems to be the crux of the appeal. Does every possible thing
> >upon which an AD can raise a DISCUSS position need to align with a
> >written rule? Don't we select leaders because we have some
> >confidence in their judgement?
> >
> >Russ
>
>Russ,
> This is casting the problem in ways that continue to miss
>the point. Of course we expect individual Area Directors to exercise
>judgement, and we expect the IESG as a body to do the same.
>
> But we also expect them to exercise due care in listening
>to the folks actually doing the work, and not over-rule them when they
>clearly have considered the issues. In this case, John's appeal makes
>clear that the folks writing the document considered the issue
>and made a decision to value continuity. A DISCUSS position
>to reconfirm that in light of an Area Director's concerns would
>be valid (and probably welcome); once confirmed though, it
>should get dropped. Otherwise, it over-rules a community decision
>with the individual technical judgement of the Area Director.
>
> There are very few cases where that is okay. It applies when
>there is a documented, larger community consensus that the WG or
>submission group decision ignores (a working group decision that
>congestion control wasn't important would get pushback on this
>front, for example). It applies when the Area Director can demonstrate
>harm to the Internet as a result of the decision; the "can demonstrate"
>there, though, is to the *community* not just to himself or the IESG.
>It applies when the Area Director can demonstrate that the proposal
>simply *does not work* to the satisfaction of the larger community, no
>matter what the proposers believe.
>
> Most DISCUSS don't need to meet any of those tests because
>the WGs or proposers agree that the issues need to be addressed, so
>there is no over-ride present. That's good, because over-riding the
>considered technical judgement of the folks doing the work doesn't
>just generate appeals, it drives folks away. The extent to which
>the current IESG is sliding back into substituting its technical
>judgement for the WGs' is a worrying trend that I've already pointed
>out. This appeal may seem to be on a small point in a single
>document, but the issue is quite fundamental. The IETF can drive
>itself into irrelevance very quickly by appearing to be driven by
>ex cathedra pronouncements; even the Pope has done that only
>once since his infallibility was declared doctrine. Doing so constantly
>over things where the AD's opinion is not backed by community
>consensus is currently getting you an appeal. The next step could
>well be reformation.
>
> I hope the IESG considers John's appeal in this light
>and responds promptly to the issues he has raised.
>
> Ted Hardie
>
>
Dave Cridland
2008-06-23 10:19:54 UTC
Permalink
On Fri Jun 20 18:14:33 2008, Russ Housley wrote:
> First, looking at a diff of RFC 2821 and draft-klensin-rfc2821bis,
> I do not find the argument about continuity very questionable.
> This document does include some clarification and lessons learned,
> and it includes much more too.

Your first sentence contains a freudian slip, I think.

But so people can sing along at home:

http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-10.txt&url1=http://tools.ietf.org/rfc/rfc2821.txt

> I am not saying that any of the changes are inappropriate, but that
> it is hard to claim that the changes are minimal.

I think it's a demonstrably easy claim to make:

Important to note is that the only new domain introduced by the
document is an example.com one (a change in section 4.3.1 of both
documents).

This also represents one of four cases where the examples or
explanatory text surrounding them were changed at all. The others
were:

Section 4.1.1.3, the word "appendix" was capitalized to "Appendix" in
one paragraph, and another paragraph was (very) slightly reworded.
(Removal of "Of course", and captilization of "MAY"). I'm not sure
this counts at all, but it's offered as a straw for the IESG to
clutch at.

Appendix D.3, the example was reworked to change from a source route
relay to an MX lookup - this is a comparitively major change, but
note from the diff that essentially it's adding some explanatory
text, and then changing the MAIL FROM lines - nothing else in the
examples is changed.

Finally, Appendix D.4 corrects an error - it's a single word change
from SEND to MAIL.

I don't think it would be at all fair to claim that the changes to
the examples - which is the significant item here - are anything but
minimal, and it's quite obvious to me as to why this is the case.

Examples, and particularly changing them, is a tough thing to get
right in application protocols. By my own experience, I tend to find
that my own example mismatch the text in early stages (and that often
leaks through to late stages); changing examples can often lead to
mismatches between discussion and example, for example if xyz.com and
foo.com were inconsistently changed to example.com and example.net;
and finally I see broken examples in the documents I review.

This is of special concern because whilst we publically chastise
implementors for only reading the examples, the fact remains that
most of us certainly rely on the examples for getting the jist of a
protocol, and turn to the rest of the text afterward, having formed
our preconceptions nice and early on.

Moving back from the general to the specific, then, it's important to
note that the examples are therefore substantially unchanged from
those which DRUMS WG carefully weighed and understood the full
implications thereof.

I'd note, as an aside, that whilst it could be argued that
ID-Checklist has a SHOULD which covers the later part of the sentence
and therefore SHOULDs the RFC 2606 names, the ID-Checklist does not
itself specify that SHOULD is to be interpreted using RFC 2119, and
therefore arguably doesn't even say SHOULD, as such.

It'd be fairly petty to argue this as a significant point, but I hope
that even if this and the (rather more serious) odd phrasing in the
ID-Checklist is overlooked, the resultant argument - that rfc2821bis
ignores a SHOULD - is essentially baseless, as the examples in
question were substantially the result of heavy consideration from a
working group, and have been previously accepted by the IESG.

> Second, from my perspective, the dialogue about this document did
> not happen as you suggest.

And that's a fine explanation of why the situation has arisen, but it
doesn't (or shouldn't) affect the outcome of the appeal - I'd have
thought that one of the great benefits of an appeal is that more
information is made available to the IESG so as to enable them to
correct a bad decision or confirm a good one. It's unfortunate that
appeals are sometimes perceived as a way to slap wrists.

Appeals are, surely, meant as a mechanism for the community to say:

Are you really sure you want to go down this route, because it looks
to me like there's stuff you've missed, and/or you've not thought
this through, and I'd like you to carefully reconsider.

In another message, you state: "Don't we select leaders because we
have some confidence in their judgement?" - we do, of course, select
them because we think they'll be right the majority of the time, and
willing to accept when they're wrong, too.

Dave.
--
Dave Cridland - mailto:***@cridland.net - xmpp:***@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Stewart Bryant
2008-06-25 09:47:28 UTC
Permalink
>
> At least three ADs believe that the examples should be changed
>

I agree with them.

Use of any identifier outside the example space may cause real harm to
the owner, where that harm may range from serious harm (technical
and/or financial) to mild embarrassment.

If anyone wants to use an identifier outside the example space, then to
protect both the owner of the identifier and the IETF, the author really
needs to provide the IETF with evidence of written authorization to use
it for this purpose.

In the case of this draft, have the owners of the identifiers
been contacted by the author, and do they agree to this use?

Stewart
Julian Reschke
2008-06-25 10:01:03 UTC
Permalink
Stewart Bryant wrote:
>
>>
>> At least three ADs believe that the examples should be changed
>>
>
> I agree with them.
>
> Use of any identifier outside the example space may cause real harm to
> the owner, where that harm may range from serious harm (technical
> and/or financial) to mild embarrassment.
>
> If anyone wants to use an identifier outside the example space, then to
> protect both the owner of the identifier and the IETF, the author really
> needs to provide the IETF with evidence of written authorization to use
> it for this purpose.
>
> In the case of this draft, have the owners of the identifiers
> been contacted by the author, and do they agree to this use?

You are aware that the same examples have been in a published RFC for
over seven years?

BR, Julian
Spencer Dawkins
2008-06-25 12:49:43 UTC
Permalink
>> Use of any identifier outside the example space may cause real harm to
>> the owner, where that harm may range from serious harm (technical
>> and/or financial) to mild embarrassment.
>>
>> If anyone wants to use an identifier outside the example space, then to
>> protect both the owner of the identifier and the IETF, the author really
>> needs to provide the IETF with evidence of written authorization to use
>> it for this purpose.
>>
>> In the case of this draft, have the owners of the identifiers
>> been contacted by the author, and do they agree to this use?
>
> You are aware that the same examples have been in a published RFC for over
> seven years?

Because this point keeps getting overlooked, it's worth saying "... a
published STANDARDS-TRACK RFC ...".

But, whatever. My suggestion is to stop posting in this thread and let the
IESG do what they need to do, now that they have an appeal in hand. We're
just distracting them and inflaming the community at this point.

They are actively discussing the topic, not just the appeal. From the most
recent IESG telechat minutes:
6.2 IESG Statement on BCP 32 (Russ Housley)

The management issue was discussed.

Action Item: Magnus Westerlund to draft an IESG Statement on BCP 32.

(taken from https://datatracker.ietf.org/iesg/telechat/391/)

Jari has split off a new thread on "Measuring IETF and IESG trends" -
obviously, that's not the kind of "posting in this thread" I'm hoping to
discourage.

Thanks,

Spencer
John Levine
2008-06-25 14:40:39 UTC
Permalink
>In the case of this draft, have the owners of the identifiers
>been contacted by the author, and do they agree to this use?

Perhaps you might want to compare the draft with RFC 2821, which was
published over seven years ago, and then reconsider the question.

Regards,
John Levine, ***@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

PS: Anyone know offhand the RFC for IP-over-Ouija-board?
SM
2008-06-20 06:39:44 UTC
Permalink
At 10:50 19-06-2008, Russ Housley wrote:
>That seems to be the crux of the appeal. Does every possible thing
>upon which an AD can raise a DISCUSS position need to align with a
>written rule? Don't we select leaders because we have some
>confidence in their judgement?

A process gets constrained if we have to go by written rules
only. However, without such rules one has to resort to second
guessing to determine what the rules might be. Written rules are a
way to set the expectations and bring in openness and fairness into
the process. The decision-making process is hampered if the rules
are too rigid. That's why guiding principles are defined.

By selecting leaders, we are demonstrating confidence in them. As in
any process, disputes may arise. Sometimes, a person might not agree
with a particular decision. The person may ask the leaders to review
their decision.

Appeals are there for a purpose. It provides a recourse if the
person is not satisfied with a judgement. Some may view it as a
process failure. Others may read it as a motion of no confidence in
the judgement of the leaders. It is better to hear both sides of the
argument instead of jumping to hasty conclusions. Whether it is in a
Working Group discussion, on a Last Call or anywhere throughout the
process, there are bound to be differences of opinion. Sometimes
this entails challenging current dogma or some higher
authority. This is after all a battleground of ideas which are
judged on their technical merits.

Regards,
-sm
Russ Housley
2008-06-23 18:19:26 UTC
Permalink
Dave:

>>>If you feel that group was rogue, please explain. If you do not,
>>>what is the basis for your view that its considerations were
>>>sufficiently faulty to warrant being overridden?
>>Prior to the appeal, this aspect of John's rationale was not
>>raised. It was not raised by John, the document PROTO shepherd, or
>>the IESG member sponsoring the document.
>
>Again, I hope we do not find ourselves in a he said/no he didn't
>exchange. I'll
>merely suggest that had the Discuss been immediately taken to the
>public mailing
>list, it seems pretty likely that salient details would quickly have been put
>forward.

This is an individual submission, not a WG document. So, there is no
charter that lists the appropriate mail list for such a
discussion. That said, John did take the issue to a mail list. I
know this because someone forward his posting to me. John did not CC
me on the posting, which I interpret as not seeking dialogue at that point.

Russ
John C Klensin
2008-06-23 19:59:41 UTC
Permalink
--On Monday, 23 June, 2008 14:19 -0400 Russ Housley
<***@vigilsec.com> wrote:

> Dave:
>
>>>> If you feel that group was rogue, please explain. If you
>>>> do not, what is the basis for your view that its
>>>> considerations were sufficiently faulty to warrant being
>>>> overridden?
>>> Prior to the appeal, this aspect of John's rationale was not
>>> raised. It was not raised by John, the document PROTO
>>> shepherd, or the IESG member sponsoring the document.
>>
>> Again, I hope we do not find ourselves in a he said/no he
>> didn't exchange. I'll
>> merely suggest that had the Discuss been immediately taken to
>> the public mailing
>> list, it seems pretty likely that salient details would
>> quickly have been put forward.
>
> This is an individual submission, not a WG document. So,
> there is no charter that lists the appropriate mail list for
> such a discussion. That said, John did take the issue to a
> mail list. I know this because someone forward his posting to
> me. John did not CC me on the posting, which I interpret as
> not seeking dialogue at that point.

Russ, that note was sent to the mailing list after I received
your "change the document or appeal" note. I believed that
note from you closed the door on any further dialogue with you
(or the IESG). The note to the SMTP list was simply to collect
opinions on which of the two choices you gave me to adopt.

If you intended the "change the document or appeal" note to be
interpreted in any other way, I apologize for not copying you on
the question to the list, but I really could not figure out any
other way to read it (and cannot to this day).

best,
john
Russ Housley
2008-06-23 20:11:32 UTC
Permalink
John:

>Russ, that note was sent to the mailing list after I received
>your "change the document or appeal" note. I believed that
>note from you closed the door on any further dialogue with you
>(or the IESG). The note to the SMTP list was simply to collect
>opinions on which of the two choices you gave me to adopt.
>
>If you intended the "change the document or appeal" note to be
>interpreted in any other way, I apologize for not copying you on
>the question to the list, but I really could not figure out any
>other way to read it (and cannot to this day).

That was in response you your note that said I needed to change my
position from DISCUSS to COMMENT or you would appeal. I was simply
confirming the position that we had reached. That position is now
clear to all.

Russ
Russ Housley
2008-06-24 22:24:20 UTC
Permalink
I'm sorry for the way that this discussion has gone. I joined the
discussion in order to let the whole community see both sides of the
disagreement. However, in an attempt to provide clarity and correct
inaccurate statements, the discussion turned into tit for tat. The
back-and-forth banter did not help any of the people that wanted to
understand the issues or context for the disagreement. For my part
in that situation, I apologize. I'll try very hard to not repeat my
mistakes in the future.

As Chair of the IESG, I am going to do my best to find ways to reduce
the number of late surprises. This is in line with the goal that I
set when I took on this position: incremental improvement to the IETF
standards process.

The I-D Tracker and the way that IESG ballot positions are used is at
the center of the issues raised by this appeal. The I-D Tracker was
built with two goals in mind. First, it was intended to increase
transparency. Second, it was intended to help ADs manage the
document review and approval process. The first goal seems to have
been achieved to a greater degree than I ever realized. As a result,
IESG members now find themselves being asked to explain processes
that were previously invisible to the community. As such, I think it
is time to consider whether the IESG ballot structure needs
revision. The ballot was designed for ADs and the Secretariat; it
tells whether a document is ready for approval. Today, it appears
that we also need a ballot that tells the document authors, WG
chairs, and PROTO shepherds what actions are needed to move a document forward.

At this point I cannot give any explicit actions that will be taken,
I sincerely hope that the handling of this appeal will provide
insights for the next steps. I think it is time to let the IESG
process the appeal.

All the best,
Russ
Russ Housley
2008-06-23 15:35:02 UTC
Permalink
John:

>As others have pointed out, you are missing the _only_ thing
>that I consider to be really important. In addition, we
>disagree about some of the details as you have presented them.
>You can consider this note an addendum to the appeal text if you
>like.
>
>The first issue is that, as several others have pointed out, the
>key issue in the appeal isn't about the 2606 names, it is about
>what I believe to be abuse of process and authority.
>
>Regardless of what actually made it into documents, there was
>very clear consensus in POISSON, in NEWTRK, and in the PESCI
>effort, which is that the community is opposed to imposition of
>new requirements on documents after Last Call and by the IESG
>during IESG review. There was also clear consensus that the
>community considers such actions, and the frustration and delays
>they introduce, harmful to the Standards process and
>inconsistent with a fair and open process.

I agree with this principle. In fact, I think that the IESG has
taken many steps over the last four or more years to reduce the
nearly-end-of-process surprises. Obviously, you do not think these
measures have been sufficient. One lesson from the many attempts to
make updates to RFC 2026 is that such policy documents needs to set
expectations without taking away flexibility and judgement.

>While that community consensus has never appeared explicitly in
>a BCP or other document with equivalent force, it is nonetheless
>clear to many of us. One reason it has not appeared is that it
>would be hard, or impossible, to write a specific and
>appropriate rule where _technical_ issues are involved:
>sometimes, one comes up late in the process and sometimes it is
>legitimate and worth attention to the point of blocking a
>document. Even in those cases, the community has seemed to
>feel quite strongly that everything reasonable should be done to
>avoid the issues showing up only because an AD raises them after
>last call. For an essentially stylistic or documentary issue,
>it appears to me that there is no excuse for continued late
>actions and assertions of rules, even if those rules were
>reasonable.
>
>Your own discussions of this topic, both before and after the
>appeal was filed, reinforce the view that this is not a
>technical issue or, to paraphrase Brian's early comment, a
>judgment call about the likelihood of confusion. There is no
>issue of confusion here. Others have made the point that the
>claim of harm is, at best, dubious.
>
>The fact that the IESG has done something before, even regularly
>before, does not make raising the issue after Last Call any less
>"new", unless you actually believe that it is the responsibility
>of every author, editor, or WG in the community to study
>previous IESG decisions, deduce patterns from them, and then
>infer the rules that are to be followed. I don't think that
>position is tenable with regard to previous community
>discussions about "late surprises". I also take the existence
>of extensive guidelines and checklists as an indication that the
>IESG doesn't believe it either, but perhaps you disagree.

As you said in your note, we disagree on the details. I have
forwarded the text to the list that shows that the issue was raised
during IETF Last Call. Meaning, it was not a late surprise.

I agree that the community should not have to watch IESG decisions to
infer trends. In this case, the ID Checklist already includes a
SHOULD statement. It could be more clear. More about that below.

>In that context, there were at least two ways that this appeal
>could have been avoided. I tried to be explicit about both:
>
> (i) Had the blocking DISCUSS been removed and changed to
> a comment, I would have reviewed the names in the
> document with the mailing list and, unless they
> objected, changed most or all of them. My objection is
> primarily to the blocking DISCUSS itself, although I'll
> review the issue with the specific names below.

Yes, you made this offer. You said that the DISCUSS needed to be
change to a COMMENT or you would appeal. Instead, I rewrote my
DISCUSS position to be clear that the domain names associated with
the tribute to Jon were not included in the DISCUSS position. The
Data Tracker clearly shows this part of the history.

> (ii) Had you or the IESG said "yes, it is inappropriate
> for us to insist on a blocking requirement for the 2606
> names without documenting that fact, we will change,
> e.g., the 'I-D Checklist' to clearly indicate that they
> are required in the absence of an explicit IESG waiver",
> then we would not be having this discussion at all. We
> might well be having a discussion about whether that
> change to the I-D Checklist rules was appropriate, but
> that is exactly the discussion, IMO, that we should be
> having. Instead, it appears from where I sit that the
> IESG generally, and you in particular, have chosen to
> impose the rule but avoid a community discussion of
> whether that rule is appropriate by keeping the rule
> --as a blocking issue, rather than a preference to be
> interpreted by authors, editors, and WGs/ mailing
> lists-- secret. And that is _exactly_ what years of
> discussion about process have told the IESG to not do.

I believe this action was taken. First, Magnus Westerlund agreed to
write an IESG statement on this topic. This action item is clearly
documented in Section 1.3 of the minutes from the IESG Telechat on
May 22nd ( https://datatracker.ietf.org/iesg/telechat/391/ ). Second,
on June 9th, Bert Wijnen agreed to make updates to the ID Checklist
when he returned from vacation. Your appeal was submitted on Friday,
June 13th, after these actions had begun but before either was ready
for community review.

>I believe that there is also clear community consensus,
>expressed many times in WG and IETF List discussions, that they
>IESG should follow the rules, whether those rules are explicit
>in 2026 or its successors or are rules set by the IESG for
>itself.
>
>I had taken the very existence of the "DISCUSS criteria" and
>"I-D Checklist" documents as evidence that the IESG understood
>that community consensus and was trying to improve things by
>getting the rules written down and open to community discussion
>where needed, rather than playing 'gotcha' with WGs, document
>authors, and the community. I applauded both. This appeal was
>made necessary precisely because that conclusion appears to have
>been incorrect unless the IESG is constrained to actually follow
>the rules it writes done and to write down the rules it expects
>to follow.
>
>Several people have suggested to me, both before and after the
>appeal was posted, that I not raise an appeal about the 2821bis
>issue at all but simply appeal the process problem, thereby
>avoiding the confusion that has appeared in many messages to the
>list in recent days, including yours. Others have suggested
>that this appeal should have gone directly to the ISOC BoT as a
>demonstration that existing procedures, as the IESG chooses to
>interpret them, are insufficient to ensure a fair an open
>process. I do not believe that either of those approaches is
>unambiguously permitted under RFC 2026. While I can certainly
>read 2026 as permitting them, I can also see how applying either
>one could result in rejection of the appeal on procedural
>grounds while we all go into the rathole of a debate about what
>2026 really says and means.

I agree that mixing the two issues in one appeal has made the two
issues more difficult to process by the IESG and more difficult to
discuss on this thread.

>Instead, the appeal is based on a specific action (the DISCUSS
>on 2821bis), claims that it violates the process and clear
>community intent, and claims that the fact that this case has
>arisen demonstrates that the current procedures are not
>sufficient to protect a fair and open standards process. The
>last of these isn't about 2821bis at all; it is about whether
>the IESG is permitted to make up editorial and stylistic rules
>after Last Call on a document, or to have long-standing rules
>that it doesn't tell the community about, and then to use those
>rules to block documents. I believe that it cannot do so if we
>are to have a fair, open, and efficient standards process in the
>IETF. You apparently disagree. I trust that this appeal will
>help to resolve that issue.

I do not disagree. I think the two actions initiated before the
appeal was submitted clearly illustrate the opposite.

>However, even on the specifics of the 2821bis issues, we
>obviously disagree. More on that below.
>
>--On Wednesday, 18 June, 2008 22:35 -0400 Russ Housley
><***@vigilsec.com> wrote:
>
> >...
> > You are missing a few things that I consider to be relevant
> > and important.
> >
> > - We're talking about rfc2821bis (not RFC 2821 or RFC 821).
> >
> > - The examples in RFC 821 use different domains from the ones
> > in RFC 2821.
>
>Yes, and the decision to make those changes, and what to change
>them too, were explicit decisions in the DRUMS WG. The examples
>in 2821bis are not different from the examples in 2821, and that
>actually is important here.

This is not true! Look a section 4.3.1.

RFC 2821 includes this example:

220 ISIF.USC.EDU Service ready
or
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
or
220 [10.0.0.1] Clueless host service ready

draft-klensin-rfc2821bis-10 includes this revised example:

220 ISIF.USC.EDU Service ready

or

220 mail.example.com SuperSMTP v 6.1.2 Service ready

or

220 [10.0.0.1] Clueless host service ready

Frankly, I took this as an indication that the updating of the
examples had begun, but was done incompletely. In fact, it was this
section that was highlighted in the SecDir Review comments that were
raised in IETF Last Call.

> > If the document were being advanced to Draft Standard with no
> > changes at all, then I think it would be unreasonable to
> > anyone ask for a change to address this issue. However,
> > other changes were deemed necessary. Given that situation,
> > it seems appropriate to consider current guidance. This
> > guidance is referenced in the appeal. The I-D Checklist
> > (IDnits, http://www.ietf.org/ID-Checklist.html), Section 6,
> > says:
> >
> > Addresses used in examples SHOULD preferably use
> > fully qualified domain names instead of literal IP
> > addresses, and preferably use example fqdn's such as
> > foo.example.com instead of real-world fqdn's.
>
>There are at least two issues here, both of which have been
>discussed at length on the list. To summarize my view of them
>(borrowing somewhat from the examples in another note):
>
>I live in a community in which any change to a building may lead
>to a requirement that I bring that system of the building up to
>contemporary codes. My neighbor is free to continue to use his
>fuse box, but any update to any part of his electrical system,
>even replacing an outlet or light fixture or adding a circuit
>for which the fuse box has space, may lead to a regulatory
>demand that he upgrade his entire system back to the service
>entrance and install contemporary equipment including GFIs and
>arc protectors. As one might imagine, this sort of policy has
>some bad effects (and it has been imposed much less often in
>recent years than a few decades ago). But, even here, no one
>thinks that I should be required to replace my electrical system
>if I repair a toilet.
>
>2821bis contains only those changes that the mailing list (and a
>few years of comments before the revision effort formally
>started) believed were needed to clarify the document. It
>carefully does not contain changes made for purely stylistic
>reasons. The argument that, because some changes were made,
>changes should be required to "update" examples that were
>completely unaffected by those substantive changes is very much
>like the argument "you fixed a toilet, therefore you must update
>all of the electrical systems to contemporary standards before
>we give you permission to occupy the house". Even if the
>principle had merit --which I suggest that it does not-- it is
>undesirable to apply it because it is disproportionate,
>unnecessary, imposes risks, and ultimately discourages people
>from trying to advance documents along the standards track.
>Each of those negative factors has been discussed in other notes
>to this mailing list; I will not repeat them.

Interesting analogy. I could not have figured out this motive given
the diff between this document an RFC 2821. It is far from
minimal. In fact, two text samples above show the introduction of
additional blank lines. To me, that is a style change.

> > RFC 2119 has a pretty clear definition of "SHOULD". It says:
> >
> > This word, or the adjective "RECOMMENDED", mean that there
> > may exist valid reasons in particular circumstances to
> > ignore a particular item, but the full implications must
> > be understood and carefully weighed before choosing a
> > different course.
>
>As others have pointed out at some length, the statement in
>IDNits apply a "SHOULD" to the use of fully qualified domain
>names and only a (lower case) "preferably use" to "example
>fqdns". So, once again, unless the IESG insists that the
>community is either required to read its collective mind or that
>we all read the history of IESG decisions and apply some sort of
>exegesis to derive the rules, this is completely irrelevant.

As I said earlier, actions have begun to add clarity.

> > This document uses "isif.usc.edu" and "***@isi.edu" as
> > examples. The authors want to leave these as a tribute to
> > Jon. Fine. I think the implications of these are well
> > understood.
>
>Independent of what you were told, or thought you were told, by
>the Proto shepherd, the decision made by DRUMS, and reaffirmed
>by the mailing list considering 2821bis, was to preserve Jon's
>examples to the extent possible, not to preserve (only) those
>two examples. However, because it obviously cannot be repeated
>enough times, that is not the issue here. The issue is the
>imposition of a blocking "surprise" requirement by the IESG.

That does not match the message I got from the PROTO shepherd.

> > This document also uses "foo.com", "foo.org", "bar.org",
> > "foo-u.edu", and "generic.com" in examples. I have not heard
> > anyone offer "valid reasons" for using them instead of the
> > ones in BCP 37. I have heard people say that they are not
> > causing harm. That is not the same. We have seen examples
> > that use real IP addresses and domain names cause harm. The
> > excessive traffic sent to one NTP server comes to mind.
>
>Others have addressed this comment and ones like it but, to
>repeat: I believe that the community has told the IESG many
>times that late imposition of requirements on documents are
>undesirable and that, if they cannot be avoided, they require
>significant justification. This is a late requirement, no
>matter how many times the IESG has applied it in the past, and
>you have offered no evidence of harm. The strongest claim you
>made in our correspondence was "rude". In addition, several
>people have now offered concrete data that there is no evidence
>of harm in the specific cases covered by 2821 or 2821bis. The
>mere absence of complaints to the IETF about 2821 strengthens
>their case. You suggest above that harm has occurred in other
>places (other than the NTP example), but have not identified
>those cases, especially sufficiently to overcome the presumption
>of seven years of experience with 2821. As others have
>suggested, there is a huge difference between examples of syntax
>and operation and example configuration files (including the NTP
>case).

I agree that this aspect of the issue has been covered very
completely on this thread already. Saying more will simply be
repeating things that have already been said more than once.

> > The IESG has been using DISCUSS positions since before 2003 to
> > remove real domain names. I'm sure that some have slipped
> > through. A couple have been pointed out in this thread.
>
>Again, unless the IESG is willing to take the position that the
>community is expected to review its previous decisions to deduce
>the rules that will be applied, this is irrelevant. In
>addition, and precisely relevant to the issue of whether a fair
>and open process is operating here, there is evidence that at
>least some of the domain name changes imposed by the IESG as
>above were coerced in the sense that the requirement to get a
>document out rather than engaging in an extended discussion with
>the IESG overcame any desire to resist this type of demand.

Again, I believe the appropriate actions have already been
started. So some extent, we cannot avoid people sharing stories
about things that worked or didn't for them. This is human
nature. However, when we identify a defect in the documentation, we
do try to correct it.

>Finally,
>--On Thursday, 19 June, 2008 13:50 -0400 Russ Housley
><***@vigilsec.com> wrote:
>
> >> Yet, for all of the IETF's formal documentation of technical
> >> and stylistic requirements, we do not seem to have any
> >> community consensus document -- and not even an IESG
> >> document -- that justifies asserting this as a requirement.
> >
> > That seems to be the crux of the appeal. Does every possible
> > thing upon which an AD can raise a DISCUSS position need to
> > align with a written rule? Don't we select leaders because
> > we have some confidence in their judgement?
>
>If you review the archives of discussions about IETF process
>matters, you will find that I've consistently been one of the
>strongest advocates of giving the IESG considerable discretion
>and latitude in technical matters. I do not believe it is
>possible to anticipate or enumerate every case, and I believe
>that attempting to do so just gets us into large problems.
>
>However, stylistic issues --the form, organization, and content
>of I-Ds and RFCs are a different matter. If the IESG cannot
>identify the relevant rules and be explicit about them, then
>either those rules are not important enough to enforce on a
>blocking basis or they should have been written down long ago.
>The fact that you can argue that 2606 names have been fairly
>consistently for five or more years is an argument that they are
>not a matter of technical judgment that requires discretion but
>that they are like all of the materials that IDNits identifies
>as "required".

We are in agreement. I have been working toward incremental
improvement since becoming IETF Chair.

>Alternatively, you can claim that you are applying a technical
>judgment in this case, a judgment that the IESG needs the
>flexibility and discretion to discover and apply. But that is
>inconsistent, IMO, with the claim of consistent reinforcement of
>a rule... and I believe that the community has said that it
>requires case-specific justification, for which "well, this
>causes harm in some unrelated situation" or "it is rude" are,
>IMO, insufficient.
>
>I believe that you can't have it both ways, at least consistent
>with a fair and open process, much less one that is focused on
>efficiently moving documents through the IETF unless significant
>problems are found.

We cannot get it all done in one day. It ought to be clear at this
point that actions were initiated even before your appeal was
submitted. You may or many not agree that these actions are
sufficient. In fact, in your position, I'd hold judgement until the
proposed text is available.

I find we agree on more than we disagree,
Russ
Pete Resnick
2008-06-23 20:39:24 UTC
Permalink
On 6/18/08 at 10:35 PM -0400, Russ Housley wrote:

>The I-D Checklist (IDnits, http://www.ietf.org/ID-Checklist.html),
>Section 6, says:
>
> Addresses used in examples SHOULD preferably use
> fully qualified domain names instead of literal IP
> addresses, and preferably use example fqdn's such as
> foo.example.com instead of real-world fqdn's.
>
>RFC 2119 has a pretty clear definition of "SHOULD". It says:
>
> This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.

Ahem. RFC 2119 is also pretty clear about two other things:

In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents.

I-D Nits ain't no "standards track document", and it barely qualifies
as an "IETF document". It's certainly not an IETF consensus document.

But also:

6. Guidance in the use of these Imperatives

Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.

Indeed, the real potential for causing harm or failure to
interoperate in the case of 2821bis would be to change all of the
examples to "example.org", inadvertently screw it up in some
interesting way, and cause people to implement incorrectly. In the
case of a document where almost all of the examples have been left
alone, and those examples have been in use for 7 years without
problems, the burden of proof is on you to demonstrate harm if you
want to put a DISCUSS on the document. If you want to put a COMMENT
on the document, it is incumbent on the document editors to review
the decision of 7 years ago and have them explain why that path was
chosen. But unless there is *demonstrable* harm at this point in the
life cycle of the document, it's an editorial issue that does not
warrant a DISCUSS.

(To wit: Wouldn't it have been amusing if John had changed all of the
examples to fit 2606 names and some AD came along and said, "DISCUSS:
This document is heading for Draft Standard after 7 years of
deployment. Even though I can't see an overt problem in the examples
now used, changing them from perfectly good examples that have
interoperated for 7 years without problem has the potential for harm.
Please change them back to their original forms." I'd be far less in
favor of an appeal against *that* DISCUSS.)

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Robert Elz
2008-06-16 08:51:15 UTC
Permalink
Date: Mon, 16 Jun 2008 13:23:28 +1200
From: Brian E Carpenter <***@gmail.com>
Message-ID: <***@gmail.com>


| Which, in fairness, the IESG has documented, in the DISCUSS criteria
| document and generally in practice, over the last several years.

The IESG is free to document their own procedures, that's a good thing.

They're not free to invent rules for the IETF, that's for the IETF as
a whole. What gets a document approved is IETF rough consensus, that's
been the IETF rule for years. If there's any real question whether this
revision has IETF consensus or not, then it should be blocked. If there's
no question as to that, then it should be approved - after all, the IETF
would (under that assumption) have approved it, along with all of its
examples. If the example domain names were really an issue to anyone,
that would have been raised during last call. At that point, whether or
not rough consensus existed to continue with the doc as it was could have been
judged.

Even if we had a rule that all domain names in RFCs must be from the reserved
set (which we do not) the IETF has the power to change its rules. That can
be done in general, or on a case by case basis. Raising the issue during
last call, and having the IETF decide to ignore the problem for the doc in
question would be all that is required to set aside the rule for that doc.

But we have no such rule, there's never been a last call on anything that
says that all domain names in examples in RFCs must be from the set
documented in 2606, so the issue should not even arise. If there ever were
such a last call, you can expect I'd be an vociferous opponent, as rules
like that make no sense at all. There are perfectly good reasons for those
domains to exist, and very definitely places where they should be used,
but this is not one of those cases.

| I don't think that changing foo.com to foo.example.com would
| destabilise the email system too much.

Of course it wouldn't break e-mail, but it would make following the RFC
sequence, and working out what changed, and why, much more difficult.

Further, when dealing with something which necessarily deals (or should)
deal with many different domain names (like e-mail does), constraining
the examples to be from just a small set or (seemingly relayed) names would
do a disservice. Sure, you and I know that the "example" in foo.example.com
is meant to be ignored, and isn't there for any particular purpose, but can
you expect that every reader of the doc will understand that.

Even if there was an "only those domain names" rule, and there was a good
reason for having that (neither of which is actually the case), there would
be a good case for ignoring it for this one doc. If the "real" domain names
used in this doc are a problem to the owners of the domains, I have no real
doubt but they would be changed upon request, so that straw-man objection
can be ignored.

I have no idea which AD has the arrogance to put their own view of what
the IETF rules should be above the stated desires of the IETF as a whole
(as determined by the last call), but whoever that is really ought to
consider resignation as an honourable way out of the mess they're creating.

kre
TSG
2008-06-16 22:40:20 UTC
Permalink
----- Original Message -----
From: "Robert Elz" <***@munnari.OZ.AU>
To: "Brian E Carpenter" <***@gmail.com>
Cc: "John C Klensin" <john-***@jck.com>; <***@ietf.org>;
<***@bbiw.net>; <***@ietf.org>
Sent: Monday, June 16, 2008 12:51 AM
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis


> Date: Mon, 16 Jun 2008 13:23:28 +1200
> From: Brian E Carpenter <***@gmail.com>
> Message-ID: <***@gmail.com>
>
>
> | Which, in fairness, the IESG has documented, in the DISCUSS criteria
> | document and generally in practice, over the last several years.
>
> The IESG is free to document their own procedures, that's a good thing.

No they are NOT. The IESG's processes MUST also be transparent just like the
IETF's or they risk creating liability for their sponsor's that NONE of
those sponsor's will be too happy with.

>
> They're not free to invent rules for the IETF, that's for the IETF as
> a whole. What gets a document approved is IETF rough consensus, that's
> been the IETF rule for years. If there's any real question whether this
> revision has IETF consensus or not, then it should be blocked. If
> there's
> no question as to that, then it should be approved - after all, the IETF
> would (under that assumption) have approved it, along with all of its
> examples. If the example domain names were really an issue to anyone,
> that would have been raised during last call. At that point, whether or
> not rough consensus existed to continue with the doc as it was could have
> been
> judged.
>
> Even if we had a rule that all domain names in RFCs must be from the
> reserved
> set (which we do not) the IETF has the power to change its rules. That
> can
> be done in general, or on a case by case basis. Raising the issue during
> last call, and having the IETF decide to ignore the problem for the doc in
> question would be all that is required to set aside the rule for that doc.
>
> But we have no such rule, there's never been a last call on anything that
> says that all domain names in examples in RFCs must be from the set
> documented in 2606, so the issue should not even arise. If there ever
> were
> such a last call, you can expect I'd be an vociferous opponent, as rules
> like that make no sense at all. There are perfectly good reasons for
> those
> domains to exist, and very definitely places where they should be used,
> but this is not one of those cases.
>
> | I don't think that changing foo.com to foo.example.com would
> | destabilise the email system too much.
>
> Of course it wouldn't break e-mail, but it would make following the RFC
> sequence, and working out what changed, and why, much more difficult.
>
> Further, when dealing with something which necessarily deals (or should)
> deal with many different domain names (like e-mail does), constraining
> the examples to be from just a small set or (seemingly relayed) names
> would
> do a disservice. Sure, you and I know that the "example" in
> foo.example.com
> is meant to be ignored, and isn't there for any particular purpose, but
> can
> you expect that every reader of the doc will understand that.
>
> Even if there was an "only those domain names" rule, and there was a good
> reason for having that (neither of which is actually the case), there
> would
> be a good case for ignoring it for this one doc. If the "real" domain
> names
> used in this doc are a problem to the owners of the domains, I have no
> real
> doubt but they would be changed upon request, so that straw-man objection
> can be ignored.
>
> I have no idea which AD has the arrogance to put their own view of what
> the IETF rules should be above the stated desires of the IETF as a whole
> (as determined by the last call), but whoever that is really ought to
> consider resignation as an honourable way out of the mess they're
> creating.
>
> kre
>
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Dave Crocker
2008-06-15 23:44:41 UTC
Permalink
Brian E Carpenter wrote:
> I think one can make a case that in some documents, use of non-RFC2606
> names as examples is a purely stylistic matter, and that in others,
> it would potentially cause technical confusion. I'm not asserting which
> applies to 2821bis, but I do assert that there is scope here for
> a judgement call and therefore the inconsistency is understandable.


Actually, Brian, scope is exactly what this judgment call is out of.

The underlying question is whether rules matter in the IETF or whether the
IETF is subject to whatever ADs feel like declaring at the moment.

If rules do matter, then the IESG needs to follow them. In very concrete
terms, the IESG needs to be constrained it its application of a Discuss to
matters of serious import and to document the basis for an application of a
Discuss.

The current case has an AD asserting a Discuss by claiming a rule that does
not exist. That's not judgment call, that's invention.

Even better is that application of this invented rule on a revision to an
established standard represents an orientation towards change that is
de-stabliling rather than helpful.

With that combination, you can't get much more out of scope.

d/
--

Dave Crocker
Brandenburg InternetWorking
bbiw.net
John C Klensin
2008-06-16 20:09:23 UTC
Permalink
Eric, Brian, and others...

Since this has turned into a general discussion about DISCUSS,
etc., a few comments. With regard to the specific appeal,
everyone should remember that, under our procedures, the focus
of an appeal in the first instance is "please reconsider this
and decide whether you really want to do it". I still hope that
model works and that the IESG will reconsider, remove the
DISCUSS, and clear up some of what, IMO, is the mess that seems
to surround it.

To me, that mess includes (almost independent of the particular
document or appeal):

(1) The tracker categories are a matter of IESG decisions, not
of anything on which the community has ever reached consensus or
been asked to do so (something I actually consider a good
thing). The IESG can change them as needed. If the current
state of the tools is such that they cannot be changed, then I
believe that

(i) the IESG should be having a discussion with the
IAOC, the Secretariat, and/or the Tools team as needed.
One of those groups should report back to the community
with a plan.

(ii) the IESG consists entirely of very smart people
with years of experience in the industry. Even with
limitations imposed by the tools, I think they could
figure out contentions to make positions absolutely
clear to each other and to the community.

If we have to learn a secret language (e.g., "discuss discuss")
in order to understand the status of a document, and learn it
without a dictionary or glossary, then I think the IETF is in
trouble. If, as I assume, the absence of that glossary is
either an oversight or a too-low priority, I hope that the IETF
will take this discussion as an indication that it is time to
increase the priority. The only other possibility I can see is
that the IESG is deliberately trying to confuse the community.
I don't believe that is happening but, if it were, it is time
for people to either grow up or start stepping down.

(2) IMO, the argument that the choice of names in an example is
a technical clarification matter, even as a judgment call, is
_extremely_ hard to justify. I basically support 2606. I
think it is generally a bad idea for us to use names that others
have registered and that it is a bad idea for others to register
names that we are using. I would hope that no editor would use
color.example.com and colour.example.com in the same document in
a way that would leave the reader wondering whether the
difference was intended to make a point or was an editorial
error. And I would expect that such examples would be swiftly
corrected if they were pointed out and were, in fact, errors.
Even that is an editorial issue, not a substantive technical
one. There could be cases where it would interfere with clarity
enough to justify a judgment call to hold the document until it
was fixed. But those cases would be rare and would deserve
explicit justification. As others have pointed out, there has
been no justification in this case other than "the IESG has been
enforcing 2026 names consistently for at least five years").

Again, until we start using IDNs in examples (where I can
imagine some exceptions), all of those are issues of editorial
style and presentation, not technical substance. And, until
and unless some descendant of Frank Ellerman's recent draft is
approved, we have no reserved IDN names or guidance anyway.


(3) I believe that it would be perfectly reasonable for the IESG
to decide to require the 2606 names, or to require them unless
justification were explicitly provided and a waiver requested
and granted. If they want to do that, they should modify the ID
Checklist ("Nits") to say so and adjust the DISCUSS Criteria as
needed to indicate that use of other names is blocking, even for
revisions of documents that used other names. I would hope that
they would ask for community comment and establish consensus
before reissuing those documents with these provisions, but, if
they didn't, the posting of the documents would make an appeal
possible.

However, if there is one topic in the IETF's discussions in the
last several years about procedures on which there is clear
consensus, it is that the community doesn't like unnecessary
late surprises and considers them destructive. Regardless of
how the IESG (or anyone else) feels about the use or non-use of
2606 names, having a DISCUSS on this topic show up long after
Last Call, when much of the IESG has signed off on the document,
and with no warning in the various guideline, checklist, and
criteria documents is one of the very worst examples of such a
surprise. This is not a technical issue associated with a
disagreement about a protocol specification in which the IESG
has to make a judgment call. It is an editorial/procedural
matter that is easily documented, especially if the IESG has
really applied the criterion to its evaluation of every document
it has touched in the last five years.

Finally, Eric wrote...
> Either DISCUSS means what it implies (maybe we add some
> separate status for BLOCK), or we change the state name to an
> intentionally more ambiguous name (like HOLD, or PENDING).

I believe that there is no excuse for ambiguous categories in
this sort of area and that they are a disservice to the
community and the process. So I want to see less ambiguity, not
more.

and kre wrote...
> If the example domain names were really an issue to anyone,
> that would have been raised during last call. At that point,
> whether or not rough consensus existed to continue with the
> doc as it was could have been judged.

Yes, exactly. And the fact that this was discussed, and an
explicit decision reached, months before Last Call makes the
situation even worse, IMO.

best regards,
john
Dave Crocker
2008-06-17 04:09:31 UTC
Permalink
John C Klensin wrote:
> (1) The tracker categories are a matter of IESG decisions, not
> of anything on which the community has ever reached consensus or
> been asked to do so (something I actually consider a good
> thing). The IESG can change them as needed. If the current
> state of the tools is such that they cannot be changed, then I
> believe that

This type of problem with DISCUSS pre-dates the tools.

Yes, the tools will need to be changed, but they aren't the problem.


> (3) I believe that it would be perfectly reasonable for the IESG
> to decide to require the 2606 names, or to require them unless
> justification were explicitly provided and a waiver requested
> and granted.

It is not reasonable to apply this requirement to advancement/revision
efforts, absent active demonstration of problems with the existing choices
used in the draft under revision.

> However, if there is one topic in the IETF's discussions in the
> last several years about procedures on which there is clear
> consensus, it is that the community doesn't like unnecessary
> late surprises and considers them destructive.

This is definitely a deeper issue.


> Yes, exactly. And the fact that this was discussed, and an
> explicit decision reached, months before Last Call makes the
> situation even worse, IMO.

Another deeper issue. A single individual attempting to counter-act the
judgement of the working group, without affirmative justification except
erroneous citation of rules and without specific expertise to counteract the
substantial expertise of the particular working group. (Lest anyone want to
invoke the "rogue" wg strawman.)

d/

--

Dave Crocker
Brandenburg InternetWorking
bbiw.net
Scott O. Bradner
2008-06-17 19:20:17 UTC
Permalink
if indeed RFC 2606 (a.k.a, BCP 32) said "all domain names in
RFCs MUST use one of the following bases" then a blocking DISCUSS
by an IESG member would be a reasonable thing. RFC 2606 does not
say that and, thus, a blocking DISCUSS is not reasonable

if the IESG had posted a set of rules that said the same thing
and asked for community comment and the comunity consensus supported
the rules then a blocking DISCUSS by an IESG member would be a
reasonable thing. But no such rules were posted and no such comunity
consensus was shown. (Actually, I whoud hope that comunity consensus
woud be against the idea of the IESG doing any such thing since
such things should be left to normal IETF process rather
that to management from the top.)

Scott
John C Klensin
2008-06-23 20:00:02 UTC
Permalink
--On Monday, 23 June, 2008 14:19 -0400 Russ Housley
<***@vigilsec.com> wrote:

> Dave:
>
>>>> If you feel that group was rogue, please explain. If you
>>>> do not, what is the basis for your view that its
>>>> considerations were sufficiently faulty to warrant being
>>>> overridden?
>>> Prior to the appeal, this aspect of John's rationale was not
>>> raised. It was not raised by John, the document PROTO
>>> shepherd, or the IESG member sponsoring the document.
>>
>> Again, I hope we do not find ourselves in a he said/no he
>> didn't exchange. I'll
>> merely suggest that had the Discuss been immediately taken to
>> the public mailing
>> list, it seems pretty likely that salient details would
>> quickly have been put forward.
>
> This is an individual submission, not a WG document. So,
> there is no charter that lists the appropriate mail list for
> such a discussion. That said, John did take the issue to a
> mail list. I know this because someone forward his posting to
> me. John did not CC me on the posting, which I interpret as
> not seeking dialogue at that point.

Russ, that note was sent to the mailing list after I received
your "change the document or appeal" note. I believed that
note from you closed the door on any further dialogue with you
(or the IESG). The note to the SMTP list was simply to collect
opinions on which of the two choices you gave me to adopt.

If you intended the "change the document or appeal" note to be
interpreted in any other way, I apologize for not copying you on
the question to the list, but I really could not figure out any
other way to read it (and cannot to this day).

best,
john
Bernard Aboba
2008-06-24 02:41:27 UTC
Permalink
Russ Housley said:

"I agree with this principle. In fact, I think that the IESG has taken many steps over the last four or more years to reduce the nearly-end-of-process surprises. Obviously, you do not think these measures have been sufficient. One lesson from the many attempts to make updates to RFC 2026 is that such policy documents needs to set expectations without taking away flexibility and judgement. "

Can you elaborate on what steps the IESG has taken to reduce the "nearly-end-of-process surprises" and why effect this has had, if any? For example, have the delays resulting from IESG reviews actually *decreased* as a result?

The research by Prof. Simcoe of the Rotman School is not encouraging:
http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%20-%20Delays.pdf
Harald Tveit Alvestrand
2008-06-24 09:41:34 UTC
Permalink
--On Monday, June 23, 2008 07:41:27 PM -0700 Bernard Aboba
<***@hotmail.com> wrote:

> Russ Housley said:
>
> "I agree with this principle. In fact, I think that the IESG has taken
> many steps over the last four or more years to reduce the
> nearly-end-of-process surprises. Obviously, you do not think these
> measures have been sufficient. One lesson from the many attempts to make
> updates to RFC 2026 is that such policy documents needs to set
> expectations without taking away flexibility and judgement. "
>
> Can you elaborate on what steps the IESG has taken to reduce the
> "nearly-end-of-process surprises" and why effect this has had, if any?
> For example, have the delays resulting from IESG reviews actually
> *decreased* as a result?
>
> The research by Prof. Simcoe of the Rotman School is not encouraging:
> http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%2
> 0-%20Delays.pdf

The Simcoe dataset ends in approximately 2001.

This was 2 years before the I-D tracker got implemented. 'Nuff said.

Harald
Russ Housley
2008-06-24 14:19:06 UTC
Permalink
Bernard:

Many of the IESG activities are listed in John's appeal. The DISCUSS
Criteria document is probably the biggest step that was taken. ADs
routine challenge each other to stay within those guidelines.

At the IESG Retreat we had a discussion on this topic. It is very
hard to measure. During the discussion, we quickly discovered that
there are a number of DISCUSS positions related to some comment that
was raised in Last Call but not addressed in any way. One cannot
call these "late surprises" and most of them are resolved very quickly.

We have a way to count DISCUSS positions, but we do not have a way to
figure out what percentage of them are perceived as "late surprises"
by the community. So, while we are taking action in an attempt to
make things better, we do not have a way to measure our success or
failure beyond community perception. Suggestions on making this more
objective and less subjective are greatly appreaciated.

Russ


At 10:41 PM 6/23/2008, Bernard Aboba wrote:
>Russ Housley said:
>
>"I agree with this principle. In fact, I think that the IESG has
>taken many steps over the last four or more years to reduce the
>nearly-end-of-process surprises. Obviously, you do not think these
>measures have been sufficient. One lesson from the many attempts to
>make updates to RFC 2026 is that such policy documents needs to set
>expectations without taking away flexibility and judgement. "
>
>Can you elaborate on what steps the IESG has taken to reduce the
>"nearly-end-of-process surprises" and why effect this has had, if
>any? For example, have the delays resulting from IESG reviews
>actually *decreased* as a result?
>
>The research by Prof. Simcoe of the Rotman School is not encouraging:
><http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%20-%20Delays.pdf>http://www.rotman.utoronto.ca/strategy/research/working%20papers/Simcoe%20-%20Delays.pdf
Bernard Aboba
2008-06-24 15:32:37 UTC
Permalink
> We have a way to count DISCUSS positions, but we do not have a way to
> figure out what percentage of them are perceived as "late surprises"
> by the community. So, while we are taking action in an attempt to
> make things better, we do not have a way to measure our success or
> failure beyond community perception. Suggestions on making this more
> objective and less subjective are greatly appreciated.
>
> Russ

I agree that it might be hard to measure the effect of particular actions (e.g. changes in
procedures). However, it is *not* hard to measure overall trends in performance, and
to break these trends down between areas and types of documents.

My understanding is that the Simcoe dataset continues beyond 2001, and that with some
relatively modest effort, a detailed analysis could be produced quantifying how the IETF
has performed. This would give us a window into what the actual results have been.
Russ Housley
2008-06-24 20:35:46 UTC
Permalink
Bernard:

The data is all public. Jari has done a very good job of extracting
the data from the I-D Tracker and making it accessible to
everyone. Of course, any requests for changes to additional graphs
need to go to Jari.

http://www.arkko.com/tools/admeasurements/stat/base.html

Russ

At 11:32 AM 6/24/2008, Bernard Aboba wrote:
> > We have a way to count DISCUSS positions, but we do not have a way to
> > figure out what percentage of them are perceived as "late surprises"
> > by the community. So, while we are taking action in an attempt to
> > make things better, we do not have a way to measure our success or
> > failure beyond community perception. Suggestions on making this more
> > objective and less subjective are greatly appreciated.
> >
> > Russ
>
>I agree that it might be hard to measure the effect of particular
>actions (e.g. changes in
>procedures). However, it is *not* hard to measure overall trends in
>performance, and
>to break these trends down between areas and types of documents.
>
>My understanding is that the Simcoe dataset continues beyond 2001,
>and that with some
>relatively modest effort, a detailed analysis could be produced
>quantifying how the IETF
>as performed. This would give us a window into what the actual
>results have been.
Jari Arkko
2008-06-25 11:37:15 UTC
Permalink
Bernard, Russ,

I changed the subject line, I think the thread has continued long enough
:-) Indeed, I collect a set of measurements. These are based on pulling
information from the tracker and the documents. The reason for setting
this up was to try to better understand what is happening in the IETF
process at various levels: for each document, my own AD work, how the
IESG works, where is the time spent in the IETF process as a whole.

http://www.arkko.com/tools/admeasurements/ (start page and disclaimers)
http://www.arkko.com/tools/admeasurements/stat/base.html (main IESG
measurements)

http://www.arkko.com/tools/lifecycle/draft-ietf-mobike-protocol-timing.html
(exists for each approved draft)

The data is current and is being updated every week or so. But before
everyone looks at the graphs and jumps to conclusions, I wanted to
insert a few disclaimers. First, this is based on tracker data and it
does not go into that far into the past -- and some of the older data
might even not be all that accurate. Second, I recently added a lot of
measurements and I don't yet have 100% confidence that my tool gets
everything correct. This is particularly true of the items looking at
various aspects of Discusses. Third, some of the measurements look at
tracker substates, which are not used by all ADs and no one uses them
completely accurately. And last but not least, I don't want anyone to
blindly look at the numbers without considering what's behind them.
There are significant variations between documents. Tracker status and
real world situation may be different. Areas differ. There is limited
amount of information about documents prior to them becoming WG
documents. And its not necessarily the goal of the IETF to produce a
large number of documents as fast as it can; I have no way to measure
quality in these numbers. These are so hard issues that its not even
clear that the statistics have more value than acting as entertaining
trivia about the process.

That being said, it is beneficial to understand what is happening and
what changes are occurring in the process. Or understand where
improvements might have a negligible vs. visible impact.

One of the things that the IESG has been concerned about recently is
that the number of outstanding Discusses is growing. We talked about
this in our May retreat and identified some actions to help reduce this
problem. For instance, better tool support so that the ADs would better
see the different things that are waiting for their action, getting the
document shepherds better involved in the resolution process, informing
authors how they should respond to Discusses, using RFC Editor notes to
make small changes when the authors are slow in producing a new version,
better checks of documents before they come to telechats (e.g., to
ensure that formal syntax in a document is free of errors), etc. These
would be in addition to the usual things we'd do, like debate whether
the Discuss was within the Discuss criteria, whether the issue is real,
try to ensure that the AD and the authors are being responsive over
e-mail, etc.

Another interesting area to think about is the time that our processes
take. For instance, documents that go through me take on the average
five months from publication request to approval. But there is a lot of
variation. This time includes everything from AD review, IETF Last Call
to IESG review and waiting for document revisions, etc. One interesting
piece of information is that documents that require no revision during
this process are very rare, but they go through the system about five
times as fast. If we look at the (unreliable) substates, they appear to
indicate that the IESG processing time is divided roughly 1:2:1 for
waiting on AD, authors, and mandatory process waits like last call periods.

I am working to extend the analysis a little bit further by including
individual draft and WG document stages. You see some of the results of
this in the third URL above, but I'd like to understand what fraction of
the overall draft-smith-00 to RFC time is taken by the different stages
for all IETF work, and how the stages have developed over time.

Comments and suggestions on what would be useful to measure are welcome.

Jari
Marshall Eubanks
2008-06-25 13:56:04 UTC
Permalink
Dear Jari;


On Jun 25, 2008, at 7:37 AM, Jari Arkko wrote:

> Bernard, Russ,
>
> I changed the subject line, I think the thread has continued long
> enough :-) Indeed, I collect a set of measurements. These are based
> on pulling information from the tracker and the documents. The
> reason for setting this up was to try to better understand what is
> happening in the IETF process at various levels: for each document,
> my own AD work, how the IESG works, where is the time spent in the
> IETF process as a whole.
>
> http://www.arkko.com/tools/admeasurements/ (start page and
> disclaimers)
> http://www.arkko.com/tools/admeasurements/stat/base.html (main IESG
> measurements)
> http://www.arkko.com/tools/lifecycle/draft-ietf-mobike-protocol-timing.html
> (exists for each approved draft)
>
> The data is current and is being updated every week or so. But
> before everyone looks at the graphs and jumps to conclusions, I
> wanted to insert a few disclaimers. First, this is based on tracker
> data and it does not go into that far into the past -- and some of
> the older data might even not be all that accurate. Second, I
> recently added a lot of measurements and I don't yet have 100%
> confidence that my tool gets everything correct. This is
> particularly true of the items looking at various aspects of
> Discusses. Third, some of the measurements look at tracker
> substates, which are not used by all ADs and no one uses them
> completely accurately. And last but not least, I don't want anyone
> to blindly look at the numbers without considering what's behind
> them. There are significant variations between documents. Tracker
> status and real world situation may be different. Areas differ.
> There is limited amount of information about documents prior to them
> becoming WG documents. And its not necessarily the goal of the IETF
> to produce a large number of documents as fast as it can; I have no
> way to measure quality in these numbers. These are so hard issues
> that its not even clear that the statistics have more value than
> acting as entertaining trivia about the process.


> That being said, it is beneficial to understand what is happening
> and what changes are occurring in the process. Or understand where
> improvements might have a negligible vs. visible impact.
>
> One of the things that the IESG has been concerned about recently is
> that the number of outstanding Discusses is growing. We talked about
> this in our May retreat and identified some actions to help reduce
> this problem. For instance, better tool support so that the ADs
> would better see the different things that are waiting for their
> action, getting the document shepherds better involved in the
> resolution process, informing authors how they should respond to
> Discusses, using RFC Editor notes to make small changes when the
> authors are slow in producing a new version, better checks of
> documents before they come to telechats (e.g., to ensure that formal
> syntax in a document is free of errors), etc. These would be in
> addition to the usual things we'd do, like debate whether the
> Discuss was within the Discuss criteria, whether the issue is real,
> try to ensure that the AD and the authors are being responsive over
> e-mail, etc.
>
> Another interesting area to think about is the time that our
> processes take. For instance, documents that go through me take on
> the average five months from publication request to approval. But
> there is a lot of variation. This time includes everything from AD
> review, IETF Last Call to IESG review and waiting for document
> revisions, etc. One interesting piece of information is that
> documents that require no revision during this process are very
> rare, but they go through the system about five times as fast. If we
> look at the (unreliable) substates, they appear to indicate that the
> IESG processing time is divided roughly 1:2:1 for waiting on AD,
> authors, and mandatory process waits like last call periods.
>
> I am working to extend the analysis a little bit further by
> including individual draft and WG document stages. You see some of
> the results of this in the third URL above, but I'd like to
> understand what fraction of the overall draft-smith-00 to RFC time
> is taken by the different stages for all IETF work, and how the
> stages have developed over time.
>
> Comments and suggestions on what would be useful to measure are
> welcome.
>

I, at least, always like looking at such statistics, so I thank you.

In my opinion, the real value of this come from trends. The IESG
clearly should not have
Soviet style work norms, for a bunch of reasons, and it may not be
possible to say what an approval rate should be,
but if something changes greatly over time it is generally worthwhile
to figure out why.

To that end, I frequently find it useful to put means and standard
deviations as horizontal lines on the plot, at least once enough data
is available (say, 5 data points). (You can do the mean as a solid
line and the mean + and - one or two standard deviations as dashes or
dots or a fainter line).

The assumption is that there are underlying random (gaussian or
poisson) processes that cause the numbers to fluctuate about the mean
and that there is no other way to determine these means and S.D.
except from the data. Under these assumptions, there should be fairly
frequent fluctuations > 1 standard deviation from the mean, and
occasional fluctuations > 2 standard deviations from the mean, but a
string of fluctuations 2 + standard deviations from the mean probably
should be looked into. (Of course, the underlying assumptions here may
be faulty, and
these bounds may need to be adjusted based on experience.)

BTW, this page seems to have blank plots, which may be due to not
enough data :

http://www.arkko.com/tools/admeasurements/stat/Eronen_Pasi-approved.html

Regards
Marshall

> Jari
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
Lakshminath Dondeti
2008-06-25 15:44:32 UTC
Permalink
Hi all,

I am concerned by the following trends:

* Number of outstanding Discusses is growing. (Thanks to Jari's data)

* The extent of text changes as part of Discuss Resolution is increasing
(I have only anecdotal evidence on this; perhaps others have statistics).

* In some cases, members of the IESG are pretty much writing core parts
of documents (or worse yet make authors iterate until the text is
satisfactory), overruling WG consensus, based on personal opinions or
citing solicited reviews.

There are a number of derivative trends as well:

* ADs who cannot convince working groups seem to use the threat of
DISCUSS to get their way.

* I would have thought document shepherds represent and defend working
group consensus and shepherding ADs defend the completeness, accuracy,
relevance of the drafts and defend their assessment of the IETF
consensus. But, increasingly, it seems to fall on an AD holding a
DISCUSS position, and authors to discuss and agree on text which becomes
finalized without any other review.

(Note: I am a guilty party in some of these cases, as document author
and document shepherd. In all cases, I seem to have looked for an
expedient way out rather than find a solution to what seems to be
problematic).

* One of the new trends seems to be to use DISCUSS to include
applicability statements in current drafts to avoid potential DISCUSS
positions on future drafts.

That or some variation of that is status quo. It should not be that
way. I would like to see a better definition of the roles of the WG,
authors of a document, document shepherds, shepherding ADs and other ADs
in our standards process.

I would like to hear others' opinions (I was going to put together a
draft with some ideas on how we might define these roles, but I want to
hear others' thoughts before I do that) on this topic.

thanks,
Lakshminath

On 6/25/2008 4:37 AM, Jari Arkko wrote:
<deleted text>
>
> That being said, it is beneficial to understand what is happening and
> what changes are occurring in the process. Or understand where
> improvements might have a negligible vs. visible impact.
>
> One of the things that the IESG has been concerned about recently is
> that the number of outstanding Discusses is growing. We talked about
> this in our May retreat and identified some actions to help reduce this
> problem. For instance, better tool support so that the ADs would better
> see the different things that are waiting for their action, getting the
> document shepherds better involved in the resolution process, informing
> authors how they should respond to Discusses, using RFC Editor notes to
> make small changes when the authors are slow in producing a new version,
> better checks of documents before they come to telechats (e.g., to
> ensure that formal syntax in a document is free of errors), etc. These
> would be in addition to the usual things we'd do, like debate whether
> the Discuss was within the Discuss criteria, whether the issue is real,
> try to ensure that the AD and the authors are being responsive over
> e-mail, etc.
>
> Another interesting area to think about is the time that our processes
> take. For instance, documents that go through me take on the average
> five months from publication request to approval. But there is a lot of
> variation. This time includes everything from AD review, IETF Last Call
> to IESG review and waiting for document revisions, etc. One interesting
> piece of information is that documents that require no revision during
> this process are very rare, but they go through the system about five
> times as fast. If we look at the (unreliable) substates, they appear to
> indicate that the IESG processing time is divided roughly 1:2:1 for
> waiting on AD, authors, and mandatory process waits like last call periods.
>
> I am working to extend the analysis a little bit further by including
> individual draft and WG document stages. You see some of the results of
> this in the third URL above, but I'd like to understand what fraction of
> the overall draft-smith-00 to RFC time is taken by the different stages
> for all IETF work, and how the stages have developed over time.
>
> Comments and suggestions on what would be useful to measure are welcome.
>
> Jari
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Melinda Shore
2008-06-25 16:19:18 UTC
Permalink
On 6/25/08 11:44 AM, "Lakshminath Dondeti" <***@qualcomm.com> wrote:
> I would like to hear others' opinions (I was going to put together a
> draft with some ideas on how we might define these roles, but I want to
> hear others' thoughts before I do that) on this topic.

I think your points are valid, but I'm not sure what the
effect would be if you controlled for quality coming out
of the working groups. That is to say, I think that
occasionally working groups are coming to consensus on
bad documents or bad ideas, and that the incidence of that
is increasing. If that's true it once again raises the
very familiar question of picking up quality problems
earlier in the process. Actually, that latter question
applies regardless.

Melinda
Ross Callon
2008-06-25 17:19:19 UTC
Permalink
I think that this is a very good partial summary of the trends, and I am
also concerned about these.

My personal opinion only: I think that we need stronger guidelines on
what is a valid discuss, and what is not. We might need some mechanism
for the WG or the IETF or the IAB to override a DISCUSS that does not
represent consensus. As one example, personally I would prefer to not
allow DISCUSS's for the purpose of motivating future or ongoing work --
there are lots of people associated with the IETF who would like to get
their names on drafts, and if work is needed it should be possible to
motivate it without stopping progression of some different related
draft. Also, if work is being done motivated solely by the desire to get
past a DISCUSS comment and without any intention of ever deploying the
result, then there is a very real possibility that the work might not
result in the most practical solution.

I think that producing and coming to consensus on these guidelines might
be a significant challenge. However, I think that this is needed.

Ross

-----Original Message-----
From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On Behalf Of
Lakshminath Dondeti
Sent: 25 June 2008 11:45
To: ***@ietf.org
Subject: Qualitative Analysis of IETF and IESG trends (Re: Measuring
IETFand IESG trends)

Hi all,

I am concerned by the following trends:

* Number of outstanding Discusses is growing. (Thanks to Jari's data)

* The extent of text changes as part of Discuss Resolution is increasing

(I have only anecdotal evidence on this; perhaps others have
statistics).

* In some cases, members of the IESG are pretty much writing core parts
of documents (or worse yet make authors iterate until the text is
satisfactory), overruling WG consensus, based on personal opinions or
citing solicited reviews.

There are a number of derivative trends as well:

* ADs who cannot convince working groups seem to use the threat of
DISCUSS to get their way.

* I would have thought document shepherds represent and defend working
group consensus and shepherding ADs defend the completeness, accuracy,
relevance of the drafts and defend their assessment of the IETF
consensus. But, increasingly, it seems to fall on an AD holding a
DISCUSS position, and authors to discuss and agree on text which becomes

finalized without any other review.

(Note: I am a guilty party in some of these cases, as document author
and document shepherd. In all cases, I seem to have looked for an
expedient way out rather than find a solution to what seems to be
problematic).

* One of the new trends seems to be to use DISCUSS to include
applicability statements in current drafts to avoid potential DISCUSS
positions on future drafts.

That or some variation of that is status quo. It should not be that
way. I would like to see a better definition of the roles of the WG,
authors of a document, document shepherds, shepherding ADs and other ADs

in our standards process.

I would like to hear others' opinions (I was going to put together a
draft with some ideas on how we might define these roles, but I want to
hear others' thoughts before I do that) on this topic.

thanks,
Lakshminath

On 6/25/2008 4:37 AM, Jari Arkko wrote:
<deleted text>
>
> That being said, it is beneficial to understand what is happening and
> what changes are occurring in the process. Or understand where
> improvements might have a negligible vs. visible impact.
>
> One of the things that the IESG has been concerned about recently is
> that the number of outstanding Discusses is growing. We talked about
> this in our May retreat and identified some actions to help reduce
this
> problem. For instance, better tool support so that the ADs would
better
> see the different things that are waiting for their action, getting
the
> document shepherds better involved in the resolution process,
informing
> authors how they should respond to Discusses, using RFC Editor notes
to
> make small changes when the authors are slow in producing a new
version,
> better checks of documents before they come to telechats (e.g., to
> ensure that formal syntax in a document is free of errors), etc. These

> would be in addition to the usual things we'd do, like debate whether
> the Discuss was within the Discuss criteria, whether the issue is
real,
> try to ensure that the AD and the authors are being responsive over
> e-mail, etc.
>
> Another interesting area to think about is the time that our processes

> take. For instance, documents that go through me take on the average
> five months from publication request to approval. But there is a lot
of
> variation. This time includes everything from AD review, IETF Last
Call
> to IESG review and waiting for document revisions, etc. One
interesting
> piece of information is that documents that require no revision during

> this process are very rare, but they go through the system about five
> times as fast. If we look at the (unreliable) substates, they appear
to
> indicate that the IESG processing time is divided roughly 1:2:1 for
> waiting on AD, authors, and mandatory process waits like last call
periods.
>
> I am working to extend the analysis a little bit further by including
> individual draft and WG document stages. You see some of the results
of
> this in the third URL above, but I'd like to understand what fraction
of
> the overall draft-smith-00 to RFC time is taken by the different
stages
> for all IETF work, and how the stages have developed over time.
>
> Comments and suggestions on what would be useful to measure are
welcome.
>
> Jari
>
> _______________________________________________
> IETF mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Jari Arkko
2008-06-25 18:30:46 UTC
Permalink
Lakshminath,

Better understanding of the type of behaviors in this space would
certainly be useful. And I don't want to disagree with your assessment
of the behaviors; many of them sound like something that appears in
practice. In particular, the shepherds are far less involved in the
Discuss resolutions than the authors. And we do not involve the WGs as
much as we should. I think writing guidelines on what the role of the
various persons in the process is would be very useful. And obviously we
should start by better following of the existing documents, like the
Proto Shepherd RFC or the Discuss criteria document.

However, with regards to blocking consensus of a WG, please remember
that the WG is not necessarily the only place where consensus is tested.
I recently had a case which had significant IETF Last Call discussion. I
held a Discuss to ensure that the (fairly clear, IMO) conclusion from
the discussion would be taken into the document. It did eventually, but
only after significant back-and-forth with the authors. Overriding the
original WG consensus? Yes. Right thing to do? I think so, not only was
it right technically but it was something backed up by the Last Call.
Did we get the details right, did the text go too far or did it fall
short? I don't know, its a judgment call. The end result was somewhere
between the LC guidance and authors' opinions. Painful for the WG? Sure.

On text that comes from the IESG: this is more common in recent years
than it was before. I am one of the ADs who tends to do that, both for
the documents that I sponsor and for resolving my Discusses. But I would
rather not do it. But I often end up doing it if there is no progress
otherwise; I want to get my sponsored documents approved and I want to
reduce the list of my outstanding Discusses. If I can help my authors by
proposing text, I will do it. But I would really like to see the
document shepherds in active role here. Or at least the authors. The
general guidance for authors whose document gets a Discuss is to first
confirm whether the raised issue is a real one or not. If it is not, ask
the Discuss to be cleared. Fight if needed! If it is real, work with
your shepherd and WG to develop a proposal to fix the problem. Mail the
proposal to the Discussing ADs in a timely manner. Address explicitly
all components raised in a Discuss, either by explaining how they are
not issues or providing a solution to resolve the issue.

Jari
Brian E Carpenter
2008-06-25 21:41:24 UTC
Permalink
On 2008-06-26 06:30, Jari Arkko wrote:
> Lakshminath,
>
> Better understanding of the type of behaviors in this space would
> certainly be useful. And I don't want to disagree with your assessment
> of the behaviors; many of them sound like something that appears in
> practice. In particular, the shepherds are far less involved in the
> Discuss resolutions than the authors. And we do not involve the WGs as
> much as we should. I think writing guidelines on what the role of the
> various persons in the process is would be very useful. And obviously we
> should start by better following of the existing documents, like the
> Proto Shepherd RFC or the Discuss criteria document.
>
> However, with regards to blocking consensus of a WG, please remember
> that the WG is not necessarily the only place where consensus is tested.
> I recently had a case which had significant IETF Last Call discussion. I
> held a Discuss to ensure that the (fairly clear, IMO) conclusion from
> the discussion would be taken into the document. It did eventually, but
> only after significant back-and-forth with the authors. Overriding the
> original WG consensus? Yes. Right thing to do? I think so, not only was
> it right technically but it was something backed up by the Last Call.
> Did we get the details right, did the text go too far or did it fall
> short? I don't know, its a judgment call. The end result was somewhere
> between the LC guidance and authors' opinions. Painful for the WG? Sure.
>
> On text that comes from the IESG: this is more common in recent years
> than it was before. I am one of the ADs who tends to do that, both for
> the documents that I sponsor and for resolving my Discusses. But I would
> rather not do it. But I often end up doing it if there is no progress
> otherwise; I want to get my sponsored documents approved and I want to
> reduce the list of my outstanding Discusses. If I can help my authors by
> proposing text, I will do it. But I would really like to see the
> document shepherds in active role here. Or at least the authors. The
> general guidance for authors whose document gets a Discuss is to first
> confirm whether the raised issue is a real one or not. If it is not, ask
> the Discuss to be cleared. Fight if needed! If it is real, work with
> your shepherd and WG to develop a proposal to fix the problem. Mail the
> proposal to the Discussing ADs in a timely manner. Address explicitly
> all components raised in a Discuss, either by explaining how they are
> not issues or providing a solution to resolve the issue.

Our fundamental collective job is defined in RFC 3935:

The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people
design, use, and manage the Internet in such a way as to make the
Internet work better.

That means that it is *not* our collective job to ensure that a WG
consensus survives critical review by the IETF as a whole and by
the IESG, if there's reason to believe that the IETF as a whole
doesn't agree with the WG consensus. And it's clearly the IESG's
job to ensure that the critical review and final consensus (or lack
of consensus) occur.

That, IMHO, is the proper role of a DISCUSS and the proper reason
for delays in document approval. And if we see fluctuation in
these delays, and fluctuation in the amount of active intervention
by the ADs, it does not follow that the IESG is to blame. Maybe
there are external factors, maybe there are WGs that are forgetting
the IETF's mission, maybe our technology is getting harder and
more complex. So I'm very dubious about using either quantitative
*or* qualitative observations to point the finger at the IESG, or
at process issues in general, without digging much deeper.

Of course, the IESG needs to pay attention to delays,
so Jari's data (like the earlier data that Bill Fenner used to
produce) are very valuable. And of course, individual ADs
have to think carefully whether a given issue is or is not
worthy of a DISCUSS, and sometimes they get it wrong. But
that will always be true, however we tune the process and
procedures.

Brian
Spencer Dawkins
2008-06-25 21:52:53 UTC
Permalink
> And if we see fluctuation in
> these delays, and fluctuation in the amount of active intervention
> by the ADs, it does not follow that the IESG is to blame. Maybe
> there are external factors, maybe there are WGs that are forgetting
> the IETF's mission, maybe our technology is getting harder and
> more complex. So I'm very dubious about using either quantitative
> *or* qualitative observations to point the finger at the IESG, or
> at process issues in general, without digging much deeper.

I'm remembering conversations with Allison and some other Proto types where
Allison made the point that the tracker stages didn't actually map onto who
held the token very cleanly - I'd agree with Brian's point here.

Thanks,

Spencer
John C Klensin
2008-06-25 23:28:34 UTC
Permalink
--On Thursday, 26 June, 2008 09:41 +1200 Brian E Carpenter
<***@gmail.com> wrote:

>...
> And of course, individual ADs
> have to think carefully whether a given issue is or is not
> worthy of a DISCUSS, and sometimes they get it wrong. But
> that will always be true, however we tune the process and
> procedures.

Brian,

While I agree with this, I also believe that there have to be
effective safeguards against bad judgments prevailing for too
long. And I believe that those have largely slipped away from
us... unless we believe that making changes, unvalidated by WG
or mailing list consensus, simply to get a DISCUSS removed is
the right way to get to "high quality, relevant technical and
engineering documents...".

john
Continue reading on narkive:
Loading...