Subject: Call for review of proposed IESG Statement on Examples

From: The IESG <[email-masked]>
Date: Thu, 18 Sep 2008 10:07:12 -0700 (PDT)

The IESG has received the attached text for a proposed IESG Statement:
IESG Statement on the Usage of Assignable Codepoints in Specification
Examples

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this proposed IESG statement.  Please send substantive
comments to the [email-masked] mailing lists by 2008-10-02. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

On behalf of the IESG,
  Russ Housley

= = = = = = Text of Proposed IESG Statement = = = = = = =

IESG Statement on the Usage of Assignable Codepoints in Specification
Examples

Protocol specifications and other documents intended for RFC publication
often include useful examples with correctly formatted and syntactically
valid codepoints.  Example codepoints may be names, addresses or assigned
numbers, such as email addresses, domain names, IP addresses or ports. The
value used in an example may already have been assigned or may become 
assigned in the future to entities on the Internet, and this can cause
problems.

Codepoints used in specification examples can result (and have in the
past resulted) in some amount of unwanted traffic. The impact of this
unwanted traffic varies highly depending on the context and nature of the
example. Some examples of causing unwanted traffic include:

1) Spam: apparently valid email addresses in an RFC are widely believed
to have been harvested and included in Spam lists. The domain may receive
spam at mailboxes other than the one used in the example email address, if
the domain name is used in common name or brute force attacks.

2) Test code: when test implementors use the examples from the
specification, sometimes they forget to change the example addresses,
potentially resulting in unwanted traffic to the example address.

3) Configuration files: example configuration files are commonly copied
and then edited.  Configuration files may be distributed to a large number
of hosts as part of a software package.  That software may be deployed or
tested before removing the example address. In several cases, this class
of error caused substantial impact on the resource named. The results were
effectively distributed denial of service attacks and increased
operational costs for the targets.

Use of examples in RFCs is not a new concern.  The issues have been known
and considered for several types of codepoints.  BCP 32 (RFC 2606 -
Reserved Top Level DNS Names) reserved some domain names for use in
examples. RFC 3330 (Special-Use IPv4 Addresses) and RFC 5156 (Special-Use
IPv6 Addresses) assigned some IP address ranges specially for examples and
documentation.  RFC4735 (Example Media Types for Use in Documentation)
registered one example media type and one subtype under each of the
registered media types for example use. Other similar specifications and
reserved codepoints exist.

The IESG understands that not all types of codepoints have reserved
values or ranges for documentation and examples. The IESG also understands
that sometimes the use of reserved values makes examples harder to read or
less apt. In these cases authors have several options:

 - The specification itself can request further values or codepoints to
be assigned.

 - The author can get permission from the holders of assigned values.
However, the stability of the assignment needs to be considered.

 - The author can request approval for use of non-example addresses,
names or codepoints, with an analysis of the expected effect of this use.

Documents that update previously published RFCs fall under less pressure
to update examples that have already been published. The use of reserved 
codepoints is still recommended in these documents when new examples are 
added or when examples change.

Upon publication of this statement, the IESG will apply the following 
requirements to documents submitted for publication as RFCs in the IETF
Stream. The document SHOULD use values reserved for examples where such 
assignments exist (e.g. BCP 32, RFC 3330, RFC 4735, and RFC 5156) and when
the necessary semantic can be communicated clearly enough. If unassigned
codepoints are desired it is RECOMMENDED that those codepoints be assigned
or registered.  If assigned codepoints are desired, it is RECOMMENDED that
the authors get approval from the current codepoint holder.  Designers of
new protocols SHOULD consider example usage and register or assign values
for example usage.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Sep 2008 14:19:53 -0400

A brief comment on this... I may have more to say later on...

--On Thursday, 18 September, 2008 10:07 -0700 The IESG
<[email-masked]> wrote:

> 
> The IESG has received the attached text for a proposed IESG
> Statement: IESG Statement on the Usage of Assignable
> Codepoints in Specification Examples
>... 
> 
>...

> 1) Spam: apparently valid email addresses in an RFC are widely
> believed to have been harvested and included in Spam lists.
> The domain may receive spam at mailboxes other than the one
> used in the example email address, if the domain name is used
> in common name or brute force attacks.

Please note that a careful reading of this paragraph would
either ban or discourage the appearance of author email
addresses in RFCs.  Yet such addresses have been a firm
requirement for many years (if I recall, since before there was
an IETF).  Questions:

	(i) Does the IESG intend to change the requirement for
	email addresses?
	
	(ii) Does the IESG believe that the appearance of a
	domain name in an email address in an example is somehow
	more harmful or likely to draw the attention of spammers
	than one in an "Author's Address" section?   If not,
	could you explain your reasoning?
	
	(iii) Does the IESG intend to pursue the idea, discussed
	many times, of creating a reserved mail domain and
	assigning all RFC authors mailboxes or aliases in it?

I note with interest that this statement does not appear to
apply (or at least does not appear to offer justification for
applying) these rules to domain names that do not appear in
email addresses (or in configuration files, etc.).  I note with
even more interest that reservation of "codepoints" for example
or other documentation purposes would violate existing IESG
statements and rules about conservation of scarce resources
(where scarcity is an issue) or would require negotiation with
other bodies.  

regards,
   john

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Sep 2008 10:34:46 +0200

Hi John,

Thanks for the comments. Please see inline.

> 	(i) Does the IESG intend to change the requirement for

No, that has not been the intention. I also don't think the statement 
say anything that explicitly changes that.

> 	could you explain your reasoning?

No, I don't think there is a difference from a spam perspective. From my 
point of view it is quite clear that the moment I stuck my email address 
in a internet draft I started receiving spam volumes several magnitudes 
larger than before. So as an author using your own address in an example 
may not make much difference from a spam perspective. However, it make 
more difference for other reasons, like if it is a test script you are 
putting in your email address in. If you are putting someone else email 
address into your document you may increase there volume of spam.

> 	assigning all RFC authors mailboxes or aliases in it?

We haven't discussed this at all at this point in time. I don't see how 
applicable this is to the general intention of the IESG statement to 
cover all type of codepoints, including domain names, email addresses, 
and media types. So if we want to continue any discussion on this topic, 
can we please that that in a separate thread.

