[KI-LC] Types of Group Output

Paul Madsen paulmadsen at rogers.com
Mon Sep 14 06:00:21 PDT 2009


the jist of the definition appears to be 'technical information designed 
to enable compliance'

As such, a deployment guide would not fit.

thanks

paul

Brett McDowell wrote:
> Since LC is discussion OP changes this week I thought I'd just point
> out how it's been defined in the bylaws, as follows:
>
> “Technical Specification” shall mean a document created by a Work Group that is
> expressly designated as a “Technical Specification” and that contains
> detailed technical
> information of a nature that must be implemented as described therein for an
> implementation thereof to be deemed compliant.  [...]
>
>
>
> Brett McDowell | http://info.brettmcdowell.com | http://kantarainitiative.org
>
>
>
> 2009/9/8 J. Trent Adams <adams at isoc.org>:
>   
>> Paul -
>>
>> It is my understanding that a "Technical Specification" is a document
>> that clearly defines how to build and deploy a solution for an
>> identified set of requirements.
>>
>> I'd suggest that something akin to a Best Practices Deployment Guide
>> would not be considered a Technical Specification as it won't contain
>> the same level of specificity.  Rather, the guide relies on the more
>> detailed specification in order to be useful.
>>
>> Further, while someone MUST adhere to the rules identified in the
>> specification, a deployment guide would most likely be only one
>> suggested method.
>>
>> - Trent
>>
>>
>> Paul Madsen wrote:
>>     
>>> Thanks Trent, so the question becomes then, what is a 'technical
>>> specification'?
>>>
>>> Is it any doc with normative MUSTs & MAYs etc?
>>>
>>> Would a deployment guideline (e.g. giving recommendations on how to
>>> deploy OpenID & SAML together) be considered a technical spec?
>>>
>>> paul
>>>
>>> J. Trent Adams wrote:
>>>       
>>>> Paul -
>>>>
>>>> Paul Madsen wrote:
>>>>
>>>>         
>>>>> Thanks for the overview Trent.
>>>>>
>>>>> Other than the voting process & resultant 'branding' implications, is
>>>>> there a difference between report & recommendation in the nature of
>>>>> their allowed content?
>>>>>
>>>>>           
>>>> Here's what the OP and Bylaws have to say:
>>>>
>>>> “Recommendation” shall mean any output of a Work Group (e.g. draft
>>>> Technical
>>>> Specification, policy, guidelines, procedures, etc.) that has been
>>>> approved by a
>>>> Supermajority of those Voting in an All Member Ballot. (Bylaws 1.15)
>>>>
>>>> “Report” shall mean any Work Group or Discussion Group output that is not a
>>>> Technical Specification that is approved by a Majority of the Group and
>>>> submitted
>>>> to the Leadership Council.  A Report is not a branded product of the
>>>> Organization
>>>> (i.e. it is not submitted for an All Member Ballot). (OP 1.7)
>>>>
>>>> So, from what I can tell, the only limitation is that Reports can't be
>>>> technical specifications.  They seem to be able to convey anything else.
>>>>
>>>> - Trent
>>>>
>>>>
>>>>         
>>>>> paul
>>>>>
>>>>> J. Trent Adams wrote:
>>>>>
>>>>>           
>>>>>> All -
>>>>>>
>>>>>> It's exciting that so many groups are actively working.  As such, there
>>>>>> is already interest in the process of moving the final output from the
>>>>>> groups out into the world.  I've put together a couple notes that should
>>>>>> help provide some guidance.
>>>>>>
>>>>>> The KI rules provide for two output types:
>>>>>>
>>>>>>  1. Report
>>>>>>  2. Recommendation
>>>>>>
>>>>>> In short, a Report is a general document that's officially published by
>>>>>> the WG/DGs, but is not branded as KI output.  Recommendations, on the
>>>>>> other hand, are documents produced by WGs (not DGs) that can be ratified
>>>>>> by an all-member ballot as officially branded KI output.  These two
>>>>>> types provide a lot of flexibility for various opinions to co-exist and
>>>>>> be heard while protecting the integrity of the voice of the entire
>>>>>> initiative.
>>>>>>
>>>>>> If, for example, your WG would like to publicly comment on a topic you
>>>>>> could do so by producing a Report or a Recommendation.  The difference
>>>>>> is that one carries the full weight of the KI membership while the other
>>>>>> is a statement coming from the WG/DG itself.
>>>>>>
>>>>>> The process for a WG/DG producing a Report is simple.  After a Majority
>>>>>> of the Group votes to approve it, the Report is submitted to the
>>>>>> Leadership Council, and it is thus recorded as official output of the
>>>>>> Group.  At that point it can be publicized as the voice of the Group.
>>>>>>
>>>>>> The process for a WG producing a Recommendation is a bit more
>>>>>> rigorous. It starts the same way as a Report out of the WG with a
>>>>>> Majority of the
>>>>>> Group voting to approve it as a Draft Recommendation.  Once it is
>>>>>> submitted, the LC will review it to ensure it's within the scope of the
>>>>>> WG charter.  After the LC approves it by a Simple Majority of those
>>>>>> voting, it is made available for at least a 45-day review period by the
>>>>>> full KI Membership.  At the end of the review, the LC Secretary
>>>>>> initiates an All Member Ballot.  This ballot will be conducted via email
>>>>>> and will be open for at least 14 days.  The Recommendation will become
>>>>>> officially branded KI output if a Supermajority of those Voting in the
>>>>>> All Member Ballot agree.
>>>>>>
>>>>>> As you can see, it's a lot easier (and faster) to produce a Report than
>>>>>> a Recommendation, though it falls short of being able to carry the
>>>>>> imprimatur of KI.  Also, there is nothing in the rules that indicates a
>>>>>> Report can't be made into a Recommendation, if that path meets the needs
>>>>>> of the WG.
>>>>>>
>>>>>> Any output that's short of a Report or Recommendation, though, should be
>>>>>> considered the opinion of the individual person/people and not the WG/DG
>>>>>> or KI.
>>>>>>
>>>>>> For more detailed information, you may went to review the following from
>>>>>> the Operating Procedure (OP) [1] and the Bylaws [2]:
>>>>>>
>>>>>>  * OP 0 "Scope"
>>>>>>  * OP 2.6 "Voting"
>>>>>>  * OP 1.4 “Draft Recommendation”
>>>>>>  * Bylaws 1.15 “Recommendation”
>>>>>>  * OP 1.7 "Report"
>>>>>>  * OP 5 "All-Member Ballot of a Draft Recommendation"
>>>>>>
>>>>>> I hope this helps, but please feel free to reply to this or contact me
>>>>>> with any comments, questions, or suggestions.  If it sounds like we may
>>>>>> need to modify the OP in any way, we should capture the thoughts in
>>>>>> the Operating Procedures Review page on the wiki [3].
>>>>>>
>>>>>> Cheers,
>>>>>> Trent
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> http://kantarainitiative.org/confluence/download/attachments/2293776/Kantara+Initiative+Operating+Procedures+_V1.0_+2009-04-03.pdf?version=1&modificationDate=1245549205000
>>>>>>
>>>>>> [2]
>>>>>> http://kantarainitiative.org/confluence/download/attachments/2293776/Kantara+Initiative+ByLaws_v1.0_+2009-04-03.pdf?version=1&modificationDate=1239840451000
>>>>>>
>>>>>> [3]
>>>>>> http://kantarainitiative.org/confluence/display/LC/Operating+Procedures+Review
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>         
>> --
>> J. Trent Adams
>> =jtrentadams
>>
>> Outreach Specialist, Trust & Identity
>> Internet Society
>> http://www.isoc.org
>>
>> e) adams at isoc.org
>> o) 703-439-2149
>>
>>
>>
>> _______________________________________________
>> LC mailing list
>> LC at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/lc_kantarainitiative.org
>>
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/lc_kantarainitiative.org/attachments/20090914/2b3980cd/attachment.html>


More information about the LC mailing list