Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

Hi Ran,

I have specific responses in-line, but I'll start with a summary of sorts
for less patient readers.

IMHO, the current text places a responsibility on the IESG to deal with
"exceptional circumstances" but fails to provide the tools to execute that
responsibility.  After 27 years in government, I have a lot of experience
with assignment of responsibility without authority, and none of it was
positive.

I completely accept the community's consensus that IESG notes should be
reserved for the egregious cases, if any should emerge, but I would like to
see a process for achieving that goal where *necessary*.  Making notes
mandatory is one possible mechanism, although others might be preferable.  I
personally support the position outlined in Jari's 9/13/09 email...

On 9/12/09 7:20 AM, "RJ Atkinson"  wrote:

> Earlier, Tim Polk wrote (in part):
> % And are we really helping anyone by not clarifying the
> % relationship between the document and other RFCs?
> %
> % Shouldn't we provide this information as a
> % service to the reader?
> 
> Tim,
> 
> I like you, but your reasoning on this topic comes
> across as very confused or incompletely informed.
> 

Both of which may be true... but I'll give it another shot anyway.

> The information you discuss is ALREADY available and
> HAS BEEN available for well over a DECADE now.
> 
> To be frank, the status is also very very clear to anyone
> who actually glances at any modern RFC.
> 
> 1) Each modern RFC has a "Category" field in the header
> on the first page.  This dates back at least to RFC-1517,
> which was published in September 1993 -- 16 years ago.
> 
> 2) Separately, and for redundancy, the "Status of This Memo"
> field has made that information available in less
> abbreviated form.
> 
> To pick two arbitrary examples from ~15 years ago that
> illustrate both that the markings are QUITE CLEAR at even
> a quick glance AND that these markings go back MANY years
> now:
>
> A) RFC-1704 "On Internet Authentication"
> 
> 1) "Category: Informational" (top left corner)
> 2) "Status of this Memo" says in entirety:
> "This document provides information for the Internet
> community.  This memo does not specify an Internet
> standard of any kind.  Distribution of this memo
> is unlimited."
> 
> B) RFC-1626 "IP MTU for use over ATM AAL5"
>  
> 1) "Category: Standards Track" (top left corner)
> 2) "Status of this Memo" says in entirety:
> "This document specifies an Internet standards track
> protocol for the Internet community, and requests
> discussion and suggestions for improvements.  Please
> refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the
> standardization state and status of this protocol.
> Distribution of this memo is unlimited."
> 

I don't know think that this is a core issue, since it is addressed in the
headers and boilerplates document, but I don't think Category and Status of
Memo provide all the information needed.  Even assuming the reader looks at
the boilerplate and understands provided information, there is a difference
in my mind between an informational (or experimental) RFC that comes from
the IETF process or the IRTF process than one that is an independent
submission.  It is information the reader might want to factor into any
implementation or deployment decisions, but is not available.

> 3) As I understand things, and on this I might be a bit
>out-dated as to the current state of things, there is
>a concrete proposal to also add to each RFC (starting
>in the near future and continuing forward) the specific
>"Document Stream" (i.e. IETF, IRTF, IAB, Independent
>Submission) via which a particular RFC was published.
> 
>I have no objection to that addition.  I don't think that
>it is really necessary, given (1) and (2) above, but it
>seems to make some folks more comfortable and I don't
>immediately see any harm in that addition.
> 

I actually think this is a very good addition, precisely because I believe
(1) and (2) are insufficient.  If the reader reads and understands the
boilerplate, we have the 98% solution.  (I personally have my doubts about
reading and understanding the boilerplate, but I believe that is the
criteria the community would have the IESG apply: "Assuming the reader
understands the headers and boilerplate, is a note really needed?")

> 
> ANALYSIS:
>Noel's recent note pointing to Donald Eastlake's note
>is an accurate summary of the situation.  We have substantial
>actual operational experience indicating that IESG notes
>are handled appropriately by the RFC Editor team.  There
>is zero evidence of a problem.   So there is no reasonable
>cause to make IESG notes on non-IETF-trac

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

On 9/14/09 10:13 AM, "RJ Atkinson"  wrote:

> 
> 
> On  14 Sep 2009, at 10:00, Polk, William T. wrote:
>> IMHO, the current text places a responsibility on the IESG to deal
>> with
>> "exceptional circumstances" but fails to provide the tools to
>> execute that
>> responsibility.  After 27 years in government, I have a lot of
>> experience
>> with assignment of responsibility without authority, and none of it
>> was
>> positive.
> 
> It is interesting to better understand your perspective.
> 
> I would have read the "current text" in a nearly inverted meaning:
>providing "authority to deal with someone trying to make an
>'end run' around the IETF in some area of current IETF effort",
>by requesting the RFC-Editor to add an IESG note in such a case,
>but not requiring the IESG to do so.
> 

It is a fair observation... The word "responsibility" doesn't appear, so
that is just the way I interpret it.  Since this option is reserved for
"exceptional" cases, I guess I think the IESG would have an obligation to
address the issue, but that may be an AD-specific reading.

> To me, the most relevant datum is that we have more than 15 years
> of operational experience with the current setup, and zero actual
> problems.
> 

If we are lucky, this a painful exercise to establish process that will not
need to be tested in practice.  I certainly hope that is the case.

> [...stuff deleted here...]
> 
>>> 3) As I understand things, and on this I might be a bit
>>>   out-dated as to the current state of things, there is
>>>   a concrete proposal to also add to each RFC (starting
>>>   in the near future and continuing forward) the specific
>>>   "Document Stream" (i.e. IETF, IRTF, IAB, Independent
>>>   Submission) via which a particular RFC was published.
>>> 
>>>   I have no objection to that addition.  I don't think that
>>>   it is really necessary, given (1) and (2) above, but it
>>>   seems to make some folks more comfortable and I don't
>>>   immediately see any harm in that addition.
>>> 
>> 
>> I actually think this is a very good addition, precisely because I
>> believe
>> (1) and (2) are insufficient.  If the reader reads and understands the
>> boilerplate, we have the 98% solution.
>> 
>> (I personally have my doubts about reading and understanding the
>> boilerplate,
> 
> This parenthetical bit just above is confusing, and (at least to me)
> non-obvious.
> 
> Why would someone who can read sufficiently well to understand
> the content of an RFC have trouble distinguishing between the
> "Status of this Memo" texts AND also have trouble understanding
> the RFC's "Category" field ?
> 

It's not that the reader can't, it's that they *won't*.  I don't believe
readers always read the boilerplate, and I don't think many readers bother
to research the difference between the categories.  I find even long time
members of the IETF Community can debate whether a particular document
should be PS vs. BCP vs. Informational for a long time, so I am sure that
the nuances will be lost on the casual reader.

However, my limited expectations of the reader are irrelevant beyond
confirming my pessimistic nature.  I think the test we should apply is for
people that will read and understand the boilerplate.  (Otherwise, they
wouldn't see the IESG note anyway!)

>> but I believe that is the
>> criteria the community would have the IESG apply: "Assuming the reader
>> understands the headers and boilerplate, is a note really needed?")
> 
> I'm glad that you agree that seems to be the (most of the)
> community's perspective.
> 
> [...stuff deleted here...]
> 
>> [I wouldn't assume that anyone speaks for the IESG on this topic,
>> especially
>> me!  This represents my personal views only.]
> 
> Fair enough.
> 
> Thanks for the explanations.  At a minimum, I think I understand
> your perspective much better.
> 

+1

Tim

> Yours,
> 
> Ran Atkinson
> r...@extremenetworks.com
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[RJ Atkinson]

On  14 Sep 2009, at 10:00, Polk, William T. wrote:
IMHO, the current text places a responsibility on the IESG to deal  
with
"exceptional circumstances" but fails to provide the tools to  
execute that
responsibility.  After 27 years in government, I have a lot of  
experience
with assignment of responsibility without authority, and none of it  
was

positive.


It is interesting to better understand your perspective.

I would have read the "current text" in a nearly inverted meaning:
  providing "authority to deal with someone trying to make an
  'end run' around the IETF in some area of current IETF effort",
  by requesting the RFC-Editor to add an IESG note in such a case,
  but not requiring the IESG to do so.

To me, the most relevant datum is that we have more than 15 years
of operational experience with the current setup, and zero actual  
problems.


[...stuff deleted here...]


3) As I understand things, and on this I might be a bit
  out-dated as to the current state of things, there is
  a concrete proposal to also add to each RFC (starting
  in the near future and continuing forward) the specific
  "Document Stream" (i.e. IETF, IRTF, IAB, Independent
  Submission) via which a particular RFC was published.

  I have no objection to that addition.  I don't think that
  it is really necessary, given (1) and (2) above, but it
  seems to make some folks more comfortable and I don't
  immediately see any harm in that addition.



I actually think this is a very good addition, precisely because I  
believe

(1) and (2) are insufficient.  If the reader reads and understands the
boilerplate, we have the 98% solution.

(I personally have my doubts about reading and understanding the  
boilerplate,


This parenthetical bit just above is confusing, and (at least to me)
non-obvious.

Why would someone who can read sufficiently well to understand
the content of an RFC have trouble distinguishing between the
"Status of this Memo" texts AND also have trouble understanding
the RFC's "Category" field ?


but I believe that is the
criteria the community would have the IESG apply: "Assuming the reader
understands the headers and boilerplate, is a note really needed?")


I'm glad that you agree that seems to be the (most of the)
community's perspective.

[...stuff deleted here...]

[I wouldn't assume that anyone speaks for the IESG on this topic,  
especially

me!  This represents my personal views only.]


Fair enough.

Thanks for the explanations.  At a minimum, I think I understand
your perspective much better.

Yours,

Ran Atkinson
r...@extremenetworks.com


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joe Touch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



RJ Atkinson wrote:
...
> BOTTOM LINE:
>   There seems to be clear consensus amongst folks outside
>   the IESG that (1) there is no current problem and (2)
>   no process change is warranted to make IESG notes mandatory
>   on non-IETF-track documents.

+1

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkquTaQACgkQE5f5cImnZrslVwCglTLLQLG+CyzUvJcTQclN93NC
n8YAnj3TKxXsqEHjvsl0Ur2+OAa7uh1y
=T1Qd
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[RJ Atkinson]

Earlier, Tim Polk wrote (in part):
% And are we really helping anyone by not clarifying the
% relationship between the document and other RFCs?
%
% Shouldn't we provide this information as a
% service to the reader?

Tim,

I like you, but your reasoning on this topic comes
across as very confused or incompletely informed.

The information you discuss is ALREADY available and
HAS BEEN available for well over a DECADE now.

To be frank, the status is also very very clear to anyone
who actually glances at any modern RFC.

1) Each modern RFC has a "Category" field in the header
   on the first page.  This dates back at least to RFC-1517,
   which was published in September 1993 -- 16 years ago.

2) Separately, and for redundancy, the "Status of This Memo"
   field has made that information available in less
   abbreviated form.

To pick two arbitrary examples from ~15 years ago that
illustrate both that the markings are QUITE CLEAR at even
a quick glance AND that these markings go back MANY years
now:

A) RFC-1704 "On Internet Authentication"

1) "Category: Informational" (top left corner)
2) "Status of this Memo" says in entirety:
"This document provides information for the Internet
community.  This memo does not specify an Internet
standard of any kind.  Distribution of this memo
is unlimited."

B) RFC-1626 "IP MTU for use over ATM AAL5"

1) "Category: Standards Track" (top left corner)
2) "Status of this Memo" says in entirety:
"This document specifies an Internet standards track
protocol for the Internet community, and requests
discussion and suggestions for improvements.  Please
refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.
Distribution of this memo is unlimited."

3) As I understand things, and on this I might be a bit
  out-dated as to the current state of things, there is
  a concrete proposal to also add to each RFC (starting
  in the near future and continuing forward) the specific
  "Document Stream" (i.e. IETF, IRTF, IAB, Independent
  Submission) via which a particular RFC was published.

  I have no objection to that addition.  I don't think that
  it is really necessary, given (1) and (2) above, but it
  seems to make some folks more comfortable and I don't
  immediately see any harm in that addition.


ANALYSIS:
  Noel's recent note pointing to Donald Eastlake's note
  is an accurate summary of the situation.  We have substantial
  actual operational experience indicating that IESG notes
  are handled appropriately by the RFC Editor team.  There
  is zero evidence of a problem.   So there is no reasonable
  cause to make IESG notes on non-IETF-track documents
  mandatory.

  Separately, The IESG lacks authority over the overall
  RFC publication process -- our process documents say that
  the RFC-Editor reports to the IAB, not the IESG.  This
  was done *precisely* because it has always been true
  that many RFCs are not produced via the IETF processes.

  The RFC process dates back to 1969 -- 40 years ago.
  The IETF wasn't itself formed until the middle 1980s.

  Lastly, the RFC Editor and IAB have responsibilities to
  the entire "Internet community", whilst the IESG has more
  narrow responsibilities for IETF Standards activities.
  The "IETF Community" is a proper subset of the larger
  "Internet Community".  A number of folks aren't active
  in IETF work, but are active in IRTF work or are otherwise
  important parts of the broader "Internet Community".

  For this reason, even if there were IETF consensus of a
  problem (and frankly, there seems to be smooth consensus
  amongst non-IESG members that there is NOT a problem),
  that would be the wrong yard-stick to use for changing
  processes applicable to non-IETF-track documents.  Again,
  this is why RFC publication is an IAB responsibility
  instead of an IESG responsibility, and why our process
  documents say that the RFC Editor reports to the IAB.

BOTTOM LINE:
  There seems to be clear consensus amongst folks outside
  the IESG that (1) there is no current problem and (2)
  no process change is warranted to make IESG notes mandatory
  on non-IETF-track documents.

REQUEST:
  I would urge the IESG to formally abandon the advocacy
  to change this aspect of our processes, and to say that
  this has been abandoned on the IETF discussion list.

Yours,

Ran Atkinson
r...@extremenetworks.com


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joe Touch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Andrew Sullivan wrote:
> On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote:
>> First, you lack empirical data to substantiate your assessment of the 
>> perception.
> 
> Well, Wikipedia (which IMO is primarily useful as a repository for
> finding out what "everyone knows") has this first sentence in its
> description of the RFC series:

It's certainly *not* what everybody knows; it's more like what
everybody's being told.

If you don't like a Wikipedia definition, change it. ;-)

Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkqqbTMACgkQE5f5cImnZruATgCePexWhxGHNJR2ygAU1iig4Smk
EaQAn110fNjgej7dQhiF+XKxXvmOY7w0
=4tjN
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joe Touch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Noel Chiappa wrote:
> > From: Stephan Wenger 
> 
> > For the IETF as an organization, I see no value beyond traditions in
> > staying with the RFC publication model. (The marketing value of using
> > the RFC series is IMHO contradicted by the lack of control of the IETF
> > over the RFC series).
> 
> If I understand you correctly, you're suggesting creating a new document
> series for use by the IETF, for its standards documents?  If so, I don't
> recall this possibility being discussed before, although I can't believe it
> hasn't been suggested at some point.

Well, there's STDs. Do you also want PSTD and DSTD numbers?

> Such a change would be acceptable to me - although it might take a while to
> build up the distribution system that already exists for RFCs.

Using STD/DSTD/PSTD would just be additional numbers.

Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkqqbLsACgkQE5f5cImnZrv5WwCg58JSLLQTkOPBJWZzkNx8HyDJ
ahkAn2O/m6u2U6jUTxybaR1myDUEwscm
=2c62
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian E Carpenter]

On 2009-09-10 03:53, Noel Chiappa wrote:
> > From: Donald Eastlake 
> 
> > The burden of proof rests on those ... who wish to change the
> > independent stream from a respected independent publishing channel to
> > something subservient to the Area Directors, a change which seems
> > entirely gratuitous without any historically demonstrated need.
> 
> A most concise and incisive summary of the situation.

And hereby hangs a problem. The person who is charged with judging
consensus on this conversation is an Area Director. I fear that he has
a dilemma: if he reaches the conclusion that the consensus is to change
the historical practice (that the IESG merely requests notes to be included
in independent submissions), that conclusion would immediately be
suspect, and I'd guess would be appealed in very short order.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

On 9/9/09 11:09 AM, "Robert Elz"  wrote:

> Date:Wed, 9 Sep 2009 09:53:42 -0400
> From:"Polk, William T." 
> Message-ID:  
> 
>   | IMHO, the RFC series (as comprised by the four document streams) is not
>   | similar to IEEE Transactions on Networking or the NY Times.  I am not sure
>   | that there is really a close analog out there.
> 
> It is an independent publisher publishing material submitted to it - the
> NY Times analogy isn't close, as they create much of their own material,
> which neither IEEE Transactions, nor the RFC editor do (or not much of,
> indexes and stuff like that excepted), but aside from that, there shouldn't
> be a lot of difference.

Yes, but everything that IEEE Transactions produces is similar in nature.
It is all personal submissions.  My point is that the RFC series is shared
by different communities with different submission policies.  I don't think
the analogy fits.  There is a completely different balancing act required.

> 
>   | The better question is, if IEEE was distributing the output of the IETF in
>   | its series of standards publications
> 
> You're operating under the mistaken impression that the RFC series is
> IETF standards - it isn't - some of he RFCs are IETF standards, others
> are other IETF publications, and others have nothing to do with the IETF
> at all.   It is just a document series that the IETF happens to use as
> a place to publish its output.
> 
> If there was a document series and publisher that was exclusively for
> IETF standards, then we wouldn't be publishing anything else there at all,
> and the question of notes would be irrelevant - that would be closer to the
> way IEEE and ISO standards are published - but that is not what the RFC
> series is now, or ever has been.
> 

I am not suggesting that the RFC series is IETF standards only, or should
be.  The streams coexist because they all provide services to the same
community.