> email addresses (or in configuration files, etc.).  

The statement intendeds to provide examples why using real domain names 
or other types of code points can be harmful. Reasons will vary with 
protocol and the type of "codepoint". And there will be cases where 
there will be no impact, maybe other than us being a little rude and 
using someone else domain name. Which I think is a good enough reason 
unless there some real counter reason while this particular name is so 
good for the example and can't be illustrated with another. And as the 
statement says, in those cases, please ask the owner before going ahead.

I note with
> (where scarcity is an issue) or would require negotiation with

Which IESG statements are you referring to? I can't find any on that 
topic, but I may be missing one.

There clearly are tradeoffs between assigning code-points and the 
possible scarcity or unavailability of them. Then one simple have to use 
another option of ensuring that this usage has minimal impact. Including 
using assigned values with the owners approval. It also include the 
consideration of the impact.

Maybe there are some text clarification that could help make this 
clearer. Adding something to the following bullet ", unless prevented by 
scarcity or other registration considerations."

I do like to point out that the goal with the statement is to have 
people think about these issues. Be aware that IESG will consider them 
and may object to certain usages unless reasonably motivated.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 19 Sep 2008 11:30:38 +0200

On Fri, Sep 19, 2008 at 10:34:46AM +0200,
 Magnus Westerlund <[email-masked]> wrote 
 a message of 122 lines which said:

> > I note with even more interest that reservation of "codepoints"
> > for example or other documentation purposes would violate existing
> > IESG statements and rules about conservation of scarce resources
> Which IESG statements are you referring to? 

The rules I'm personally concerned about when reading the proposed
IESG statement are:

RFC 5236, section 3.3 (which mentions "scarcity")

RFC 5237 for an example in a densely populated field

---

From: <[email-masked]>
Date: Fri, 19 Sep 2008 12:34:08 +0300

> 	(i) Does the IESG intend to change the requirement for

BTW, http://www.rfc-editor.org/rfc-editor/instructions2authors.txt
does not absolutely require including an email address (if you give
some other contact method, such as postal address or telephone
number), and there are RFCs that don't include it (e.g RFC 3718 
from 2004; perhaps others exist, too).

> 	could you explain your reasoning?

If you're an author, you have presumably given your permission to 
being listed in the Author's Address section, and can choose what 
address to put there.

IMHO the crux of the proposed text is that since using email addresses
(and domains, etc.) belonging to someone else can potentially cause harm
(although usually not very serious), it's better if the owner of the
address (instead of IESG) decides whether the potential harm is
acceptable or not -- and this should be opt-in (instead of assuming
that lack of complaints means its OK). 

(There may be exceptional cases when something else needs to be
done, though.)

Best regards,
Pasi

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Sep 2008 13:10:38 +0200

Hi Stephane,

See below:

> RFC 5236, section 3.3 (which mentions "scarcity")

Do you mean another RFC, that RFC is Improved Packet Reordering Metrics 
and Section 3.3 is the definition of Displacement metric.

> RFC 5237 for an example in a densely populated field

Yes, I am aware that there exist codepoints where there are little space 
to assign values for example usage. That is why this is recommendations, 
not strict requirements. And if you are writing a new protocol and you 
think there will be need to examples including a particular field, then 
you can create the example codepoints at time of defining the field.

I hear the message that we need to be clearer on that it might not be 
possible and the other alternatives is to be explored.

Cheers

Magnus Westerlund

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 19 Sep 2008 13:43:52 +0200

On Fri, Sep 19, 2008 at 01:10:38PM +0200,
 Magnus Westerlund <[email-masked]> wrote 
 a message of 50 lines which said:

> Do you mean another RFC,

Yes, that was RFC 5226, sorry.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Sep 2008 17:14:30 +0300 (EEST)

> from 2004; perhaps others exist, too).

There are also cases wheres where contacting the author would require 
somewhat unconventional methods, e.g. RFC 3542...

What disturbs me as a reviewer is when a draft does not include email 
address(es) of authors or where comments should be sent.  I'm having 
difficulty figuring out the usefulness of such a draft.

FWIW, IMHO, any spam argument seems bogus.  Anyone actively 
participating is already leaving such an email address footprint all 
over the net (including elsewhere in the IETF) that a) they already 
need protection mechanisms, and b) obfuscation methods (if used) 
should be reasonable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Fri, 19 Sep 2008 07:55:51 -0700

>the domain name is used in common name or brute force attacks.

Given that the IESG states that the use of valid email addresses 
causes unwanted traffic, will the IESG prohibit the use of valid 
email addresses in RFCs?

>However, the stability of the assignment needs to be considered.

Will authors have to seek the permission from the holders, in the 
case of domain names (e.g. www.w3.org), before using such domains in RFCs?

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Sep 2008 14:49:37 -0400

Pasi,

--On Friday, 19 September, 2008 12:34 +0300
[email-masked] wrote:

> John C Klensin wrote:
> 
>> > 1) Spam: apparently valid email addresses in an RFC are
>> > widely believed to have been harvested and included in Spam
>> > lists. The domain may receive spam at mailboxes other than
>> > the one used in the example email address, if the domain
>> > name is used in common name or brute force attacks.
>> 
>> requirement for many years (if I recall, since before there
>> was an IETF).  Questions:
>> 
> BTW,
> http://www.rfc-editor.org/rfc-editor/instructions2authors.txt
> does not absolutely require including an email address (if you
> give some other contact method, such as postal address or
> telephone number), and there are RFCs that don't include it
> (e.g RFC 3718  from 2004; perhaps others exist, too).

Others probably do exist, and I was aware of the language of the
requirement.  However, for standards track documents, I am aware
of IESG pressure on authors to, in fact, include email
addresses.  I suggest that, in practice, we can't really have it
both ways.

> If you're an author, you have presumably given your permission
> to  being listed in the Author's Address section, and can
> choose what  address to put there.

