[KI-LC] Types of Group Output

Brett McDowell email at brettmcdowell.com
Sun Sep 13 18:56:21 PDT 2009


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
>



More information about the LC mailing list