[occi-wg] confusion about status of link / headers

[Alexis Richardson]

On Mon, Oct 19, 2009 at 6:08 PM, Andre Merzky <andre at merzky.net> wrote:
> Quoting [Alexis Richardson] (Oct 19 2009):
>
>> 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)

Thanks Andre.  I agree with most of your points but not the above
point, unless you mean "anyone can work on an edit and present it".
But, I think the model where the draft can be changed at any time by
anyone has led to difficulties and confusion (certainly on my part) as
to what is "going on".

alexis



>  - 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.
>