But you may not have explicit permission from the holder of the
domain in that address to expose them to additional traffic,
including traffic that uses dictionary methods or
sequentially-generated local-parts.   I apologize for being
difficult here, but I think the IESG really should be pushing
for "more exercise of good sense" rather than "more rules".   If
the desire is really "more rules", then 

	(1) I'm going to feel obligated to point out just how
	difficult it is to get such rules right, how much time
	it takes --from both the IESG and the community-- and to
	question whether that is the best use of resources, even
	as compared with the IESG having to spend a little more
	time evaluating special cases (a task that this
	statement clearly does not eliminate, since it includes
	provision for such special cases).
	
	(2) I suggest that the Nomcom, as part of its activity
	of trying to determine the sense of the community that
	feeds into the selection process, consider whether the
	community prefers that more time be spent on rule-making
	(or, worse, the enforcement of rules that exist only in
	the minds of the IESG) and then make selections
	consistent with that community preference.  To be more
	blunt about that, unless the community really wants more
	rules and priority given to the time that they might
	take, the Nomcom should be, IMO, seriously considering
	whether IESG incumbents or candidates who prefer more
	rule might better serve the community in other ways.

With regard to email addresses specifically, I very much agree
with what Pekka wrote:

>> participating is already leaving such an email address
>> footprint all over the net (including elsewhere in the IETF)
>> that a) they already need protection mechanisms, and b)
>> obfuscation methods (if used) should be reasonable.

But that is not the main point...

> IMHO the crux of the proposed text is that since using email
> addresses (and domains, etc.) belonging to someone else can
> potentially cause harm (although usually not very serious),
> it's better if the owner of the address (instead of IESG)
> decides whether the potential harm is acceptable or not -- and
> this should be opt-in (instead of assuming that lack of
> complaints means its OK). 

Ok.  We agree on the principle.  Moreover, if I haven't said it
already, I very much appreciate the efforts of the IESG to bring
this issue out in the open and to promote discussion of it,
rather than expecting people to deduce what is expected and then
see documents held up at a late stage if their deductions are
not correct.

