ietf
[Top] [All Lists]

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

2007-10-02 03:50:38
Hi Lakshminath, 

your comments solve my concerns, mostly. 
I understand your reasons and actually am not sure I have a really better idea. 
So please consider my comments rather as personal concerns, not comments that 
need to be resolved: 

#2: I still do not feel 100% comfortable with the fact that the SG will 
introduce a new second extension after the second BOF; on the other hand, as 
the SG is at the discretion of the AD, there should be no harm.


#3: I fully understood the part with the "SG ... MUST NOT include milestones 
relating to development of a protocol specification", but actually let me 
envision the following scenario: 
People start to work in a SG, e.g. on charter and requirements and as they most 
probably also already have a solution in mind (e.g. they made a prototype or 
even full implementation) they will in parallel prepare the other drafts. Ok 
they can not track this via milestones, but maybe this is not perceived as so 
critical by them and the current experiment draft also actually allows them to 
submit I-Ds in the SG about protocols etc. - just like a normal WG..... (and 
probably to submit such I-Ds SHOULD NOT be forbidden in the experiment, as it 
can help to work on the requirements when you have an example solution to look 
at, and actually I would hate to stop people to think or work in any direction 
- just for the sake of a process...) So you see, this distinction line between 
SG and WG feels very faint to me and maybe might also initiate an automatism to 
_always_ go from SG to WG, "because so much work has already been done..."
However, having that said, I believe that you can't make a process 100% 
foolproof (at least not one that you actually want to really use in real life) 
and hey that's what an experiment is for, so I will be fine to try it. 


Again as a summary: I think it's a great idea and would hum for progressing the 
draft and the experiment. 

- Tobias





-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com]
Sent: Tuesday, October 02, 2007 5:55 AM
To: Tobias Gondrom
Cc: iesg(_at_)ietf(_dot_)org; secdir(_at_)mit(_dot_)edu; 
Bernard_Aboba(_at_)hotmail(_dot_)com;
narten(_at_)us(_dot_)ibm(_dot_)com; jari(_dot_)arkko(_at_)ericsson(_dot_)com; 
ietf(_at_)ietf(_dot_)org
Subject: Re: [secdir] draft-aboba-sg-experiment-02.txt

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.


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
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?

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.

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*
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:tobias(_dot_)gondrom(_at_)opentext(_dot_)com
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>