Subject: Re: [tsvwg] Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03

From: James Polk <[email-masked]>
Date: Thu, 12 Jul 2012 17:17:04 -0500

Ken

Thank you for this review, and I apologize for the late response - 
but I believe I will address each of your concerns below in the next 
rev, and have included the text I modified in the draft below to do just that.

At 12:19 PM 6/15/2012, ken carlberg wrote:
>James,
>
>at present, I just have just a few general and specific comments 
>about the draft, some of which are aimed at different audiences.  To 
>the (other) chair and the group, I'd like to advocate changing the 
>disposition of the draft from individual contribution to a working 
>group draft.  The document is very symbiotic to the existing working 
>group draft <draft-ietf-mmusic-traffic-class-for-sdp-01> in MMUSIC, 
>and  efforts that compliment or strengthen other work items are good 
>things to have.  In addition, the document builds on existing work 
>[rfc-2872] and provides more granular information to nodes along the 
>path, which I feel is always a good thing.  Finally, the draft 
>appears in a state where the foundation is solid, with only 
>refinements that are needed -- which seems sufficient in changing 
>status to a working group draft
>
>as for some specific comments...
>
>- at the end of the 1'st paragraph in Section 1, you state "An 
>application profile defined by a sender may not be understood by the 
>intermediaries or receiver in the same or different domain".  My 
>impression is that its different domains that may not under the 
>application profile, but that intermediaries *within the same 
>domain* would understand the profile.  If I missed something, it 
>would be helpful to expand on your original text.

You didn't miss anything, as I can see the existing text is unclear. 
I've changed this sentence to:

    "An application profile used by a sender might
     not be understood by the intermediaries or
     receiver in a different domain."

>- towards the end of section 2, you state that the specification 
>"allows an RFC that defines a well known word or string to be a 
>valid identifier".  The first question that comes to mind is 
>who/what defines this well known word or string?  Is it done later 
>in the draft, or does this come from some otehr draft/RFC or 
>registry?  Its the "well known" part of the text that caught my eye.

good catch. I replaced "well known" with "industry recognizable term" 
to soften up any restrictions on what some folks may believe is 
allowable. I want to say "IETF recognizable term", but then someone 
would ask for where that term is defined, and that could get messy if 
the terms were pulled from more than one doc.

>- i'm not convinced in how you separated real-time interactive 
>profiles in Section 3.2 and multimedia conferencing profiles in 
>Section 3.3.  I say this because your brief description of each 
>(which may be too brief) doesn't seem associate characteristics that 
>are different from each other.  Rather, each grouping only separates 
>types of applications.  in contrast, broadcast and streaming are 
>distinguished by the size of buffers.

fair conclusion. I've changed both profile descriptions with these 
leading paragraphs to differentiate the traffic types:

Realtime Interactive:

   "Realtime Interactive profiles are for on-line gaming, and both
   remote and virtual avconf applications, in which the timing is
   particularly important towards the feedback to uses of these
   applications. This traffic type will generally not be UDP based,
   with minimal tolerance to RTT delays."

Multimedia Conferencing:

   "There will be Multimedia Conferencing profiles for presentation
   data, application sharing and whiteboarding, where these
   applications will most often be associated with a larger
   Conversational (audio and/or audio/video) conference. Timing is
   important, but some minimal delays are acceptable, unlike the case
   for Realtime-Interactive traffic."

BTW - I'll need to change the descriptions of these traffic types 
within the MMUSIC traffic class draft too, as I want to keep both as 
synchronized as possible.

Let me know what you think of each change.

James

>cheers,
>-ken

---

From: ken carlberg <[email-masked]>
Date: Fri, 27 Jul 2012 12:41:59 -0400

James,

sorry for the tardy reponse.  The changes look good to me.

-ken

On Jul 12, 2012, at 6:17 PM, James Polk wrote:

