Subject: Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

From: John C Klensin <[email-masked]>
Date: Fri, 07 Nov 2008 23:58:29 -0500

--On Tuesday, 21 October, 2008 08:02 -0700 The IESG
<[email-masked]> wrote:

> The IESG has received a request from an individual submitter
> to consider the following document:
> 
> - 'IESG Procedures for Handling of Independent and IRTF Stream 
>    Submissions '
>    <draft-housley-iesg-rfc3932bis-04.txt> as a BCP

Russ, Harald, and IESG,

While the version listed in the Last Call was -04, I note that
-05 has been posted and my comments are addressed to it.   As a
procedural observation, my recollection is that, for many years,
the IESG has been discouraging posting of new versions of
documents  during Last Call, precisely to avoid confusion about
which version to comment on. 

While this document is much improved from earlier versions, I
believe it is not nearly ready for BCP publication.  I see
sweeping and more specific issues as well as several nits.

Sweeping Issue:

The assertion of "harm" is a very serious one.  We claim that
the Internet is incredibly robust and that there are few
proposed changes that can actually cause significant damage.  If
the places in which "harm" is used in this document are really
intended to mean "contrary to the spirit of the IETF standards
process" or 
even "damaging to the effectiveness of the standards process",
then say that.  Note that the first example in Section 4 is
clearly about something that is problematic for the standards
process with no need to believe that the alternate path is
"harmful to the Internet", while the second one falls into the
category of an inappropriate extension (more discussion on that
below).  Even getting from "hard-to-debug interoperability
problems" to "harm to the Internet" would be a stretch (if the
authors had been able to produce a careful explanation of how to
experiment with those bits in an escape-proof walled garden, the
document might still describe a bad idea, but that would become
a technical judgment --one that this document asserts the IESG
is not supposed to make-- and it would not have been, a priori,
harmful. I believe that the assertion of "harm to the Internet"
is a sufficiently strong one that the IESG should not make it
without clear evidence of community consensus, starting with an
explanation of why it thinks there is a problem (nor merely
asserting "harm") and including an IETF-wide Last Call on the
assertion and explanation.

Specific Issues

(1)  The IESG should never make an assertion that is known to be
false.  This has been an issue since 3932 was published and then
interpreted in a way that several of us did not anticipate; a
revision should not require the IESG to lie (or continue lying).
The fact is that, subject to publication delay, this document
and RFC 4846 permit publication of documents considered by WGs
and rejected.  In addition, some Independent Submissions receive
very extensive review in the IETF.  I hope we are not moving
into the sort of lawyer-land in which formally disclaiming
knowledge --counter to observable fact that the knowledge
exists-- may have a special meaning.  Even if the IESG has not
reviewed a document, it doesn't imply that "the IETF" has not.
If we are not moving to that part of lawyer-land, then it may be
appropriate to say that the IETF takes no position on whether a
document meets certain criteria or that there was no
determination of IETF consensus, but it is not appropriate to
say that the IETF "disclaims knowledge" (or "has no knowledge")
without a case-by-case determination of whether any significant
review within the IETF occurred.

The third paragraph of the Introduction should be modified to
change "are not reviewed" to "are not required to be reviewed"
or equivalent.  The second sentence of that paragraph should be
removed entirely unless the IESG wants to deprive itself of
flexibility to formally ask for community input by prohibiting
the use of Last Calls on Independent Submission drafts (a
flexibility that language in 4846 was intended to preserve).

As a further example of this problem, consider the last
paragraph of the Introduction, where the text talks about the
IESG pushing a document into the Independent stream that had
been "submitted to the IETF".   Such documents are often
reviewed in the IETF before being called to the IESG's attention
via a publication request and then presumably reviewed and
discussed by the IESG (or at least parts of it).

(2) The numbered list in Section 3 is the substantive core of
this document.  "Harmful" in Item 3 is "potentially damaging to,
or problematic for, the IETF Standards Process", not "harmful to
the Internet".   "Potentially" is important there too.  The IESG
should not be expected to foretell possible futures or provide
an analysis of how damage might occur: it should merely have to
have a reasonable basis for believing that WG or other standards
process disruption might occur or that an end-run is being
attempted.