I also note that "get permission" is an odd business.  Domain
names change.  For example, people change jobs, email providers,
and other arrangements.  Several prominent members of this
community have dropped domain names that were in use for many
years and switched to new ones after various combinations of
pressure and financial inducements.  I'm not likely to give up
"jck.com", largely because I'm a little pig-headed about the
"market" that creates the offers, but it probably wouldn't take
a very large incentive for me to stop finding the use of
"bogus.domain.name" amusing enough to justify (and I think I
have used it in IETF-related examples).  I believe "nokia.com"
is probably stable under current management and policies, but,
at one stage, I would have made equally strong predictions about
"univac.com", "apollo.com", and even "dg.com".   The RIRs
believe that address allocations (at least address allocations
since they came into being) are on loan and that, under various
circumstances, they could be repossessed.  Even without that,
many people expect that the future of IPv4 will involve a good
deal of migration of responsibility for address blocks.
Probably identifiers that are actually allocated under IESG
supervision are more stable, but we can't count on even those if
the relevant registries start running out of space.  SO, while
I'm sympathetic to the "permission" concept, I think it is often
meaningless in the long term (unless one expects new acquirers
of domain names or addresses to do due diligence on prior uses
and accept the consequences... and the IESG has already rejected
the argument that such a requirement is reasonable.

However, I also agree with your observation that the "harm" is
not very serious, a subject on which several people commented at
length during the last IETF list discussion on this subject.  I
believe that more rules have costs to the community, even if
only as encouragement and nutrition for those who consider
nit-picking a more valuable activity than producing standards
(especially Proposed Standards).  Consequently, unless serious
harm can be demonstrated, I'd rather see fewer rules and
discussion of them and more good sense backed up with general
guidance.  

> (There may be exceptional cases when something else needs to be

Of course, there will always be such cases.  The question is
whether, given that they exist, this sort of effort is
worthwhile.

I continue to believe that the IESG could do something much
easier and much more effective by issuing, not a collection of
new rules, but a simple statement requiring that people either
use suitably-reserved and dedicated identifiers or that they
explain, explicitly and subject to community review, why not.
Since good sense suggests using these identifiers when there is
not a plausible reason to do something else and general laziness
(and the desire to avoid last-minute debates about the
usually-trivial) is likely to encourage the use of such
identifiers unless there really is a reason why not.  Given
that, let's stop there and not try to anticipate all of the
possible reasons or create lengthy new sets of rules and
procedures.

best,
   john

---

From: <[email-masked]>
Date: Mon, 22 Sep 2008 11:49:07 +0300

John C Klensin wrote:

> I continue to believe that the IESG could do something much easier
> and much more effective by issuing, not a collection of new rules,
> but a simple statement requiring that people either use
> suitably-reserved and dedicated identifiers or that they explain,
> explicitly and subject to community review, why not.  

I think that's pretty much what we tried to do, but apparently,
the text doesn't quite read that way (and I agree that it's quite
long).

Best regards,
Pasi

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Sep 2008 11:40:22 +0200

Hi John,

I have tried to write a statement that allows the IESG to use common 
sense. However, the problem I have seen several times when the IESG 
tries to use common sense in issues that comes up regularly is that some 
people complains about not knowing about this and that we can't enforce 
it because there are no written rules. Thus the draft statement is an 
attempt to satisfy several different requirements:

- Provide motivation why there are issues with examples
- Provide some guidance on how to handle situations which aren't clear cut
- Be clear that this is something IESG do look at and authors need to 
think about.
- Prevent complaints about late surprise and heavy hands when we are 
applying what we think are common sense.

If you have a suggestion on how this better can be written up I am 
interested.

When it comes to harm, I think we clearly have some cases where examples 
can have really serious effects, configurations being what comes to 
mind. When it comes to email addresses they are primarily an annoyance, 
but I think any one of us would be might irritated to learn that the 
suddenly started receive spam in large quantities because someone 
published their address in example in an internet draft or RFC. I think 
that this is as far as this goes and something any contributor to the 
IETF unfortunately have to pay for their contribution in an open 
organization with open access to its documents.

Best Regards

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Sep 2008 12:01:23 +0200

> causes unwanted traffic, will the IESG prohibit the use of valid 

As I stated in response to John's question. No, the spam problem for us 
contributors are one of the prices to contribute to IETF unfortunately.

> case of domain names (e.g. www.w3.org), before using such domains in RFCs?

Depends fully on the context. In a reference I clearly say no. In a 
configuration script or as point to load validation data from, definitely!

Cheers

Magnus Westerlund

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Sep 2008 05:36:17 -0500

Hi, Magnus,

While not even dreaming of trying to speak for John, what I understood his 
point to be was that our process is, and needs to be, more than a set of 
rules.

You guys are going to get complaints (and you know that better than I do). 
But you're going to get complaints whether there is a perfectly-crafted IESG 
statement or not.

We've never recalled an AD, and we've never even had a public recall 
petition presented to the community. Please feel free to use your judgement, 
because the chances of that backfiring in any meaningful way are just about 
zero.

On this particular topic, I've been really dismayed that we've gotten so far 
into the weeds on what was obviously (to me) an attempt to do the right 
thing - provide example domain names - that is now morphing into a set of 
rules. You guys can keep tuning (and probably will keep tuning), but

- the principal justifications being advanced for why the problems you are 
solving are real, seem very bogus, and

- you are spending valuable AD time trying to perfect a set of rules, so you 
are trying to use your judgement now to avoid having to use your judgement 
in the future.

Specifications are hard. Corner cases make them harder. Don't write detailed 
specifications that you don't have to write. Asking authors to consider (!) 
using example domain names as part of last call comments, or AD review, is 
all that is required. Formally specifying when it is OK to use non-example 
domain names is overkill.

<rant>

The "but what if a domain name is published in an RFC and gets picked up by 
spammers?" concern wasn't even realistic in 2000. It's totally unrealistic 
now. I challenge you guys to name any domain name that started getting spam 
because it was published in an RFC (or Internet-Draft) after 2005, and 
received no spam before publication.

If this was a real problem we'd stop publishing author e-mail addresses in 
I-Ds and RFCs, and there's no chance we'll do that. So please take it as 
read that 99-point-something percent of e-mail is going to be spam anyway.

</rant>

Thanks,

Spencer, who will now start drinking caffeine...

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 22, 2008 4:40 AM
Subject: Re: Call for review of proposed IESG Statement on Examples

Hi John,

Best Regards

Magnus

-- 

Magnus Westerlund

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Sep 2008 07:43:17 -0400

--On Monday, 22 September, 2008 11:40 +0200 Magnus Westerlund
<[email-masked]> wrote:

> Hi John,
> 
> I have tried to write a statement that allows the IESG to use
> common sense. However, the problem I have seen several times
> when the IESG tries to use common sense in issues that comes
> up regularly is that some people complains about not knowing
> about this and that we can't enforce it because there are no
> written rules. 

Magnus, Spencer's note does a fairly good job of summarizing
most of my concerns.  Let me address a few things that he does
not, but please read his note along with this one.

First of all, I see a huge difference among three categories
that your note, and the draft statement, seem to roll together:

	(i) The class of things that the IPR WG might think of
	as "code", here including MIBs, configuration files,
	tables, and code excerpts that implementers are expected
	to copy, either verbatim or with simple, template-like,
	modifications.
	
	(ii) Test scripts and similar things, written in a form
	in which they will obviously be copied, perhaps modified
	slightly, and then executed repeatedly (with fairly high
	multiples of "repeatedly").
	
	(iii) Simple, illustrative examples that, even if
	executed, are not likely to be executed more than once
	by a given implementer.

One might draw the boundaries in other ways, but they are
different enough that saying "the cases in the first group are
harmful, therefore the cases in the third are harmful enough to
require extensive rules" is just bogus.

> Thus the draft statement is an attempt to
> satisfy several different requirements:
> 
> - Be clear that this is something IESG do look at and authors
> need to think about.
> - Prevent complaints about late surprise and heavy hands when
> we are applying what we think are common sense.

One can make extensive rules or one can apply common sense.  The
pushback when this came up was because of a perception that
common sense was _not_ being applied.   This document does not
somehow instantiate common sense, what it does it to transform
the rigid rule that was undocumented into the rigid rule that
is.  And, while "undocumented" makes things much worse, the real
objection is to the rigid rule, especially against the backdrop
of a concern that it will take far too much time and energy to
get such a rule right and that there will _still_ be exception
cases.

In general, any time you write a page of rules and case analysis
when a sentence of guidance would do, I (and perhaps others) are
going to object.  Keeping things simple is of significant and
substantive importance.

> If you have a suggestion on how this better can be written up
> I am interested.

Yes.  I've made that suggestion several times.  It was actually
in my previous note (see Pasi's comment).  Don't try to
delineate every case and build a rule on that basis.  Just
indicate that you expect safe/protected/reserved names (or
codepoints or other identifiers), to be used, especially when
they occur in situations in which copying and repeated execution
are likely and that, if the author believes otherwise, that must
be explained in a comment (in the document or wherever else you
would like it) that is clear enough that the community can
comment on the justification during Last Call.  If you want to
say something about the difference between new and revised
documents, I would, based on recent experience, appreciate it,
but I don't think even that is necessary.

> When it comes to harm, I think we clearly have some cases
> where examples can have really serious effects, configurations
> being what comes to mind. When it comes to email addresses
> they are primarily an annoyance, but I think any one of us
> would be might irritated to learn that the suddenly started
> receive spam in large quantities because someone published
> their address in example in an internet draft or RFC. I think
> that this is as far as this goes and something any contributor
> to the IETF unfortunately have to pay for their contribution
> in an open organization with open access to its documents.

See Spencer's note about spam and the comment above about
conflating "configurations" with "email addresses in a purely
illustrative example".

regards,
   john

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Sep 2008 13:58:01 +0200

Spencer Dawkins skrev:
> Hi, Magnus,
> 
> While not even dreaming of trying to speak for John, what I understood 
> his point to be was that our process is, and needs to be, more than a 
> set of rules.
> 
> You guys are going to get complaints (and you know that better than I 
> do). But you're going to get complaints whether there is a 
> perfectly-crafted IESG statement or not.
> 
> petition presented to the community. Please feel free to use your 
> judgement, because the chances of that backfiring in any meaningful way 
> are just about zero.
> 
> On this particular topic, I've been really dismayed that we've gotten so 
> far into the weeds on what was obviously (to me) an attempt to do the 
> right thing - provide example domain names - that is now morphing into a 
> set of rules. You guys can keep tuning (and probably will keep tuning), but
> 
> - the principal justifications being advanced for why the problems you 
> are solving are real, seem very bogus, and
> 
> - you are spending valuable AD time trying to perfect a set of rules, so 
> you are trying to use your judgement now to avoid having to use your 
> judgement in the future.
> 
> Specifications are hard. Corner cases make them harder. Don't write 
> detailed specifications that you don't have to write. Asking authors to 
> consider (!) using example domain names as part of last call comments, 
> or AD review, is all that is required. Formally specifying when it is OK 
> to use non-example domain names is overkill.

I not trying to find perfect rules or even guidelines. I trying to find 
something that is reasonably works and is understandable by the 
community. And this is not about non-example domain names. It is about 
the general case. I thought that I had managed to do a reasonable 
generalization of the statement to cover examples of all types that may 
cause issues. But I am apparently wrong. However, I don't know if it is 
a function of the discussion around SMTP that make everyone dive 
straight into email addresses and domain names.

But I do get the message make it even more general and don't have a lot 
of rules. Simply a statement about this and the need to consider it. 
Because I still have the feeling that if we don't publish any statement 
about examples then we will have a lot of complaints that;
- the ID checklist can't contain think of statements because it is not a 
rule
- as you haven't informed the community we will refuse to change text 
even if problematic.

I also note that when we don't document reasonably well it becomes 
impossible for others than the long timers to understand what should be 
thought of.

> 
> <rant>
> 
> The "but what if a domain name is published in an RFC and gets picked up 
> by spammers?" concern wasn't even realistic in 2000. It's totally 
> unrealistic now. I challenge you guys to name any domain name that 
> started getting spam because it was published in an RFC (or 
> Internet-Draft) after 2005, and received no spam before publication.
> 
> If this was a real problem we'd stop publishing author e-mail addresses 
> in I-Ds and RFCs, and there's no chance we'll do that. So please take it 
> as read that 99-point-something percent of e-mail is going to be spam 
> anyway.
> 
> </rant>

I agree that it is a red herring from most perspectives. I think all of 
us that have a reasonably big foot-print on the Internet do receive spam 
in quite large volumes. I personally receive on the order of 50 spam per 
day to my work account which is very well published, while my private 
account gets 5 per month. This is the result from writing to IETF mail 
lists, having my address in drafts and RFCs. No question about it. And I 
would be kind of annoyed if anyone of you decided to publish one of my 
private addresses without my permission. That is why SPAM was listed as 
an example.

But as people are apparently get annoyed of this as an example of 
unwanted traffic I guess we should remove it because it isn't the most 
important.

Cheers

Magnus Westerlund

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 22 Sep 2008 09:14:32 -0400

...
> right thing - provide example domain names - that is now morphing into a 

+1

Perhaps the most important lesson from the last few years of diligent effort to 
create and write detailed rules is to make clear that that is not where IETF 
problems reside.

Yes, we need good documentation.  Far better than we used to have.  But that 
does not mean that the documents need to list microscopic rules.

The reality we have seen is that folks don't remember the rules, don't follow 
the fine-grained details and the details from one rule to the next are starting 
to conflict.

What we need are documents that define scope, goals, principals, and the like.

The application of these more-basic constructs needs to demonstrate careful 
thought and compelling need. And they need to demonstrate it with careful 
documentation.

Note a continuing disparity:  What is significant about documentation of a 
decision for an appeal is that they usually are careful to describe the 
situation and careful to provide the basis for the decision.  Publicly.

This is in marked contrast the handling of something like a Discuss.  Much more 
modest requirements for documentation and publication.

So...

Fewer rules.  More concepts and rationale.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 22 Sep 2008 07:28:31 -0600

Magnus Westerlund <magnus dot westerlund at ericsson dot com> wrote:

> I think any one of us would be might irritated to learn that the 
> published their address in example in an internet draft or RFC.

and later:

> And I would be kind of annoyed if anyone of you decided to publish one 
> of my private addresses without my permission. That is why SPAM was 
> listed as an example.

Is that the concern, that people will start receiving spam to their 
e-mail addresses, or excessive or inappropriate hits on their Web site, 
unexpectedly or without their permission, because these addresses were 
used in an RFC or I-D unexpectedly or without their permission?

I think that is a completely different use case, and moral problem, from 
using one's own e-mail address or URL in a document, or using well-known 
addresses such as <[email-masked]> that have already appeared in 
well-known and heavily cited RFCs (John's use case that launched the 
present debate).

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 22 Sep 2008 09:47:42 -0400

Magnus Westerlund wrote:
> it because there are no written rules.

No matter what you do, there will be complaints.

It's the nature of interesting social processes like the IETF.

So the fact that "some people" complain needs to be run through a dual-function 
filter.  The first is whether the complaint makes sense or is merely serving as 
an unfortunate form of entertainment for the complainer.  In the former case, is 
"makes sense" obvious and compelling?

The other filter is community concern.  If the complaint gets no serious support 
from others in the community and isn't otherwise compelling, then it's noise. 
Noise can be ignored.  Or rather, for a system as noisy as the IETF community 
is, noise MUST be ignored.

I'll predict that the more serious issue underlying real complaints about "not 
knowing" has to do with predictability.

If folks can't predict what the IESG will take exception to, they have a right 
to complain.  And making an infinite list of fine-grained details doesn't solve 
this... as we have now seen.

For the exemplar that triggered the current round of effort, an established bit 
of documentation, for a long-standing and popular standard, was being required 
to make a change where no specific problem had been documented.

That there is a general truth to the general tendency to have some possible 
problems with poorly chosen names doesn't change the fact that this particular 
case had no history of any reported problems, after 20 years.  Or 10, depending 
on you count.  One decade or two.

This made the IESG demand significantly unpredictable.  And please note that the 
presence of detailed rules didn't help, since the IESG citation was for rules 
that didn't substantiate the demand.  The rules were written as guidance, not 
inflexible, normative requirement.

So it didn't help to have lots of rules and it didn't help that the IESG was 
paying attention to a legitimate problem... legitimate in the general case.

What was missing was a deeper consideration of the particular situation.  And 
writing fine-grained rules won't fix that.

  Thus the draft statement is an
> applying what we think are common sense.

This is an excellent list.  Really.

The problem is not with the goals, but how these goals are being pursued.

> can have really serious effects, 

Correct.  However please note how you phrased this:

    Some cases.

    Examples.

That form of statement will tend to hold true for any rule or decision that 
isn't patently silly.  In complex systems, there is certain to be an "example" 
of almost any problematic case one can imagine.

Notice that you didn't say things like:

    Usually, or always

and

    Significant problem

These decisions by the IESG need to present some sort of cost/benefit statement, 
where the cost is not based on a mere existence proof that a problem has been 
seen sometimes, but a basis for knowing that there is a real and substantial 
problem... in the current real situation.

In other words, the problem is clearly serious and clearly applicable to the 
current case.

And please note that an analysis like this will a) not require fine-grained 
rules to be documented, and b) will stand up against stray complaints.