>   | And are we really helping anyone by not clarifying the relationship
> between
>   | the document and other RFCs?  Shouldn't we provide this information as a
>   | service to the reader?
> 
> Many times that is reasonable, probably, and no-one is suggesting that
> the RFC editor always refuse to publish IESG notes (though some of us
> don't believe the IESG should very often, if at all, request one) - the
> question isn't what happens when an IESG note is appropriate, the question
> is what happens when it isn't - and who gets to decide.
> 

I believe that when a requested IESG note is not appropriate, the RFC Editor
will push back and the IETF community will support that position.  If the
IESG is appropriate, but the RFC Editor pushes back, I believe the community
will make the right decision there.  Essentially, I trust that the IETF
community will ensure that the IESG does not abuse their position.  The
energy on this thread would seem to support my expectations...

Tim

> kre
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

Hi Robert,

On 9/9/09 8:54 AM, "Robert Elz"  wrote:

> Date:Wed, 09 Sep 2009 07:17:50 -0400
> From:Sam Hartman 
> Message-ID:  
> 
>   | Right; I think I made it fairly clear in my reply to John Klensin that
>   | I disagreed fairly strongly with that and argued why I believed that
>   | the IETF needs a special role to attach a note to something.  No
>   | discussion prior or since has changed my mind.
> 
> Ask yourself if you'd have the same opinion if the IETF was publishing
> its output in IEEE Transactions on Networking (or any similar publication),
> or even something like the NY Times.
> 

IMHO, the RFC series (as comprised by the four document streams) is not
similar to IEEE Transactions on Networking or the NY Times.  I am not sure
that there is really a close analog out there.

> Would you still expect the IESG to be able to tell the editor of that
> publication what they are required to do?
> 
> Then note that this is exactly the same ralationship that the RFC
> editor should have with the IETF.
> 

The better question is, if IEEE was distributing the output of the IETF in
its series of standards publications and the IETF work was in conflict with
their own standards, would it be appropriate to publish without a note from
the IEEE explaining the incongruity?

And are we really helping anyone by not clarifying the relationship between
the document and other RFCs?  Shouldn't we provide this information as a
service to the reader?

Tim

> In any case, if the editor is failing to perform adequately, the correct
> response is to replace the editor - there is no rational consittuency here
> in which to seek consensus (no matter who does the seeking) and no-one
> rational to handle appeals, so I'm not in favour of John K's compromise
> proposal.
> 
> Simply allow the editor the discretion to make his/her own decisions
> (in this case, it will become the ISE with co-ordination from the RFC editor)
> and then if they're failing (which mostly means, not getting things published,
> but might also mean sub-standad publications), then replace them with
> someone who can do better.
> 
> Nothing more than that is needed.
> 
> kre
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

Olaf,

Let me suggest tuning this a bit, with the understanding that
what I'm about to suggest lies well within current procedures,
RFC 5620, etc.

--On Wednesday, September 09, 2009 09:11 +0200 Olaf Kolkman
 wrote:

>...
> But there is a nugget in the introduction of a last call: I
> think that the ISE has a very hard time explaining to the RSE
> that a note that has backing of IESG consensus will not be
> published. (I am assuming the use of the appeal procedure as
> described in RFC5620, which I think is appropriate for a
> difference of opinion between RFC entities such as the ISE and
> the IESG). If in such conflict the RSE would choose sides of
> the ISE then I am pretty sure something is severely broken and
> the appearance of a note is the least of our problems.

I would not assume that unless you assume that there is some
part of the model that somehow prevents the IESG from getting
out of control.  If there is not, then, to be orderly, one has
to assume that it is fully as possible that the IESG (as the
IETF stream-approver) is out of control as it is that the ISE
(as the Independent Submission stream approver) is out of
control.

I also imagine that the IESG could, if so inclined, issue a Last
Call that would be so stated as to produce a confirming result,
especially if comments from those who do not believe that there
should be an Independent Stream were counted along with those
who actually understood the particular issues and confirmed the
importance of the note.  Also remember that the IESG does the
counting and, to refer back to an earlier comment on the list,
figures out what the consensus is even when it is not obvious.

The particular case I would be most concerned about would
involve a document that was highly critical of an IETF Standard,
but that was extremely clear that it was a critique, that
documented the disagreement in a balanced way, etc. -- in other
words, where there was a dissent from an IETF standards-track
document and no possibility of confusion with one.  I could
easily imagine the IESG disagreeing with such a document and
wanting to get the last word in with a "don't pay any attention
to this" note.  If they are permitted to do that, with or
without a claim of IETF consensus, then there is no Independent
Stream, only an "independent as long as documents are reasonably
supportive of IETF views and political correctness" one.

Were that situation to arise, I would expect the RSE to do a
balanced evaluation and the IAB, if it got involved, to do so
too, with both paying a lot of attention to the differences
among "note needed to ensure clarity about what the document
is", "note to warn against a diagnosed danger to the Internet
posed by the suggestions in the document", and "IESG wants to
get the last word in".  And, again, my personal view is that the
first two represent flaws in the document that ought to get
resolved, without add-on text, before the ISE agrees to publish
and that the third is not acceptable.   Put differently, I think
we have a problem any time the ISE (or other stream entity)
chooses to ignore, or reject without good reason, input about
changes to a document to make its status, or issues with its
suggested technology, clear.   

> So in other words what I am saying is don't invent process but
> follow existing pieces:
> 
> - put a note in front of the ISE
> o if the ISE pushes back
> - last call the note in the IETF, to make sure the IESG
> actually represents IETF consensus --whereby the consensus is
> called by the IESG following normal process and appeal--, and
> go back to the ISE telling that the note has IETF backing.
> o if the ISE pushes back
> - consider this a disagreement between stream entities and
> follow RFC 5620 appeal process.

I think whether or not to do that Last Call should be up to the
IESG.  Nothing prevents them from invoking the "disagreement
between stream entities" procedures on their own remit, although
their position would certainly be stronger with clear IETF
backing.

> o if the RSE chooses sides with the ISE the note gets
> published but the IAB, the IESG, and the RSE have some serious
> talking to do because something is severely broken elsewhere
> than just the note. The RFC will most probably be published
> without the note but the IESG has the possibility to publish a
> "This RFC sucks for this reason RFC" while the real problems
> are being addressed

And we should operate on the guideline that, if the IESG simply
wants to dissent from a particular document, the mechanism is
publication of such an RFC, not attachment of notes.  But,
again, I believe that any situation in which a note is perceived
to be needed is a failure in the publication model _and_, if we
think notes are an appropriate way to resolve problems, that any
of the other streams should be able to ask the ISE to attach
notes of their choosing to IETF Stream documents, doing so as
soon as the Document Action or Protocol Action appears.

> Obviously publ

RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Lawrence Rosen]

Andrew Sullivan wrote:
> Again, I wish to emphasise that this is completely distinct from the
> question of whether anyone ought to do anything about the state of
> affairs.  I refuse to take a position on that, or even consider it as
> a topic for a conversation in which I'll be involved.  There are
> enough windmills around without us throwing up new ones at which we
> can tilt.

That's a shame. The standards world is looking for someone who can tilt at
the windmills that are the entrenched habits of our day. Who wants to be the
hero of that novel?

I'm being serious. I agree with you that there is much unhelpful confusion
about "RFCs".

/Larry


Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 
3001 King Ranch Road, Ukiah, CA 95482
Cell: 707-478-8932


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Andrew Sullivan
Sent: Wednesday, September 09, 2009 11:20 AM
To: ietf@ietf.org
Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature
of IESG notes

On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote:

> for example, the second and third.  Based on that latter set, I could 
> claim that "THE" perception is that the RFC series is 

I am at the best of times uneasy with universal quantifiers, and
certainly when talking about THE belief of THE Internet, I feel pretty
uneasy.  Also, I haven't followed this discussion much, partly because
I fully agree with the observation that most of it has been hashed so
much, and warmed over so many times, that it's now turned into a form
of American breakfast potato.

But it doesn't seem to me to be doing favours to anyone to deny the
obvious point that there's at least a substantial community of people
who regard the label "RFC" as bespeaking "an IETF document" and also
"Internet standard".  Claiming that it's not true by pointing to
examples of careful and clueful definitions (one of which is
practically a sockpuppet for the IETF pages themselves) does not
clarify this matter.  Even organizations involved in the
administration of the Internet apparently rely on something "being an
RFC" as somehow implying an _imprimatur_ or at least _nihil obstat_
(if anyone wants evidence of that matter, I think the archives of
agreements found at ICANN will be instructive). 

Again, I wish to emphasise that this is completely distinct from the
question of whether anyone ought to do anything about the state of
affairs.  I refuse to take a position on that, or even consider it as
a topic for a conversation in which I'll be involved.  There are
enough windmills around without us throwing up new ones at which we
can tilt.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Andrew Sullivan]

On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote:

> for example, the second and third.  Based on that latter set, I could 
> claim that "THE" perception is that the RFC series is 

I am at the best of times uneasy with universal quantifiers, and
certainly when talking about THE belief of THE Internet, I feel pretty
uneasy.  Also, I haven't followed this discussion much, partly because
I fully agree with the observation that most of it has been hashed so
much, and warmed over so many times, that it's now turned into a form
of American breakfast potato.

But it doesn't seem to me to be doing favours to anyone to deny the
obvious point that there's at least a substantial community of people
who regard the label "RFC" as bespeaking "an IETF document" and also
"Internet standard".  Claiming that it's not true by pointing to
examples of careful and clueful definitions (one of which is
practically a sockpuppet for the IETF pages themselves) does not
clarify this matter.  Even organizations involved in the
administration of the Internet apparently rely on something "being an
RFC" as somehow implying an _imprimatur_ or at least _nihil obstat_
(if anyone wants evidence of that matter, I think the archives of
agreements found at ICANN will be instructive). 

Again, I wish to emphasise that this is completely distinct from the
question of whether anyone ought to do anything about the state of
affairs.  I refuse to take a position on that, or even consider it as
a topic for a conversation in which I'll be involved.  There are
enough windmills around without us throwing up new ones at which we
can tilt.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Andrew Sullivan wrote:

On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote:

First, you lack empirical data to substantiate your assessment of the 
perception.


Well, Wikipedia 

...

The fourth link from Google in response to, "What is an RFC?" says

...

So even if those pages go on to refine their statements, I don't think
it preposterous to suggest that people think "the RFC series" is "from
the IETF".



Andrew (and Stephen),

Thank you for exploring the question of empirical data, as well as demonstrating 
how methodologically challenged discussion in the IETF tends to be, particularly 
with respect to anything involving or implying statistics...


The original comment was about universality of perception.  Particular examples 
were cited at the beginning of Stephen's note, but they morphed into a statement 
of universality by the end of it.


Your own note cited the first and fourth google listings but left out, for 
example, the second and third.  Based on that latter set, I could claim that 
"THE" perception is that the RFC series is "the working notes of the Internet 
research and development community" and "a formal mechanism used to describe 
communications standards for the Internet and systems (like USENET) that are 
closely tied to it."


That's quite a different characterization of the RFC series and besides being 
more accurate, it has the same empirical basis being put forth as "the" 
perception" of the series as what you are citing.


But, of course, this is all about the first of two challenges I offered and 
empirical data for the latter is what justifies considering a change.


Stephen just posted the view that we should be "proactive", but does not seem to 
understand that we missed that opportunity 20 years ago.  Whatever "problem" we 
need to anticipate has failed to materialize for two decades.


But the real crux of this debate is represented by the difference between my 
second challenge and Stephen's alternative challenge: "If there were indeed no 
value beyond traditions, why run any risk, no matter how small?"


First, it means that we need to be clearer about the intended benefit behind 
having the Independent stream.  (For any activity, it's always a good idea to 
have an explicit and visible value proposition...)


Second, it misses the practical implication of making changes due to imagined 
risks, particularly since there is always an infinite set of them to choose from.


Third, it ignores the operations rule that all change is, itself, risk, and that 
therefore no change is justified unless there is a solid basis for expecting 
very, very substantial benefits.  (For any activity, it's always a good idea to 
have an explicit and visible value proposition...)


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: Stephan Wenger 

> For the IETF as an organization, I see no value beyond traditions in
> staying with the RFC publication model. (The marketing value of using
> the RFC series is IMHO contradicted by the lack of control of the IETF
> over the RFC series).

If I understand you correctly, you're suggesting creating a new document
series for use by the IETF, for its standards documents?  If so, I don't
recall this possibility being discussed before, although I can't believe it
hasn't been suggested at some point.

Such a change would be acceptable to me - although it might take a while to
build up the distribution system that already exists for RFCs.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephan Wenger]

Hi Dave,

I agree with your second observation.  It may well be that the current RFC
editor model has not *yet* caused a pragmatic problem.

I stand to my first assessment, as originally formulated.

The main issue is: should the IETF be pro-active on these matters, or not.
For the IETF as an organization, I see no value beyond traditions in staying
with the RFC publication model.  (The marketing value of using the RFC
series is IMHO contradicted by the lack of control of the IETF over the RFC
series).  If there were indeed no value beyond traditions, why run any risk,
no matter how small?  Certainly there must be some risk in giving the RFC
editor, rather than the duly appointed IETF officials, the last say in
publishing documents that are perceived as IETF documents.

I could follow an argument that changing the publication mechanism is large
enough a pain to best avoid it, for the small pragmatic gains we may get.

Regards,
Stephan




On 9/9/09 9:19 AM, "Dave CROCKER"  wrote:

> 
> 
> Stephan Wenger wrote:
>> This *perception* is important.  And changing it means changing the
>> *perception* of a large number of people, for very little value except
>> honoring a 40 year old institution.  That's not a value proposition I can
>> easily support.
>> 
>> If the IETF is *perceived* as the owner and/or sole contributor to the IETF
>> series, 
> 
> 
> Stephen,
> 
> First, you lack empirical data to substantiate your assessment of the
> perception.
> 
> Second, you lack empirical data that it is causing a pragmatic problem.
> 
> That is what ought to be the lesson of having repeated this thread every few
> years for 20 years ought to be.
> 
> Make a change when you have a demonstrable, real and damaging problem, not
> just 
> something you don't like.
> 
> d/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Andrew Sullivan]

On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote:
> First, you lack empirical data to substantiate your assessment of the 
> perception.

Well, Wikipedia (which IMO is primarily useful as a repository for
finding out what "everyone knows") has this first sentence in its
description of the RFC series:

> In computer network engineering, a Request for Comments (RFC) is a
> memorandum published by the Internet Engineering Task Force (IETF)
> describing methods, behaviors, research, or innovations applicable to
> the working of the Internet and Internet-connected systems.

The fourth link from Google in response to, "What is an RFC?" says

> RFC is an acronym for Request for Comments and official documents from
> the Internet Engineering Task Force (IETF) with an unlimited
> distribution.  RFC's are numbered in a series and are referred to by
> numbers.

So even if those pages go on to refine their statements, I don't think
it preposterous to suggest that people think "the RFC series" is "from
the IETF".

I am totally unwilling to have an opinion on whether anyone ought to
try to do anything about this, but I don't think we should pretend
that the world is otherwise than it is.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Stephan Wenger wrote:

This *perception* is important.  And changing it means changing the
*perception* of a large number of people, for very little value except
honoring a 40 year old institution.  That's not a value proposition I can
easily support.

If the IETF is *perceived* as the owner and/or sole contributor to the IETF
series, 



Stephen,

First, you lack empirical data to substantiate your assessment of the 
perception.

Second, you lack empirical data that it is causing a pragmatic problem.

That is what ought to be the lesson of having repeated this thread every few 
years for 20 years ought to be.


Make a change when you have a demonstrable, real and damaging problem, not just 
something you don't like.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephan Wenger]

Hi,

As it has been pointed out here often, the RFC series is more than just the
document numbering scheme for IETF standards.  However, if you attend a
marketing gathering, a random CS conference, a non-IETF standardization
meeting, or even the IETF plenary, a majority of people (probably a large
majority) would answer the question "what are RFCs" with "standards set by
the IETF", or something thereabouts.

This *perception* is important.  And changing it means changing the
*perception* of a large number of people, for very little value except
honoring a 40 year old institution.  That's not a value proposition I can
easily support.

If the IETF is *perceived* as the owner and/or sole contributor to the IETF
series, it should have influence up to veto power regarding the content of
that series, through its chosen management structure---that is, AFAIK and in
this case, the IESG.  Otherwise, it cannot stop the publication of documents
against its interest.

It's pretty clear now that the IESG is not going to get the tools I consider
required to influence the RFC editor, due to historical facts and the
independence of the RFC editor and its support functions.

Is it time that the IETF considers publishing its material elsewhere?

Regards,
Stephan
 


On 9/9/09 8:32 AM, "Dave CROCKER"  wrote:

> 
> 
> Robert Elz wrote:
>>   | The better question is, if IEEE was distributing the output of the IETF
>> in
>>   | its series of standards publications
>> 
>> You're operating under the mistaken impression that the RFC series is
>> IETF standards - it isn't - some of he RFCs are IETF standards, others
>> are other IETF publications, and others have nothing to do with the IETF
>> at all.   It is just a document series that the IETF happens to use as
>> a place to publish its output.
> 
> 
> This is the core point.  Some folk want to re-cast the RFC series as structly
> subservient to the IETF.  But that's not how it has operated for 40 years.
> Yes, 
> folks, 4 decades.
> 
> There is a fundamental difference between "having a strong relationship"
> versus 
> "being subservient".
> 
> In order to make such a basic change, there needs to be a compelling statement
> of need for which there is strong community consensus.  None has yet been
> offered, except the same one that gets repeated every few years, for at least
> 20 
>   years, namely that some folk don't understand the RFC series.  Sigh.  Yes,
> folks, this thread is the same as has been repeated many, many times,
> including 
> the consistent lack of demonstrated damage from the current arrangement.
> 
> d/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: Donald Eastlake 

> The burden of proof rests on those ... who wish to change the
> independent stream from a respected independent publishing channel to
> something subservient to the Area Directors, a change which seems
> entirely gratuitous without any historically demonstrated need.

A most concise and incisive summary of the situation.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Robert Elz wrote:

  | The better question is, if IEEE was distributing the output of the IETF in
  | its series of standards publications

You're operating under the mistaken impression that the RFC series is
IETF standards - it isn't - some of he RFCs are IETF standards, others
are other IETF publications, and others have nothing to do with the IETF
at all.   It is just a document series that the IETF happens to use as
a place to publish its output.



This is the core point.  Some folk want to re-cast the RFC series as structly 
subservient to the IETF.  But that's not how it has operated for 40 years.  Yes, 
folks, 4 decades.


There is a fundamental difference between "having a strong relationship" versus 
"being subservient".


In order to make such a basic change, there needs to be a compelling statement 
of need for which there is strong community consensus.  None has yet been 
offered, except the same one that gets repeated every few years, for at least 20 
 years, namely that some folk don't understand the RFC series.  Sigh.  Yes, 
folks, this thread is the same as has been repeated many, many times, including 
the consistent lack of demonstrated damage from the current arrangement.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Elz]

Date:Wed, 9 Sep 2009 09:53:42 -0400
From:"Polk, William T." 
Message-ID:  

  | IMHO, the RFC series (as comprised by the four document streams) is not
  | similar to IEEE Transactions on Networking or the NY Times.  I am not sure
  | that there is really a close analog out there.

It is an independent publisher publishing material submitted to it - the
NY Times analogy isn't close, as they create much of their own material,
which neither IEEE Transactions, nor the RFC editor do (or not much of,
indexes and stuff like that excepted), but aside from that, there shouldn't
be a lot of difference.

  | The better question is, if IEEE was distributing the output of the IETF in
  | its series of standards publications