Item 5, when read in the context of paragraph 5 of that section
("The last two...") is a horse of a different color.  Let me
restate what is being said in that Paragraph:    A document
makes it through the standards-track process and is approved,
with community consensus that presumably includes its provisions
for review of changes and extensions, and published.   Some time
later, a document comes along as an Independent Submission that
extends the original spec in some way.   Here, the IESG asserts
its right, without any community review, to say "never mind what
decision was made by community consensus and included in the
original document; we are going to apply a different criterion
entirely".  I believe that, in most cases, the more appropriate
action is to invoke Item 3, ask for a publication delay, and go
back to the community to get consensus for a revised procedure
for signing off on changes or extensions.

Textual nit-picking

* The second full paragraph of the Introduction ("The IETF is
responsible..."), second sentence, should read "..., and any
other IETF-generated Informational or Experimental documents".
Otherwise, one may suck most of the Independent Submission
stream into the IETF stream, contradicting the rest of the
document. Part of the problem with the text that is now in the
document is that there is no clear definition of
"standards-related".

* The document is confused about tense and mood of particular
words  and the general tone of the language used.  For example,
Section 1 Paragraph 5, last sentence, says "...was a
considerable drain... this is not" and should probably should
have been "...this was not".   As another example, consider the
numbered list in Section 3.  The first item says "has not
found", but the others are "The IESG finds".  Note also the
difference between "a finding" and the result of an unsuccessful
search ("we looked for it and didn't find it"). Personally, I
believe that the notion of the IESG making "findings"
excessively judicial -- several of these items are really
statements about the IESG's beliefs--  but that is a matter of
taste.

* The assertion in paragraph 7 of Section 1 is not correct.
While it probably was the case in the years _immediately_
preceding 2006, there was a period of several years in which the
IAB performed a (sometimes pro-forma) review of IRTF
Informational and Experimental documents and then published them
as IAB documents, with minimal or no interaction with the IESG.
Of course, IRTF submissions onto the standards track (if not
entirely prohibited) are outside the scope of this document.

* If you really want to right to claim "harmful to the
Internet", then Section 6 is incomplete, because some of the
classes of harm that you might be trying to prevent involve
security.

* Finally, unless the omission from the Acknowledgments was
intended as an editorial comment, I call your attention to the
rather extensive discussion I participated in about this
document among Jari, Olaf, yourself, and sometimes Leslie and
Harald in early October.   Although I identified the historical
problem with the description of IRTF processes there (a comment
that was apparently ignored, since the problematic text is still
present), several of my comments made it into the document.  I
believe that that the IETF's IPR rules, as well as ordinary
courtesy, require that set of contributions (which certainly
include Jari's) be reflected in the Acknowledgments.   That is
clearly a nit and, at some level, I don't care.   But it also
suggests, especially in context with some of the issues raised
above, that this document has been handled somewhat less
carefully that might be appropriate for something of its
importance.

 regards,
    john

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

---

From: SM <[email-masked]>
Date: Sat, 08 Nov 2008 06:19:43 -0800

At 07:02 21-10-2008, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the

I'm commenting on draft-housley-iesg-rfc3932bis-05 as that's the 
latest version at the moment.

In Section 1:

   "These RFCs, and any other Informational or Experimental standards-related
    documents, are reviewed by appropriate IETF bodies and published as part of
    the IETF Stream."

I read that as Informational and Experimental are also 
standards-related.   This is at odds with statements such as "This 
memo does not specify an Internet standard of any kind." which is 
usually seen in Informational and Experimental documents.

Although most people know what WG is, it doesn't hurt to have the 
following for clarity:

   This review was often a full-scale  review of technical content, with the
   Area Director (ADs) attempting to clear points with the authors, stimulate
   revisions of the documents, encourage the authors to contact appropriate
   working groups (WG) and so on.

In Section 3:

   "3. The IESG finds that publication is harmful to the IETF work done
       in WG <X> and recommends not publishing the document at this time."

I don't think that harmful is appropriate here.  I gather that the 
aim is to prevent circumvention of the IETF process and conflicts 
with work being carried out by the Working Group.

It could be phrased as:

     The IESG finds that this work is related to IETF work done in WG <X>
     and recommends not publishing the document at this time.

   "5. The IESG finds that this document extends an IETF protocol in a
       way that requires IETF review and should therefore not be
       published without IETF review and IESG approval."

I read that as "we cannot publish this document as it requires IETF 
review and IESG approval".  It may be easier for all parties to ask 
for an IETF review instead of rejecting publication outright.

   "The IESG assumes that the RFC Editor, in agreement with the IAB, will
    manage mechanisms for appropriate technical review of independent
    submissions. Likewise, the IESG also assumes that the IRSG, in
    agreement with the IAB, will manage mechanisms for appropriate
    technical review of IRTF submissions."

I don't see why there has to be assumptions here.  I suggest dropping 
the "assumes" and clearly spell out who is going to manage what.

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Sun, 09 Nov 2008 17:10:35 -0500

Thanks for your review.  My responses below.

>usually seen in Informational and Experimental documents.

Not all Informational and Experimental documents are 
standards-related.  Some are.  Not all Informational and Experimental 
documents are published as part of the IETF stream.  Some are.  I'm 
not sure what text change would help add clarity.

>   working groups (WG) and so on.

Sure.

>     and recommends not publishing the document at this time.

This is very similar to the point raised by John Klensin.  Since 
"harmful" is the term used in RFC 3292, I have asked Harald to 
provide some insights before making any changes to this wording.  I 
understand your point, but I want to make sure that I'm not missing 
some historical context.

>for an IETF review instead of rejecting publication outright.

The point is that a different publication path, not the Independent 
Publication Stream, is needed to obtain the IETF review.  That is the 
point of the IETF stream.

>I don't see why there has to be assumptions here.  I suggest 
>dropping the "assumes" and clearly spell out who is going to manage what.

How about:

The RFC Editor, in agreement with the IAB, shall manage mechanisms 
for appropriate technical review of independent submissions. 
Likewise, the IRSG, in agreement with the IAB, shall manage 
mechanisms for appropriate technical review of IRTF submissions.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Nov 2008 13:33:32 +0200

SM,

Thanks for your review and thank you Russ for the edits. I'll just 
comment on the one remaining issue:

>> I don't think that harmful is appropriate here. I gather that the aim 
>> is to prevent circumvention of the IETF process and conflicts with 
>> work being carried out by the Working Group.
>>
>> It could be phrased as:
>>

The issue is that mere conflict with work in a WG is not a sufficient 
reason to recommend against publishing. The IESG needs to make a 
judgment call that such publication would actually be harmful to the 
standardization process in the WG. For instance, in a recent case we 
approved an independent publication even if the document was clearly in 
the domain of a WG because we felt the circumstances supported it. You 
have to consider a number of aspects, where the WG is in its process, 
whether the particular submission is likely to confuse the process, etc.

I don't care so much what words we use to say this, but I would like to 
see that the ability to make this judgment call is retained. This is why 
I like the current text more than the proposed one above.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Nov 2008 14:11:37 +0200

John,

That was a long list of issues.

Let me start off by saying that RFC 3932 is already a part of the daily 
procedures we operate on. Draft-housley was written to make an 
incremental improvement on it. This incremental improvement is the 
publication of the headers and boilerplates document, which allows us to 
simplify the process for independent submissions and requires less use 
of IESG notes. I believe we both share the opinion that these are 
necessary and useful improvements. And, given that the headers and 
boilerplates change is going forward I hope we can accomplish the 3932 
revision at the same time.

Some more detailed answers:

> false.  ...  Even if the IESG has not

I agree that some independent submission stream documents have been in 
the IETF discussions. The issue is whether any sort of final review 
occurred. I'd be happy to see a wording change here. E.g., "Documents 
published in streams other than the IETF Stream are not reviewed by the 
IETF for such things ..." => "Documents published in streams other than 
the IETF Stream do not get a full review and are not required to get any 
review by the IETF for such things ..."

> The second sentence of that paragraph should be

As I commented to SM, I do believe the IESG needs to have the room to 
make judgment calls. In the case that I mentioned in that e-mail, we 
actually did ask for community input (after first getting some 
unsolicited input :-), though not in the form of document review or a 
last call. Again, I would like to see a change in the document on this.

> the Internet".

Yes. And this is what is says: "harmful to the IETF work".

> "Potentially" is important there too.  The IESG

I agree and I support adding this word.

On your sweeping issue: I believe most of the practical applicability of 
RFC 3932 has been in the area of checking for conflict with WG process 
(response 3) and IANA rules (response 4). Again, response 3 text is IMHO 
already clear. That being said, I do believe there should be an 
opportunity check for possible harm as stated in response 5 as well. 
 From my perspective that item is reserved for the cases where we, e.g., 
old protocols for which no IANA procedures have been defined. The 
practical reality is that we find such cases daily. We could make the 
text more specific, require more last calls and steps before such claims 
can be made. But frankly, I do not want to turn the independent 
submission process into a one that requires IETF review; it seems 
counter-intuitive. The IESG should make a quick check as described in 
the document, and if they screw up, the next step should be an appeal or 
talking to the nomcom. Of course, as I already explained I don't mind 
stating that a last call might be a useful tool in some special cases.

Jari

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Nov 2008 10:25:15 -0500

John & Jari:

>Let me start off by saying that RFC 3932 is already a part of the 
>daily procedures we operate on. Draft-housley was written to make an 
>publication of the headers and boilerplates document, which allows 
>us to simplify the process for independent submissions and requires 
>less use of IESG notes. I believe we both share the opinion that 
>these are necessary and useful improvements. And, given that the 
>headers and boilerplates change is going forward I hope we can 
>accomplish the 3932 revision at the same time.
>
>I agree that some independent submission stream documents have been 
>in the IETF discussions. The issue is whether any sort of final 
>review occurred. I'd be happy to see a wording change here. E.g., 
>"Documents published in streams other than the IETF Stream are not 
>reviewed by the IETF for such things ..." => "Documents published in 
>streams other than the IETF Stream do not get a full review and are 
>not required to get any review by the IETF for such things ..."

Even if such a document started in the IETF process, it did not 
complete the IETF process.

I can imagine a situation where a document goes to IETF Last Call 
that demonstrates that there is not consensus, and that document ends 
up being published in the individual submission stream, but that has 
not happened in my memory.  It certainly is not the normal situation.

I suggest: "Documents published in streams other than the IETF Stream 
do not receive full review by the IETF for such things as security, 
congestion control, or inappropriate interaction with deployed protocols."

>As I commented to SM, I do believe the IESG needs to have the room 
>to make judgment calls. In the case that I mentioned in that e-mail, 
>we actually did ask for community input (after first getting some 
>unsolicited input :-), though not in the form of document review or 
>a last call. Again, I would like to see a change in the document on this.

I suggest a replacement sentence: "Generally, there is no attempt for 
IETF consensus or IESG approval."

>I agree and I support adding this word.

The revised sentence says: "The IESG finds that publication is 
potentially harmful to the IETF work done in WG <X> and recommends 
not publishing the document at this time."

>On your sweeping issue: I believe most of the practical 
>applicability of RFC 3932 has been in the area of checking for 
>conflict with WG process (response 3) and IANA rules (response 4). 
>Again, response 3 text is IMHO already clear. That being said, I do 
>believe there should be an opportunity check for possible harm as 
>stated in response 5 as well. From my perspective that item is 
>reserved for the cases where we, e.g., old protocols for which no 
>IANA procedures have been defined. The practical reality is that we 
>find such cases daily. We could make the text more specific, require 
>more last calls and steps before such claims can be made. But 
>frankly, I do not want to turn the independent submission process 
>into a one that requires IETF review; it seems counter-intuitive. 
>The IESG should make a quick check as described in the document, and 
>if they screw up, the next step should be an appeal or talking to 
>the nomcom. Of course, as I already explained I don't mind stating 
>that a last call might be a useful tool in some special cases.

This was the whole point of RFC 3932 and the subsequent creation of 
the RFC Editorial Board.

The IESG received the following comment.  I think it is okay to share 
here with the sender's identity removed.

|  I think the draft is good as it is. I don't plan to respond in detail to
|  John Klensin's comments, but my bottom line is that I think the proposed
|  wording is correct. I do support the independence of the Independent stream,
|  but I don't think that deprives the IESG of the right to speak for the
|  IETF in asserting harm, etc.

I make this public to let people know that the IESG is also getting 
private comments on this draft.  To properly judge consensus, the 
IESG needs to hear from the whole community, not just a few vocal members.

Thanks,
   Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Nov 2008 11:19:56 -0500

John:

In the previous note from me, I responded to you and Jari on your 
main points.  In this note, I am responding to your editorial points.

>document is that there is no clear definition of

I agree.  The revised sentence reads: "These RFCs, and any other 
IETF-generated Informational or Experimental documents, are reviewed 
by appropriate IETF bodies and published as part of the IETF Stream."

>statements about the IESG's beliefs--  but that is a matter of

Agree: s/this is not/this was not/

To make them all parallel in structure, the first numbered item in 
section 3 becomes: "1. The IESG finds no conflict between this 
document and IETF work."

In RFC 3932, these numbered items (except the first one, which is the 
same until the modification above) begin "The IESG thinks"  During 
pre-Last-Call-review, I received feedback that "The IESG finds" was a 
better.  Now, you propose "The IESG believes".    I do believe that 
the current wording is better than the original.  I'm willing to 
change it to something else if there is consensus to do so.  What do 
other reviewers find/think/believe/prefer?

>entirely prohibited) are outside the scope of this document.

I suggest the following change to the first sentence in that 
paragraph: "Prior to 2006, documents from the IRTF were treated as 
either IAB submissions or individual submissions via the RFC Editor."

>classes of harm that you might be trying to prevent involve

Are you talking about this paragraph?

    If the IESG does not find any conflict between an independent
    submission and IETF work, then the RFC Editor is responsible for
    judging the technical merits for that submission, including
    considerations of possible harm to the Internet.  If the IESG does
    not find any conflict between an IRTF submission and IETF work, then
    the IRSG is responsible for judging the technical merits for that
    submission, including considerations of possible harm to the
    Internet.

>carefully that might be appropriate for something of its

The acknowledgements now include these names:  Jari Arkko, Leslie 
Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, and Olaf 
Kolkman.  My apologies to anyone who was inadvertently omitted.  If 
others ought to be included as well, please speak up.

Russ

---

From: SM <[email-masked]>
Date: Mon, 10 Nov 2008 10:07:38 -0800

Hi Russ,
At 14:10 09-11-2008, Russ Housley wrote:
>standards-related.  Some are.  Not all Informational and 
>Experimental documents are published as part of the IETF 
>stream.  Some are.  I'm not sure what text change would help add clarity.

I understand that.  You provided some text in a later message which 
sounds better.

>understand your point, but I want to make sure that I'm not missing 

Jari's message provided me an insight of why the word is used and 
about documents on which the IESG reaches conclusion 5.

>mechanisms for appropriate technical review of IRTF submissions.

That sounds better.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 10 Nov 2008 10:21:42 -0800

Hi Jari,
At 03:33 10-11-2008, Jari Arkko wrote:
>The issue is that mere conflict with work in a WG is not a 
>sufficient reason to recommend against publishing. The IESG needs to 
>make a judgment call that such publication would actually be harmful 
>to the standardization process in the WG. For instance, in a recent 
>case we approved an independent publication even if the document was 
>clearly in the domain of a WG because we felt the circumstances 
>supported it. You have to consider a number of aspects, where the WG 
>is in its process, whether the particular submission is likely to 
>confuse the process, etc.

I see your point.  I do expect the IESG to make a judgement call and 
not turn down a work merely because it may have some relation to the 
work being carried out in a Working Group.  Although I don't like the 
word "harmful", I see the rationale for that word in the text.

>I don't care so much what words we use to say this, but I would like 
>to see that the ability to make this judgment call is retained. This 
>is why I like the current text more than the proposed one above.

I agree with you.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Nov 2008 17:05:35 -0500

--On Monday, 10 November, 2008 11:19 -0500 Russ Housley
<[email-masked]> wrote:

> John:
> 
> In the previous note from me, I responded to you and Jari on
> your main points.  In this note, I am responding to your
> editorial points.
> 
>> Textual nit-picking
>> 
>...

> I agree.  The revised sentence reads: "These RFCs, and any
> other IETF-generated Informational or Experimental documents,
> are reviewed by appropriate IETF bodies and published as part
> of the IETF Stream."

Excellent

>> words  and the general tone of the language used.  For
>> example, Section 1 Paragraph 5, last sentence, says "...was a
>> have been "...this was not".   As another example, consider
>...

> To make them all parallel in structure, the first numbered
> item in section 3 becomes: "1. The IESG finds no conflict
> between this document and IETF work."

Much better.

> In RFC 3932, these numbered items (except the first one, which
> is the same until the modification above) begin "The IESG
> thinks"  During pre-Last-Call-review, I received feedback that
> "The IESG finds" was a better.  Now, you propose "The IESG
> believes".    I do believe that the current wording is better
> than the original.  I'm willing to change it to something else
> if there is consensus to do so.  What do other reviewers
> find/think/believe/prefer?

I find (sic) that "find" is better than "thinks", but probably
prefer "believes".   "has concluded" would be even better, IMO.

>> preceding 2006, there was a period of several years in which
>> the IAB performed a (sometimes pro-forma) review of IRTF
>...
> paragraph: "Prior to 2006, documents from the IRTF were
> treated as either IAB submissions or individual submissions
> via the RFC Editor."

That would be correct.  Thanks.

>     submission, including considerations of possible harm to

Not really.  Most of the really problematic text about "harm"
has been removed, for which I thank you.  But, just as we have
(correctly, IMO) been quite insistent that publication of a
document cannot infringe anyone's (non-copyright) IPR, it is
hard for me to believe that the publication of a document can
"harm" the Internet or even "harm" the IETF's standards process.
Cause some operational difficulties if implemented, yes.  Cause
some confusion if published out of sequence with other work,
probably.  But I think this document would be enhanced if all
language about "harm" resulting from publication (even the
above) were removed and replaced by language describing what
sort of damage is being anticipated or prevented.

>...

   john

---

From: SM <[email-masked]>
Date: Thu, 13 Nov 2008 07:41:07 -0800

At 08:19 10-11-2008, Russ Housley wrote:
>In RFC 3932, these numbered items (except the first one, which is 
>the same until the modification above) begin "The IESG 
>thinks"  During pre-Last-Call-review, I received feedback that "The 
>IESG finds" was a better.  Now, you propose "The IESG 
>believes".    I do believe that the current wording is better than 
>the original.  I'm willing to change it to something else if there 
>is consensus to do so.  What do other reviewers find/think/believe/prefer?

In a different message, John mentioned ""has concluded".  That sounds 
better as the numbered items are about conclusions reached.  My 
second preference would be "The IESG believes".

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Nov 2008 12:41:53 -0500

>In a different message, John mentioned ""has concluded".  That 
>sounds better as the numbered items are about conclusions 
>reached.  My second preference would be "The IESG believes".

I am happy with "has concluded".  The numbered list is changed as follows:

    The IESG review of these Independent Stream and IRTF Stream documents
    reach one of the following five types of conclusions.

    1. The IESG has concluded that there is no conflict between this
       document and IETF work.

    2. The IESG has concluded that this work is related to IETF work done
       in WG <X>, but this relationship does not prevent publishing.

    3. The IESG has concluded that publication is potentially harmful to
       the IETF work done in WG <X> and recommends not publishing the
       document at this time.

    4. The IESG has concluded that this document violates IETF procedures
       for <X> and should therefore not be published without IETF review
       and IESG approval.

    5. The IESG has concluded that this document extends an IETF protocol
       in a way that requires IETF review and should therefore not be
       published without IETF review and IESG approval.

Russ

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2008 13:01:12 -0500

Russ,

FWIW, I can live with this formulation.  I would still prefer to
get rid of "harmful"... see below.

 
 
>        the IETF work done in WG <X> and recommends not

I would recommend replacing "is potentially harmful" with
something like "could impede the smooth progress of".   That
eliminates the issue of "harm" and replaces it with what is
actually a slightly weaker condition.  Phrases like "could
potentially disrupt" would be roughly equivalent, again without
implying that the IETF process is so fragile that the
publication of a document could "harm" it.

But, if the IESG is ok with that implication of fragility and
you prefer to leave "harmful", I can live with it.

   john

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Nov 2008 18:39:34 -0500

John:

I am pleased to go with:

    The IESG has concluded that publication could potentially disrupt the
    IETF work done in WG <X> and recommends not publishing the
    document at this time.

Thanks for the suggestions.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Nov 2008 07:39:25 -0600

> IETF work done in WG <X> and recommends not publishing the

I'm OK with this as well.

Jari