Subject: [AVT] WGLC for draft-ietf-avt-rtcp-port-for-ssm-01

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Aug 2010 13:17:14 +0200

(As WG co-chair)

This is to annouce working group last call for draft-ietf-avt-rtcp-port-for-ssm-01

Due to summer vacations, the WGLC will be for 3 weeks, so please get your comments submitted by close of business Wednesday August 25th.

Please respond to this message with your comments.

It is always helpful to try and categorise your comments as to the degree of severity, e.g. editorial, minor technical correction, major technical showstopper or whatever.

It is also helpful to propose what you believe would be acceptable replacement text to fix your concern.

(Note that we have two AVT WGLCs in parallel here - please comment on both documents)

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Aug 2010 18:44:16 +0200

My comments from a review of the document. I found nothing major.

1)	Section 1 (editorial): 

   In this specification, we introduce a new SDP attribute to remove
   this restriction.  The new attribute allows the multicast sender to
   use its desired port in the RTCP session.This document updates
   [RFC5760].

There are spaces missing between the second and third sentences.

2)	Section 3 (minor technical)

The only constraint you provide on port value in this document seems to be syntactic, i.e. defining it as "port", which is merely defined as 

   port =                1*DIGIT

Do you not need some text like that used in RFC 4566 for what that port number is. To quote an RFC 4566 example:

   <port> is the transport port to which the media stream is sent.  The
      meaning of the transport port depends on the network being used as
      specified in the relevant "c=" field, and on the transport
      protocol defined in the <proto> sub-field of the media field.
      Other ports used by the media application (such as the RTP Control
      Protocol (RTCP) port [19]) MAY be derived algorithmically from the
      base media port or MAY be specified in a separate attribute (for
      example, "a=rtcp:" as defined in [22]).

3)	Section 3 (minor technical)

   The 'multicast-rtcp' attribute MAY be used as both a media-level and 
   session-level attribute. 

I do not think the RFC 2119 language is justified here. We are just defining the atttribute, and that definition is that it can be both session level and media level. So I would prefer to say:

   The 'multicast-rtcp' attribute is defined as both a media-level and 
   session-level attribute.   

4)	Section 3.1 (editorial)

I don't really see why this is section 3.1 rather than section 4.

5)	Section 3.1 (editorial)

   In the SDP description ...

if expanded reads:

   In the session description protocol description...

You mean

   In the session description ...

6)	Section 4 (minor technical)

   Therefore, as usual
   adequate security measures are RECOMMENDED to ensure the integrity
   and authenticity of the SDP descriptions so that transport addresses
   of the media senders, distribution sources, feedback targets as well
   as other session-specific information can be authenticated.

You are using RFC 2119 language here but I don't think there is anything here specific enough to test.

I suspect the attribute itself introduces no security implications in its own right, but rather, as part of SDP it needs to embrace the same security constraints as the rest of SDP.

If so, I think you need to say this, and then refer to section 7 of RFC 4566.

7)	Section 5.1 (editorial)

        Purpose:            See this document
        Reference:          This document
        Values:             See this document

These are the entries that are going to appear in the IANA table, so I think you need to replace them with something more specific.

I think the Purpose should be real text, something like: "specifies a desired port for the SSM RTCP session"

The Reference should be "RFC xxxx" with an RFC editor note at the bottom of the section saying replace RFC xxxx by the RFC number of this RFC.

Not sure what to put in values - but see comment on section 3.

Note that you are trying to fulfil the following from RFC 4566:

   New attribute registrations are accepted according to the
   "Specification Required" policy of RFC 2434, provided that the
   specification includes the following information:

   o  contact name, email address, and telephone number

   o  attribute name (as it will appear in SDP)

   o  long-form attribute name in English

   o  type of attribute (session level, media level, or both)

   o  whether the attribute value is subject to the charset attribute

   o  a one-paragraph explanation of the purpose of the attribute

   o  a specification of appropriate attribute values for this attribute

   The above is the minimum that IANA will accept.  Attributes that are
   expected to see widespread use and interoperability SHOULD be
   documented with a standards-track RFC that specifies the attribute
   more precisely.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, August 04, 2010 12:17 PM
> To: IETF AVT WG
> Cc: [email-masked]
> Subject: [AVT] WGLC for draft-ietf-avt-rtcp-port-for-ssm-01
> 
> (As WG co-chair)
> 
> Due to summer vacations, the WGLC will be for 3 weeks, so 
> please get your comments submitted by close of business 
> Wednesday August 25th.
> 
> It is always helpful to try and categorise your comments as 
> to the degree of severity, e.g. editorial, minor technical 
> correction, major technical showstopper or whatever.
> 
> It is also helpful to propose what you believe would be 
> acceptable replacement text to fix your concern.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>