You're operating under the mistaken impression that the RFC series is
IETF standards - it isn't - some of he RFCs are IETF standards, others
are other IETF publications, and others have nothing to do with the IETF
at all.   It is just a document series that the IETF happens to use as
a place to publish its output.

If there was a document series and publisher that was exclusively for
IETF standards, then we wouldn't be publishing anything else there at all,
and the question of notes would be irrelevant - that would be closer to the
way IEEE and ISO standards are published - but that is not what the RFC
series is now, or ever has been.

  | And are we really helping anyone by not clarifying the relationship between
  | the document and other RFCs?  Shouldn't we provide this information as a
  | service to the reader?

Many times that is reasonable, probably, and no-one is suggesting that
the RFC editor always refuse to publish IESG notes (though some of us
don't believe the IESG should very often, if at all, request one) - the
question isn't what happens when an IESG note is appropriate, the question
is what happens when it isn't - and who gets to decide.

kre

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Donald Eastlake]

Sam,

The burden of proof rests on those like you who wish to change the
independent stream from a respected independent publishing channel to
something subservient to the Area Directors, a change which seems
entirely gratuitous without any historically demonstrated need.

Donald

On Wed, Sep 9, 2009 at 9:22 AM, Sam Hartman wrote:
>> "Robert" == Robert Elz  writes:
>
>    Robert> Then note that this is exactly the same ralationship that
>    Robert> the RFC editor should have with the IETF.
>
> I disagree for reasons I have previously stated.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

> "Robert" == Robert Elz  writes:

Robert> Then note that this is exactly the same ralationship that
Robert> the RFC editor should have with the IETF.

I disagree for reasons I have previously stated.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Elz]

Date:Wed, 09 Sep 2009 07:17:50 -0400
From:Sam Hartman 
Message-ID:  

  | Right; I think I made it fairly clear in my reply to John Klensin that
  | I disagreed fairly strongly with that and argued why I believed that
  | the IETF needs a special role to attach a note to something.  No
  | discussion prior or since has changed my mind.

Ask yourself if you'd have the same opinion if the IETF was publishing
its output in IEEE Transactions on Networking (or any similar publication),
or even something like the NY Times.

Would you still expect the IESG to be able to tell the editor of that
publication what they are required to do?

Then note that this is exactly the same ralationship that the RFC
editor should have with the IETF.

In any case, if the editor is failing to perform adequately, the correct
response is to replace the editor - there is no rational consittuency here
in which to seek consensus (no matter who does the seeking) and no-one
rational to handle appeals, so I'm not in favour of John K's compromise
proposal.

Simply allow the editor the discretion to make his/her own decisions
(in this case, it will become the ISE with co-ordination from the RFC editor)
and then if they're failing (which mostly means, not getting things published, 
but might also mean sub-standad publications), then replace them with
someone who can do better.

Nothing more than that is needed.

kre

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

> "Olaf" == Olaf Kolkman  writes:

Olaf> On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:

> Tim, I definitely agree with you that it should be the IETF community
>> that is last called.  Normally, the IESG judges IETF consensus.
>> However, if it makes the IAB more comfortable for the IAB chair
>> to do the consensus call, that's fine with me.  If we do that
>> we'd need to make it clear how this interacts with the IETF
>> appeals process.



Olaf> Sam,

Olaf> the underlying point of my question is that the streams are
Olaf> independent and that the IETF (stream) has no say about the
Olaf> other streams. IETF consensus or not. 

Right; I think I made it fairly clear in my reply to John Klensin that
I disagreed fairly strongly with that and argued why I believed that
the IETF needs a special role to attach a note to something.  No
discussion prior or since has changed my mind.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Olaf Kolkman]

On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:


Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to  
do the

consensus call, that's fine with me.  If we do that we'd need to make
it clear how this interacts with the IETF appeals process.




Sam,

the underlying point of my question is that the streams are  
independent and that the IETF (stream) has no say about the other  
streams. IETF consensus or not. I am not even sure the IAB has a roll  
in calling the consensus.


But there is a nugget in the introduction of a last call: I think that  
the ISE has a very hard time explaining to the RSE that a note that  
has backing of IESG consensus will not be published. (I am assuming  
the use of the appeal procedure as described in RFC5620, which I think  
is appropriate for a difference of opinion between RFC entities such  
as the ISE and the IESG). If in such conflict the RSE would choose  
sides of the ISE then I am pretty sure something is severely broken  
and the appearance of a note is the least of our problems.


So in other words what I am saying is don't invent process but follow  
existing pieces:


- put a note in front of the ISE
o if the ISE pushes back
- last call the note in the IETF, to make sure the IESG actually  
represents IETF consensus --whereby the consensus is called by the  
IESG following normal process and appeal--, and go back to the ISE  
telling that the note has IETF backing.

o if the ISE pushes back
- consider this a disagreement between stream entities and follow RFC  
5620 appeal process.
o if the RSE chooses sides with the ISE the note gets published but  
the IAB, the IESG, and the RSE have some serious talking to do because  
something is severely broken elsewhere than just the note. The RFC  
will most probably be published without the note but the IESG has the  
possibility to publish a "This RFC sucks for this reason RFC" while  
the real problems are being addressed


Obviously publication of the document should be delayed on request  
from the IESG while the above is sorted out in a timely manner.


-- Olaf 








Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Polk, William T. wrote:

I believe Sam's suggestion offers a good compromise position: if the IESG
and RFC Editor do not come to an agreement, we should last call the proposed
IESG Note and let the community determine whether (1) this is an exceptional
case meriting a note and (2) if the text accurately clarifies the
relationship.



On its face, this is certainly a reasonable path to follow.  However it has 
three practical problems.


One is effort and delay.  Adding more layers of decision-making and negotiation 
imposes non-trivial cost. The more barriers we place in the way of independent 
submission, the less it will get used. Worse, that's a stated goal for some folk.


The second is that it has become nearly impossible to find anything that looks 
like classic "rough consensus" on the IETF list.  The diversity of 
understanding, commitment and goals of participants on the IETF list has become 
far too diverse.  So as a mechanism for discerning how to resolve an impasse, it 
isn't likely to be very helpful.


The third is that it creates a negative incentive for the RFC Editor to act as 
an independent agency.  When it presses a point and finds a wall of hassle to 
deal with, this has a chilling effect on its likelihood of pressing.  They come 
to see such matters of principle as not worth the effort.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

Olaf,

I meant the IETF community.  Since the note would exist to clarify the
relationship with documents developed by the IETF community,  that seems the
right one to evaluate whether a note is needed.

As to who calls the consensus, that is a tricky one.  How about the IAB
chair?

Tim


On 9/8/09 10:36 AM, "Olaf Kolkman"  wrote:

> 
> On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote:
> 
>> I believe Sam's suggestion offers a good compromise position: if the
>> IESG
>> and RFC Editor do not come to an agreement, we should last call the
>> proposed
>> IESG Note and let the community determine whether (1) this is an
>> exceptional
>> case meriting a note and (2) if the text accurately clarifies the
>> relationship.
> 
> 
> Which community, The IETF community or the wider RFC community? And
> who calls the consensus?
> 
> 
> 
> --Olaf
> 
> 
> 
> 
> Olaf M. KolkmanNLnet Labs
> Science Park 140,
> http://www.nlnetlabs.nl/   1098 XG Amsterdam
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

In my opinion, 3932bis is internally inconsistent about IESG notes.  This
document expressly directs the IESG to reserve IESG notes for exceptional
cases, but then leaves the decision on whether the note should be included
to the RFC Editor:
   
>In exceptional cases, when the relationship of the document to the IETF
>standards process might be unclear, the IESG may request that the RFC
>Editor include an IESG note to clarify the relationship of the
>document to the IETF standards process, such a note is likely to
>include pointers to related IETF RFCs.

Personally, I think that the relationship is unclear in many cases, but it
is all a question of degree.  I interpret this text as directing the IESG to
reserve such notes for cases where serious conflicts exist and it is
particularly important to clarify the relationship and identify the
documents that represent community consensus.  In such a case, I would not
want to see the RFC Editor ignore the request or modify the note without
IESG agreement.  The current text of 3932bis seems to permit either.

I believe Sam's suggestion offers a good compromise position: if the IESG
and RFC Editor do not come to an agreement, we should last call the proposed
IESG Note and let the community determine whether (1) this is an exceptional
case meriting a note and (2) if the text accurately clarifies the
relationship.

Tim Polk

On 9/2/09 12:38 PM, "Sam Hartman"  wrote:
> 
> I'd also be happy with a
> mechanism where the IESG could propose a note, and the RFC editor had
> the option of accepting the note or asking the IESG to last-call its
> note within the IETF community.
> 
> I would not consider it acceptable if the note were purely advisory.
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to do the
consensus call, that's fine with me.  If we do that we'd need to make
it clear how this interacts with the IETF appeals process.  I'm not
thrilled with the appeals process starting with the IAB and only going
to the ISOC BOT in case there is no adequate process (6.5.3 in RFC
2026).  However I could live with that.  I suspect this may be one of
those cases where we know we've gotten a good compromise because no
one is happy with it.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Tuesday, September 08, 2009 16:36 +0200 Olaf Kolkman
 wrote:
 
> On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote:
> 
>> I believe Sam's suggestion offers a good compromise position:
>> if the   IESG
>> and RFC Editor do not come to an agreement, we should last
>> call the   proposed
>> IESG Note and let the community determine whether (1) this is
>> an   exceptional
>> case meriting a note and (2) if the text accurately clarifies
>> the relationship.
> 
> 
> Which community, The IETF community or the wider RFC
> community? And who calls the consensus?

Also, please remember, again, that the IESG _always_ has the
right and opportunity to publish a dissent as a separate RFC in
the IETF Track.  If that dissent is wildly out of line with the
wishes of the IETF community, the IETF community presumably has
ways to deal with that.  Anything sufficiently controversial to
justify the procedure above almost certainly justifies that
treatment because a separate RFC can document reasoning and
context, while any plausible note (and all such notes so far,
including the texts specified in 3932) merely provide a
statement of conclusions.

The main argument I've heard against that approach is that the
IESG doesn't have the time.  But, if it doesn't, then a full
community review as described above, with the inevitable
community fine-tuning of text, is certainly going to equally
time-consuming.  The issue justifying comment is either
important or it is not, and allowing the IESG to impose a note
by a cryptic comment (whether intentionally so or not) in
minutes and/or the tracker doesn't serve either the community
nor the separation of streams well.

Perhaps we should be discussing supplementing "Obsoletes" and
"Updates" in RFC headers and the index with "Dissents from",
"Heaps abuse upon", and/or "Ridicules" to make the intended
relationships among document more clear, but...

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Olaf Kolkman]

On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote:

I believe Sam's suggestion offers a good compromise position: if the  
IESG
and RFC Editor do not come to an agreement, we should last call the  
proposed
IESG Note and let the community determine whether (1) this is an  
exceptional

case meriting a note and (2) if the text accurately clarifies the
relationship.



Which community, The IETF community or the wider RFC community? And  
who calls the consensus?




--Olaf




Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Doug Ewell]

"SM"  wrote:

Some people interpret RFCs as Internet Standards even though the 
document contains "It does not specify an Internet standard of any 
kind."


The document also says "Request for Comments," which is not even 
remotely true -- it represents the end of a long reviewing and 
commenting and evaluating process, not the beginning -- and it also says 
"Network Working Group," when there are over 100 active WGs but none 
with that name.


The more boilerplate takes over a document, the less readers will be 
inclined to interpret any of it literally.


--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Michael StJohns]

Hi John - 

I'm convinced we (the internet community) still need an true independent 
submissions path.  I'm no longer convinced that the path should or can lead 
through the RFC editor.

In the far past, the RFC Editor was a true independent entity - part of the 
internet community, participating and part of the IAB, but with its own funding 
source and a mandate to do the right thing.  The RFC Editor was a both a 
technical and stylistic reviewer and final arbiter of what got published - but 
that wasn't a very heavy burden for the community.

Over the years that independence has waned  - with the cessation of independent 
funding, with Jon Postel's death, with the termination of the IETF's CNRI 
relationship, and most recently with the competition of the RFC Editor 
function. Control has been centralized and the RFC Editor's editorial 
independence has all but been eliminated.  

At this point, it appears to be about who gets to decide.  And that goes back 
to the golden rule.  It's too easy for those who control the funding to control 
the publication, especially since the RFC editor function has mostly been 
reduced to stylistics without the ability (either contractually or technically) 
to act as a fair and independent decider. I may be overstating the case, but I 
can't see how it could be any different given what I've read in the 
solicitations.

I can't see any way to provide an objective set of publication rules that can 
be implemented by rote by the editor.  Which right now throws the subjective 
decisions over to the IESG which can have a conflict of interest with respect 
to certain submissions - hence the whole set of discussions about "notes".   

I fear the problem is intractable without reference to an editorial/publication 
decision function that is completely independent of the IESG. 

Mike

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Donald Eastlake]

On Mon, Aug 31, 2009 at 2:29 PM, Adam Roach wrote:
> Joel M. Halpern wrote:
>...
>> Remember also that in terms of the text being a recommendation, this is
>> not a change in practice.  This is the practice we have had for more than
>> the last 15 years.  If, for Independent Submissions, it is that big a
>> problem, I would expect ot have heard of it.
>
> Perhaps I'm just unclear on the frequency of independent submissions -- but
> can you find me an RFC that came from a source other than the IETF that does
> not include a prominent note indicating that fact?

I believe that the Independent Stream should continue to exist and
that IESG notes should be recommendations, rather than mandatory.

Here are some of RFCs of which I was an author that were Independent
Stream submissions, with notes:

RFC1898 CyberCash Credit Card Protocol Version 0.8
 This RFC documents a propriety protocol, making the protocol
public. The document internally makes it pretty clear that it came
from CyberCash, Inc., but I wouldn't say there is a "prominent note"
to that effect. It contains statements that could easily be
categorized as marketing. One effect of publishing this RFC was to
preclude later patent claims for the ideas it contained.

RFC2706 ECML v1: Field Names for E-Commerce
 This one has an IESG note commenting on its source and noting
technical deficiencies in internationalization. I'm not sure what the
policy was at the time but the IESG was, in effect, doing technical
reviews of such submissions. As an author, I had no objection to the
IESG note as I basically agreed with it. It was obsoleted by:

RFC 3106 ECML v1.1: Field Specifications for E-Commerce
 I believe this was also an independent submission. It's IESG note
points out the non-IETF source for these documents and that this work
was moving into the IETF where an IETF working group was working on a
v2. This v2 was later published as RFC 4112 as a Proposed Standard.
Thus, in this case, the independent stream provided a convenient means
to provide some continuity in the publication of work which was
transitioning into the IETF.

RFC 4144 How to Gain Prominence and Influence in Standards Organizations
 I submitted this to the IESG, it was assigned to the IETF Chair
who, after reviewing, decided that it was inappropriate for anything
but the Independent Submission stream. See:
https://datatracker.ietf.org/idtracker/draft-eastlake-prominence/comment/28295/

Hopefully the above examples give some idea of the range of items
published in the Independent Stream.

Thanks,
Donald

> I'm under the distinct impression that historical practice tagged all (or
> almost all) such documents with a prominent note. The proposed procedure
> tries to make this an extreme exception, not the norm.
>
> /a
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Thursday, September 03, 2009 12:48 +0300 Jari Arkko
 wrote:

> John,
> 
>> I suggest that it is not so much a conflict with the ongoing
>> work of an IETF WG, but a flat technical error. 
> 
> And I would in general agree with you, but in this case the
> stuff was already deployed very widely, and the purpose of the
> publication was to document existing practice. I agreed that
> the draft had to be published as it was. Of course, a clean
> design would have been different, but what do you do?

It is hard to argue against an accurate description of deployed
existing practice, even if it is conflicting or otherwise
terrible.  I think that the process should have caught the
terminology discrepancy and that the authors should have been
required to describe it, and the problems it could cause, very
carefully.

Again,  I think we are fairly closely aligned about the
principle here.  I just think that "notes" -- especially
non-specific ones that are, or appear to be, boilerplate-- are
rarely a desirable solution and that authors should be forced
into careful description of issues and/or critical reviews of
differences as a better alternative.  The job of doing the
"forcing" is that of the RFC Editor/ ISE, not the IESG, but I'd
be very concerned about any ISE who didn't take the
responsibility for ensuring that documents are not confusing wrt
IETF (and other identifiable) work were not clarified to the
point that a reader would have no trouble telling from context
was was going on.

It may amuse you to know that I've been pushing the theme that
independent submissions that even vaguely overlap with IETF work
should both show an awareness of that situation and include
critical reviews of the differences for many years, enough years
to have repeatedly made the comment to the previous RFC Editor
as well as the current one (and probably persistently enough to
occasionally irritate both).   I've also suggested from time to
time that, if someone can read an independent submission
(non-April-1) RFC that overlaps with IETF work with reasonable
care and not emerge with a clear understanding of the
relationship, the RFC Editor has not done their job.   I'm sort
of an extremist on the topic, even though the pragmatics of
getting useful documents posted have often caused me to not get
exactly what I've asked for.  But, again, I see the primary
responsibility for making sure that Independent submission
documents are clear about what they are lies 
with the authors and RFC Editor(ISE), that the considerable
improvements in Headers and Boilerplates will play a major role
in helping with that, and that qualifying "notes", regardless of
source, are a very poor choice, to be used cautiously,
selectively, with careful relationship to context, and only if
the issues cannot be resolved in any other way.

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Wednesday, September 02, 2009 17:23 -0400 Russ Housley
 wrote:

> I'd like to keep this discussion focused on the question that
> Jari asked.  While changes to the Independent Stream can be
> discussed, that seems like rfc4846bis, not this document ...
> 
> Several people have said that the RFC Editor already has the
> authority we are discussing here.  Sadly, it is not that
> simple.  The words cited below from RFC 3932 cloud this issue.
> I think they conflict with the words in the RFCs cited by John.

They do indeed and I'm not sure how helpful it is to spend a lot
of time exploring this.  I'd much rather just get 3932bis
approved and move on.   But...

> RFC 3932 says:
> 
> The IESG may return five different responses, any of which
> may be
> accompanied by an IESG note to be put on the document if
> the RFC
> Editor wishes to publish.
> 
> I think that "... to be put on the document if the RFC Editor
> wishes to publish" is the heart of the matter.  RFC 3932
> leaves the RFC Editor with the final say on publication, but
> if the document is published, the note must be included.

