Subject: with merit? (was: draft-kolkman-appeal-support)

From: "Robert Sayre" <[email-masked]>
Date: Thu, 19 Oct 2006 02:35:28 -0400

On 10/17/06, Sam Hartman <[email-masked]> wrote:
>
>     Michael>   Can an appeal be rejected with merit?
>
> Yes.  I think Robert's recent appeal was rejected that way.

I don't feel that way. I did wait a long time for a response.

What security policy or process documentation changes can we look forward to?

-- 

Robert Sayre

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Oct 2006 09:08:47 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> On 10/17/06, Sam Hartman <[email-masked]> wrote:
    >>  Yes.  I think Robert's recent appeal was rejected that way.

    Robert> I don't feel that way. I did wait a long time for a
    Robert> response.

Brian's note explained why we believe that the current process and
security policy support our position.  I respect that you disagree
with that conclusion.  However the ball is now in your court.  You are
welcome to build consensus behind a proposal to change the process, to
better document the process, etc.

Text about interoperability was added to Brian's recently approved
protocol extensions discussion.  The text was drawn from the IETF
mission statement with added emphasis on what interoperability means
in practice.

So, we felt that it was reasonable for you to ask us to explain where
our interoperability and security requirements come from.  Your appeal
had merit because we actually had to dig up an answer; we couldn't
point you at one place.  It turned out that once we'd done the
digging, the answer was clear to us.  Again, I respect that you
disagree.

The IESG cannot and should not be responsible for initiating all
process and documentation clarifications.  If you think our processes
are unclear, then try to help clean them up.  Either write informative
documents or try to start building a consensus behind a change.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Oct 2006 12:29:07 -0400

Sam Hartman wrote:
> security policy support our position.  

RFC2026 doesn't support your position or the security policy. And I 
found the sentence about discussion that took place on this list 
particularly objectionable. You heard from a lot of HTTP implementers 
and decided that the process junkies on this list make IETF consensus.

> I respect that you disagree

OK. I want to write a document that makes MTI a non-requirement for 
HTTP1.1-based protocols, because I believe that is the consensus in the 
HTTP community. How do I get that done?

-Rob

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Oct 2006 13:05:25 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> OK. I want to write a document that makes MTI a
    Robert> non-requirement for HTTP1.1-based protocols, because I
    Robert> believe that is the consensus in the HTTP community. How
    Robert> do I get that done?

You start by writing a draft.
It would need to be  targeted at a BCP.

You ask people to discuss your draft.  Get consensus in the HTTP
community.

Then, try and get broader discussion.  Eventually, if you get enough
support, ask an apps or security AD to sponsor the document.  There
are some tricky issues surrounding internal IESG process because
currently, it takes at least one person who believes a document is a
good idea to bring it before the IESG.  However if you get sufficient
IETF consensus that it is clear the document needs to be considered
we'll find a way to do that.

Now, I do think you will be fighting an up-hill battle.  I strongly
disagree with what you are trying to do.  A lot of other people do to;
we will all try and build a consensus against you.

However, I at least, and I think everyone on the IESG will strongly
support your ability to try and build a consensus and to make sure
that your ideas and drafts are given fair consideration.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 19 Oct 2006 13:27:50 -0400

> HTTP community. How do I get that done?

Are you trying to change general IETF policy on security requirements or
just get an exception for this one case?  Either way, you need to write an
I-D. The latter would be easier -- the I-D should be structured as a
process variance.  It should explain why this particular case should be
exempt from the usual requirements for secure protocol design.  Such RFCs
are unusual but not unprecedented; Alex Zinin and I wrote one, RFC 4278,
-- and it was a security-related variance -- where we knowingly approved a
security protocol that does not meet today's standards.  (More precisely,
the variance was to approve a downref in maturity, to let a Draft Standard
have a normative dependency on a Proposed Standard security document,
because the security document is too flawed to be promoted to Draft.  4278
explains why we think it's acceptable in this context.)

(Note, btw, that I'm not familiar with the specifics of this particular
protocol, so I have no opinion on whether or not I personally would
support such a waiver.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Keith Moore <[email-masked]>
Date: Fri, 20 Oct 2006 23:42:02 -0400

> HTTP community. How do I get that done?

IMHO, you need IETF-wide consensus for this, not just consensus within 
the "HTTP community", because your proposal would affect a lot more than 
just the "HTTP community".  The fact that a group of implementors wants 
to relax the requirements for standardization is, by itself, unpersuasive.

But don't let that stop you from writing a draft and attempting to build 
community consensus around it.  If you can make a good technical 
argument for why the criteria should be relaxed, you might convince 
enough people to get rough consensus.

Keith