Subject: Re: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Sep 2007 23:16:43 -0700 (PDT)

Alexey Melnikov said:

"This statement taken in isolation is certainly correct. However if the 
original LC didn't ask the right question, don't you think this makes 
answers meaningless?"

The reviews are not meaningless.  They represent the feedback of the IETF 
community.  Rather than asking a different question in hope of getting a 
different answer, it would be better to address the feedback in an 
attempt to achieve consensus (or at least a lower level of disagreement). 

IMHO, it also might be appropriate to find a better forum and process 
for  discussing and moving forward on this document.  The topic is 
important, and one that the IETF has an opportunity to make a contribution 
to, over time.  I think this may be a case where the existing BOF process 
has limited our options.  For an alternative, see:
http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-02.txt

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Sep 2007 11:28:18 +0100

Hi Bernard,

Bernard Aboba wrote:

>The reviews are not meaningless.
>
I didn't say that reviews were meaningless. They were indeed quite useful.

But as far as I can see, there were 2 separate groups of issues with the 
document: technical issues with document content and a question about 
whether the document represents any form of consensus (and its intended 
status). I was referring only to the second issue. The first group of 
issues obviously needs to be addressed first.

>They represent the feedback of the IETF 
I thought my original message was quite clear that further work on the 
document is needed. I guess it wasn't clear enough.
I also think it is pointless to ask the question about status of the 
document before technical issues are resolved.

>http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-02.txt
I will study your draft, thank you for the pointer.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Sep 2007 18:35:02 +0100

Alexey Melnikov wrote:

>> important, and one that the IETF has an opportunity to make a 
>> contribution to, over time.  I think this may be a case where the 
>> existing BOF process has limited our options.  For an alternative, see:

Bernard,
I quickly looked through your draft. I don't think it applies for a case 
when there is no intention to form a WG. Is my understanding correct?

Regards,
Alexey

P.S. Please consider my question unrelated to 
draft-hartman-webauth-phishing-05.txt.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Sep 2007 15:35:24 -0700 (PDT)

> Bernard,
> I quickly looked through your draft. I don't think it applies for a case when
> there is no intention to form a WG. Is my understanding correct?

Section 2 says:

"The Charter for a Study Group SHOULD include at least the following 
milestones:

      o Development of a Working Group Charter.

      o Development of a document demonstrating fulfillment of
        the Working Group formation criteria described in
        [RFC2418] Section 2.1."

So the expectation is that Study Groups will focus on enabling WG 
formation.  Are you imagining other scenarios in which a SG might be 
useful?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Sep 2007 12:50:26 +0100

>formation.  Are you imagining other scenarios in which a SG might be 
I am looking for a lightweight process that doesn't introduce as much 
delay as a typical WG does. In particular I am interested in something 
that might work for reviewing and building consensus around a well 
defined piece of work (typically a document). One use case I have is a 
document that is not a product of a WG, but  which defines a framework 
shared by two existing working groups.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Sep 2007 15:30:11 +0300

Alexey,

> delay as a typical WG does. 

I'm not sure the SG process is what you are looking for.

FYI: Depending what you do, you may have different alternatives, too
besides creating a BOF, then WG, and completing your document there.

Some of the alternatives include

- Adding a work item in an existing WG. Rechartering for something that
  is clearly needed & uncontroversial should not be a big problem.

- Some areas have area WGs that process topics, bug fixes, etc. that
  do not fit in other WGs.

- Individual submission process. Submission to the AD, last call
  on the IETF main list.

  See http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html

But if you are just generally unhappy with the speed of WGs,
that's a tougher problem to solve. Some of the problems, like
lack of author cycles or contentious topics might follow you
to whatever process you try to employ.

> In particular I am interested in something that might work for
> reviewing and building consensus around a well defined piece of work
> (typically a document). One use case I have is a document that is not
> a product of a WG, but  which defines a framework shared by two
> existing working groups.

Sounds like the individual submission process or an area WG might
be more appropriate for this.

Jari

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Sep 2007 21:44:21 +0100

>I'm not sure the SG process is what you are looking for.
Hi Jari,
I think your reply just confirmed that.

>- Individual submission process. Submission to the AD, last call
For the case I was thinking about (i.e. a draft which was a common 
dependency between 2 WGs), the 3rd alternative proved to be the 
quickest. Luckily the document wasn't as controversial as I thought it 
would be. Option 2 was not available due to lack of any such WG in the 
Apps Area. Option 1 might have worked, but it could have lead to a 
discussion about which WG should take it, which is a distraction in 
itself. There is also a perception than rechartering is sufficiently 
painful, so many WG don't bother unless they are forced to.

>that's a tougher problem to solve.
>
Agreed. My message was partially motivated by a recent thread on apps 
mailing list regarding Individual Submissions versa WG documents.

>Some of the problems, like