The question isn't about what 3932 says (about which we agree)
but from where the IESG derives the authority to say such
things.  Nothing in 2026 or any other defining documents gives
the IESG the authority to make such demands on the RFC Editor.
Nothing that I can find even gives an IETF Community consensus
process the ability to impose such a requirement.

> Sam and Pasi have already pointed out that the RFC Editor can
> appeal the action taken by the IESG if they think the note is
> off base.  In practice, the RFC Editor has asked the IESG to
> reconsider the text of one note, and the IESG has done so.

> There have not been any appeals on this topic since the
> publication of RFC 3932.

Some of us considered appealing the language in 3932 discussed
above when it was under review and decided not to because of the
degree to which 3932, in toto, seemed like an improvement over
its predecessor and because we didn't dream at the time that the
sample notes would be interpreted as rigid and prescriptive
text.   Similarly, while there were a few specific notes on a a
few documents that I think the RFC Editor should have appealed,
I don't think it is reasonable to infer "acceptance of the
IESG's authority" from "no appeals".

To use a deliberately silly and unlikely example, the RFC Editor
(and the IAB) have accepted the notion that the IESG can take an
IETF-track document and insist that it be published and
published without alteration.  Let's suppose the IESG put a
document over that transom that claimed BCP status, said
"publish and publish as-is", and whose content said "the earth
is flat and the moon is made of green cheese".  I assume it
would be published as an RFC and entered into the index as a
BCP.   I assume that it wouldn't have much effect on the shape
of the earth or composition of the moon.  The IESG's approving a
document that says "if we supply a 'note', the RFC Editor can
either publish with that note or not publish at all" should not
be considered as much more effective.

Whatever authority 3932 has in this area derives from the very
general IAB statement that makes up Section 6.   But the IAB has
subsequently (as that paragraph contemplates) made its position
on this subject very clear in the stream-defining RFC 4844 and
the provisions of RFC 4846.  As one of Olaf's notes indicated,
that IAB conclusion didn't favor mandatory notes across streams.

> Please, let's try to answer this one question on this thread:
> When the IESG performs review of an Independent stream or IRTF
> stream document and provides an IESG Note, does the RFC Editor
> have the authority (without a request for reconsideration or
> an appeal) to publish the document without the IESG Note?

It should be clear from the above that my answer is "yes, the
RFC Editor does... and always has, regardless of what 3932 says
or appears to say, and that nothing the IESG does in terms of
document-writing or approval can change that".   Given its
responsibility to supervise the RFC Editor function, a decision
by the IAB might, of course, be another matter.

   john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Richard Barnes wrote:
What is clearly going on here is that our branding is out of sync with 
the expectations of our customers. 


One of the historical items of note is that this supposed problem has been
present for about 20 years.  In other words, nothing has changed.

For example, it prompted RFC 1796, "Not All RFCs are Standards" almost 15 years 
ago.


  Whatever their historical meaning, 
RFCs are now interpreted by the broad community as documents that have 
the been reviewed and approved, to a greater or lesser degree, by the 
Internet community. 


To whatever extent it is true now, it's been true for decades and it hasn't 
caused any real-world problems that have been documented.


Let me repeat: we have no documentation that, to whatever extent there is 
confusion amongst RFC readers about the status of different RFCs, it causes 
meaningful problems.


Moreover, the core implication of your assessment is that we should shut down
the Independent Stream entirely. And indeed, you indicate that that would be 
your preference.


However, please note that you are creating a new distinction in this area of 
discussion:  "reviewed and approved by the Internet community" versus "IETF 
Standard".  Again, there is no evidence that the broader community understands 
the subtlety of that distinction, so perhaps we should really require that all 
RFCs be standards?



> I think we all agree that documents that go through

the IETF or the IAB can more or less legitimately claim that imprimatur.
Independent submissions clearly cannot.  Given that, it's not clear to 
me why the independent stream exists at all, other than for historical 
reasons.


That's your real question.  And absent an understanding of its reason for being,
how is it possible to state a preference for how it should be handled?

On the other hand, your clear statement that you believe the stream should not 
exist substantiates the concern that allowing the IESG to mandate content of an 
Independent document effectively brings that stream under the control of the 
IESG.  So Independent won't be.



Given that the abolition of the independent stream doesn't seem to be an 
option at this point, the next best thing to do is to require that 
independent-stream RFCs alert the reader to two things:

1. That this is not a document that has received IETF or IAB review, and
2. If the Internet community has any serious concerns, what they are


The IESG is not "The Internet Community".  It is a tiny group of folk, with the
usual array of expertise and biases.  Why should it be allowed to mandate the
content of documents that it has no involvement in and that are intended to be 
independent of IESG control.



The other implication of the above paragraph is that the *absence* of an 
IESG note indicates to the reader that the community has no serious 
concerns, 


Really?  This presumes that folk would know to expect an IESG Note.  Given the 
other things we know they don't know about the RFC series, they aren't likely to 
know about this possibility.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: 

> Your suggestion would largely address my concerns related to the timely
> appeal path.

I agree - this proposal:

>> if the ISE receives input from the IESG requesting specific changes to
>> a document ... and the ISE and authors decide to not incorporate those
>> proposed changes, the ISE is required to explain to the IESG, in
>> writing, why not and allow a reasonable period of time for the IESG to
>> respond. If it felt it were necessary, the IESG could then open a
>> further discussion, ask the RSE to mediate, or launch a formal request
>> for IAB review. 

is in line with the open 'checks and balances' I like to see, while not
adding additional process to almost all of what the RFC Editor does.

> From: Jari Arkko 

> I still want to see the RFC Editor as a simple journal-like function

Exactly.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

John,


I suggest that it is not so much a conflict with the ongoing
work of an IETF WG, but a flat technical error. 


And I would in general agree with you, but in this case the stuff was 
already deployed very widely, and the purpose of the publication was to 
document existing practice. I agreed that the draft had to be published 
as it was. Of course, a clean design would have been different, but what 
do you do?


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Thursday, September 03, 2009 11:55 +0300 Jari Arkko
 wrote:

>...
> In particular, when I have been an AD it has always been a
> pleasure to work with the RFC Editor, and they have always
> made exactly the right decisions. In my honest opinion of
> course.

And I'd rather count on that and think about ways to deal with
any patterns of deviation if they should occur than start
devising ways for one stream to tell another one what it must do.
 
> But I did want to bring up a couple of other angles. First of
> all, all the streams get their share of garbage. And sometimes
> the right decision is to publish the document despite it
> having some faults, or at least differences of opinion to
> established IETF practice. However, in such cases the notes
> that we are talking about really can be necessary (e.g., when
> a document redefines RADIUS Access-Reject as Access-Accept, to
> cite one real example from a few years back).

And that is perhaps exactly an example for the other side.
First, it is at the very margin between the "procedural review
for conflicts with ongoing IETF work" that both 3932 and 4846
call for and the "technical review" that both documents more or
less indicate should be handled on an individual review basis.
I suggest that it is not so much a conflict with the ongoing
work of an IETF WG, but a flat technical error.  The right
solution for such errors is to fix them, or at least ask the
authors to include a detailed discussion of why the terminology
needs to be different, not a "note"... especially, IMO, one
that, per the current interpretations of the current RFC 3932,
is closer to "nah, nah, we don't like this" than a useful
explanation that identifies the specific problem.   I believe
that, if an ISE were to ignore reviews/input on a subject like
that, or fail to push the authors very hard after getting it, we
would have a very serious problem on our hands... whether that
review came from the IESG, from a single AD, from within some
relevant WG, or from a moderately random IETF participant or
onlooker.   

So I don't see that "notes" are the right solution to that
problem.  At worst, they become a crutch that reduces the ISE's
belief that it is the responsibility of the authors and the RFC
Editor function to actually get these documents right.

> The second point was that in general, human organizations are
> prone to occasional failures. I at least prefer designs that
> are inherently capable of dealing with such failures (e.g.,
> appeals path, way to fix a bad decision). 

We agree about that, which is one of the reasons why
institutionalizing the current practice of telling the IESG why
comments are being rejected (if that happens) strikes me as a
good idea.   But, to paraphrase (I think) Joel, I'll prefer to
see things work in a way that gets documents improved rather
than ones that drop cross-stream notes into them (mandatory or
not).  And that is especially so after many decades of
experience in watching people's eyes glaze over as they notice
what appears to be boilerplate and skip it... getting the text
right, or getting it to clearly note that there are dissenting
views and why, is just a much better way to get the point across
than note-inserting.

> However, I still
> want to see the RFC Editor as a simple journal-like function;
> please don't take my comment as an indication that board
> members should be selected by Nomcom, publication decisions
> should have public last calls or anything like that. We
> already have the IETF which runs in a community driven manner.

Good.  And thanks.
john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[SM]

Hi Richard,
At 20:31 02-09-2009, Richard Barnes wrote:

Stated at more length:

What is clearly going on here is that our branding is out of sync 
with the expectations of our customers.  Whatever their historical 
meaning, RFCs are now interpreted by the broad community as 
documents that have the been reviewed and approved, to a greater or 
lesser degree, by the Internet community.  I think we all agree that 
documents that go through the IETF or the IAB can more or less 
legitimately claim that imprimatur.


Some people interpret RFCs as Internet Standards even though the 
document contains "It does not specify an Internet standard of any 
kind." on the first page.  One of the differences between the IETF 
Stream and the Independent Stream is that the former is reviewed by 
the IETF Community.  The IETF Community is small part of the Internet 
community.  This discussion is about a specific type of IESG Note 
where the IESG is supposed to only check for conflicts between the 
work of the IETF and the documents submitted.  That sounds fairly 
simple.  This discussion highlights there may be divergent views even 
for simple questions.


Independent submissions clearly cannot.  Given that, it's not clear 
to me why the independent stream exists at all, other than for 
historical reasons.


The Independent Stream offers you a path to publish your document if 
the IESG does not find it suitable for publication.  If you are using 
that path to bypass an IETF Working Group, the IESG Note under 
discussion comes into play.


Some people find the IETF path too expensive as it seems that you 
have to be an insider to get your document published.


The important point here is that you are offering a workable 
alternative to people to publish their work even though the IETF does 
not agree with the contents of the document, i.e. diverse views are 
not suppressed.  It's more than a check and balance.  Having this 
stream also allows the IETF to assess the effectiveness of its 
processes and document quality.  In other words, if it is faster to 
publish through the Independent Stream and the output of that stream 
is better, the IETF can find out whether there is a problem with its stream.


Given that the abolition of the independent stream doesn't seem to 
be an option at this point, the next best thing to do is to require 
that independent-stream RFCs alert the reader to two things:

1. That this is not a document that has received IETF or IAB review, and
2. If the Internet community has any serious concerns, what they are

Clearly the first point is an issue for Headers and 
Boilerplates.  The second point is represented in the current 
process by IESG notes; if the Internet community has concerns about 
a document, they can be included in the document as an IESG 
note.  Given that the IESG is selected through a community process, 
I'm comfortable with this delegation, though requiring IETF 
consensus would clearly add some assurance.


The second point is not represented in the current process by the 
IESG Note under discussion.  That note does not mean that the 
Internet community has concerns.  It means that it is the opinion of 
the IESG that the document fulfills one of the five conditions in Section 3.


The other implication of the above paragraph is that the *absence* 
of an IESG note indicates to the reader that the community has no 
serious concerns, which means that enabling the ISE to reject IESG 
notes effectively enables the ISE to speak on behalf of the 
community.  Given the choice, I would prefer the IESG to speak for 
me than the ISE.


The ISE is not speaking on behalf of the IETF Community.

I don't know whether you would agree to me as to whether the RFC 
Editor has been able to ensure the consistency of the RFC Series over 
the years.  I encourage you to read some of the notes from Bob Braden 
and the RFC Editor team about the RFC Editor.  Some of them may be 
historical in nature but they also spell out a constant line of 
thinking.  The decisions taken are not done lightly and they are 
still relevant after all these years.  Consistency also means that it 
is highly unlikely the RFC Editor will drop an IESG Note based on a whim.


At 14:23 02-09-2009, Russ Housley wrote:
Please, let's try to answer this one question on this thread: When 
the IESG performs review of an Independent stream or IRTF stream 
document and provides an IESG Note, does the RFC Editor have the 
authority (without a request for reconsideration or an appeal) to 
publish the document without the IESG Note?


It would be better to define the problem.  As I see it, the problem 
is that the RFC Editor might drop the IESG Note and publish the 
document as a RFC.  Once that is done, there is no way to revert 
back.  With the forthcoming changes to the RFC Editor, the IETF 
Community and/or the IESG are facing an unknown.  I suggest following 
John's proposal.  A formal notification from the ISE and delay in the 
publication

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

John,


we've had repeated examples
over the years of the IESG and/or individual ADs abusing the
independent submission process and/or the RFC Editor and zero
examples of the RFC Editor handling a request from the IESG
unreasonably or arbitrarily.


I don't want to open a discussion about who is more evil, particularly 
when opinions about any particular case probably differ. All I want to 
say about that is that as long as I have been looking, the score has 
been zero and zero on both sides. In particular, when I have been an AD 
it has always been a pleasure to work with the RFC Editor, and they have 
always made exactly the right decisions. In my honest opinion of course.


But I did want to bring up a couple of other angles. First of all, all 
the streams get their share of garbage. And sometimes the right decision 
is to publish the document despite it having some faults, or at least 
differences of opinion to established IETF practice. However, in such 
cases the notes that we are talking about really can be necessary (e.g., 
when a document redefines RADIUS Access-Reject as Access-Accept, to cite 
one real example from a few years back).


The second point was that in general, human organizations are prone to 
occasional failures. I at least prefer designs that are inherently 
capable of dealing with such failures (e.g., appeals path, way to fix a 
bad decision). However, I still want to see the RFC Editor as a simple 
journal-like function; please don't take my comment as an indication 
that board members should be selected by Nomcom, publication decisions 
should have public last calls or anything like that. We already have the 
IETF which runs in a community driven manner.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Olaf Kolkman]

On Sep 2, 2009, at 7:20 PM, John C Klensin wrote:


We simply
require that, if the ISE receives input from the IESG requesting
specific changes to a document ("specific changes" including,
but not limited to, so-called "IESG Notes") and the ISE and
authors decide to not incorporate those proposed changes, the
ISE is required to explain to the IESG, in writing, why not and
allow a reasonable period of time for the IESG to respond.  If
it felt it were necessary, the IESG could then open a further
discussion, ask the RSE to mediate, or launch a formal request
for IAB review.  Consistent with other provisions in RFC 4846,
either the IESG or the ISE could, at their discretion, make the
correspondence (the request and response) public.




I think it is more than reasonable to expect documented communication  
if a request from the IESG is not honored by the ISE. I also think it  
is reasonable to expect such decision to be appealable/reviewable and  
that all the communication is timely.


So yes, I support this, in fact I take this for granted.

I believe that difference of technical opinion follows RFC 4846 sect 5  
(which is about publishing or not publishing). The denial of a note  
from the IESG is a dispute between streams that follows RFC 5620  
4.2.1. I can see that there could be some argument about which  
procedure to follow but in the end the RFC Editor (the RSE in this  
case) will make the final decisions based on various recommendations  
(that is how both 4846 and 5820 are written).


--Olaf (no hats)

--Olaf




Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Pasi.Eronen]

John,

Your suggestion would largely address my concerns related to the
timely appeal path.

Best regards,
Pasi

> -Original Message-
> From: ext John C Klensin [mailto:john-i...@jck.com]
> Sent: 02 September, 2009 20:20
> To: Eronen Pasi (Nokia-NRC/Helsinki); j...@joelhalpern.com;
> b...@estacado.net
> Cc: i...@ietf.org; ietf@ietf.org
> Subject: RE: draft-housley-iesg-rfc3932bis and the optional/mandatory
> nature of IESG notes
> 
> 
> 
> --On Tuesday, September 01, 2009 09:55 +0200
> pasi.ero...@nokia.com wrote:
> 
> > Joel M. Halpern wrote:
> >
> >> If the ISE / RSE is unreasonable, the IAB will slap the
> >> editor and say "stop doing that."  There is no equivalent
> >> process if we reverse the structure.
> >
> > Yes, there is. If the IESG would request/recommend a
> > particularly bad IESG note, this decision can be appealed just
> > like any other IESG decision. The IAB would then determine if
> > the IESG acted appropriately or not.
> >
> > On the other hand, if the ISE/RSE decides to publish a document
> > without an IESG note even if the IESG requested/recommended
> > it, this decision cannot be effectively appealed (since the
> > RFC already came out, and can't be really "recalled").
> >
> > Although I'm not expecting this really to happen very often
> > (if ever), from checks-and-balances viewpoint I would support
> > (b) from Jari's email (in other words: RFC Editor cannot
> > unilaterally ignore a note requested by IESG, but has to take
> > it to the IAB via the usual appeal procedures).
> 
> Pasi,
> 
> A comment and then a suggested middle position.
> 
> I've been watching what we now call the Independent Submission
> Process for far longer than there has been an IETF.   I've seen
> it as an insider for a large fraction of two decades -- as an
> AD, an IAB member and then chair, as an editorial board member,
> and now as an IAB member again.   During that period, I've never
> seen an RFC Editor abuse the process by ignoring legitimate
> input.  Bob Braden may be able to provide an inside view --not
> in his present role of RFC Editor but as the very-long-time IAB
> Exec Director -- of what happened before 1992, but my educated
> guess is that instances of "RFC Editor ignores input" during
> that time were also about zero.
> 
> During the same period, I'd seen behavior I consider abusive
> from ADs or the IESG many times --  attempting to prevent
> publication of documents with which they had personal/ emotional
> disagreements that they were unwilling or unable to explain in
> public, asking for publication holds on documents for multiples
> of years, insisting that the RFC Editor not move forward until
> the IESG responds in some way and then not responding for months
> and months, demanding changes that would significantly weaken
> the document or change its meaning, and so on.  Many of those
> problems have been resolved by negotiation, but some have not.
> RFC 3932, and its limitation on technical review, was a huge
> improvement over its predecessors in that regard, but we've
> heard multiple ADs over the years claim that they can redefine
> any disagreement about a document into either a technical issue
> or a technical one (whichever is needed) if they care enough and
> especially if they can define the boundary (which they also have
> insisted that the IESG has the unilateral right to do).
> 
> In principle, the IAB could appoint a new ISE to take over in
> January who would adopt a policy of abusiveness.  But I think I
> can speak for the ACEF membership and the IAB if I say that we
> don't intend to do that... and that the IAB would expect the RSE
> to move fairly quickly, with the IAB's backing, to correct the
> attitudes involved if it occurred anyway.
> 
> So trying to make IESG notes mandatory on documents originating
> in another stream for the reasons you cite above is solving a
> problem we've never had at the risk of making a problem worse
> that we've had several times.  That strikes me as bad
> engineering at best.
> 
> And insisting that the RFC Editor invoke a formal appeals
> procedure in case of disagreement with the IESG about an
> Independent Submission would, as Olaf points out, largely undo
> the efforts of the last few years to clearly separate the
> different streams.  It would be as sensible to say that IESG
> notes should be sufficiently exceptional that the IESG would
> need to consult the IAB and get permission before sending any
> such note-request to the ISE.  I suspect that such a provision
> would not make either

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: Richard Barnes 

