Subject: Policy-Discussion
List archive
- From: Dieter Hennig <dieter.hennig AT id.ethz.ch>
- To: <cacert-policy AT lists.cacert.org>
- Subject: Re: SP => POLICY?
- Date: Tue, 23 Mar 2010 22:38:06 +0100
Dear Ian,
can I ask two newbie questions?
There are five types of persons (or team-members)
Access Engineers,
Support Engineers,
Systems Administrators,
Software Assessors,
Application Engineers.
Is somewhere to find a list, who is who? And exist a team, which is empty?
What would happen, if we would have a very specific policy, but no
people in the groups? If the Application Engineer group would have no
members, than there is no software update, right?
And maybe a second question about the following up duties? If we change
SP, we have to change SM too?
As an example, please look to point 3.4.2, one (SP) quoted about five
lists, the other one (SM) quoted only three. And with different names.
SP states
<<
1.4.2. The Security Manual (Practices) Document
(1) This Policy explicitly defers detailed security practices to the
Security Manual ("SM"), The SM says how things are done. As practices
are things that vary from time to time, including between each event of
practice, the SM is under the direct control of the Systems
Administration team. It is located and version-controlled on the CAcert
wiki.
(2) Section Headings are the same in both documents. Where Sections are
empty in one document, they are expected to be documented in the other.
"Document further in Security Manual" can be implied from any section
heading in the Policy.
>>
(I introduce some numbering to guide to the sentences.)
Subparagraph (1) is not fulfilled, because SP is more detailed than SM
in this point.
Subparagraph (2) is also not fulfilled, because is not empty in SP.
Have I oversee something?
Best Regards
Dieter
Ian G schrieb am 22.03.2010 22:13:
> According to PoP, a policy can only be in DRAFT for a year ...
>
> Security Policy reaches this milestone this Saturday, following p20090327.
>
> https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html
>
> Now, there are some marked up suggestions in BLUE that have not been
> voted upon. These basically add an "Application Engineer" who is
> responsible for the application. We would need to make a bit of a
> decision here as to which way we want to go.
>
> 1. Keep SP in DRAFT for another period, and
> re-work those BLUE sections.
>
> 2. Accept the BLUE, and go to POLICY.
>
> 3. Discard the BLUE as not voted, and go to POLICY.
>
> 4. Or?
>
>
>
> What do policy group people vote for?
>
>
>
> iang
>
> PS: Green should disappear.
>
--
Dieter Hennig
Informatikdienste/Helpdesk
ETH Zuerich, STB G 18.2
8092 Zuerich, Stampfenbachstr. 69
Tel: +41 44 632 4278
Fax: +41 44 632 1900
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
- SP => POLICY?, Ian G, 03/23/2010
- Re: SP => POLICY?, Andreas Bürki, 03/23/2010
- Re: SP => POLICY?, Dieter Hennig, 03/23/2010
- Re: SP => POLICY?, Ian G, 03/23/2010
- Re: SP => POLICY?, Dieter Hennig, 03/23/2010
- Re: SP => POLICY?, Ian G, 03/24/2010
- Re: SP => POLICY?, Dieter Hennig, 03/24/2010
- Re: SP => POLICY?, Ian G, 03/24/2010
- Re: SP => POLICY?, Dieter Hennig, 03/23/2010
- Re: SP => POLICY?, Ian G, 03/23/2010
- RE: SP => POLICY?, Ernestine, 03/23/2010
- Re: SP => POLICY?, Ian G, 03/24/2010
- Re: SP => POLICY?, Michael Tänzer, 03/27/2010
- Re: SP => POLICY?, Ian G, 03/27/2010
- Re: SP review questions comments and improvements, Daniel Black, 03/25/2010
- Re: SP holes/ questions - root key managment, Daniel Black, 03/27/2010
Archive powered by MHonArc 2.6.16.