d/
-- 

   Dave Crocker

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Sep 2008 16:00:52 +0200

> used in an RFC or I-D unexpectedly or without their permission?

 From my point of view this is one of many reasons why care needs to be 
taken with what one puts into examples. Clearly a minor issue, more 
about etiquette than anything else. Configuration files are clearly one 
of the major issues where inclusion of someones NTP sever in something 
that accidentally gets deployed can amount to a DDoS.

> well-known and heavily cited RFCs (John's use case that launched the 

Agreed. And that was not really what the discusses from IESG was based 
on either. The one I reacted to where the ones belonging to commercial 
websites. Which, I personally consider inappropriate an a bit rude. From 
my point of view the long usage and the lack of actual reported issues 
and minimal impact a change would have on the situation is why I cleared 
when I finally was engaged in any discussion on the issue.

However, the goal with the statement is to cover the general issues not 
specific ones.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Sep 2008 16:07:00 +0200

John,

I might be to much a protocol designer to be a good writer of rule 
documents. I will take your, Spencer's and Dave's input when 
reformulating the note.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 22 Sep 2008 10:09:44 -0400

I think that this statement is reasonably clear, and I support it.

To be pedantic, a statement that an RFC author's contact information  
is not an example could be added.

Regards
Marshall

On Sep 18, 2008, at 1:07 PM, The IESG wrote:

> believed
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 22 Sep 2008 11:19:58 -0400

Magnus Westerlund wrote:
>     From 

Magnus,

Offhand, it would seem as if these ought to be strong factors nearly always.  If 
folks disagree, that's probably worth discussing, since this is such a 
fundamental issue.  (It's called protecting the installed base...)

At the least, it would seem that it ought to require that a very compelling case 
be made for changing things.

 From what you are saying, it swayed you at the end.  But evidently you weren't 
swayed at the start.  It might be worth understanding why not, since it might 
provide some input for better understanding these types of disconnection between 
a working group's comfort with a decision, versus and area director's dis-comfort.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Mon, 22 Sep 2008 08:47:31 -0700

At 03:01 22-09-2008, Magnus Westerlund wrote:
>As I stated in response to John's question. No, the spam problem for 
>us contributors are one of the prices to contribute to IETF unfortunately.

Item (1) takes us one step closer to discouraging the publication of 
email addresses instead of seeing it as one of the prices to pay for 
contributing to the IETF.  I suggest dropping item (1) from the 
proposed statement.

>configuration script or as point to load validation data from, definitely!

That sounds sensible at the outset.  The following question is for a 
specific case.  Will the IESG ask (I-D) authors to seek permission 
from the W3C before using the domain name in XML schemas?

Regards,
-sm

---

From: Randy Dunlap <[email-masked]>
Date: Mon, 22 Sep 2008 09:05:00 -0700

> = = = = = = Text of Proposed IESG Statement = = = = = = =

Hi,

My comment isn't similar to the rest of the mail threads here:

I find the use of the word "codepoint" confusing here.  It apparently means
something different to some readers (or writers) here.  To me (and I'm almost
never unique in things like this), it means a point in a character set
space.  See http://en.wikipedia.org/wiki/Codepoint or possibly
http://code.google.com/search/#q=codepoint .

Maybe here it means an extension of that, like "a (virtual) point in some
world network address space."  Is that close?

Perhaps it should define what a codepoint is or use some other word/phrase
for it.

> new protocols SHOULD consider example usage and register or assign values

Regards,
---
~Randy

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Sep 2008 14:35:32 +0200

SM skrev:
> contributing to the IETF.  I suggest dropping item (1) from the proposed 
> statement.

Okay.

> specific case.  Will the IESG ask (I-D) authors to seek permission from 
> the W3C before using the domain name in XML schemas?
> 

I would say no, without looking into this. Schema names that include 
domains clearly need to be included and in my view the one publishing 
schemas implictly have allowed the usage. I think this comes back to the 
common sense angle of this.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Sep 2008 14:38:01 +0200

> Perhaps it should define what a codepoint is or use some other word/phrase

Thanks Randy,

We used codepoint as the best word that was sufficiently encompassing 
about the different type of names and values for different type of name 
and value spaces. I think a clarification/definition will be the best 
way to resolve your comment.

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Sep 2008 15:07:26 +0200

Dave CROCKER skrev:
> 
> 
> Magnus Westerlund wrote:
>>     From my point of view the long usage and the lack of actual 
>> reported issues and minimal impact a change would have on the 
>> situation is why I cleared when I finally was engaged in any 
>> discussion on the issue.
> 
> 
> Magnus,
> 
> Offhand, it would seem as if these ought to be strong factors nearly 
> always.  If folks disagree, that's probably worth discussing, since this 
> is such a fundamental issue.  (It's called protecting the installed 
> base...)

Fundamentally I do agree on this. However, I am also quite concerned 
that we in the IETF are not receiving reports about any problems we are 
creating. If an example creates just a little extra load this may never 
be looked into. One simply accepts it. I see a problem of correctly 
categorizing the impact of examples. That is why I would error on the 
side of caution. Especially when this can be done without any 
significant impact on how examples reads.

> 
> At the least, it would seem that it ought to require that a very 
> compelling case be made for changing things.

If you are talking about updates to already deployed specifications I 
agree. But when it comes to new specifications that are written now I 
don't see a reason to not think about this.

> 
>  From what you are saying, it swayed you at the end.  But evidently you 
> weren't swayed at the start.  It might be worth understanding why not, 
> since it might provide some input for better understanding these types 
> of disconnection between a working group's comfort with a decision, 
> versus and area director's dis-comfort.

In the SMTP case there where never any communication with me in the loop 
about my discuss position until after the appeal has been submitted. 
 From the point we actually had any discussion it didn't take that long. 
But clearly a communication problem that involved several parties.

I still consider it impolite to use others domain names and would have 
preferred to have some of the domain names changed for that reason.

Cheers

Magnus Westerlund

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Sep 2008 14:59:32 +0200

On 18 sep 2008, at 19:07, The IESG wrote:

> The document SHOULD use values reserved for examples where such
> the authors get approval from the current codepoint holder.

First of all: note that this issue goes well beyond the traditional  
reach of the IESG. For instance, I've written books and taught  
training courses where obviously examples had to be used.

For domain names I used example.com et al, operating under the idea  
that anyone who registers such a domain can't complain that it's used  
in examples.

However, IP addresses are often a concern. IPv4 only has 192.0.2.0/24  
which is completely insufficient for decent examples. IPv6 has  
2001:db8::/32 which is big, but still not useful in all cases because  
it's often necessary to clearly show that two address ranges are  
different so they must be different prefixes. A common solution is to  
use RFC 1918 addresses for examples but I don't like it in general and  
it's not really workable in certain cases because these addresses  
carry a special meaning. (I.e., an RFC 1918 address in a 6to4 example  
would create the impression that this is a workable combination which  
isn't the case.)

So I suggest reserving three or so additional IPv4 and IPv6 global  
unicast prefixes for documentation purposes, that look sufficiently  
different from each other.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 20 Sep 2008 20:37:33 +0200

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Sep 2008 11:08:29 -0400

--On Tuesday, 23 September, 2008 15:07 +0200 Magnus Westerlund
<[email-masked]> wrote:

>...
> I still consider it impolite to use others domain names and
> would have preferred to have some of the domain names changed
> for that reason.
>...

Magnus,

This is actually another example of why the rules should be kept
as simple as possible, rather than trying to cover every case.
Consider the following examples:

	(1) I use "disney.com" in an example without their
	permission and in a way that they consider rude.  Given
	their well-established history of aggressively
	protecting their well-known trademark, they don't need
	the IESG to protect them.   Indeed, doing so in an RFC
	might result in a situation in which we would need to
	take the RFC down, so it would be very poor practice...
	but not because of rudeness and a problem the RFC Editor
	should address, not the IESG.
	
	(2) J. Random IETF-Participant registers
	"magnuswesterlund.biz." and uses it in examples.  Some
	of those examples have a tone that you would consider
	rude.  But, since he is the proper registrant of that
	name, none of the rules proposed so far would apply.
	
	(3) I use "ibm.com" in an example that constitutes free,
	and favorable, advertising of their product.  They don't
	consider it rude; they might write me a thank-you note.
	
	(4) The history of using "foo" and its variations in
	information technology examples goes back a very long
	time and examples using those forms predates the first
	registration of "example" names by years.  Independent
	of arguments about the rudeness (or lack thereof)
	associated with use of newly-coined domain names the
	"belong" to someone else, anyone managing to register
	these particular names could reasonably be assumed to
	have done sufficient due diligence to understand and
	accept the risks -- the wide use of the terms doesn't
	change because someone decides to try to exploit them
	commercially.

I want to stress that we are in complete agreement that having a
set of reserved names available is a good idea, that people
should think about the names (or "codepoints") they decide to
use, and that the reserved names ought to be the default in the
absence of other considerations.  What I'm objecting to is only:

	-- the attempt to make the jump from general guidance
	about good (and polite) practices to a list of cases and
	specific rules
	
	-- the attempt to equate your personal feelings about
	rude behavior with  a position that seems to amount to
	"I think this causes harm, so you need to prove that it
	doesn't"
	
	-- the assumption that, since ill-chosen example
	configuration file examples can cause problems, so can
	any other use of poorly-chosen names or identifiers.

and the implicit belief that the details and explicit rules in
the document, and hence this discussion, are a good use of IESG
and the community's time.

    john

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 23 Sep 2008 14:26:50 -0400

>    However, I am also quite concerned 
> creating. 

If we are not receiving any reports, then any assertion that there is a problem 
is a theoretical exercise.  Such exercises can be useful, but they form a very 
poor basis for blocking something that has a couple of decades of established 
practice.

This morning's posting by John K nicely captures this problem:  We need to make 
a distinction between topics worthy of discussion (and even concern) versus the 
authoritative imposition of blockage, particularly when it is blockage by IETF 
management that conflicts with a competent IETF working group's decision.

The bald form of this is:  Do you really think you know more about what an email 
specification needs to contain than does an experienced email working group?

Sometimes the answer will be yes.  If so, it needs to be explained.  Carefully 
and fully.

Yes, my phrasing such a question is unpleasant, because it is confrontational. 
But so is a Discuss.  It is an AD confronting the competence of a working group.

The failure to ask such a question and then answer it satisfactorily invites an 
appeal or an artificial change to a specification.  In other words, it invites 
gratuitous delay or it invites spontaneous and therefore ill-advised changes to 
a document that has otherwise been developed carefully over time and with 
extensive review.

This does not mean that there should be no Discusses.  It does mean that a 
Discuss needs to be based on truly compelling information that a working group 
either lacked or misunderstood.  And it needs to explain this deficiency in the 
working group's process.

> don't see a reason to not think about this.

This thread was triggered by changes demanded for an established document.  The 
current situation has never been theoretical or abstract.  It has only pertained 
to a real specification with 2 decades of history.

"Changing things" means "changing things that have existed in an RFC, 
potentially for a very long time."  It does not mean "changing things from one 
I-D to the next".

>>  From what you are saying, it swayed you at the end.  But evidently 
>> you weren't swayed at the start.  It might be worth understanding why 
>> not, since it might provide some input for better understanding these 
>> types of disconnection between a working group's comfort with a 
>> decision, versus and area director's dis-comfort.
> 

This suggests a process failure of some sort.  Either in the particulars of this 
case or in the basic way a Discuss is developed, pursued and resolved.  My 
impression is the latter.

This makes it worth considering how things could be changed to make concerns, 
such as you had, easier and less painful to resolve.

d/

-- 

   Dave Crocker

---

From: John Leslie <[email-masked]>
Date: Tue, 23 Sep 2008 15:10:58 -0400

Dave CROCKER <[email-masked]> wrote:
> Magnus Westerlund wrote:
> 
>> However, I am also quite concerned that we in the IETF are not
>> receiving reports about any problems we are creating. 
> 
> If we are not receiving any reports, then any assertion that there is a 
> problem is a theoretical exercise.

   A DISCUSS is not an _assertion_ that there is a problem: it is a call
for deliberation.

> Such exercises can be useful, but they form a very poor basis for
> blocking something that has a couple of decades of established practice.

   Here's the heart of this discussion: because a DISCUSS is blocking,
Dave asserts it must not be exercised without substantial research.

   IESG members, OTOH, don't have time for substantial research for
roughly 1,000 pages of documents per week. Dave's position is not
scalable to where we are today, least of all scalable to the future.

> This morning's posting by John K nicely captures this problem:  We need
> to make a distinction between topics worthy of discussion (and even
> concern) versus the authoritative imposition of blockage, particularly
> when it is blockage by IETF management that conflicts with a competent
> IETF working group's decision.

   The former is reasonable, even to Dave.

   The latter is a mythical beast.

   Our system would work much better if folks like Dave chose to consider
each DISCUSS to be an instance of the former, and explained why they
think the concern is unwarranted.

> The bald form of this is:  Do you really think you know more about what
> an email specification needs to contain than does an experienced email
> working group?

   Straw man alert!

1) There was no Working Group: this was an Individual Submission.

2) Only an Apps AD would be expected to concentrate on what an email
   specification needs: the other ADs are expected to concentrate on
   other aspects.

> Sometimes the answer will be yes.  If so, it needs to be explained.  
> Carefully and fully.

   I dissent: this fails the scalability test.

> Yes, my phrasing such a question is unpleasant, because it is 
> confrontational. But so is a Discuss.  It is an AD confronting the 
> competence of a working group.

   Dave chooses to see it that way. I don't. I choose to see it as
a call for deliberation, indicating that the document in question may
be in danger of misinterpretation.

   Granted, 100 pages of specification is probably _always_ in danger
of misinterpretation... ;^)