> What is clearly going on here is that our branding is out of sync with
> the expectations of our customers. Whatever their historical meaning,
> RFCs are now interpreted by the broad community as documents that have
> the been reviewed and approved, to a greater or lesser degree, by the
> Internet community.

This may be true, but it's also basically irrelevant to the point at hand.

Even if we stopped using the RFC series for non-standards documents, and
started a new series for indepedendent, IRTF, etc documents, (which we might
call the CFR series, with the letters reversed - it has a nice un-official
expansion, 'Can't xxx Read', in honour of those who would make it necessary)
the question of 'what authority, if any, the IESG should have over documents
in that document series' remains.

Simply not providing a dissemination path for such non-IETF document is not,
IMO, an option that's even worth discussing at any length. We need one, and
the question will remain over how much, if any, authority the IESG will have
over it.

(Temporarily reverting to your point about the series name, the problem of
the world thinking that 'RFC'=='Standard' has been with us for a long time,
and a number of things have been tried to fix it, with varying degrees of
success - the STD numbers, Internet-Drafts, etc. I generally don't put a lot
of weight on people who aren't up to speed on the details, just like I'm not
bothered by the many network users for whom 'the Internet' == 'the Web' - I
don't see any value in renaming things there, in line with their muddled
and/or simplistic model, either.)


> it's not clear to me why the independent stream exists at all, other
> than for historical reasons.

As a place for the networking community to publish things in a way which is
guaranteed to have universal, easy, ubiquitous and free access - something
which publishing in a journal does _not_ accomplish.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

In fact, I do not think the presence or absence of a note means what you 
describe.


First, remember the Independent Submission do get reviewed.  They do not 
get IETF review.  But they do get technical review by senior technical 
participants in this community.  This review can be thought of, as 
another note pointed out, as being comparable to the peer review 
required for scholarly journals.


Secondly, given that one of the points of the stream is to provide a 
mechanism for informed critique of our work, it is unsurprising that the 
IESG has objected to such critiques.


Third, it should be remembered that the IESG review being discussed is 
not a technical review.  It is a review for the relationship between 
this work and the IETF work.  If the IESG finds that there is a relevant 
relationship, and provides a reasonable note saying so, then the ISE is 
going to publish it.  (There may be negotiation about the wording, but 
the editors responsibility to be factually accurate means that such 
accurate notes will be published.)  If IESG members in reading the 
document find technical problems, then they should tell the ISE, just 
the way any other reviewer would.


Next, given that the review is not technical, and given that the review 
is done by a small number of people, I would not want a reader to draw 
conclusions about technical competence based on the presence or absence 
of an IESG note.  Such conclusions should be based on reading the document.


And let's be careful about asserting that IESG review is an assurance of 
quality.  There have been plenty of marginal documents that the IESG has 
approved over the years.   Sometimes they approved them for very good 
reasons.  Note that even 15 years ago the IESG was under interesting 
publication pressures some of the time.  I am sure it still is.


If you want to abolish the Independent Stream, then we can have a 
discussion (separately from this one) about who would get to do that, 
and whether that would mean that the IETF would have to find a different 
outlet, or the Independent Stream.  The mix of history, practice, and 
branding would make for a very confusing situation.  Personally, I think 
the Independent Stream is valuable.  (That's why I help review them.) 
So I do not want that stream or its independence weakened.


Also, remember that there are actually 4 streams.  I presume that no one 
is trying to suggest that the IESG should get to put IESG warning notes 
on IAB documents or IRTF documents?  Yet IRTF documents are actually 
sometimes less reviewed than Independent Stream documents.  It is not 
uncommon for an IRTF Working group to produce multiple reports when the 
group can not come to agreement.  (Note, I do not think that the degree 
of review correlates with the degree of quality.  That is a further 
confusion about these notes.)


Yours,
Joel M. Halpern


Richard Barnes wrote:
Being a relatively short-term IETF participant, I lack the history that 
many on this list have, but since Jari asked for comments, I'll provide 
some.


Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and 
others that it makes sense to have IESG notes be mandatory for the ISE 
to include in independent stream RFCs.



Stated at more length:

What is clearly going on here is that our branding is out of sync with 
the expectations of our customers.  Whatever their historical meaning, 
RFCs are now interpreted by the broad community as documents that have 
the been reviewed and approved, to a greater or lesser degree, by the 
Internet community.  I think we all agree that documents that go through 
the IETF or the IAB can more or less legitimately claim that imprimatur.


Independent submissions clearly cannot.  Given that, it's not clear to 
me why the independent stream exists at all, other than for historical 
reasons.


Given that the abolition of the independent stream doesn't seem to be an 
option at this point, the next best thing to do is to require that 
independent-stream RFCs alert the reader to two things:

1. That this is not a document that has received IETF or IAB review, and
2. If the Internet community has any serious concerns, what they are

Clearly the first point is an issue for Headers and Boilerplates.  The 
second point is represented in the current process by IESG notes; if the 
Internet community has concerns about a document, they can be included 
in the document as an IESG note.  Given that the IESG is selected 
through a community process, I'm comfortable with this delegation, 
though requiring IETF consensus would clearly add some assurance.


The other implication of the above paragraph is that the *absence* of an 
IESG note indicates to the reader that the community has no serious 
concerns, which means that enabling the ISE to reject IESG notes 
effectively enables the ISE to speak on behalf of the community.  Given 
the choice, I would prefer the IESG to speak for me than the ISE.


So I agree with Jari

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Richard Barnes]

Being a relatively short-term IETF participant, I lack the history that 
many on this list have, but since Jari asked for comments, I'll provide 
some.


Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and 
others that it makes sense to have IESG notes be mandatory for the ISE 
to include in independent stream RFCs.



Stated at more length:

What is clearly going on here is that our branding is out of sync with 
the expectations of our customers.  Whatever their historical meaning, 
RFCs are now interpreted by the broad community as documents that have 
the been reviewed and approved, to a greater or lesser degree, by the 
Internet community.  I think we all agree that documents that go through 
the IETF or the IAB can more or less legitimately claim that imprimatur.


Independent submissions clearly cannot.  Given that, it's not clear to 
me why the independent stream exists at all, other than for historical 
reasons.


Given that the abolition of the independent stream doesn't seem to be an 
option at this point, the next best thing to do is to require that 
independent-stream RFCs alert the reader to two things:

1. That this is not a document that has received IETF or IAB review, and
2. If the Internet community has any serious concerns, what they are

Clearly the first point is an issue for Headers and Boilerplates.  The 
second point is represented in the current process by IESG notes; if the 
Internet community has concerns about a document, they can be included 
in the document as an IESG note.  Given that the IESG is selected 
through a community process, I'm comfortable with this delegation, 
though requiring IETF consensus would clearly add some assurance.


The other implication of the above paragraph is that the *absence* of an 
IESG note indicates to the reader that the community has no serious 
concerns, which means that enabling the ISE to reject IESG notes 
effectively enables the ISE to speak on behalf of the community.  Given 
the choice, I would prefer the IESG to speak for me than the ISE.


So I agree with Jari's option (b), that IESG notes should be something 
that is always applied to the published RFC.


--Richard





Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last call 
in June because several IESG members felt uncomfortable with the IESG 
notes being used only in exceptional circumstances. I asked Russ to 
prepare the -07 version. This version allowed notes to be used at the 
IESG's discretion and suggested that the linkage (or lack thereof) to 
IETF work would typically be explained in the note. This version was 
taken to the second last call.


While the number of comments we received was small, after the last call 
was over I determined that the consensus was against this change. As a 
result, I asked Russ to prepare the -08 version. This version goes back 
to the "exceptional" wording from -06, but incorporated a number of 
editorial corrections that had been made in interim. I also took the 
draft back to the IESG telechat last week. The IESG was not extremely 
pleased with the new version, but my understanding is that they were 
willing to accept the changes. However, a new issue was brought up: one 
of the changes that Russ and I felt was editorial highlighted the fact 
that the document makes the IESG notes a recommendation to the RFC 
Editor, not something that would automatically always be applied to the 
published RFC. Some IESG members were concerned about this, and 
preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that is 
always applied to the published RFC. Please reply before the next IESG 
meeting on September 10. Some e-mails on this topic have already been 
sent in the Last Call thread -- I have seen those and there is no need 
to resend.


(For the record my own slight preference is b. But I have to say that I 
think the document has been ready to be shipped from version -06, and 
its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: Dave CROCKER 

> The IESG is not, and must not be, the sole repository for responsible
> decision-making in the IETF

Couldn't agree more. A division of powers, with checks and balances, are a
critical part of any organizational system, IMO.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Sam Hartman wrote:

Russ, I think that it is absolutely critical ...




Sam,

However, the IESG is not the IETF. 



This is the single-most important statement in your note.

"Absolutely critical" is strong language, but is not warranted by 20 years of 
experience or any other empirical basis.  We need to be very careful not to 
confuse mathematical possibility with operational reality and we need to be 
careful to consider real costs, along with theoretical benefits.


The RFC Editor is also part of the IETF, with plenty of its own accountability, 
and it has established a history of highly professional and responsible 
performance, including over the last 10 years, while under "new" management.


The IESG is not, and must not be, the sole repository for responsible 
decision-making in the IETF, yet that really seems to be at the core of your view.


There is no legitimate reason to allow the IESG to mandate language in an 
Independent RFC, and there is very good reason /not/ to allow it to.


For example, it then wouldn't be Independent...

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Wednesday, September 02, 2009 13:53 -0400 Sam Hartman
 wrote:

> John, in principle,  I would be delighted by this option if
> you made a few more changes to make the RFC process more
> accountable:
> 
> 1) Open up the rfc-editorial board so that it was selected by
> some sort of nomcom/community process.  That nomcom could of
> course draw from a broader community than the IETF as a whole
> 
> 2) Provide an appeals path for IAB decisions related to the
> RFC-editor function
> 
> I have a lot more faith in the IETF process than I do the RFC
> editor process.  I believe that the RFC editor process is more
> open to a different type of abuse than the IESG process, but I
> believe we have a far more open process for addressing
> problems with the IESG than we do with IAB decisions about the
> RFC editor or with the RFC editor process itself.
> 
> However, absent these changes, I don't believe there would be
> appropriate checks and balances present.

Sam,

Brian and Joel covered most of what I would have said had I
gotten to your note earlier.  I would add only three things to
their remarks:

(1) Checks and balances against what?  I trust the answer is not
"publication of high-quality articles which contain content with
which some AD happens to disagree" because that is the only
thing that has been at issue in the past.  On other matters, the
RFC Editor has _voluntarily_ deferred to the IESG, often going
well beyond what the current procedures require.  Remember that
RFC Editor acceptance of an IESG Note is voluntary today,
regardless of what the IESG might believe, _and_ that the
"written notice" procedure I suggested has been followed, as a
professional courtesy, for years, without any such requirement
being written down anywhere.   Put differently, what is the
threat model against which you are trying to defend?

(2) If I have to make a choice, I prefer to design systems to
deal with real and identified threats rather than purely
theoretical ones.  As I pointed out, we've had repeated examples
over the years of the IESG and/or individual ADs abusing the
independent submission process and/or the RFC Editor and zero
examples of the RFC Editor handling a request from the IESG
unreasonably or arbitrarily.   So why do you believe we need
more protection against the possibility of RFC Editor abuse than
we do against IESG abuse or, from a different perspective,
believe that the wider community would be better served by
tilting the balance even further toward the IESG?

(3) As Dave Crocker is fond of pointing out, the Nomcom cannot
be expected to make good appointments in areas that are outside
the expertise of most of its members... there is just no
foundation on which a Nomcom without that expertise can evaluate
candidates.  Given that, why do you believe that the Nomcom
could select an effective editorial board, with or without a
broader selection process?  Neither democracy nor randomness
seem to me to be guarantees of competence.   And, again, what
real problem do you think that would solve?

john


 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Russ Housley]

I'd like to keep this discussion focused on the question that Jari 
asked.  While changes to the Independent Stream can be discussed, 
that seems like rfc4846bis, not this document ...


Several people have said that the RFC Editor already has the 
authority we are discussing here.  Sadly, it is not that simple.  The 
words cited below from RFC 3932 cloud this issue.  I think they 
conflict with the words in the RFCs cited by John.


RFC 3932 says:

   The IESG may return five different responses, any of which may be
   accompanied by an IESG note to be put on the document if the RFC
   Editor wishes to publish.

I think that "... to be put on the document if the RFC Editor wishes 
to publish" is the heart of the matter.  RFC 3932 leaves the RFC 
Editor with the final say on publication, but if the document is 
published, the note must be included.


Sam and Pasi have already pointed out that the RFC Editor can appeal 
the action taken by the IESG if they think the note is off base.  In 
practice, the RFC Editor has asked the IESG to reconsider the text of 
one note, and the IESG has done so.  There have not been any appeals 
on this topic since the publication of RFC 3932.


The rfc3932bis-08 text provides greater flexibility to the RFC 
Editor, making the IESG note a recommendation to the RFC Editor.  The 
is the flexibility that several people have claimed the RFC Editor 
has had all along based on other documents.


Please, let's try to answer this one question on this thread: When 
the IESG performs review of an Independent stream or IRTF stream 
document and provides an IESG Note, does the RFC Editor have the 
authority (without a request for reconsideration or an appeal) to 
publish the document without the IESG Note?


Russ


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian E Carpenter]

Sam,

On 2009-09-03 05:53, Sam Hartman wrote:

...
> 1) Open up the rfc-editorial board so that it was selected by some sort of 
> nomcom/community process.  That nomcom could of course draw from a broader 
> community than the IETF as a whole

I'm certainly in favour of transparency in the process of setting
up the Independent stream's editorial board. I could see value in
an open call for nominations. However, you're asking for it to be
set up in way that's very different from the typical editorial board
for a scholarly journal or the typical technical programme committee
for a scholarly conference. It seems to me that the editor needs
to have the final say in the membership, because s/he needs to be able
to work well with all the board members.

Also, I have no idea how to define the community for the Independent
stream. ISOC members? RIR members? ICANN community? ACM? BCS? IEEE?
Where would it end?

Brian

N.B. I am a member of the current RFC Editorial Board, by invitation
from the current RFC Editor.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

RFC 5620 calls for the appointment of an RFC Series Advisory Group, to 
be appointed by the IAB, and a Independent Submissions Stream Editorial 
Board (ISSEB for now), which serves at the pleasure of the ISE.

This was reviewed and approved by the community.
I presume with cognizance of the existing rules about the authority over 
the Streams.


I presume you are concerned about the membership of the ISSEB.
Given that this stream is specifically not an IETF stream, I do not see 
why it would make sense for the membership to be appointed by the IETF 
community, through its nomcom designates.


With regard to appeals, are you asking for an ability to appeal an IAB 
decision about the RFC Editor?  Presumably, a procedural appeal could be 
made to the ISoC Board of Trustees, if the IAB had not followed 
documented procedures.  But otherwise, we are back to the issue of 
undermining the Independence of the Independent Stream.


Remember, all of these documents are Experimental or Informational.
Yours,
Joel

Sam Hartman wrote:

"John" == John C Klensin  writes:

John> However, if your concern is really to make sure that there
John> is a timely appeal path, I have a suggestion that might be
John> acceptable to everyone without causing unfortunate
John> side-effects.  We simply require that, if the ISE receives
John> input from the IESG requesting specific changes to a
John> document ("specific changes" including, but not limited to,
John> so-called "IESG Notes") and the ISE and authors decide to
John> not incorporate those proposed changes, the ISE is required
John> to explain to the IESG, in writing, why not and allow a
John> reasonable period of time for the IESG to respond.  If it
John> felt it were necessary, the IESG could then open a further
John> discussion, ask the RSE to mediate, or launch a formal
John> request for IAB review.  Consistent with other provisions in
John> RFC 4846, either the IESG or the ISE could, at their
John> discretion, make the correspondence (the request and
John> response) public.

John, in principle,  I would be delighted by this option if you made a few more 
changes to make the RFC process more accountable:

1) Open up the rfc-editorial board so that it was selected by some sort of 
nomcom/community process.  That nomcom could of course draw from a broader 
community than the IETF as a whole

2) Provide an appeals path for IAB decisions related to the RFC-editor function

I have a lot more faith in the IETF process than I do the RFC editor
process.  I believe that the RFC editor process is more open to a
different type of abuse than the IESG process, but I believe we have a
far more open process for addressing problems with the IESG than we do
with IAB decisions about the RFC editor or with the RFC editor process
itself.

However, absent these changes, I don't believe there would be
appropriate checks and balances present.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Bob Braden]

John, in principle,  I would be delighted by this option if you made a few more 
changes to make the RFC process more accountable:

1) Open up the rfc-editorial board so that it was selected by some sort of 
nomcom/community process.  That nomcom could of course draw from a broader 
community than the IETF as a whole

2) Provide an appeals path for IAB decisions related to the RFC-editor function

I have a lot more faith in the IETF process than I do the RFC editor
process. 



Sam,

If you have a specific complaint about the functioning of the RFC 
Editor, please bring it out on the rfc-interest list.
I don't know what kind of abuse you think we are open to, but I would 
certainly like to hear it.


Bob Braden

 I believe that the RFC editor process is more open to a
different type of abuse than the IESG process, but I believe we have a
far more open process for addressing problems with the IESG than we do
with IAB decisions about the RFC editor or with the RFC editor process
itself.

However, absent these changes, I don't believe there would be
appropriate checks and balances present.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
  



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

> "John" == John C Klensin  writes:
John> However, if your concern is really to make sure that there
John> is a timely appeal path, I have a suggestion that might be
John> acceptable to everyone without causing unfortunate
John> side-effects.  We simply require that, if the ISE receives
John> input from the IESG requesting specific changes to a
John> document ("specific changes" including, but not limited to,
John> so-called "IESG Notes") and the ISE and authors decide to
John> not incorporate those proposed changes, the ISE is required
John> to explain to the IESG, in writing, why not and allow a
John> reasonable period of time for the IESG to respond.  If it
John> felt it were necessary, the IESG could then open a further
John> discussion, ask the RSE to mediate, or launch a formal
John> request for IAB review.  Consistent with other provisions in
John> RFC 4846, either the IESG or the ISE could, at their
John> discretion, make the correspondence (the request and
John> response) public.

