Subject: [tsvwg] WGLC on draft-ietf-tsvwg-rsvp-pcn

From: "Black, David" <[email-masked]>
Date: Mon, 19 Aug 2013 19:31:37 -0400

As an individual contributor <WG chair hat off>:

"I have read this version of the draft,
 and I support its progression to RFC"

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> James Polk
> Sent: Thursday, August 01, 2013 3:43 PM
> To: [email-masked]
> Subject: [tsvwg] Start of WGLC on draft-ietf-tsvwg-rsvp-pcn
> 
> TSVWG
> 
> This is the start of the WGLC on "Generic Aggregated RSVP for IPv4
> and IPv6 Reservations Over PCN Domains"
> 
> http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-pcn/
> 
> This WGLC will last until Friday, August 23rd, 2013, which is 3 weeks
> after the conclusion of this IETF. The chairs reserve the right to
> keep any discussion going and prolong the end of the WGLC if the
> chairs see _value_ in "ongoing and active discussions" around the
> 23rd. Once those specific discussions are concluded - or stalled -
> the WGLC will conclude.
> 
> A good note to the list is "I have read this version of the draft,
> and I approve (or support) its progression to RFC". The chairs
> request at least a couple of notes to the list showing support to get
> a sense of the WG.
> 
> Of course, you can ask for alternate text (where you supply the
> actual replacement text, or convey the meaning sufficiently to the
> authors) for anywhere in the document that you find unclear or troublesome.
> 
> James/Gorry/David
> TSVWG chairs
>

---

From: ken carlberg <[email-masked]>
Date: Wed, 21 Aug 2013 06:56:21 -0400

I have reread the draft and it responds to the earlier comments I have made.  I support its progression to RFC

-ken

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 23 Aug 2013 15:25:36 +0000

Folks,

I had another look at the draft. 
It reflects well the discussion we had regarding the choice of using aggregate reservations. 
In general I support it going forward but there is one aspect I am trying to clarify with the authors (ie regarding the split of functionality between ingress node and egress node) before I give my full support fro publication. This may take a few days.

In the mean time I have a few minor comments/suggestions:

*** section 1.1:
expand the PBAC acronym in Introduction

***section 1.2:
OLD:
"This is also the reason of choosing Approach (1)"
NEW:
"This is the reason for choosing Approach (1)"

*** section 6:
I recommend you expand the text to indicate to IANA that they need to allocate all the C-Types defined in section 4.1. You probably also need to indicate the policy for allocating additional C-Types.

*** I would also consider adding an example message flow in an Appendix, similar to Appendix A of RFC4860. This considerably helps getting the general idea in a short time.

Francois