Re: [ppsp] WG item adoption confirmation

[Martin Stiemerling <[e-mail]>]

Hi Bryan,


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> David A. Bryan
> Sent: Monday, April 18, 2011 4:26 PM
> To: Yingjie Gu(yingjie)
> Cc: [e-mail]
> Subject: Re: [ppsp] WG item adoption confirmation
> 
> So a few comments here. In full disclosure, I'm an author on the
> draft, and so would personally like to see it adopted and think it is
> a good base, but there is obviously some inherent bias on my part...
> 
> My experience in the past has been that until you have a draft of some
> kind (protocol or a design document) in which to document consensus it
> is very hard to drive forward. Some folks don't even read drafts or
> get involved in a group until it has WG items. We have had debate at
> several meetings on some of these issues (HTTP/Binary, offline
> support, etc.) and it has been tough to drive toward consensus, get it
> documented, and move on. Newcomers join and the same issues get hashed
> again and again since there isn't a document to track consensus.
> (Sometimes you are lucky if you can get the comments until last
> call...)

I subscribe to the first point of having the need to document decisions and design in a draft. However, I oppose the second part of having first a WG item before people start reading. I still see the need to have a technical sound document before moving it to a WG item. This is not yet the case for the tracker protocol draft. 

It is indeed a pity that many people only read drafts once they are in WGLC. 

> 
> In P2PSIP, we had several competing (and in function, very similar,
> with one exception) proposals, and the authors spent lots of time
> incorporating each other's tweaks into their drafts. It took years
> (literally) to resolve, finally by merging the drafts. Once that
> happened, the group debated the technical points, and had a clear
> place to document the consensus -- the adopted draft. Other groups
> achieve the same goal using a design draft.

I guess we are fine with the single draft, but we need an update of the draft right now. There is no way of moving forward without having an updated version of the draft rather soon and not just before the meeting. I see this draft on the right track, but the response time to get a new draft out of the door isn't that good at this point of time.

> 
> I prefer we adopt, but if we don't adopt
> draft-gu-ppsp-tracker-protocol as a WG item, then I would at least
> suggest a WG item for a new design draft that does nothing but list
> the big questions, and use that to drive and document WG consensus
> (i.e., discussion, then slides and hums on each question, then confirm
> it on list and wrap up that document), or appoint a design team to go
> make either a design or protocol draft so that we can spend time
> productively. What I'd like to avoid is spending time nailing down
> every detail of multiple proposals when there is no place to clearly
> document the direction the group wants to go in the first place.

We do not need another design draft, but should make some decisions and document them in the tracker protocol. And we need it now :)

> 
> On a few specific issues raised about the draft:
> 
> The binary encoding remains in the draft simply because while the
> authors prefer HTTP, we haven't been able to get a clear WG consensus.
> We would be willing to adjust the draft to reflect the desired
> encoding (and change/modify as the group discussion evolves
> accordingly). We spend more time on the operations -- I feel the
> encoding is much less important than getting the operations right
> (which we would love feedback on -- we may very well have them wrong,
> but there hasn't been much discussion on list about that, despite it
> being the most important question in my opinion)

It is still draft and you do need WG consensus on that draft. However, it is preferable to capture the WGs decision for the encoding. I would say the WG tends towards HTTP. 

> 
> On the offline question, there has been a great deal of discussion in
> the early meetings (I missed Prague, so forgive me if things changed)
> to allow time-shifted, BT style designs as well. We reflected that in
> the draft, but again, it would be good to discuss further. For those
> asking about this, it might be good to go back and listen to the old
> minutes (particularly the BoF). There was very strong consensus in the
> room to support offline as well as real-time. I do agree this is
> perhaps not well reflected in the charter, and again, it would be good
> to document this consensus -- one way or another -- somewhere.

Why not go first with real-time? Isn't it better to get started with near-term issues, such as real-time, and deal with offline afterwards? 

I personally do not see yet the impact on the tracker protocol by this issue, but if there is a bigger issue, one could write a separate draft which deals with that. The outcome of that draft could be integrated in the tracker protocol later on.

> 
> As mentioned, bootstrapping is explicitly out of scope in the charter
> at present.

ACK.

> 
> Security definitely needs more work and Akbar's comment is valid -- we
> need to reorganize the text into one location. We would also love
> comments on list about this topic. The discussion online has been
> pretty quiet.

The discussion is indeed quiet.

However, please update the document in May to get a new basis for the discussions.

Thank you

  Martin


[e-mail]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014