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

Mon Oct 19 13:22:43 CDT 2009

Quoting [Alexis Richardson] (Oct 19 2009):
> 
> 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".

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.

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.