draft-aboba-sg-experiment-02.txt
Alexey Melnikov wrote: 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 I will study your draft, thank you for the pointer. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[secdir] draft-aboba-sg-experiment-02.txt
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 PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-aboba-sg-experiment-02.txt
> 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? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-aboba-sg-experiment-02.txt
Bernard Aboba wrote: 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? 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-aboba-sg-experiment-02.txt
Alexey, > I am looking for a lightweight process that doesn't introduce as much > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-aboba-sg-experiment-02.txt
Jari Arkko wrote: Alexey, I am looking for a lightweight process that doesn't introduce as much delay as a typical WG does. I'm not sure the SG process is what you are looking for. Hi Jari, I think your reply just confirmed that. 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. 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. 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. 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 lack of author cycles or contentious topics might follow you to whatever process you try to employ. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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:[EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [secdir] draft-aboba-sg-experiment-02.txt
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:[EMAIL PROTECTED] > Sent: Tuesday, October 02, 2007 5:55 AM > To: Tobias Gondrom > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.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 secti