> The failure to ask such a question and then answer it satisfactorily 
> invites an appeal or an artificial change to a specification. In other 
> words, it invites gratuitous delay or it invites spontaneous and
> therefore ill-advised changes to a document that has otherwise been
> developed carefully over time and with extensive review.

   The authors' names are in the document: they can choose to explain
or they can choose to take an "easy out". I'd prefer they explain...

> This does not mean that there should be no Discusses. It does mean
> that a Discuss needs to be based on truly compelling information that
> a working group either lacked or misunderstood. And it needs to
> explain this deficiency in the working group's process.

   Sounds like Dave is campaigning for AD. If so, three cheers!

>> In the SMTP case there where never any communication with me in the
>> loop about my discuss position until after the appeal has been
>> submitted. From the point we actually had any discussion it didn't
>> take that long. But clearly a communication problem that involved
>> several parties.
> 
> This suggests a process failure of some sort. Either in the particulars
> of this case or in the basic way a Discuss is developed, pursued and
> resolved. My impression is the latter.

   I'm willing to stipulate the latter, though the easiest finger to
point is at the Sponsoring AD, who had the theoretical responsibility
to follow through.

   In this case, Lisa agreed to list the state as "Revised I-D needed"
and the author didn't provide a revised ID. We have no current procedure
specifying what happens then. Possibly we need one, but I certainly
don't volunteer to write it.

   The easiest way, IMHO, would be for the author to explain to the
