Subject: Re: [INDEP] Forward with independent

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jul 2006 11:07:08 -0700

Olaf M. Kolkman wrote:
> 
> Kind Colleagues,
> 
> After the IAB plenary discussion the open issues concerning the
> independent stream were presented[1]. 

Is there any consideration to presenting these issues in other forums,
e.g., at ACM Sigcomm, or IEEE ICNP - where non-IETF community members
might be encouraged to provide input?

Joe

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jul 2006 13:08:00 -0700

Leslie Daigle wrote:
> 
> We've already done a pretty wide sweep to get interested non-IETF
> parties to this list, and used the plenary presentation to encourage
> people there to follow up on this list.
> 
> I.e.:  this list is the place, and now is when we need to be
> getting this document together.
>
> Looking to the future, I could see doing similar presentations
> in other fora that are demonstrated to have interest and
> involvement in the independent series, and similarly guiding
> them to a public mailing list for discussion.

IMO, this is the time, and I've already suggested places below for
similar presentations.

I would hope that we would involve those communities just as much as we
proceed with this document.

Joe

> Leslie.
> Joe Touch wrote:
>> ------------------------------------------------------------------------
>>

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 21 Jul 2006 17:24:24 -0400

Joe,

The call (to various communities (RIRs, ISOC-announces, RFC Editor
site etc)) went out over a month ago:  we *have* reached out
to people with a known interest in the RFC Series.

IMO, that is a reasonable basis for settling on a document that
captures current reality.  As I and Olaf each said in our
plenary sessions:  this is about doing a best effort of
capturing the state of and resolving issues in the here and
now.

If there are important issues left open, or new issues come up
  -- we aim to have the framework in place such that they can
be handled.

Which is why Olaf has outlined the issues that are currently
known with the document and proposed working resolutions to
them.  IMO, that's where we need to focus.

Leslie.

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jul 2006 14:44:15 -0700

> to people with a known interest in the RFC Series.

You're saying that you send email to other places, then held the
discussion at the IETF. That presumes that the IETF is the only place to
hold the face-to-face; I disagree with that assessment.

The IETF does not own that series. It's one thing to host the list here,
but another to assert that our meetings are the only place to discuss
that document.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jul 2006 15:00:47 -0700

Leslie Daigle wrote:
> 
> Nope -- go back to my earlier mail:  I said the IETF face to face
> plenary time directed discussion to *this* mailing list, which
> is where we've directed everyone else.

Which is where I would like to see face to face at other meetings direct
discussion; that's all. Without that, we have a list which is highly
skewed, which is what I would like to avoid further skewing.

Joe

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Jul 2006 03:46:45 -0700

Olaf M. Kolkman wrote:
>
> -- Issue 3: IESG control over publication of documents.
>
>
> The I-D  implies that the IESG can prevent publication when it thinks 
> that the publication is damaging to the Internet in section 2. This 
> text is argued to extend RFC 3932. RFC3932 narrows the IESG review to 
> review w.r.t. conflict with IETF work and process.
>
> The I-D continues to describe the mechanics of how the IESG can delay 
> publication in section 4.8.
>
> I think that this discussion if the IESG needs to or is allowed to 
> block publication did not conclude and we will not be able to complete 
> it due time. I think that the most reasonable way forward is to 
> removed the perceived conflict with RFC 3932 from the I-D. Brian's 
> suggestion d.d. Jul 7 is a reasonable replacement text.
>
>    In addition to the IESG review for conflict with IETF work [RFC3932],
>    individuals in the IESG, or in the IETF community as a whole,
>    are free to review a draft, and if they have comments of any kind,
>    including the extreme case of believing the proposal is damaging
>    to the Internet as whole, these comments should be directed to
>    the authors and the RFC Editor.
>
> Point remains that there may be situations where a document _is_ 
> damaging and where the IESG has strong reasons to block such document. 
> I think, how creative, that this again can be addressed in an update 
> of RFC 3932.
So as to get some discussion on something else than Joe's rants about 
"control"...
I remember a bit of case-by-case on this issue when writing RFC 3932.

The decision tree goes something like this:

1. Document is not harmful to the Internet
    No problem!
2. Document is harmful to the Internet
    2.1 The RFC Editor discovers that it is
         2.1.1 The RFC Editor decides not to publish
             No problem!
         2.1.2 The RFC Editor decides to publish anyway
             Problem!
    2.2 The RFC Editor does not discover that it is harmful
         2.2.1 The RFC Editor decides not to publish for other reasons
             No problem!
         2.2.2 The RFC Editor sends the document to IESG for review
             2.2.2.1 The IESG does not discover that it is harmful
                 Problem for the Internet, but no conflict
             2.2.2.2 The IESG discovers that it is harmful
                 2.2.2.2.1 The IESG convinces the RFC Editor that it is 
harmful
                     2.2.2.2.1.1 The RFC Editor decides not to publish
                          No problem!
                     2.2.2.2.1.2 The RFC Editor decides to publish anyway
                          Conflict!
                 2.2.2.2.2 The IESG is not able to convince the RFC 
Editor that it is harmful
                     2.2.2.2.2.1 The RFC Editor decides to not publish
                         No problem! (but some bad feelings?)
                     2.2.2.2.2.2 The RFC Editor decides to publish anyway
                         Conflict!

So the cases where we have a conflict are:

1) The RFC Editor decides to publish documents that it knows are harmful 
to the Internet

2) The RFC Editor disagrees with the IESG about whether or not they are 
harmful to the Internet

If the first case occurs, I think we have bigger problems than a 
conflict with the IESG - we have an RFC Editor who is CONSCIOUSLY 
harming the Internet.

I think the second case is rare enough that it doesn't warrant granting 
the IESG special powers to block publication - and I'm not at all sure 
the IESG will always be right and the RFC Editor always wrong.

Anyway, that was my reasoning at 3932 time...... when rereading 
draft-klensin-rfc-independent-02 section 2, I don't see anything that 
allows the IESG to block stuff for technical reasons there. So that's 
consistent.

                                  Harald