Comments on draft-polk-tsvwg-rsvp-app-id-vv-profiles-03

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”
==============

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.

==============
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
==============

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
==============

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
==============

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!
==============

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


Best regards,
Georgios

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,  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 ormodified 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 Profiledone>==============
>
>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 ­ Whiteboardingdone>==============
>
>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 ­ Webcastdone>==============
>
>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:  
> namens James M. Polk 
>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-pol...
>
>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

Hi James,

Please see in line!> -----Original Message-----
> From: James Polk 
> Sent: donderdag 14 juni 2012 23:19
> To: Karagiannis, G. (EWI); ; 
> 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.
> 
> My comments are in-line below...
> 
> At 01:58 AM 5/24/2012,  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)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.
> 
> 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.Georgios: Yes, I think that it will be good to provide more details in order to convey what you mentioned 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.Georgios: Okay

Best regards,
Georgios> 
> >==============
> >
> >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: 
> > namens James M. Polk 
> >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-pol...
> 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