> Ken
> 
> Thank you for this review, and I apologize for the late response - but I believe I will address each of your concerns below in the next rev, and have included the text I modified in the draft below to do just that.
> 
>> at present, I just have just a few general and specific comments about the draft, some of which are aimed at different audiences.  To the (other) chair and the group, I'd like to advocate changing the disposition of the draft from individual contribution to a working group draft.  The document is very symbiotic to the existing working group draft <draft-ietf-mmusic-traffic-class-for-sdp-01> in MMUSIC, and  efforts that compliment or strengthen other work items are good things to have.  In addition, the document builds on existing work [rfc-2872] and provides more granular information to nodes along the path, which I feel is always a good thing.  Finally, the draft appears in a state where the foundation is solid, with only refinements that are needed -- which seems sufficient in changing status to a working group draft
>> 
>> - at the end of the 1'st paragraph in Section 1, you state "An application profile defined by a sender may not be understood by the intermediaries or receiver in the same or different domain".  My impression is that its different domains that may not under the application profile, but that intermediaries *within the same domain* would understand the profile.  If I missed something, it would be helpful to expand on your original text.
> 
> You didn't miss anything, as I can see the existing text is unclear. I've changed this sentence to:
> 
>> - towards the end of section 2, you state that the specification "allows an RFC that defines a well known word or string to be a valid identifier".  The first question that comes to mind is who/what defines this well known word or string?  Is it done later in the draft, or does this come from some otehr draft/RFC or registry?  Its the "well known" part of the text that caught my eye.
> 
> good catch. I replaced "well known" with "industry recognizable term" to soften up any restrictions on what some folks may believe is allowable. I want to say "IETF recognizable term", but then someone would ask for where that term is defined, and that could get messy if the terms were pulled from more than one doc.
> 
> 
>> - i'm not convinced in how you separated real-time interactive profiles in Section 3.2 and multimedia conferencing profiles in Section 3.3.  I say this because your brief description of each (which may be too brief) doesn't seem associate characteristics that are different from each other.  Rather, each grouping only separates types of applications.  in contrast, broadcast and streaming are distinguished by the size of buffers.
> 
> fair conclusion. I've changed both profile descriptions with these leading paragraphs to differentiate the traffic types:
> 
> Realtime Interactive:
> 
> BTW - I'll need to change the descriptions of these traffic types within the MMUSIC traffic class draft too, as I want to keep both as synchronized as possible.
>

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 14:06:41 +0000

Hi James,

The changes look to good to me too !
My comments are worked out well!

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens ken carlberg [[email-masked]]
Verzonden: vrijdag 27 juli 2012 18:41
Aan: James Polk
CC: tsvwg
Onderwerp: Re: [tsvwg] Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03

James,

-ken

---

From: James Polk <[email-masked]>
Date: Mon, 30 Jul 2012 11:56:26 -0500

Georgios

great! Thank you for checking.

James
(individual hat on)

At 09:06 AM 7/30/2012, [email-masked] wrote:
> > Thank you for this review, and I apologize for the late response 
> - but I believe I will address each of your concerns below in the 
> next rev, and have included the text I modified in the draft below 
> to do just that.
> >
> about the draft, some of which are aimed at different 
> audiences.  To the (other) chair and the group, I'd like to 
> advocate changing the disposition of the draft from individual 
> contribution to a working group draft.  The document is very 
> symbiotic to the existing working group draft 
> <draft-ietf-mmusic-traffic-class-for-sdp-01> in MMUSIC, 
> and  efforts that compliment or strengthen other work items are 
> good things to have.  In addition, the document builds on existing 
> work [rfc-2872] and provides more granular information to nodes 
> along the path, which I feel is always a good thing.  Finally, the 
> draft appears in a state where the foundation is solid, with only 
> application profile defined by a sender may not be understood by 
> the intermediaries or receiver in the same or different 
> domain".  My impression is that its different domains that may not 
> under the application profile, but that intermediaries *within the 
> same domain* would understand the profile.  If I missed something, 
> it would be helpful to expand on your original text.
> >
> > good catch. I replaced "well known" with "industry recognizable 
> term" to soften up any restrictions on what some folks may believe 
> is allowable. I want to say "IETF recognizable term", but then 
> someone would ask for where that term is defined, and that could 
> get messy if the terms were pulled from more than one doc.
> >
> >
> (which may be too brief) doesn't seem associate characteristics 
> that are different from each other.  Rather, each grouping only 
> separates types of applications.  in contrast, broadcast and 
> streaming are distinguished by the size of buffers.
> >
> > fair conclusion. I've changed both profile descriptions with 
> these leading paragraphs to differentiate the traffic types:
> >
> > Realtime Interactive:
> >
> within the MMUSIC traffic class draft too, as I want to keep both 
> as synchronized as possible.
> >

---

From: James Polk <[email-masked]>
Date: Mon, 30 Jul 2012 11:57:08 -0500

ken

great! better late than never. Thank you for checking.

James