Subject: [secdir] draft-aboba-sg-experiment-02.txt

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 1 Oct 2007 18:39:20 +0200

Hello, 

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The document described an RFC3933 experiment in forming a Study Group prior to Working Group formation. As such I agree with the authors that there are no additional specific security considerations as also discussed in RFC3933. 

Aside from the Security Review, I have three comments: 
1. editorial comment to section 1: 
s/those who have no followed the/ those who have not followed the

2. comment to section 2:
Section 2 states that: 
"If at any point...., including after a first or second BoF session, ... the IESG MAY propose that a Study Group be formed."
This sounds to me like partially conflicting with RFC2418, which clearly states that an absolute maximum of two BOFs are allowed for a topic.
This would implicate that if a Study Group was formed after the second BOF, it would have to directly lead to a WG (or be abandoned) as it can not go back to BOF. 

I would propose to change this to that a Study Group may be initiated after the first BOF but not after the second to prevent this conflict. 
(The second BOF is already an extension and we should not add the Study Group as a second extension to the system. People should be pretty well prepared at a second BOF to get either a Yes or No - and if they are not ready for a decision by then, another second extension may probably also not help.)
So, proposal to change the line in section 2 accordingly: 
s/including after a first or second BoF session/including after a first BoF session

I.e. if a first BOF does not lead to the anticipated results (WG: yes/no decision), the appropriate mechanism for the AD should be to decide whether s/he wants to use this experiment or run straight with the second BOF as defined in the process. With the study group the second BOF could be initiated after the Study Group has concluded if the AD does not want to go to WG directly without second BOF. 

3. comment to section 3: 
In section 3 it is described that a study group shall have and run the same infrastructure identical to a WG. 
I would not agree with this suggestion, but think it should be limited to less than a WG. 
Otherwise it might lead to false impressions, de-facto situations and also prolong the work of the study group to finally get a "go" for a WG, as they might consider this an already fully functional "lightweight WG". 

Summary: 
I believe that this idea of a Study Group is a great idea that will add a new tool for the AD for the situation that a BOF has not been satisfactory preparing a WG formation.
However I would suggest to make sure to keep a clear distinction between a WG and a study group, as they differ dramatically in the regard of role and acceptance by the IETF community. If they both look similar this might be misunderstood by people outside or new to the IETF. 

Greeting, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked] 
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 01 Oct 2007 20:55:10 -0700

Hi Tobias,

Many thanks for your review.  Please see inline for my thoughts on your 
observations.

On 10/1/2007 9:39 AM, Tobias Gondrom wrote:
> Hello,
> 
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
> 
> The document described an RFC3933 experiment in forming a Study Group 
> prior to Working Group formation. As such I agree with the authors that 
> there are no additional specific security considerations as also 
> discussed in RFC3933.
> 
> 
We'll fix this in the revision.
> 
> 2. comment to section 2:
> 
> Section 2 states that:
> 
> "If at any point...., including after a first or second BoF session, ... the 
> IESG MAY propose that a Study Group be formed."
> 
> This sounds to me like partially conflicting with RFC2418, which clearly 
> states that an absolute maximum of two BOFs are allowed for a topic.
> 
> This would implicate that if a Study Group was formed after the second 
> BOF, it would have to directly lead to a WG (or be abandoned) as it can 
> not go back to BOF.
> 
> I would propose to change this to that a Study Group may be initiated 
> after the first BOF but not after the second to prevent this conflict.
> 
> (The second BOF is already an extension and we should not add the Study 
> Group as a second extension to the system. People should be pretty well 
> prepared at a second BOF to get either a Yes or No -- and if they are not 
> ready for a decision by then, another second extension may probably also 
> not help.)

My take is that after the SG it is a WG or nothing.  The sponsoring and 
other ADs would have the opportunity to observe the SG in progress just 
as they would do a BoF and can assess whether to form a WG or not.

With that clarification, does the current wording sound alright?
> I.e. if a first BOF does not lead to the anticipated results (WG: yes/no 
> decision), the appropriate mechanism for the AD should be to decide 
> whether s/he wants to use this experiment or run straight with the 
> second BOF as defined in the process. With the study group the second 
> BOF could be initiated after the Study Group has concluded if the AD 
> does not want to go to WG directly without second BOF.
> 
> 3. comment to section 3:
> 

It is in fact less than a WG.  More specifically, "A Study Group charter 
MUST NOT include milestones
    relating to development of a protocol specification." was included 
to make it less than a WG.  The limited lifetime is another constraint.

The other processes are intentionally made similar so as to reuse our 
current operational structures.

Does that clarification alleviate this concern?

regards,
Lakshminath

> 
> Otherwise it might lead to false impressions, de-facto situations and 
> also prolong the work of the study group to finally get a "go" for a WG, 
> as they might consider this an already fully functional "lightweight WG".
> 
> 
> Summary:
> 
> I believe that this idea of a Study Group is a great idea that will add 
> a new tool for the AD for the situation that a BOF has not been 
> satisfactory preparing a WG formation.
> 
> However I would suggest to make sure to keep a clear distinction between 
> a WG and a study group, as they differ dramatically in the regard of 
> role and acceptance by the IETF community. If they both look similar 
> this might be misunderstood by people outside or new to the IETF.
> 
> Greeting, Tobias
> 
> 
> 
> 
> 
> ***__________________________________________*
> *****Tobias Gondrom*
> *****Open Text*
> Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, 
> Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 
> 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: 
> München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number 
> /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John 
> Shackleton, Walter Köhler
>