[occi-wg] confusion about status of link / headers
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de
Mon Oct 19 12:26:13 CDT 2009
All,
I'd second this, as well as following the OGF consensus process, as
described in http://www.ogf.org/documents/GFD.2.pdf which, by the way
is modeled after IETF, anyway.
Overall, I *strongly* suggest to devote ourselves to consensus mode
again. From my own experience in various OGF WGs, I know that this is
sometimes hard and more often than not a tedious and boring thing, but
it is also observed (and agreed upon) that controversial parts of a
spec tend to be ignored by implementors...
Best,
Alexander
Am 19.10.2009 um 19:08 schrieb Andre Merzky:
> Quoting [Alexis Richardson] (Oct 19 2009):
>>
>> Gary
>>
>> Thanks. That strikes me as a fairly complex process.
>>
>> Does anyone have any alternative suggestions? We need a simple model
>> for reaching consensus here, that grows the community and adoption.
>
> Suggestion:
>
> - agree on one editing backend (google docs/mercury) (like now)
>
> - anybody can edit (after registration) (like now)
>
> - before publication or presentation, require a one-week final
> call on mailing list. Only allow presentation as OCCI draft
> if group agrees. Otherwise, require label 'my suggestion for
> OCCI draft' or similar.
>
> Note that OGF requires a final call on the list before submitting to
> the OGF editor anyway. Submitted documents MUST represent group
> consensus, i.e. must represent the group majority.
>
> BTW: Voting on issues is explicitely encouraged: IMHO, you disuss
> issues to death otherwise ("running code and rough consensus"). So:
>
> - discuss issue
> - consider all alternatives / implementations
> - if discussion stalls: vote on the issue
> - *stick* *to* *the* *decision* ;-)
> - only re-open the discussion IFF
> - a new alternative emerges
> - external or internal dependencies of the issue change
> - implementation is impossible
>
>
> While I am on it, one more suggestion on procedures in OCCI: Other
> OGF groups have made tremendous progress in face-to-face meetings,
> such as during the OGF events, but also outside. The OCCI group
> members don't seem to massively attend OGF events, really - probably
> because the group is much more diverse than other OGF groups (which
> is a good thing!). Anyway, I think you guys should consider a
> meeting in person: lock a couple of key players in a room for a
> couple of days, and *decide* on things.
>
> I'd be happy to help to organize a F2F. In fact, I checked with
> Thilo from the Vrije Universiteit in Amsterdam (VU), and he'd be
> willing to host, anytime (*).
>
> So, please think about that, and let me know if that would help to
> settle the open technical issues in OCCI in the near future.
>
> Cheers, Andre.
>
> (*) It is not that VU is contributing to OCCI, but Amsterdam is very
> convenient to reach for most people, and cheap for Europeans, as
> EasyJet goes there from many locations. Also, the VU is located
> about 15 minutes from the Airport (one train stop + 5 min walk).
> Also, VU is able to cover the cost for the venue. Accomodation is
> affordable and nearby. I'll rather be silent about Dutch food
> though... ;-)
>
>
>
>> alexis
>>
>>
>> On Mon, Oct 19, 2009 at 5:10 PM, Gary Mazz
>> <garymazzaferro at gmail.com> wrote:
>>> Alexis,
>>>
>>> I do not believe we can set aside the OGF27 unapproved unilateral
>>> change to
>>> the document. It is a fundamental problem in operation.
>>>
>>> These are my suggestions:
>>>
>>> 1) Place the document in a format where each interface can have
>>> its own life
>>> cycle.
>>> 2) Create a template for adjunct documents
>>> 3) Limit check-in to the repository to two people and one backup.
>>> 4) Recruit an editor and a backup editor. This spec isn't that big.
>>> 5) Provide an incubator for emerging technologies and proposals for
>>> inclusion in the specification.
>>> 6) Form a public mailing list purposed for emerging technologies,
>>> proposal
>>> discussions and voting
>>> 7) Provide a proposal document number for each submitted document
>>> 8) Before the document can be considered for review, it must be in
>>> the
>>> adjunct documents template
>>>
>>> -gary
>>>
>>>
>>>
>>> Alexis Richardson wrote:
>>>>
>>>> Leaving aside the when and how in relation to OGF 27
>>>> specifically, we
>>>> cannot claim that unilateral changes are supported by the group if
>>>> they are not supported by the group. I am very concerned about
>>>> this.
>>>> We of course don't want to ignore innovative proposals, but we
>>>> need to
>>>> build consensus around them before inclusion in the spec.
>>>>
>>>> Suggestions for a good way forward are solicited..
>>>>
>>>> alexis
>>>>
>>>>
>>>>
>>>> On Mon, Oct 19, 2009 at 4:19 PM, Gary Mazz <garymazzaferro at gmail.com
>>>> >
>>>> wrote:
>>>>
>>>>>
>>>>> That is a good point, a better question would be how did it get
>>>>> into the
>>>>> spec presented like it was the preferred method. Probably
>>>>> because there
>>>>> is
>>>>> no single editor and anyone can change the documents anyway they
>>>>> feel
>>>>> fit.
>>>>>
>>>>> I don't think what Sam is working on is out of scope for OCCI,
>>>>> it was
>>>>> unintended to support multiple interfaces. Sam seems to be
>>>>> running with
>>>>> this
>>>>> one, driving OCCI to the lowest level of the HTTP protocols,
>>>>> essentially
>>>>> creating a new technology, untried on multiple levels in the
>>>>> internet
>>>>> infrastructure.
>>>>>
>>>>> My issue with it is it was placed in the spec at the last second
>>>>> before
>>>>> OGF
>>>>> 27, other implementations were remove in lieu of this one, it
>>>>> was placed
>>>>> in
>>>>> the spec irrespective of a group consensus and SNIA, a strategic
>>>>> partner,
>>>>> publicly announcing they would NOT support this interface.
>>>>> However, this
>>>>> does not preclude the rest of this group to continue with the
>>>>> original
>>>>> concept of OCCI information in HTTP entities (content body).
>>>>> For maintainability, this does force the document to take on a
>>>>> new format
>>>>> of
>>>>> separating the implementations from reference model (we need one
>>>>> first).
>>>>> Interface implementations should fall into adjunct documents.
>>>>> This
>>>>> specification model has been successfully executed by numerous
>>>>> standards
>>>>> bodies.
>>>>>
>>>>> cheers,
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> Alexis Richardson wrote:
>>>>>
>>>>>>
>>>>>> Sam & group,
>>>>>>
>>>>>> I just saw this tweet: http://twitter.com/samj/statuses/
>>>>>> 4991958514
>>>>>>
>>>>>> You say that "HTTP has an out-of-band metadata channel in the
>>>>>> form of
>>>>>> headers. #occi's using Link: as a flexible, lightweight RDF
>>>>>> alternative".
>>>>>>
>>>>>> I'm a bit confused here.... I thought this was still under
>>>>>> discussion.
>>>>>> What am I missing?
>>>>>>
>>>>>> alexis
>>>>>> _______________________________________________
>>>>>> occi-wg mailing list
>>>>>> occi-wg at ogf.org
>>>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
>
> --
> Nothing is ever easy.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
--
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20091019/48604511/attachment.bin
-------------- next part --------------
More information about the occi-wg
mailing list