sponsoring AD why he believe the request unreasonable, and have the
sponsoring AD pass that on to the DISCUSSing AD(s). Does someone want
to write that up? What constitute an "explanation"? Does it need to
be addressed to the sponsoring AD? What if it's instead posted to a
mailing-list the AD is "likely" to read? Should the email Subject
indicate this is an explanation, or is it sufficient to bury a
sentence or two in what looks like a rant? (Again, I certainly don't
volunteer to write it.)

> This makes it worth considering how things could be changed to make 
> concerns, such as you had, easier and less painful to resolve.

   I totally agree!

--
John Leslie <[email-masked]>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 23 Sep 2008 14:19:01 -0500

>   A DISCUSS is not an _assertion_ that there is a problem: it is a call

With you so far, all the way down to ...

> Dave asserts it must not be exercised without substantial research.

Out of the eleventy-seven flavors of DISCUSS, some ARE blocking. Others 
aren't intended to survive the first telechat ("process DISCUSS", or 
"discuss DISCUSS", and after sitting with the IESG for three years I don't 
know if these are the same or not). All wear the same nametag.

My understanding of Dave's point is that a DISCUSS must not be BLOCKING 
without substantial research. That's not quite the same thing.

Thanks,

Spencer

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Sep 2008 15:58:08 -0400

>>>>> "Spencer" == Spencer Dawkins <[email-masked]> writes:

    Spencer> Out of the eleventy-seven flavors of DISCUSS, some ARE
    Spencer> blocking. Others aren't intended to survive the first
    Spencer> telechat ("process DISCUSS", or "discuss DISCUSS", and
    Spencer> after sitting with the IESG for three years I don't know
    Spencer> if these are the same or not). All wear the same nametag.

All discusses are blocking.  Some discusses are intended to be removed
either before their blockage slows anything down, or before some
point.