John, in principle,  I would be delighted by this option if you made a few more 
changes to make the RFC process more accountable:

1) Open up the rfc-editorial board so that it was selected by some sort of 
nomcom/community process.  That nomcom could of course draw from a broader 
community than the IETF as a whole

2) Provide an appeals path for IAB decisions related to the RFC-editor function

I have a lot more faith in the IETF process than I do the RFC editor
process.  I believe that the RFC editor process is more open to a
different type of abuse than the IESG process, but I believe we have a
far more open process for addressing problems with the IESG than we do
with IAB decisions about the RFC editor or with the RFC editor process
itself.

However, absent these changes, I don't believe there would be
appropriate checks and balances present.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Tuesday, September 01, 2009 09:55 +0200
pasi.ero...@nokia.com wrote:

> Joel M. Halpern wrote:
> 
>> If the ISE / RSE is unreasonable, the IAB will slap the
>> editor and say "stop doing that."  There is no equivalent
>> process if we reverse the structure.
> 
> Yes, there is. If the IESG would request/recommend a
> particularly bad IESG note, this decision can be appealed just
> like any other IESG decision. The IAB would then determine if
> the IESG acted appropriately or not.
> 
> On the other hand, if the ISE/RSE decides to publish a document
> without an IESG note even if the IESG requested/recommended
> it, this decision cannot be effectively appealed (since the
> RFC already came out, and can't be really "recalled").
> 
> Although I'm not expecting this really to happen very often
> (if ever), from checks-and-balances viewpoint I would support
> (b) from Jari's email (in other words: RFC Editor cannot
> unilaterally ignore a note requested by IESG, but has to take
> it to the IAB via the usual appeal procedures).

Pasi,

A comment and then a suggested middle position.

I've been watching what we now call the Independent Submission
Process for far longer than there has been an IETF.   I've seen
it as an insider for a large fraction of two decades -- as an
AD, an IAB member and then chair, as an editorial board member,
and now as an IAB member again.   During that period, I've never
seen an RFC Editor abuse the process by ignoring legitimate
input.  Bob Braden may be able to provide an inside view --not
in his present role of RFC Editor but as the very-long-time IAB
Exec Director -- of what happened before 1992, but my educated
guess is that instances of "RFC Editor ignores input" during
that time were also about zero.

During the same period, I'd seen behavior I consider abusive
from ADs or the IESG many times --  attempting to prevent
publication of documents with which they had personal/ emotional
disagreements that they were unwilling or unable to explain in
public, asking for publication holds on documents for multiples
of years, insisting that the RFC Editor not move forward until
the IESG responds in some way and then not responding for months
and months, demanding changes that would significantly weaken
the document or change its meaning, and so on.  Many of those
problems have been resolved by negotiation, but some have not.
RFC 3932, and its limitation on technical review, was a huge
improvement over its predecessors in that regard, but we've
heard multiple ADs over the years claim that they can redefine
any disagreement about a document into either a technical issue
or a technical one (whichever is needed) if they care enough and
especially if they can define the boundary (which they also have
insisted that the IESG has the unilateral right to do).

In principle, the IAB could appoint a new ISE to take over in
January who would adopt a policy of abusiveness.  But I think I
can speak for the ACEF membership and the IAB if I say that we
don't intend to do that... and that the IAB would expect the RSE
to move fairly quickly, with the IAB's backing, to correct the
attitudes involved if it occurred anyway.

So trying to make IESG notes mandatory on documents originating
in another stream for the reasons you cite above is solving a
problem we've never had at the risk of making a problem worse
that we've had several times.  That strikes me as bad
engineering at best.

And insisting that the RFC Editor invoke a formal appeals
procedure in case of disagreement with the IESG about an
Independent Submission would, as Olaf points out, largely undo
the efforts of the last few years to clearly separate the
different streams.  It would be as sensible to say that IESG
notes should be sufficiently exceptional that the IESG would
need to consult the IAB and get permission before sending any
such note-request to the ISE.  I suspect that such a provision
would not make either the IESG or the IAB very happy.

However, if your concern is really to make sure that there is a
timely appeal path, I have a suggestion that might be acceptable
to everyone without causing unfortunate side-effects.  We simply
require that, if the ISE receives input from the IESG requesting
specific changes to a document ("specific changes" including,
but not limited to, so-called "IESG Notes") and the ISE and
authors decide to not incorporate those proposed changes, the
ISE is required to explain to the IESG, in writing, why not and
allow a reasonable period of time for the IESG to respond.  If
it felt it were necessary, the IESG could then open a further
discussion, ask the RSE to mediate, or launch a formal request
for IAB review.  Consistent with other provisions in RFC 4846,
either the IESG or the ISE could, at their discretion, make the
correspondence (the request and response) public.

The one restriction I'd impose on this is that "reasonable time"
not be more than a few weeks... again, there has been abuse in
that area in 

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

Russ, I think that it is absolutely critical that the IETF be able to
attach a note to an RFC and that this note not simply be a
recommendation.

We can believe all we want that the IETF stream is just one stream and
that all other streams are independent.  However, the RFC process is
very tightly tied to the IETF, and I think it is reasonable for the
IESG to be able to raise a note in an exceptional circumstance.

I believe that this serves as an important check on the independent
stream, just as the independent stream is supposed to serve as an
important check on the IETF stream.


Part of my thinking is motivated by my belief that the IETF has more
structures in place and a broader community of people reviewing its
work than the independent stream.  I fully understand that there are
people who are involved/interested in the independent stream who are
not involved in the IETF.  I believe that independent+ietf is a
broader community than IETF alone.  (We assume that it is a
significantly broader community; I've never been given data to back up
that assumption, but I'm happy to hold it for the moment.)  However I
doubt that community is sufficiently broader that it should be able to
overrule the IETF.  Even if the community was sufficiently broader,
I'm still not sure that I would be comfortable with it being able to
overrule the IETF of a comment that the IETF wanted to place on an
independent stream document.

However, the IESG is not the IETF.  I'd personally be happy to ignore
that and assume it would all work out.  I'd also be happy with a
mechanism where the IESG could propose a note, and the RFC editor had
the option of accepting the note or asking the IESG to last-call its
note within the IETF community.

I would not consider it acceptable if the note were purely advisory.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Tuesday, September 01, 2009 16:37 +0300 Jari Arkko
 wrote:

> Robert,
> 
>> the IESG should not be making any kind of technical review of
>> independent submissions
> 
> Right, and we are not.
> 
>>  - the reason the review was even permitted ... was to allow
>>  work that was submitted independently but which was directly
>> in the same area as IETF work to be merged, and all
>> considered together.
> 
> That is indeed the primary goal of the 3932 and 3932bis. I.e.,
> promote independent work, but allow a check in the exceptional
> case that it collides with IETF work.

And that is, again, the answer to the question you raised.  In
the context of Headers and Boilerplates, the stream is
identified.  Many will pay attention or learn to do so.  Others
will not, but, for them (regardless of their motivation), there
is no evidence that "notices" in obvious front-matter
boilerplate will be noticed either.

If members of the IESG have technical issues with a document,
let them raise them as interested, skilled, and persuasive
individuals as both the current and proposed revised versions of
3932, and your comment above indicate that they should.   If
they have major philosophical disagreements, let them write
critical commentary, with explanations and details, and see if
they can get them published as RFCs.  Independent of their
ability to use the IETF Track to self-publish, I have never, in
the history of the RFC Series, seen the RFC Editor turn down a
competently written and clear criticism of another document --
IMO, in the last decade or two, there have been far too few such
submissions.

Conversely, independent of technical substance, if the document
is not clear enough about what it is --from the text-- tell the
RFC Editor (ISE) and thereby promote a discussion with the
authors about changes to make the document more clear.  If the
ISE ignores that advice, we quite frankly have a more serious
problem.  But I've never, and I mean never, seen that happen.

To rephrase what others have said, attaching derogatory notes
without explanations or specific attribution is the act of lazy
people who either cannot or will not take responsibility for
making document-specific comments that can either be attributed
to those making them or that have been through enough process to
represent IETF consensus.

 john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[RJ Atkinson]

All,

I value the independence of the Independent Submission stream and
IRTF Stream from the IETF (including the IESG).  Indeed, both the
RFC series and the acceptance of independent RFCs long pre-date
even the existence of the IETF.

I prefer that the IESG NOT have or assert the authority to mandate
additions to Independent Stream or IRTF Stream documents.

The existing approach where the IESG MAY request an IESG note is
more than sufficient for cases where a non-IETF document is making
an end-run around the IETF standards activities.  We have lots of
operational experience that this works well enough, so there is
no obvious reason for the current approach to change.

Robert Elz's notes from earlier today on this topic seem sensible,
as do Joel Halpern's notes on this topic over the past several days.

Yours,

Ran Atkinson
r...@extremenetworks.com


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Elz]

Date:Tue, 01 Sep 2009 16:37:31 +0300
From:Jari Arkko 
Message-ID:  <4a9d239b.7070...@piuha.net>

  | Right, and we are not.

That is very good to hear.   I haven't been watching much of recent
IETF happenings (last few years) so I explicitly make no comment about
anything that has happened recently.

In the past however, back when I was more involved, there were occasions
when that was certainly not the case - there were cases where the IESG
decided that a proposal (an independent submission) would really be bad for
the internet, and requested (and perhaps even published) notes with comments
along the lines of how insecure, unscalable, and generally horrid some
document was, and strongly advising the world to ignore it.

That's all technical discussion, and none of that should ever be a part
of an IESG note requested to be added to a doc.

Given that, what's left for an IESG note pretty much amounts to "this
does not represent IETF consensus" or "Readers should also see RFC
for an alternative solution" - neither of which are very likely to be
ignored by the editor - or in fact, by the doc author if requested of
him or her - so there should be no need for mandatory addition of notes,
just a request should be enough (ie: if one ever is refused, the chances
are really pretty good that it should never have been requested.)

One final note, none of this, of course, prevents anyone, including
IESG members, writing their own independent submission, criticising some
other proposal (in a different RFC) - such a thing could even be made
an IETF consensus doc if desired - that's all reasonable,but of course
takes more effort, and real considered and supported arguments, an IESG
note to the same effect is just the lazy way out, and should never be
used (and to repeat my opening comment, I am not claimimg that it has any
time recently, I simply have no idea.)

kre

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

Robert,


the IESG should not be making any kind of technical review of
independent submissions


Right, and we are not.


 - the reason the review was even permitted ... was to allow work that was 
submitted independently
but which was directly in the same area as IETF work to be merged, and
all considered together.


That is indeed the primary goal of the 3932 and 3932bis. I.e., promote 
independent work, but allow a check in the exceptional case that it 
collides with IETF work.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Elz]

Date:Mon, 31 Aug 2009 16:29:26 +0300
From:Jari Arkko 
Message-ID:  <4a9bd036.1000...@piuha.net>

  | And now back to the input that I wanted to hear. I would like to get a 
  | sense from the list whether you prefer (a) that any exceptional IESG 
  | note is just a recommendation to the RFC Editor or (b) something that is 
  | always applied to the published RFC.

Definitely (a) - the reasons for this have already been made by many
others and I won't repeat them.

But, I'd also change the target of the recommendation - the IESG shouldn't
be asking or instructing the editor (whichever form of editor, RFC or ISE
or ...) in any way, rather they should be suggesting to the author of a
document that it would likely be more acceptable if it included some
extra particular text.

The editor would then, of course, take the author's response to that request
into account when deciding whether or not to publish the author's document.

Lastly, as has been stated already, but this time I will restate it for
emphasis, the IESG should not be making any kind of technical review of
independent submissions - the reason the review was even permitted (remember
previously independent submissions went directly to the RFC editor who simply
published them, or declined) was to allow work that was submitted independently
but which was directly in the same area as IETF work to be merged, and
all considered together.That is, the IESG is just supposed to determine
whether there is (or perhaps should be) a WG to work on the same topic, and
if so, invite the author to submit the document to that WG for further
review (and even possibly elevation into the standards track).

Beyond that, the IESG should be leaving independent submissions alone.

kre

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Olaf Kolkman]

On Aug 31, 2009, at 3:29 PM, Jari Arkko wrote:



And now back to the input that I wanted to hear. I would like to get  
a sense from the list whether you prefer (a) that any exceptional  
IESG note is just a recommendation to the RFC Editor or (b)  
something that is always applied to the published RFC. Please reply  
before the next IESG meeting on September 10. Some e-mails on this  
topic have already been sent in the Last Call thread -- I have seen  
those and there is no need to resend.




I am happy to see the document being reverted so that an IESG note is  
exceptional.


Over the last years I've started to appreciate the fact that the RFC  
Series is not exclusively an IETF series. On the other hand I am  
sensitive to the argument that most consumers of RFCs do not see the  
fine distinction between standards track and non-standards track RFCs,  
let alone the difference between non-standards track from various  
streams. Headers and Boilerplates tried to address that and hopefully  
helps to clarify the fact that not every RFC is an IETF Standards  
Track document.


However, the whole RFC streams framework has been build with complete  
independence of the various stream in mind. In my opinion that makes  
sense. The IAB should not be able to force notes on IETF stream  
documents, the IRTF should not be able to put them on IAB stream  
documents, and the IESG should not be able to force them on IRTF, IAB  
and Independent documents. In other words it is not clear to me why  
the combination IESG and the Independent stream should have a special  
status. And, as other mentioned, deciding about that special status is  
not a matter that rests solely with the IESG/IETF stream.


I do think that in essence this is a fairly theoretical discussion. I  
believe that in general notes from the IESG will have merit and  
recommendations will in general be followed, specifically since they  
are likely to be exceptional. In the case that the judgement, by the  
IESG and ISE, of merit conflicts, there is a procedure in RFC 5620.


I'm for (a).



--Olaf (no hats)




Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Pasi.Eronen]

Joel M. Halpern wrote:

> If the ISE / RSE is unreasonable, the IAB will slap the editor and say
> "stop doing that."  There is no equivalent process if we reverse the
> structure.

Yes, there is. If the IESG would request/recommend a particularly bad
IESG note, this decision can be appealed just like any other IESG
decision. The IAB would then determine if the IESG acted appropriately
or not.

On the other hand, if the ISE/RSE decides to publish a document
without an IESG note even if the IESG requested/recommended it, this
decision cannot be effectively appealed (since the RFC already came
out, and can't be really "recalled").

Although I'm not expecting this really to happen very often (if ever),
from checks-and-balances viewpoint I would support (b) from Jari's
email (in other words: RFC Editor cannot unilaterally ignore a note
requested by IESG, but has to take it to the IAB via the usual
appeal procedures).
 
Best regards,
Pasi
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

Adam,

So, to be clear, the question you have raised has to do with the 
difference between:


   "The IESG may choose to add an IESG note to an Independent
   Submission..."


and:

   "The IESG may choose to request the addition of an IESG note to an
   Independent Submission..."



Right?


Yes.


This has nothing to do with the text:

   "In exceptional cases, when the relationship of the document to the
   IETF standards process might be unclear..." ?


Right. The exceptional vs. always-on question is another issue.

Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Lars Eggert]

On 2009-8-31, at 19:24, Joel M. Halpern wrote:
But the same could be said all our experimental and informational RFCs.

 Should we insist that all experimental and informational RFC, even
from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD."


FWIW, this was exactly what I proposed a while ago. The current way we  
label RFCs requires folks to understand the intricacies of the  
different streams. Few in the broader industry do.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Lars Eggert]

Hi,

On 2009-8-31, at 18:34, Adam Roach wrote:
In particular, when a user accesses a document at a url of the form

, there is going to be a strong
presumption on their part that the document was produced by the  
IETF. In

the cases that this presumption is incorrect, it seems tantamount to
deception to tuck the distinction between IETF and non-IETF documents
away in an obscure header field.


I agree with you. This is exactly why I had originally proposed to  
stick the words "NOT AN INTERNET STANDARD" into the top left corner on  
the first page (where it currently says "Network Working Group") for  
all non-standards-track documents in all streams.


That proposal got shot down with the (paraphrased) argument "we should  
label RFCs with what they are rather with what they are not." I still  
disagree with this, because the #1 question what looking at any RFC  
should be "is this an Internet standard or not?"


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

The scope already says that the IESG is only supposed to comment on the 
relationship to existing work.  When the comments are on that topic, 
there has rarely been an issue.  (The one related difficulty is when the 
IESG has asked for reasonable delays, to let a working group get its 
product out, and then the WG has taken much longer than expected to 
deliver.)
However, even then the editor has needed to edit the words provided.  Of 
course, such editing has to be negotiated with the IESG.  (The edit can 
edit, but he can't put words in someone elses mouth.)



Part of the problem I face is that there is significant evidence that 
the IESG has unintentionally produced very biased and inappropriate 
text.  The ISE (RSE) needs to have a strong position from which to 
discuss such things.


I will grant that an unreasonable ISE can do unreasonable things.
There is no history of difficulties in the converse.

If the ISE / RSE is unreasonable, the IAB will slap the editor and say 
"stop doing that."  There is no equivalent process if we reverse the 
structure.


Yours,
Joel M. Halpern

Ben Campbell wrote:


On Aug 31, 2009, at 9:04 PM, Joel M. Halpern wrote:

Making the IESG note mandatory, even if that required IETF agreement, 
would essentially give the IETf veto over the Independent stream.  The 
IESG would simply propose a note so extreme that no author would 
accept it on their document.  Given that I have seen proposed notes 
almost that bad in the past, I see no reason to believe it will not 
happen in the future.


Unless we wish to gut the Independent Stream of its right and 
important role of providing critical review of ongoing ideas, I would 
strongly recommend that the IAB not accept any procedure by which this 
would occur.


Remember, the IETF did not create the Independent Stream.  It arguably 
predates the existence of standards track documents.




So can the mandate be scoped? It seems like a little word smithing could 
distinguish between "notes to clarify relationship with standards work" 
vs "commentary on the quality of the work".



Yours,
Joel

Ben Campbell wrote:

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:
[...]




+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF 
document.


Can't the IETF can have a consensus that a non-IETF document 
relates to

other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.

Ah, sorry, I was agreeing with Brian Rosen statement that  a 
concensus call was okay. I didn't mean (and I doubt he did, but he 
can speak for himself) that I think we _needed_ one, only that if 
that were the only way we could make an IESG request "binding", then 
it was okay. If we feel we can trust the IESG on this, I'm okay with 
it :-)




In fact the answer to Jari's question appears to be a matter of 
logic,

