Re: [rsvp-dir] Our first work items for RSVP Directorate

[Bob Briscoe <[e-mail]>]

Bruce,

At 00:19 08/06/2010, Bruce Davie wrote:
>Bob,
>  I think we're still figuring out the rules of engagement 
> here...let me see if we can converge.
>  Here is what I said to Lars about creating this directorate:
> >
> > [...] I want to make a concrete suggestion that might help 
> address your concern going forward. I talked with Bob Braden, 
> Scott, and Francois about the formation of an "RSVP directorate". I 
> think we could assemble say 5 people, and those people would make a 
> commitment to perform the tasks mentioned above (read drafts, 
> comment on their suitability for adoption, review and comment) and 
> also beat the bushes to get more people to review and comment on 
> drafts. I truly think that the BOF has lit a fire under the people 
> who care about RSVP, which is why you're seeing people like Allain 
> from SFR and Sanjay from Espial being more forthcoming than usual. 
> In any case, while we can't change the past, the BOF sure seemed to 
> me to suggest we can't shut down RSVP work at the IETF right now 
> without ignoring the wishes of the folks who came to the BoF and spoke.
>
>
>So, as I see it, the first job of the directorate is to review 
>drafts that have been proposed for adoption, i.e., the 3 drafts that 
>I mentioned below.
>
>You seem to be saying "why should the directorate waste its time 
>reviewing drafts if the authors can't make the case that they are 
>solving a problem that matters to someone, or will matter in the future".
>And I will grant you that the 3 drafts under consideration right now 
>don't do a great job of making that case. So, how about I approach 
>the authors and ask them for a paragraph or two to justify our 
>reviewing cycles, along the lines of what you have said below.

Thanks Bruce. That's exactly what I'm saying. Except I don't expect 
them to write this sort of stuff actually in the drafts (drafts 
should normally only contain timeless info). But I would expect such 
motivation in a presentation or an email to the list at the point 
where WG draft is requested. I looked and it wasn't there (at a first 
pass at least).

When I ask for one of my drafts to become a w-g item, I am always 
expected to provide such info. So I want these guys to jump the same 
hoops we all have to.

>My hope is that they next time these guys show up at an IETF and 
>present their drafts, they can at least have a few people who will 
>admit to having read the drafts.

Certainly.

Cheers


Bob


>Bruce
>
>
>On Jun 7, 2010, at 1:29 PM, Bob Briscoe wrote:
>
> > Bruce,
> >
> > Perhaps there's a misunderstanding...
> >
> > Yes, I'm sure the authors want them to be WG drafts. And I'm sure 
> the drafts are technically interesting enough.
> >
> > But I'm asking for the motivations from the authors that 
> justifies why they think each draft is suitable to take IETF time 
> as a WG draft (and our directorate reviewing time).
> >
> > In your original email, you gave nice outlines of *what* each 
> draft is about, and we've all seen the presentations. But none of 
> the presentations or the nice text capsules answer questions like:
> >
> > - This is needed for new applications w & x that are becoming 
> important in the defence and the enterprise sectors
> > - and yes, another way to do it is already standardised, but this 
> new approach saves y amount of messages compared to approach z that 
> we already have,
> > - and n organisations/customers have said they would be 
> interested in this being standardised and will contribute reviews.
> > - or we admit no-one has said they would be interested, but it 
> will provide a new fundamental capability that will enable p,q and 
> r that people would not even be able to imagine they might want 
> unless we standardse it.
> >
> > ie, stuff specific to each doc, that satisfies the concerns that 
> led to the creation of this directorate in the first place.
> >
> >
> > Bob
> >
> > At 18:48 04/06/2010, Bruce Davie wrote:
> >> Bob,
> >> The RSVP directorate will not, of course, decide the fate of 
> these documents. Our job is to review documents and advise the TSV 
> ADs and TSVWG chairs. I'm just trying to jump start that process, 
> so that when the authors show up at TSVWG, (a) the chairs will be 
> able to say whether it's even worth the time of the WG to hear a 
> presentation on the draft (b) there will be at least a couple of 
> people in the audience who have read the drafts.
> >>
> >> For the record, all 3 of the drafts mentioned below were 
> presented at IETF 76. The authors have asked that they be taken on 
> as TSVWG items.
> >>
> >> Bruce
> >>
> >> On Jun 4, 2010, at 1:39 PM, Bob Briscoe wrote:
> >>
> >> > Bruce,
> >> >
> >> > Will take a look.
> >> >
> >> > A process break point.... for a draft to be adopted by a 
> working group, the authors have to present it (possibly a couple of 
> times) then justify to the WG why it is ready to be adopted as a WG 
> item. Shouldn't we raise a similar bar for these drafts, rather 
> than pick up "a few drafts floating around"?
> >> >
> >> > We have probably all seen these presented (tho I personally 
> haven't been in CCAMP so I will have missed narayanan). But I'd now 
> like to see the authors justify to us why they are ready to be WG 
> items, against the criteria established recently.
> >> >
> >> > Is this fair?
> >> >
> >> >
> >> > Bob
> >> >
> >> > At 17:41 04/06/2010, Bruce Davie wrote:
> >> >> Folks,
> >> >> There are a few drafts floating around that I think we should 
> take a look at and make a recommendation to the ADs regarding their 
> suitability for the TSVWG. These drafts are:
> >> >>
> >> >> draft-narayanan-tsvwg-rsvp-resource-sharing-02
> >> >>
> >> >> draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt
> >> >> draft-polk-tsvwg-intserv-multiple-tspec-03.txt
> >> >>
> >> >> The first one seems pretty non-controversial. Here are 
> comments from the author:
> >> >> >
> >> >> > draft-narayanan-tsvwg-rsvp-resource-sharing-02 is now a 
> companion draft to draft-berger-ccamp-assoc-info-01, and contains 
> only the RSVP-CAC-specific part of the resource sharing thingy. 
> Given that TSVWG is the place for RSVP CAC extensions, yes, I would 
> think TSVWG is the place for it. It's a very small draft basically 
> defining a new codepoint (Resource Sharing Remote-ID Association) 
> with a small behavioural change (only treat this Association-ID as 
> binding on the Resv, not on the Path), so I don't envision any 
> significant backpressure of the form "this is not a small change to RSVP".
> >> >>
> >> >> I would like to recommend that this be made a TSVWG work 
> item. Any comments or concerns?
> >> >>
> >> >> The lefaucheur and polk drafts should probably be treated as 
> a pair. Both relate to the issue of reserving an appropriate level 
> of resource (e.g. bandwidth) in a single round trip when it is not 
> known in advance how much resource is available. This is quite 
> helpful, for example, in a video conferencing application that has 
> a choice of codecs. The polk draft in particular was (I think) a 
> catalyst for the RSVP discussion in Anaheim because it seemed to be 
> stretching the scope of what has normally been done in TSVWG for 
> RSVP maintenance.
> >> >>
> >> >> Given the scope of the directorate, I would like a couple of 
> folks on the directorate to review those drafts and then we can 
> discuss whether they should become TSVWG work items. Can I have 
> some volunteers?
> >> >>
> >> >> Thanks,
> >> >> Bruce
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> rsvp-dir mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/rsvp-dir
> >> >
> >> > ________________________________________________________________
> >> > Bob Briscoe,                                BT Innovate & Design
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design