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

From: James Polk <[email-masked]>
Date: Thu, 14 Jun 2012 16:19:05 -0500

Georgios

Thank you for your review. I apologize for not 
responding earlier. I tend to address these 
review messages as I'm updating the draft, and I 
hadn't cycled time to get to this draft until now.

My comments are in-line below...

At 01:58 AM 5/24/2012, [email-masked] wrote:
>Hi James, Hi all,
>
>I think that this ID is useful and that it can 
>become a (tsvwg) WG document. However, I have some comments:
>
>Comment_1: Section 1 should enhance/enlarge the 
>text that motivates why this document is needed!
>==============
>
>Comment_2: In Section 2, page 3 is mentioned:
>“No other Sub-types are defined by
>    any profile within this document, but can be included by individual
>    implementations”
>It would be better to use MAY be instead of “can be”, see below:
>“No other Sub-types are defined by
>    any profile within this document, but MAY be included by individual
>    implementations”

changed from informative (can) to normative (MAY)

>==============
>
>Comment_3: At the introductory part of Section 3 
>emphasize that the IANA registries associated 
>with the application profiles are given in Section 5.2.
>==============
>
>Comment_4: In Section 3.1 it is emphasized that 
>the Application profiles are including the field 
>“VER”, but the semantics of this field are not explained.

I'm not sure which point you have an issue with

#1 - that I don't define what the VER field is, or
#2 - that I don't sufficiently define how this 
profiles document means for the VER field to be used.

To #1 - RFC 2872 defines a VER field to denote 
the version of a particular profile, though it is 
not all that specific about it - because it only 
implies the concept of "profiles". This draft 
makes that explicit as far as what's in this 
draft is concerned, but doesn't limit the use of 
the APP-ID field for other uses.

To #2 - we state the VER field, that's part of 
the APP-ID Object, is to remain as is, and it is 
set to have no value in any of the profiles this 
draft defines. This allows 2 things, first that 
each profile can be modified for a given traffic 
type can be modified, and secondly, that any VER= 
value means it has been modified from what is 
defined by this document. I guess I could specify 
that Ver=0 for each profile, but it would mean the same thing.

Please comment if the draft needs more or 
modified text to convey what I've said above.

>==============
>Comment_5: Section 5.2.1:
>o) In  Broadcast Audio IPTV Profile, please 
>chnage from: APP=broadcast.video.iptv, VER="
>INTO:
>APP=broadcast.audio.iptv, VER="
>
>o) The name of the fourth described profile should be changed from:
>Broadcast Audio Live-events Profile
>INTO:
>Broadcast Video Live-events Profile

done

>==============
>
>Comment_6: Section 5.2.3:
>o) The name of the first described profile could be changed from:
>Multimedia-Conferencing Profile
>INTO:
>Multimedia-Conferencing Profile  Presentation data
>
>o) The name of the second described profile could be changed from:
>Multimedia-Conferencing Profile
>INTO:
>Multimedia-Conferencing Profile  Application Sharing
>
>o) The name of the third described profile could be changed from:
>Multimedia-Conferencing Profile
>INTO:
>Multimedia-Conferencing Profile  Whiteboarding

done

>==============
>
>Comment_7: Section 5.2.4:
>o) The name of the first described profile could be changed from:
>   Multimedia-Streaming Profile
>INTO:
>   Multimedia-Streaming Profile  Multiplex
>o) The name of the second described profile could be changed from:
>
>   Multimedia-Streaming Profile
>INTO:
>Multimedia-Streaming Profile  Webcast

done

>==============
>
>Comment_8: The security considerations section 
>(Section 4) is not clear, see below:
>“Given that each traffic flow is within separate reservations, and
>    RSVP does not have the ability to police the bits within any
>    reservation, solving for this appears to be administratively handled
>    at best. This is not meant to be a 'punt', but there really is
>    nothing this template creates that is going to make things any
>    harder for anyone (that we know of now).”
>Please elaborate!

