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

Mon Oct 19 13:28:22 CDT 2009

On Mon, Oct 19, 2009 at 7:22 PM, Andre Merzky <andre at merzky.net> wrote:
> Quoting [Alexis Richardson] (Oct 19 2009):
>
> I see your point.  In other groups, however, the above model worked
> fine, and having an editor which signes patches to documents would
> rather be a roadblock than anything else.   I mean, the revision
> control systems all allow branches and tags etc - so it is not like
> any changes there are hewn in stone.  Good processes are in place
> for software, and the same are applicable for documents in my
> experiences.
>
> Like: Sam could create a branch OCCI-SAM for editing, which get
> (partially) merged into OCCI-DRAFT after discussion.  Restricting
> write access to SVN will slow down editing for sure, IMHO.

Personally, I don't mind people creating and editing a branch, so long
as the merge algorithm involves acute, chair-mediated, community
consensus at specific points in time.

alexis

> Anyway, this is just my opinion - don't want to impose anything, as
> I don't edit the doc myself, really...
>
> Best, Andre.
>
>>
>> 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.
>> >
>
>
>
> --
> Nothing is ever easy.
>