not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under
what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the 
IESG was

showing unreasonable bias.

I assume an ISE could also who bias.
It seems to me this all converges on deciding who has to appeal in a 
dispute.


  Brian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 9:04 PM, Joel M. Halpern wrote:

Making the IESG note mandatory, even if that required IETF  
agreement, would essentially give the IETf veto over the Independent  
stream.  The IESG would simply propose a note so extreme that no  
author would accept it on their document.  Given that I have seen  
proposed notes almost that bad in the past, I see no reason to  
believe it will not happen in the future.


Unless we wish to gut the Independent Stream of its right and  
important role of providing critical review of ongoing ideas, I  
would strongly recommend that the IAB not accept any procedure by  
which this would occur.


Remember, the IETF did not create the Independent Stream.  It  
arguably predates the existence of standards track documents.




So can the mandate be scoped? It seems like a little word smithing  
could distinguish between "notes to clarify relationship with  
standards work" vs "commentary on the quality of the work".



Yours,
Joel

Ben Campbell wrote:

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:
[...]




+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF  
document.


Can't the IETF can have a consensus that a non-IETF document  
relates to

other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a  
problem,

and I didn't think Jari was reopening that aspect.

Ah, sorry, I was agreeing with Brian Rosen statement that  a  
concensus call was okay. I didn't mean (and I doubt he did, but he  
can speak for himself) that I think we _needed_ one, only that if  
that were the only way we could make an IESG request "binding",  
then it was okay. If we feel we can trust the IESG on this, I'm  
okay with it :-)




In fact the answer to Jari's question appears to be a matter of  
logic,
not of opinion. The IESG, which acts for the IETF, logically  
cannot
determine anything about the contents of a non-IETF document. So  
the

inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request?  
Under

what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I  
would

expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect  
that

in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the  
IESG was

showing unreasonable bias.

I assume an ISE could also who bias.
It seems to me this all converges on deciding who has to appeal in  
a dispute.


  Brian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

Making the IESG note mandatory, even if that required IETF agreement, 
would essentially give the IETf veto over the Independent stream.  The 
IESG would simply propose a note so extreme that no author would accept 
it on their document.  Given that I have seen proposed notes almost that 
bad in the past, I see no reason to believe it will not happen in the 
future.


Unless we wish to gut the Independent Stream of its right and important 
role of providing critical review of ongoing ideas, I would strongly 
recommend that the IAB not accept any procedure by which this would occur.


Remember, the IETF did not create the Independent Stream.  It arguably 
predates the existence of standards track documents.


Yours,
Joel

Ben Campbell wrote:


On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:

[...]





+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF 
document.


Can't the IETF can have a consensus that a non-IETF document relates to
other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.



Ah, sorry, I was agreeing with Brian Rosen statement that  a concensus 
call was okay. I didn't mean (and I doubt he did, but he can speak for 
himself) that I think we _needed_ one, only that if that were the only 
way we could make an IESG request "binding", then it was okay. If we 
feel we can trust the IESG on this, I'm okay with it :-)







In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under
what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the IESG was
showing unreasonable bias.


I assume an ISE could also who bias.

It seems to me this all converges on deciding who has to appeal in a 
dispute.




   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:

[...]





+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF  
document.


Can't the IETF can have a consensus that a non-IETF document  
relates to

other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a  
problem,

and I didn't think Jari was reopening that aspect.



Ah, sorry, I was agreeing with Brian Rosen statement that  a concensus  
call was okay. I didn't mean (and I doubt he did, but he can speak for  
himself) that I think we _needed_ one, only that if that were the only  
way we could make an IESG request "binding", then it was okay. If we  
feel we can trust the IESG on this, I'm okay with it :-)







In fact the answer to Jari's question appears to be a matter of  
logic,

not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under
what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect  
that

in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the  
IESG was

showing unreasonable bias.


I assume an ISE could also who bias.

It seems to me this all converges on deciding who has to appeal in a  
dispute.




   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian E Carpenter]

On 2009-09-01 13:14, Ben Campbell wrote:
> 
> On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote:
> 
>> On 2009-09-01 05:56, Ben Campbell wrote:
>>>
>>> On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
>>>
 Yes, I understand, this only applies to the Independent Submission
 stream.

 We ask the IESG to review these documents, and that review is
 technical.

 I don't think it is appropriate for an editor to make a judgment of
 whether
 a technical note is, or is not appropriate to be included in a
 document.  I
 think the presumption should be that it is appropriate, and the
 authors have
 a way to object.  While I understand the role of the ISE is somewhat
 different from the RFC Editor, I understand the role to be primarily
 editorial and we are not choosing the ISE with regard to their
 ability to
 make judgments like whether the IESG note is appropriate or not.

 I think it would be okay to have the note go through an IETF consensus
 call.

>>>
>>> +1 , including the "IETF consensus call" part.
>>
>> I don't understand how IETF consensus is relevant to a non-IETF document.
> 
> Can't the IETF can have a consensus that a non-IETF document relates to
> other IETF work in some way?

Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.

> 
>>
>> In fact the answer to Jari's question appears to be a matter of logic,
>> not of opinion. The IESG, which acts for the IETF, logically cannot
>> determine anything about the contents of a non-IETF document. So the
>> inclusion of an IESG note can only be a request.
> 
> How would you expect the RFC editor to evaluate such a request? Under
> what circumstances would it be reasonable to refuse to include it?

Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the IESG was
showing unreasonable bias.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote:


On 2009-09-01 05:56, Ben Campbell wrote:


On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:


Yes, I understand, this only applies to the Independent Submission
stream.

We ask the IESG to review these documents, and that review is  
technical.


I don't think it is appropriate for an editor to make a judgment of
whether
a technical note is, or is not appropriate to be included in a
document.  I
think the presumption should be that it is appropriate, and the
authors have
a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their  
ability to

make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF  
consensus

call.



+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF  
document.


Can't the IETF can have a consensus that a non-IETF document relates  
to other IETF work in some way?




In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under  
what circumstances would it be reasonable to refuse to include it?




Brian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephen Kent]

Joel,

I agree that IESG notes should be rare, but primarily because 
independent stream submissions should be rare :-).


Long ago, when I served on the IAB, we grappled with this problem, 
and failed to find a good solution. Despite what we say about RFC 
status and origin markings, the public sees RFCs as carrying the 
imprimatur of the IETF (not just that of the RFC Editor). When Jon 
Postel was the RFC editor, we were pretty comfortable with his 
judgement on these matters, this was less of an issue. However, time 
have changed and I would be happy to see inclusion of an IESG note be 
mandatory, contrary to historical practice.


Steve
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian E Carpenter]

On 2009-09-01 05:56, Ben Campbell wrote:
> 
> On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
> 
>> Yes, I understand, this only applies to the Independent Submission
>> stream.
>>
>> We ask the IESG to review these documents, and that review is technical.
>>
>> I don't think it is appropriate for an editor to make a judgment of
>> whether
>> a technical note is, or is not appropriate to be included in a
>> document.  I
>> think the presumption should be that it is appropriate, and the
>> authors have
>> a way to object.  While I understand the role of the ISE is somewhat
>> different from the RFC Editor, I understand the role to be primarily
>> editorial and we are not choosing the ISE with regard to their ability to
>> make judgments like whether the IESG note is appropriate or not.
>>
>> I think it would be okay to have the note go through an IETF consensus
>> call.
>>
> 
> +1 , including the "IETF consensus call" part.

I don't understand how IETF consensus is relevant to a non-IETF document.

In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.

 Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
 wrote:

> I would like to get some further input from the community on
> this draft.
>...
> And now back to the input that I wanted to hear. I would like
> to get a sense from the list whether you prefer (a) that any
> exceptional IESG note is just a recommendation to the RFC
> Editor or (b) something that is always applied to the
> published RFC. Please reply before the next IESG meeting on
> September 10. Some e-mails on this topic have already been
> sent in the Last Call thread -- I have seen those and there is
> no need to resend.

Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.

>...

regards,
  john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[SM]

Hi Jari,
At 06:29 31-08-2009, Jari Arkko wrote:
And now back to the input that I wanted to hear. I would like to get 
a sense from the list whether you prefer (a) that any exceptional 
IESG note is just a recommendation to the RFC Editor or (b) 
something that is always applied to the published RFC. Please reply 
before the next IESG meeting on September 10. Some e-mails on this 
topic have already been sent in the Last Call thread -- I have seen 
those and there is no need to resend.


I prefer option (a); the IESG note is just a recommendation to the RFC Editor.

If the IESG wants the IESG Note to always be applied, it is 
determining the RFC Editor policy and that's the role of the IAB 
according to Section 5.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Andrew G. Malis]

+1 to Dave's suggestion below regarding the name of the draft, as well
as Joel's and John's responses to Jari's original question (i.e.,
retain existing practice regarding IESG notes).

Cheers,
Andy

On Mon, Aug 31, 2009 at 12:27 PM, Dave CROCKER wrote:
>
>
> Joel M. Halpern wrote:
>>
>>    The documented rules and practice has long been that with regard to
>> Independent Submissions the IESG notes are a request / recommendation to the
>> RFC Editor (soon to be ISE), not a statement of what will be included in the
>> result.
>
> ...
>>
>> Based on having seen a number of IESG notes, and reading the resulting
>> text and its inherent tone, I would strongly prefer that IESG notes be an
>> exception.
>
> ...
>>
>> Thus, I strongly prefer (a).   I prefer that such notes be rare, and that
>> they remain recommendations to the ISE.
>
>
> +1.
>
> It might help folks to understand the independent relationship, between the
> IETF/IESG and these other RFC streams, if the title of this draft were
> changed from "Handling of" to "Assisting with".
>
> d/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

Jari Arkko wrote:
However, in this case: if you have a general comment on 3932bis, 
please post to the Last Call thread. If you want to answer my specific 
question about the optional/mandatory nature of the IESG note, please 
respond to this thread.


So, to be clear, the question you have raised has to do with the 
difference between:


   "The IESG may choose to add an IESG note to an Independent
   Submission..."


and:

   "The IESG may choose to request the addition of an IESG note to an
   Independent Submission..."



Right? This has nothing to do with the text:

   "In exceptional cases, when the relationship of the document to the
   IETF standards process might be unclear..." ?



/a
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

Dave,

The current question is about IESG Notes.  We ought to restrict 
postings on this thread to that question.


Yes.

As always, before a draft is actually approved we appreciate getting all 
kinds of feedback on it. Particularly if there's a serious problem 
somewhere. Of course, when a Last Call period is over, we do not re-open 
a document lightly even if it hasn't been approved yet.


However, in this case: if you have a general comment on 3932bis, please 
post to the Last Call thread. If you want to answer my specific question 
about the optional/mandatory nature of the IESG note, please respond to 
this thread. My current plan is NOT to reopen other aspects of the 
document, though I understand that some of them may have to be discussed 
to provide context for the specific question.


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Joel M. Halpern wrote:

If every document needs this marking, ...



If this line of discussion needs to happen, it needs to happen on a separate
thread, because I believe it has nothing to do with the current text, proposal, 
or concern.


As noted, it is opening a very old -- and I believe very different -- basic 
concern.

The current question is about IESG Notes.  We ought to restrict postings on this 
thread to that question.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 13:20 -0500 Adam Roach
 wrote:

> Joel M. Halpern wrote:
>> And given that these are Independent Submissions, they aren't
>> supposed  to be subject to community review.
> 
> Given this fact, why is there pushback on the idea that we
> would prominently mark the documents to indicate that they
> have not been subjected to community review? It seems like the
> kind of thing that is of extreme relevance to the reader.

Because the statement "this has not been subjected to community
review" is often factually incorrect and because there are
multiple communities out there.  Some of these documents are
actually more intensively reviewed, by more experts, than some
things the IETF puts on the standards track.

If the IESG were inclined to quiz the RFC Editor as to what
review had occurred and then jointly identify each document,
including IETF Stream documents, with the precise type of review
that had occurred, we would be having a different discussion.
Headers and Boilerplates provides for some of that type of
annotation without requiring any IESG notes.

Alternately, if the IESG wanted to subject every Independent
Submission document to IETF Last Call, review the results of
that Last Call, and on that basis, sometimes generate a note and
subject it to IETF Last Call, I'd have no problem at all
introducing a section into Independent Submission Track RFCs
containing the IETF's opinion of the document, identified as
such.  For lots of good reasons, I don't expect that to happen
and do not consider vague text that may be false (e.g., claiming
that no review within the IETF community occurred when, in fact,
it might have) to be helpful in this regard.  I also believe
that having the IESG tell lies that can easily be tested and
exposed as such does not contribute positively to the reputation
of the IETF.

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

If every document needs this marking, then that is a matter for headers 
and boilerplates.  I can understand arguing about how we mark documents.
If our headers and boilerplate are not sufficient, then we should 
renegotiate them.  I personally think that they are about as good as we 
can get.


But the IESG review is for checking for conflicts with IETF work.  It is 
for reporting such conflicts.  It is not a general review for "does the 
IETF like this work."


Yours,
Joel

Adam Roach wrote:

Joel M. Halpern wrote:
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.


Given this fact, why is there pushback on the idea that we would 
prominently mark the documents to indicate that they have not been 
subjected to community review? It seems like the kind of thing that is 
of extreme relevance to the reader.


/a


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

Joel M. Halpern wrote:
Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.


And I agree that there is an issue of the community not distinguishing 
among standards-track, informational, and experimental documents. But 
that's a separable problem that is, in my opinion, of much smaller 
consequence.


I assert that the distinction between these classes of documents is 
much, much smaller than the distinction between IETF-reviewed documents 
and independent stream documents.



Remember also that in terms of the text being a recommendation, this 
is not a change in practice.  This is the practice we have had for 
more than the last 15 years.  If, for Independent Submissions, it is 
that big a problem, I would expect ot have heard of it.


Perhaps I'm just unclear on the frequency of independent submissions -- 
but can you find me an RFC that came from a source other than the IETF 
that does not include a prominent note indicating that fact?


I'm under the distinct impression that historical practice tagged all 
(or almost all) such documents with a prominent note. The proposed 
procedure tries to make this an extreme exception, not the norm.


/a
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 10:30 -0700 Bob Braden
 wrote:

> Your argument seems to me to be the latest version of the
> 30-year old discussion about whether all RFCs are standards.
>...

Not quite 30 years, because it took us a while to start using
terms like "standard", and even longer to get the IETF into
existence into existence.  But, as part of that long argument it
is worth reminding those those think that non-standards RFCs
should be published in a different series that the IETF, after
it was created, decided to publish its standards-track documents
in the RFC Series.  It isn't as if the other documents were
somehow grafted on -- it is the IETF standards-track materials
that were grafted on to what was previously an
almost-all-independent-submissions situation (there were a few
IANA and IAB documents in the series too).   I know you know
that, but others seem to forget, and to do so fairly regularly.

The Headers & Boilerplate document is supposed to help with the
identification situation by explicitly identifying the streams
and the role of each.  If those warnings are not sufficient, it
is not clear to me that boilerplate notes, of the variety that
RFC 3932 has been read as calling for, will help much.

>...
> And even documents in the
> IETF stream (which includes
> individual submission, by the way) very considerably in
> quality and safety.

Hmm.  I have a counter-proposal to those IESG members who
believe in their right to include negative-sounding comments
about independent submission documents without explaining the
reasons for their objections (or, often, even the objections
themselves) or taking responsibility for those objections by
signing  their names or at least putting explicit information
into the tracker.  

The current RFC Editorial Board contains significant expertise
and does review the Independent Submission documents for
technical adequacy.  If IESG membership is a special
qualification, it is worth noting that the Editorial Board's
membership includes several former ADs and even two former IETF
Chairs.  

How about we start Editorial Board review of all IETF Stream
documents arriving from the IESG and, where the Editorial Board
deems it appropriate, attaches notes that reflect on the quality
and/or safety of the ideas suggested.   I imagine that the
Editorial Board would at least be willing to be specific about
objections and to sign specific notes, unlike, at times, the
IESG.

Let the second-guessing begin!

No, not really it is a terrible idea and I can't imagine
most Editorial Board members having time, but perhaps it makes
the point.

john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

Joel M. Halpern wrote:
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.


Given this fact, why is there pushback on the idea that we would 
prominently mark the documents to indicate that they have not been 
subjected to community review? It seems like the kind of thing that is 
of extreme relevance to the reader.


/a
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

If we really feel that the current approach does not make non-standards 
clear enough, then we should address that for all experimental or 
informational documents.  It is basically unrelated to the Independent 
Stream issue.



With regard to documents that are alternatives to existing IETF work, 
the RFC Editor has always required, as is appropriate for any academic 
work, a description of the relationship to existing work.  Reviewers who 
know the area and work are selected.  Thus, the document, in its text, 
is expected to explain why it is different from the standard.  Which 
also requires it to be clear that it is different from the standard.


Handling such discrepancies in the document is both clearer, more 
effective, and fairer to the authors than trying to solve the problem by 
slapping a note on the front of the document.


And before someone says "but the ISE is not requrie to do that", note 
that the ISE is required to maintain the quality of the stream.  That 
includes ensuring that there is suitable description of the relationship 
to existing work.  So not only is this the current practice, but it is 
part of what we can reasonably expect.


I guess this relates to a lot of my problem with this whole "mandatory 
IESG notes" approach.  If there is a real problem with the document, 
then the document should address the problem.  If the IESG does not like 
the light the document puts the IETF into, then we probably made a 
mistake earlier, and this is not the place to fix it.
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.


Yours,
Joel

Ben Campbell wrote:


On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:

Yes, I understand, this only applies to the Independent Submission 
stream.


We ask the IESG to review these documents, and that review is technical.

I don't think it is appropriate for an editor to make a judgment of 
whether
a technical note is, or is not appropriate to be included in a 
document.  I
think the presumption should be that it is appropriate, and the 
authors have

a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their ability to
make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF consensus 
call.




+1 , including the "IETF consensus call" part.


(...and to venture into the water under the consensus bridge part of the 
discussion...)


Joel wrote:

If I understand your note properly, your primary concern is that folks 
will think that Independent submission are IETF products.

This is a fair concern.
But the same could be said all our experimental and informational 
RFCs.  Should we insist that all experimental and informational RFC, 
even from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
Repeated multiple times to make sure folks do not miss it?

(remember, Independent Submissions are never standards track documents.)

Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.


And we fail miserably in those cases too.

Since I first started contributing in the IETF, I have on countless 
occasions had to explain to people who don't participate that some given 
RFC is not a standard. To most of the world, RFC==standard. Maybe 
putting "THIS IS NOT AN IETF STANDARD" all over the place would help, 
but I'm not sure about even that. Even worse, I have personally seen 
multiple instances of marketing people intentionally introducing FUD by 
talking about compliancy to some non standards-track RFC. (or even an ID 
that had been actively deprecated by the relevant working group.) 
Personally, I think our first mistake was using the same document name 
prefix for the different streams.