What I mean to say here is to cover what happens 
if some claims a certain type of traffic is 
actually another type of traffic. In other words, 
lying about which profile they used. I'm saying 
that RSVP itself has no ability to police this. I 
have changed the word "bits" to "type of traffic" 
to make that distinction more clear. I hope you 
agree. Let me know if you do not.

>==============
>
>Comment_9: The reference to RFC 2750 is not 
>listed in Section 8, while t is used in the text.

oops - fixed

Thank you

James

>Best regards,
>Georgios
>
>
>
>________________________________________
>Van: [email-masked] 
>[[email-masked]] namens James M. Polk [[email-masked]]
>Verzonden: woensdag 14 maart 2012 0:42
>Aan: tsvwg
>Onderwerp: draft-polk-tsvwg-rsvp-app-id-vv-profiles uploaded
>
>TSVWG
>
>(as author)
>
>I've uploaded the next version of
>
>http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profiles-03.txt
>
>The following changes were made in this version:
>
>- Added draft-ietf-mmusic-traffic-class-for-sdp-01.txt as a
>    reference
>
>- Changed to a new format of the profile string.
>
>- Added many new profiles based on the new format into each parent
>    category of Section 3.
>
>- changed the GUID to refer to draft-ietf-mmusic-traffic-class-for-
>    sdp-01.txt
>
>- changed 'desktop' adjective to 'avconf' to keep in alignment with
>    draft-ietf-mmusic-traffic-class-for-sdp-01.txt
>
>- Have a complete IANA Registry proposal for each application-ID
>    discussed in this draft.
>
>- General text clean-up of the draft.
>
>I don't believe there are any open issues with this document, and
>hope to ask the WG to adopt this draft during the Paris meeting.
>
>James

---

From: <[email-masked]>
Date: Fri, 15 Jun 2012 10:06:46 +0000

Hi James,

Please see in line!

> -----Original Message-----
> From: James Polk [mailto:[email-masked]]
> Sent: donderdag 14 juni 2012 23:19
> To: Karagiannis, G. (EWI); [email-masked]; [email-masked]
> Subject: Re: Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03
> 
> Georgios
> 
> Thank you for your review. I apologize for not responding earlier. I tend to
> address these review messages as I'm updating the draft, and I hadn't cycled
> time to get to this draft until now.
> 
> >I think that this ID is useful and that it can become a (tsvwg) WG
> >document. However, I have some comments:
> >
> >Comment_1: Section 1 should enhance/enlarge the text that motivates
> why
> >this document is needed!
> >==============
> >
> >"No other Sub-types are defined by
> >    implementations"
> >It would be better to use MAY be instead of "can be", see below:
> >"No other Sub-types are defined by
> >    implementations"

Georgios: Okay
> 
> >==============
> >
> >Comment_3: At the introductory part of Section 3 emphasize that the
> >IANA registries associated with the application profiles are given in
> >Section 5.2.
> >==============
> >
> >Comment_4: In Section 3.1 it is emphasized that the Application
> >profiles are including the field "VER", but the semantics of this field
> >are not explained.
> 
> #2 - that I don't sufficiently define how this profiles document means for the
> VER field to be used.
> 
> To #1 - RFC 2872 defines a VER field to denote the version of a particular
> profile, though it is not all that specific about it - because it only implies the
> concept of "profiles". This draft makes that explicit as far as what's in this
> draft is concerned, but doesn't limit the use of the APP-ID field for other
> uses.
> 
> To #2 - we state the VER field, that's part of the APP-ID Object, is to remain
> as is, and it is set to have no value in any of the profiles this draft defines. This
> allows 2 things, first that each profile can be modified for a given traffic type
> can be modified, and secondly, that any VER= value means it has been
> modified from what is defined by this document. I guess I could specify that
> Ver=0 for each profile, but it would mean the same thing.
> 
> Please comment if the draft needs more or modified text to convey what
> I've said above.

Georgios: Yes, I think that it will be good to provide more details in order to convey what you mentioned above!

> >"Given that each traffic flow is within separate reservations, and
> >    harder for anyone (that we know of now)."
> >Please elaborate!
> 

Georgios: Okay

Best regards,
Georgios