I am most particularly concerned about the case where a draft that was 
presented to a work group that selected not to publish it, and then 
later gets published in the independent 
stream.___

Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:

Yes, I understand, this only applies to the Independent Submission  
stream.


We ask the IESG to review these documents, and that review is  
technical.


I don't think it is appropriate for an editor to make a judgment of  
whether
a technical note is, or is not appropriate to be included in a  
document.  I
think the presumption should be that it is appropriate, and the  
authors have

a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their  
ability to

make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF  
consensus call.




+1 , including the "IETF consensus call" part.


(...and to venture into the water under the consensus bridge part of  
the discussion...)


Joel wrote:

If I understand your note properly, your primary concern is that  
folks will think that Independent submission are IETF products.

This is a fair concern.
But the same could be said all our experimental and informational  
RFCs.  Should we insist that all experimental and informational RFC,  
even from IETF WGs, carry big warnings "THIS IS NOT AN IETF  
STANDARD." Repeated multiple times to make sure folks do not miss it?
(remember, Independent Submissions are never standards track  
documents.)


Wed try very hard to make it clear to folks that there is a  
difference between standards track documents and non-standards track  
documents. Independent Stream documents are not standards track  
documents.


And we fail miserably in those cases too.

Since I first started contributing in the IETF, I have on countless  
occasions had to explain to people who don't participate that some  
given RFC is not a standard. To most of the world, RFC==standard.  
Maybe putting "THIS IS NOT AN IETF STANDARD" all over the place would  
help, but I'm not sure about even that. Even worse, I have personally  
seen multiple instances of marketing people intentionally introducing  
FUD by talking about compliancy to some non standards-track RFC. (or  
even an ID that had been actively deprecated by the relevant working  
group.) Personally, I think our first mistake was using the same  
document name prefix for the different streams.


I am most particularly concerned about the case where a draft that was  
presented to a work group that selected not to publish it, and then  
later gets published in the independent stream. 
___

Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Bob Braden]

Brian Rosen wrote:

Yes, I understand, this only applies to the Independent Submission stream.

We ask the IESG to review these documents, and that review is technical.


  
It seems important to begin a discussion with true facts, and the 
statement immediately above is false.

To quote Harald's words from RFC 3932:

  In March 2004, the IESG decided to make a major change in this review
  model.  The new review model will have the IESG take responsibility
  ONLY for checking for conflicts between the work of the IETF and the
  documents submitted; soliciting technical review is deemed to be the
  responsibility of the RFC Editor.  If an individual IESG member
  chooses to review the technical content of the document and finds
  issues, that member will communicate these issues to the RFC Editor,
  and they will be treated the same way as comments on the documents
  from other sources.

Sigh. I suppose this message is a derivative work.

Bob Braden'



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
  



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Bob Braden]

Adam Roach wrote:



While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.


In particular, when a user accesses a document at a url of the form 
, there is going to be a strong 
presumption on their part that the document was produced by the IETF. 
In the cases that this presumption is incorrect, it seems tantamount 
to deception to tuck the distinction between IETF and non-IETF 
documents away in an obscure header field.


/a


Your argument seems to me to be the latest version of the 30-year old 
discussion about whether all
RFCs are standards.   They are not.  And even documents in the IETF 
stream (which includes

individual submission, by the way) very considerably in quality and safety.

Bob Braden



Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last 
call in June because several IESG members felt uncomfortable with the 
IESG notes being used only in exceptional circumstances. I asked Russ 
to prepare the -07 version. This version allowed notes to be used at 
the IESG's discretion and suggested that the linkage (or lack 
thereof) to IETF work would typically be explained in the note. This 
version was taken to the second last call.


While the number of comments we received was small, after the last 
call was over I determined that the consensus was against this 
change. As a result, I asked Russ to prepare the -08 version. This 
version goes back to the "exceptional" wording from -06, but 
incorporated a number of editorial corrections that had been made in 
interim. I also took the draft back to the IESG telechat last week. 
The IESG was not extremely pleased with the new version, but my 
understanding is that they were willing to accept the changes. 
However, a new issue was brought up: one of the changes that Russ and 
I felt was editorial highlighted the fact that the document makes the 
IESG notes a recommendation to the RFC Editor, not something that 
would automatically always be applied to the published RFC. Some IESG 
members were concerned about this, and preferred the latter.


And now back to the input that I wanted to hear. I would like to get 
a sense from the list whether you prefer (a) that any exceptional 
IESG note is just a recommendation to the RFC Editor or (b) something 
that is always applied to the published RFC. Please reply before the 
next IESG meeting on September 10. Some e-mails on this topic have 
already been sent in the Last Call thread -- I have seen those and 
there is no need to resend.


(For the record my own slight preference is b. But I have to say that 
I think the document has been ready to be shipped from version -06, 
and its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian Rosen]

Yes, I understand, this only applies to the Independent Submission stream.

We ask the IESG to review these documents, and that review is technical.

I don't think it is appropriate for an editor to make a judgment of whether
a technical note is, or is not appropriate to be included in a document.  I
think the presumption should be that it is appropriate, and the authors have
a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their ability to
make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF consensus call.

Brian

On 8/31/09 11:25 AM, "John C Klensin"  wrote:

> 
> Brian,
> 
> Remember that 3932bis applies to the Independent Submission
> stream, not to IETF documents of any flavor.  These are, in
> general, documents that have not been formally reviewed in the
> IETF (although many of them have been extensively discussed).
> They are not IETF Stream documents, about which, subject to
> push-back from WGs and the community, the IESG can do pretty
> much as it likes.
> 
> For these documents, there is no IETF Last Call.  If the IESG
> creates a note, that note reflects the individual judgments of
> the ADs (and presumably IESG review and approval of those
> judgments) and not the rough consensus of the IETF community.
> Given that, while it may be a "technical concern" (or at least
> reflective of a technical preference), it is a concern from (at
> most) a group of individuals who happen to be on the IESG; there
> is no requirement that it represent a technical concern from the
> IETF community.  
> 
> In that context, what you are really asking for is that the
> preferences or concerns of that group of individuals --
> preferences that they could not get the RFC Editor or document
> authors to accept through normal review channels -- override the
> decision-making process and approval of a non-IETF stream.
> Especially since we expect documents in the Independent
> Submission stream that would carefully criticize or provide
> alternatives to IETF-approved approaches (see RFC 4846), giving
> the IESG that much authority, especially without consulting the
> IETF Community and determining consensus, does not seem sensible
> or consistent to me.  Indeed, it seems like a mechanism for
> permitting only authorized dissent.
> 
>> ...
> 
> YMMD.
> 
> john
> 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Joel M. Halpern wrote:
The documented rules 
and practice has long been that with regard to Independent Submissions 
the IESG notes are a request / recommendation to the RFC Editor (soon to 
be ISE), not a statement of what will be included in the result.

...
Based on having seen a number of IESG notes, and reading the resulting 
text and its inherent tone, I would strongly prefer that IESG notes be 
an exception.  

...


Thus, I strongly prefer (a).   I prefer that such notes be rare, and 
that they remain recommendations to the ISE.



+1.

It might help folks to understand the independent relationship, between the 
IETF/IESG and these other RFC streams, if the title of this draft were changed 
from "Handling of" to "Assisting with".


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

If I understand your note properly, your primary concern is that folks 
will think that Independent submission are IETF products.

This is a fair concern.
But the same could be said all our experimental and informational RFCs. 
 Should we insist that all experimental and informational RFC, even 
from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
Repeated multiple times to make sure folks do not miss it?

(remember, Independent Submissions are never standards track documents.)

Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.


While it is important to note when experimental or informational 
documents have had community review, and when they haven't, I do not see 
that the distinction, for these documents, warrants denigrating outside 
comment and input.


Remember also that in terms of the text being a recommendation, this is 
not a change in practice.  This is the practice we have had for more 
than the last 15 years.  If, for Independent Submissions, it is that big 
a problem, I would expect ot have heard of it.


Also, to pick up a comment from Robert, and reinforce and answer from 
John, in providing an IESG note for an Independent Submission, the IESG 
is not shining the light of IETF consensus (rough or otherwise) on the 
document.  While I strongly respect the IESG judgment, and want them to 
keep using and applying that judgment, I do not think it fair to 
conflate that with reflecting IETF consensus on something where there no 
source for such consensus.  (For clarity, I do want the IESG to have the 
opportunity to make their recommendation, and I want it taken serious by 
the ISE / RSE.  This is because they do have a view of the IETF activity 
picture, and can provide necessary perspective and judgment about the 
relationships among the moving parts.  But let us not induce confusion 
by assigning that judgment inappropriate grounding.)


Yours,
Joel

Adam Roach wrote:
I have a serious concern about the impact of this decision and the 
perception of RFCs by the community that uses the output of the IETF.


The IETF process has a number of very strong safeguards in place to 
ensure that the protocols we publish have certain levels of quality and 
safety built in, and the Internet community at large has grown to 
associate that level of quality with the RFC series.


While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.


In particular, when a user accesses a document at a url of the form 
, there is going to be a strong 
presumption on their part that the document was produced by the IETF. In 
the cases that this presumption is incorrect, it seems tantamount to 
deception to tuck the distinction between IETF and non-IETF documents 
away in an obscure header field.


/a

Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last 
call in June because several IESG members felt uncomfortable with the 
IESG notes being used only in exceptional circumstances. I asked Russ 
to prepare the -07 version. This version allowed notes to be used at 
the IESG's discretion and suggested that the linkage (or lack thereof) 
to IETF work would typically be explained in the note. This version 
was taken to the second last call.


While the number of comments we received was small, after the last 
call was over I determined that the consensus was against this change. 
As a result, I asked Russ to prepare the -08 version. This version 
goes back to the "exceptional" wording from -06, but incorporated a 
number of editorial corrections that had been made in interim. I also 
took the draft back to the IESG telechat last week. The IESG was not 
extremely pleased with the new version, but my understanding is that 
they were willing to accept the changes. However, a new issue was 
brought up: one of the changes that Russ and I felt was editorial 
highlighted the fact that the document makes the IESG notes a 
recommendation to the RFC Editor, not something that would 
automatically always be applied to the published RFC. Some IESG 
members were concerned about this, and preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that 
is always applied to the published RFC. Please reply before the next 
IESG meeting on September 10. Some e-mails on this topic have already 
been sent in the Last Call thread -- I have seen those and there is no 
need to resend.


(For the record my own slight preference is b. But I have to 

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephen Farrell]

Joel M. Halpern wrote:
> Thus, I strongly prefer (a).   I prefer that such notes be rare, and
> that they remain recommendations to the ISE.

+1 to that,

S.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

Before commenting on the question, I wish to comment slightly on the 
exposition.  While I understand that some IESG members were surprised 
that the text brought to them treated IESG notes as a recommendation to 
the RFC Editor, such surprise gap in historical information rather than 
a change.  That text was not a change in practice.  The documented rules 
and practice has long been that with regard to Independent Submissions 
the IESG notes are a request / recommendation to the RFC Editor (soon to 
be ISE), not a statement of what will be included in the result.


Based on having seen a number of IESG notes, and reading the resulting 
text and its inherent tone, I would strongly prefer that IESG notes be 
an exception.  Also, I believe that the stream identification and 
associated indications are quite sufficient for the normal case.  Unless 
we wish to deliberately denigrate the Independent Submissions tream, we 
should not be putting extra notes on the front of them.  I consider the 
Independent Stream to be an important source of information and 
commentary that helps the overall internet process, and would be very 
unhappy to see it denigrated.


Thus, I strongly prefer (a).   I prefer that such notes be rare, and 
that they remain recommendations to the ISE.


Even if the IAB were to agree that such notes should be common, I would 
strongly recommend that the tone and content of such notes remain at the 
discretion of the ISE.  Otherwise, there is no true Independent series.


Yours,
Joel M. Halpern

Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last call 
in June because several IESG members felt uncomfortable with the IESG 
notes being used only in exceptional circumstances. I asked Russ to 
prepare the -07 version. This version allowed notes to be used at the 
IESG's discretion and suggested that the linkage (or lack thereof) to 
IETF work would typically be explained in the note. This version was 
taken to the second last call.


While the number of comments we received was small, after the last call 
was over I determined that the consensus was against this change. As a 
result, I asked Russ to prepare the -08 version. This version goes back 
to the "exceptional" wording from -06, but incorporated a number of 
editorial corrections that had been made in interim. I also took the 
draft back to the IESG telechat last week. The IESG was not extremely 
pleased with the new version, but my understanding is that they were 
willing to accept the changes. However, a new issue was brought up: one 
of the changes that Russ and I felt was editorial highlighted the fact 
that the document makes the IESG notes a recommendation to the RFC 
Editor, not something that would automatically always be applied to the 
published RFC. Some IESG members were concerned about this, and 
preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that is 
always applied to the published RFC. Please reply before the next IESG 
meeting on September 10. Some e-mails on this topic have already been 
sent in the Last Call thread -- I have seen those and there is no need 
to resend.


(For the record my own slight preference is b. But I have to say that I 
think the document has been ready to be shipped from version -06, and 
its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

I have a serious concern about the impact of this decision and the 
perception of RFCs by the community that uses the output of the IETF.


The IETF process has a number of very strong safeguards in place to 
ensure that the protocols we publish have certain levels of quality and 
safety built in, and the Internet community at large has grown to 
associate that level of quality with the RFC series.


While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.


In particular, when a user accesses a document at a url of the form 
, there is going to be a strong 
presumption on their part that the document was produced by the IETF. In 
the cases that this presumption is incorrect, it seems tantamount to 
deception to tuck the distinction between IETF and non-IETF documents 
away in an obscure header field.


/a

Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last 
call in June because several IESG members felt uncomfortable with the 
IESG notes being used only in exceptional circumstances. I asked Russ 
to prepare the -07 version. This version allowed notes to be used at 
the IESG's discretion and suggested that the linkage (or lack thereof) 
to IETF work would typically be explained in the note. This version 
was taken to the second last call.


While the number of comments we received was small, after the last 
call was over I determined that the consensus was against this change. 
As a result, I asked Russ to prepare the -08 version. This version 
goes back to the "exceptional" wording from -06, but incorporated a 
number of editorial corrections that had been made in interim. I also 
took the draft back to the IESG telechat last week. The IESG was not 
extremely pleased with the new version, but my understanding is that 
they were willing to accept the changes. However, a new issue was 
brought up: one of the changes that Russ and I felt was editorial 
highlighted the fact that the document makes the IESG notes a 
recommendation to the RFC Editor, not something that would 
automatically always be applied to the published RFC. Some IESG 
members were concerned about this, and preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that 
is always applied to the published RFC. Please reply before the next 
IESG meeting on September 10. Some e-mails on this topic have already 
been sent in the Last Call thread -- I have seen those and there is no 
need to resend.


(For the record my own slight preference is b. But I have to say that 
I think the document has been ready to be shipped from version -06, 
and its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Sparks]

John, Jari -

I was one of the folks expressing the concern Jari points to below,  
and it's
a small facet of a larger worry I have about a potential (and I think  
likely)
unintended consequence of the header/boilerplate changes. To capture  
that
in this thread (with apologies for walking through old discussions) :  
specifically,
I think we're making it even harder for people who are not deeply  
steeped in

IETF arcana to tell the difference between the output of a working group
(or any other IETF product) and the output of an individual. By  
downplaying
that distinction, we are also making it easier for people with the  
motivation
to champion technologies that compete with IETF products to convince  
those

non IETF-arcana-steeped folks around them to follow.

But, that's water under the headers and boilerplate consensus building  
bridge.


I think it should be more _routine_ than we are making it for _some_  
body

representing IETF consensus to shine a light on that distinction when
necessary. The escalation process you point to is a fairly high bar  
and it
puts providing the required energy on the wrong parties. I'm sensitive  
to

the 'how it has always been' argument, but we are exactly in the process
of changing to a new RFC-editor model.

I've also been asking a few regular contributors and some chairs what
they thought about this, and am very frustrated with how little  
attention

the entire change this small conversation is part of appears to have
received in the greater community. I don't know what to do to improve  
that
beyond what we're doing now (through calls like this and through  
individual

prodding).

RjS

On Aug 31, 2009, at 9:37 AM, John C Klensin wrote:




--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
 wrote:


I would like to get some further input from the community on
this draft.
...
And now back to the input that I wanted to hear. I would like
to get a sense from the list whether you prefer (a) that any
exceptional IESG note is just a recommendation to the RFC
Editor or (b) something that is always applied to the
published RFC. Please reply before the next IESG meeting on
September 10. Some e-mails on this topic have already been
sent in the Last Call thread -- I have seen those and there is
no need to resend.


Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.


...


   regards,
 john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 10:59 -0400 Brian Rosen
 wrote:

> Following a request to look at this document, and with only a
> cursory look at the archives, I'm confused.
> 
> The note is always intended to be included in the document
> itself, right?
> 
> Is this change designed to compel, as opposed to request, the
> RFC Editor to include the note?
> 
> If the answer to those is yes, then I support the change.  The
> RFC Editor is not selected to make judgments on whether a note
> from the IESG should, or should not be included in a document.
> It's not an editorial judgment, it's is a technical concern.

Brian,

Remember that 3932bis applies to the Independent Submission
stream, not to IETF documents of any flavor.  These are, in
general, documents that have not been formally reviewed in the
IETF (although many of them have been extensively discussed).
They are not IETF Stream documents, about which, subject to
push-back from WGs and the community, the IESG can do pretty
much as it likes.

For these documents, there is no IETF Last Call.  If the IESG
creates a note, that note reflects the individual judgments of
the ADs (and presumably IESG review and approval of those
judgments) and not the rough consensus of the IETF community.
Given that, while it may be a "technical concern" (or at least
reflective of a technical preference), it is a concern from (at
most) a group of individuals who happen to be on the IESG; there
is no requirement that it represent a technical concern from the
IETF community.  

In that context, what you are really asking for is that the
preferences or concerns of that group of individuals --
preferences that they could not get the RFC Editor or document
authors to accept through normal review channels -- override the
decision-making process and approval of a non-IETF stream.
Especially since we expect documents in the Independent
Submission stream that would carefully criticize or provide
alternatives to IETF-approved approaches (see RFC 4846), giving
the IESG that much authority, especially without consulting the
IETF Community and determining consensus, does not seem sensible
or consistent to me.  Indeed, it seems like a mechanism for
permitting only authorized dissent.

>...

YMMD.

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf