Ingemar Johansson S | 2 Oct 19:51 2009
Picon

Image attribute and layered coding

Hi

After a period of silence I am in the process of updating the image attrubute draft. 
I have an issue with the image attribute and how it can be used with layered codecs.

From RFC5583 one can take the following example 
         v=0
         o=svcsrv 289083124 289083124 IN IP4 host.example.com
         s=LAYERED VIDEO SIGNALING Seminar
         t=0 0
         c=IN IP4 192.0.2.1/127
         a=group:DDP L1 L2 L3
         m=video 40000 RTP/AVP 96 97
         b=AS:90
         a=framerate:15
         a=rtpmap:96 H264/90000
         a=rtpmap:97 H264/90000
         a=mid:L1
         m=video 40002 RTP/AVP 98 99
         b=AS:64
         a=framerate:15
         a=rtpmap:98 H264-SVC/90000
         a=rtpmap:99 H264-SVC/90000
         a=mid:L2
         a=depend:98 lay L1:96,97; 99 lay L1:97
         m=video 40004 RTP/AVP 100 101
         b=AS:128
         a=framerate:30
         a=rtpmap:100 H264-SVC/90000
         a=rtpmap:101 H264-SVC/90000
(Continue reading)

HAAS Christian | 3 Oct 11:34 2009
Picon

Re: WGLC: draft-ietf-mmusic-rfc2326bis-22

Hello again!

In here I list my findings of my first pass of the syntax review. As always, I'm optimistic to find extra time for another pass.

I) Syntax modifications

1. accept-param:
The syntax does not enforce using the q parameter as 'delimeter' between media-type-range and accept-range parameters; HTTP does this more explicitly in 14.1
Suggestion:

accept-range      =  media-type-range [ SEMI accept-params ]
accept-params     =  "q" EQUAL qvalue *( SEMI generic-param )

this then also affects other definitions that rely on current accept-param:

encoding          =  codings [ SEMI accept-params ]
language          =  language-range [ SEMI accept-params ]

...although this then requires the q parameter to be first for the encoding and language definitions as well. Bad / Not Bad?


2. language-range (for Accept-Ranges):
It could reference the language-tag definition (one page below), suggestion:

language-range    =  language-tag / "*"


3. Proxy-Require and Proxy-Supported:
They can both reference the feature-tag-list below, suggestion:

Proxy-Require        =  "Proxy-Require" HCOLON feature-tag-list
Proxy-Supported      =  "Proxy-Supported" HCOLON feature-tag-list


4. Retry-After:
a) 16.40 allows this header to specify seconds or a date, the syntax only allows delta-seconds.
b) What is the comment for? Maintenance description?
c) Usage of duration retry-param is not described in 16.40 nor anywhere else

Suggestion (assuming no further description text is added):

Retry-After          = "Retry-After" HCOLON ( RTSP-date / delta-seconds )


5. channel (for transport parameter)
I suggest a comment like at ttl:

channel              = 1*3DIGIT ; 0 to 255


6. User-Agent
I guess the syntax should be identical to the one of Server; the extra '0' for the * list is unnecessary.


II) Things I might have not properly understood:

1. Accept-Language:
The header allows to be empty. If this is the case, does this mean all languages have a q value of 1 or does the last sentence in 16.4 imply NO language is acceptable: "If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable."
I guess it of course means all languages are equally acceptable, especially with the default q value of 1 -- yet, does this mean for all explicitly given languages or all the server knows of which are not explicitly given?


2. Allow:
This header may also be empty. How can I reach a valid resource that does not produce 404, but 405 and allows no request to be performed?


3. Content-Type:
May be given in SIP-like short form "c" -- This is the only header to allow this according to the syntax.
Why?


Regards,
ch


-----Original Message-----
From: mmusic-bounces <at> ietf.org on behalf of HAAS Christian
Sent: Fri 9/25/2009 7:23 AM
To: mmusic <at> ietf.org
Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22

Hello all!

I've read through the draft (skipping the syntax definitions) and found only
minor issues regarding wording, typos and consistency so far, which I already
sent to Magnus directly.

I will try to find some time during the upcoming days for a dedicated check
of the syntax.

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    christian.haas <at> frequentis.com

Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.



-----Original Message-----
From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On Behalf Of
Joerg Ott
Sent: Sonntag, 20. September 2009 18:19
To: mmusic <at> ietf.org
Cc: Magnus Westerlund; Jean-Francois Mule; Martin Stiemerling
Subject: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22

Folks,

as agreed in Stockholm, we are issuing working group last call on the revised
RTSP spec, draft-ietf-mmusic-rfc2326bis-22 heading for Proposed Standard.
(http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22)

The WGLC will expire in four weeks, on 19 Oct 2009.

We know that this is a long spec, the more important is it to receive
thorough review by the community.  While we have three volunteer reviewers
(thanks again!), we urge everyone who cares to provide detailed feedback.

Please review the document and post your comments to the MMUSIC list and/or
the authors.

Thanks,
Joerg

MMUSIC co-chair

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Internet-Drafts | 8 Oct 23:30 2009
Picon

I-D ACTION:draft-ietf-mmusic-media-loopback-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: An Extension to the Session Description Protocol (SDP) for Media Loopback
	Author(s)	: C. Sivachelvan, N. Venna, P. Jones, N. Stratton, A. Roychowdhury, K. Hedayat
	Filename	: draft-ietf-mmusic-media-loopback-11.txt
	Pages		: 33
	Date		: 2009-10-7
	
The wide deployment of Voice over IP (VoIP), Real-time Text and 
    Video over IP services has introduced new challenges in managing 
    and maintaining voice/real-time Text/video quality, reliability, 
    and overall performance.  In particular, media delivery is an area 
    that needs attention.  One method of meeting these challenges is 
    monitoring the media delivery performance by looping media back to 
    the transmitter.  This is typically referred to as "active 
    monitoring" of services.   Media loopback is especially popular in 
    ensuring the quality of transport to the edge of a given VoIP, 
    Real-time Text or Video over IP service.  Today in networks that 
    deliver real-time media, short of running 'ping' and 'traceroute' 
    to the edge, service providers are left without the necessary tools 
    to actively monitor, manage, and diagnose quality issues with their 
    service.  The extension defined herein adds new SDP media 
    attributes which enables establishment of media sessions where the 
    media is looped back to the transmitter. Such media sessions will 
    serve as monitoring and troubleshooting tools by providing the 
    means for measurement of more advanced VoIP, Real-time Text and 
    Video Over IP performance metrics.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Jean-Francois Mule | 9 Oct 10:34 2009

Update of draft-ietf-mmusic-media-loopback-11.txt


   At the last IETF meeting in July, we discussed the status of your
draft.
See the WG meeting notes in the proceedings.
Hadriel mentioned that there were a few comments that had not been
addressed and the action was for Hadriel to sync up with you and work on
the changes to get the draft ready for publication request.

  I just looked at the ID update you submitted this week using the diff
on tools.ietf.org.
All I can see in draft-11 is:
	- the I-D date and company refresh for two of the authors
	- the addition of some text in the Copyright Notice:
"Code Components extracted from this
document must include Simplified BSD License text as described in	
Section 4.e of the Trust Legal Provisions and are provided without	
warranty as described in the BSD License."

   Can the authors go through the list of open comments and close them
by sending a summary to the mmusic list?
In particular, those comments referred by  Hadriel at the mike in
Stockholm?

A draft update with draft-12 addressing the last comments received would
be appreciated.

Thank you,
Jean-Francois
MMUSIC co-chair.

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
> Behalf Of Internet-Drafts <at> ietf.org
> Sent: Thursday, October 08, 2009 3:30 PM
> To: i-d-announce <at> ietf.org
> Cc: mmusic <at> ietf.org
> Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-
> 11.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiparty Multimedia Session
> Control Working Group of the IETF.
> 
> 	Title		: An Extension to the Session Description
> Protocol (SDP) for Media Loopback
> 	Author(s)	: C. Sivachelvan, N. Venna, P. Jones, N.
> Stratton, A. Roychowdhury, K. Hedayat
> 	Filename	: draft-ietf-mmusic-media-loopback-11.txt
> 	Pages		: 33
> 	Date		: 2009-10-7
> 
> The wide deployment of Voice over IP (VoIP), Real-time Text and
>     Video over IP services has introduced new challenges in
> managing
>     and maintaining voice/real-time Text/video quality,
> reliability,
>     and overall performance.  In particular, media delivery is an
> area
>     that needs attention.  One method of meeting these challenges
> is
>     monitoring the media delivery performance by looping media back
> to
>     the transmitter.  This is typically referred to as "active
>     monitoring" of services.   Media loopback is especially popular
> in
>     ensuring the quality of transport to the edge of a given VoIP,
>     Real-time Text or Video over IP service.  Today in networks
> that
>     deliver real-time media, short of running 'ping' and
> 'traceroute'
>     to the edge, service providers are left without the necessary
> tools
>     to actively monitor, manage, and diagnose quality issues with
> their
>     service.  The extension defined herein adds new SDP media
>     attributes which enables establishment of media sessions where
> the
>     media is looped back to the transmitter. Such media sessions
> will
>     serve as monitoring and troubleshooting tools by providing the
>     means for measurement of more advanced VoIP, Real-time Text and
>     Video Over IP performance metrics.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-
> loopback-11.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
Jean-Francois Mule | 9 Oct 16:25 2009

Review of IKE/IPsec media description in SDP, draft-saito-mmusic-sdp-ike-05

This is a partial review of an individual draft, Media Description for IKE in the Session Description Protocol, http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-05. Note that a Security Directorate review has been requested via Tim Polk.

 

It is my understanding that this draft has been around for almost 3 years. Some operators have deployed applications based on the mechanism described in the document. 

 

This review is done at the request of the authors who intend to request publication as an informational RFC.  Additional reviews and comments are welcome.

 

 

--- http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-05

--- Technical comments and questions

 

·         General questions

I’m not sure if all the points below need to be addressed in the document but there are questions that popped up reviewing the draft:

 

o    Handling of provisional SIP responses:

Is there a need to mandate that the first response from the answering entity should be a final response, and not a provisional response? 

If a provisional response is allowed, does it need to be sent reliably?

If the SIP UA sending the INVITE receives an unreliable provisional response containing SDP, what does it do?

 

o    Handling of multiple SDP media lines

The draft should cover the cases where a Remote Client offers multiple media lines, for example one with media format of "ike-esp" and another with media format for an audio codec.

 

o    Forking

Can the INVITE be forked to multiple registered instances? Probably doesn't make sense for this application -- so should you add text that says there is only one registered instance?

If multiple registered instances are allowed, how is forking handled?

 

o    SIP session and VPN state sync?

There is little bit of text on page-8, para-2 on this but it prompts more questions.

How does either the Remote Client or Home Router detect when an established VPN fail? Is there a native "keep-alive" supported by VPN.

Should the RFC 4028 "SIP session timer" extension be supported?

Is there any need to re-authenticate an established VPN, say if some security association times out (i.e., can the Remote Client re-INVITE the session)?

Basically, how are the SIP dialog and VPN states maintained (independently, does a state change to a SIP termination state implies the VPN is terminated, vice-versa).

 

·         Security comments and questions

The mechanism is based on the assumption that the SDP media description is protected using encryption. 

You have text on page-5 section 1.2 as part of the “background” but it would be good to call this out in the document, and create a specific section on it.  It could take the form of an Applicability Statement (see http://tools.ietf.org/html/rfc3325#section-1) to reinforce the requirements that must be met in order for the solution to be of any meaningful use.

 

On a different note, if the remote client and home router are pre-configured with a shared secret or a certificate issued by a trusted CA, is there a need to have a hash fingerprint in the SDP to identify which certificate or secret to use?

 

 

·         Security - authorization and user authentication model

This is related to Page-5, para-2, Page-19 in Security Consideration and other places in the document.

It is mentioned that SIP is used for name resolution and authorization.  It is unclear to me where it is described who is responsible for ensuring that only authorized clients can use this mechanism to gain access the Home Router.

Say there are three Remote Clients; RC-1, RC-2, RC-3, and three Home Routers (in different homes); HR-a, HR-b, HR-c. And say that only the following combinations are allowed for IKE:

 RC-1 to HR-a

 RC-2 to HR-b

 RC-3 to HR-c

If RC-1 attempts to establish an IKE session with HR-2, who blocks it? Based on what information in the SIP signaling or IKE exchange?

Basically, the model for service authorization needs to be explained in more details.

In the scenario where service authorization is done by the “SIP cloud”, could the user behind the Remote Client be authorized to initiate an IKE session independent of the terminating Home Router user? And could the Home Router user authorize the IKE session independent of the initiating RC user? 

Some text on this would help.

 

·         Page-5, para-6:

Do any of the RFC 4474 deficiencies discussed in DISPATCH affect this document (e.g., issues related to B2BUA traversal)? For more info, see http://tools.ietf.org/html/draft-rosenberg-sip-rfc4474-concerns-00.

 

·         Page-7 Section-2 Protocol Overview:

Comments on Figure-1, step 3:

This 3rd step says...

    "After SDP exchange, Remote Client (SDP offerer)

     initiates IKE with the SDP answerer to establish

     IPsec SA."

This is not accurate, since the offer/answer negotiation can result in either end initiating the IKE session.  Indicate the active role to address this comment.

 

 

·         Page-9, section-3 Protocol Identifier:

Given you are re-using the values of the “setup” attribute from RFC 4145, suggest being specific in the sentence below.

 

Change...

<  The semantics of "active", "passive", and "actpass" in the offer/

<  answer exchange is the same as the definition described in 4.1 of RFC

<  4145.

 

To...

>   The semantics for the "udp-setup" attribute values of "active",

>   "passive", and "actpass" in the offer/answer exchange are the same as

>   that described for the "setup" attribute in 4.1 of RFC 4145, except that

>   it applies to an IKE session instead of a TCP connection.

 

·         Page-9, section-3 Protocol Identifier:

This section would benefit some rewrite to normatively define what each new SDP parameter defines.

For example, paragraph 1 could define the new SDP attributes more clearly:

 

This document defines two SDP media formats for the “udp” protocol under the “application” media type, "ike-esp" and "ike-esp-udpencap":

        + "ike-esp" indicates that the media described is IKE for the establishment of an IPsec security association as described in IPsec ESP as specified in []...

        + "ike-esp-udpencap" indicates that the media described is IKE for the establishment of UDP encapsulation of IPsec packets through NAT boxes as specified in []...

 

 

·         Page-12, section 5.2 Offer and Answer Exchange with ICE:

a) It would be good to add a few sentences to explain that the mechanism that ICE specifies for keeping NAT bindings open for RTP & RTCP traffic does work for UDP encapsulated IKE exchanges.

b) The use of “UDP session” in sections 5.2, 5.3 and other parts of the document is improper.  There are UDP-based media sessions but there is no such thing as a UDP session.  Consider rewording the sentences that explain the needs to multiplex several types of UDP packets over the same UDP ports, something like that.

 

·         Page 20, section 9 IANA Considerations

 This section must be written to ask IANA to register the attributes.

See the requirements in http://tools.ietf.org/html/rfc4566#section-8.2.8 and a good example in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-10#page-72

 

 

--- Editorial and other comments

The document needs to be scrubbed for grammar errors, conversational phrasing (e.g., "by the way..."), run-on sentences, etc.  I will send a list of nits directly to the authors.

 

idnits 2.11.14 reports 4 warnings and 1 comment; check the results at http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-saito-mmusic-sdp-ike-05.txt

 

Acknowledgment: David Hancock and Stuart Hoggan provided input into the above review – many thanks to them.

 

Regards,

Jean-Francois as an individual contributor.

 

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Kaynam Hedayat | 12 Oct 15:42 2009

Re: Update of draft-ietf-mmusic-media-loopback-11.txt

Jean-Francois,

We will follow-up with Hadriel and others to close the remaining items
raised and will provide a summary to the mailing list.

Regards,
Kaynam

-----Original Message-----
From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On Behalf
Of Jean-Francois Mule
Sent: Friday, October 09, 2009 4:34 AM
To: draft-ietf-mmusic-media-loopback <at> tools.ietf.org
Cc: mmusic <at> ietf.org
Subject: [MMUSIC] Update of draft-ietf-mmusic-media-loopback-11.txt

   At the last IETF meeting in July, we discussed the status of your
draft.
See the WG meeting notes in the proceedings.
Hadriel mentioned that there were a few comments that had not been
addressed and the action was for Hadriel to sync up with you and work on
the changes to get the draft ready for publication request.

  I just looked at the ID update you submitted this week using the diff
on tools.ietf.org.
All I can see in draft-11 is:
	- the I-D date and company refresh for two of the authors
	- the addition of some text in the Copyright Notice:
"Code Components extracted from this
document must include Simplified BSD License text as described in	
Section 4.e of the Trust Legal Provisions and are provided without	
warranty as described in the BSD License."

   Can the authors go through the list of open comments and close them
by sending a summary to the mmusic list?
In particular, those comments referred by  Hadriel at the mike in
Stockholm?

A draft update with draft-12 addressing the last comments received would
be appreciated.

Thank you,
Jean-Francois
MMUSIC co-chair.

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
> Behalf Of Internet-Drafts <at> ietf.org
> Sent: Thursday, October 08, 2009 3:30 PM
> To: i-d-announce <at> ietf.org
> Cc: mmusic <at> ietf.org
> Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-
> 11.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiparty Multimedia Session
> Control Working Group of the IETF.
> 
> 	Title		: An Extension to the Session Description
> Protocol (SDP) for Media Loopback
> 	Author(s)	: C. Sivachelvan, N. Venna, P. Jones, N.
> Stratton, A. Roychowdhury, K. Hedayat
> 	Filename	: draft-ietf-mmusic-media-loopback-11.txt
> 	Pages		: 33
> 	Date		: 2009-10-7
> 
> The wide deployment of Voice over IP (VoIP), Real-time Text and
>     Video over IP services has introduced new challenges in
> managing
>     and maintaining voice/real-time Text/video quality,
> reliability,
>     and overall performance.  In particular, media delivery is an
> area
>     that needs attention.  One method of meeting these challenges
> is
>     monitoring the media delivery performance by looping media back
> to
>     the transmitter.  This is typically referred to as "active
>     monitoring" of services.   Media loopback is especially popular
> in
>     ensuring the quality of transport to the edge of a given VoIP,
>     Real-time Text or Video over IP service.  Today in networks
> that
>     deliver real-time media, short of running 'ping' and
> 'traceroute'
>     to the edge, service providers are left without the necessary
> tools
>     to actively monitor, manage, and diagnose quality issues with
> their
>     service.  The extension defined herein adds new SDP media
>     attributes which enables establishment of media sessions where
> the
>     media is looped back to the transmitter. Such media sessions
> will
>     serve as monitoring and troubleshooting tools by providing the
>     means for measurement of more advanced VoIP, Real-time Text and
>     Video Over IP performance metrics.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-
> loopback-11.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Internet-Drafts | 14 Oct 02:45 2009
Picon

I-D Action:draft-ietf-mmusic-ice-tcp-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : TCP Candidates with Interactive Connectivity Establishment (ICE)
	Author(s)       : S. Perreault, J. Rosenberg
	Filename        : draft-ietf-mmusic-ice-tcp-08.txt
	Pages           : 19
	Date            : 2009-10-13

Interactive Connectivity Establishment (ICE) defines a mechanism for
NAT traversal for multimedia communication protocols based on the
offer/answer model of session negotiation.  ICE works by providing a
set of candidate transport addresses for each media stream, which are
then validated with peer-to-peer connectivity checks based on Session
Traversal Utilities for NAT (STUN).  ICE provides a general framework
for describing candidates, but only defines UDP-based transport
protocols.  This specification extends ICE to TCP-based media,
including the ability to offer a mix of TCP and UDP-based candidates
for a single stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-mmusic-ice-tcp-08.txt): message/external-body, 70 bytes
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Simon Perreault | 14 Oct 02:58 2009
Picon

Re: I-D Action:draft-ietf-mmusic-ice-tcp-08.txt

On Tuesday 13 October 2009 20:45:01 Internet-Drafts <at> ietf.org wrote:
> 	Title           : TCP Candidates with Interactive Connectivity
> Establishment (ICE) Author(s)       : S. Perreault, J. Rosenberg
> 	Filename        : draft-ietf-mmusic-ice-tcp-08.txt
> 	Pages           : 19
> 	Date            : 2009-10-13

This new revision is an effort to gauge what is the interest in ICE-TCP and 
where it should go. There is only one change, the addition of this paragraph:

      Note: It has been reported that the simultaneous-open technique
      has a low success rate (~40%) with the population of NAT devices
      in use as of this writing.  Therefore, it is RECOMMENDED that
      implementations of this specification acquire and use IPv6 host
      candidates.  Means of doing so across NATs include Tunnel Setup
      Protocol [I-D.blanchet-v6ops-tunnelbroker-tsp], Teredo [RFC4380],
      IPSec NAT-T [RFC3947], and others.

Two questions for this WG:

- Should this effort be dropped or continue?

- What is needed for this draft to get WG consensus?

Thanks, and sorry for not posting this sooner,
Simon
--

-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org
Jean-Francois Mule | 14 Oct 18:10 2009

WGLC on draft-ietf-mmusic-rfc4756bis-03

This is to start a 2-week working group last call on draft
draft-ietf-mmusic-rfc4756bis-03,
http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03.  The comment
period will end on Wednesday October 28.

Please send your comments to the mmusic list and the authors.

Thank you,
Jean-Francois.
Jean-Francois Mule | 15 Oct 00:31 2009

Comments on draft-ietf-mmusic-rfc4756bis-03

Ali,

   The draft is well written and provides clear justifications for the
updates to RFC 4756.

   Below are a few comments for your consideration.

Regards,
Jean-Francois.

- Document frontpage:
Given this draft extends the group and ssrc-group attributes with new
semantics (a=group:FEC-XR, a=ssrc-group:FEC-XR), the boiler plate should
indicate that this document does update RFC 3388bis and RFC 5576, I
think. 

- page 4, para 4: typo
s/the grouping semantics defined in this document offers flexibility
about which source streams can be grouped together prior to FEC
protection/ the grouping semantics defined in this document offer the
flexibility to determine how source streams are grouped together prior
to applying FEC protection

- page 5, numbered bullets 
(see next comment)
a) You summarize a few FEC framework requirements.  
I suppose they are contained in the document, if so put the document
reference [].
b) I'm not sure about this comment but I wonder whether these
requirements should be included with the capital verbs here. I would
turns those MAY into may, as they are duplicate requirements in the FEC
framework and implementations compliant with this draft would not need
to meet those as stated (see the comment below).  You only drive the one
SDP grouping semantics requirement you have below them (as a MUST).

- page 5, last sentence of section 1
Change the requirement to be more explicit on what the SDP semantics
must be able to express (and I would split bullet 3 into two bullets).
As written, the reader has to translate what the FEC requirements mean
for the SDP semantics (in reference to "these features").
Old text:
---
To summarize, the FEC Framework supports the following:
   1.  A source flow MAY be protected by multiple different FEC schemes.
   2.  An FEC scheme MAY generate multiple repair flows.
   3.  Source flows MAY be grouped prior to FEC protection.  That is,
       one or more repair flows MAY protect a group of source flows.

   To fully benefit from the flexibility provided by the FEC Framework,
   the grouping semantics for FEC MUST support these features.
---

New text:
In summary, based on the FEC Framework [], the SDP grouping semantics
for FEC MUST support the ability to indicate that:
   1.  a given source flow is protected by multiple different FEC
schemes.
   2.  multiple repair flows are associated with a given source flow
   3.  multiple source flows are grouped prior to applying FEC
protection
   4.  one or more repair flows protect a group of source flows.
--- or something like that.

- page 5, section 3
The text in section 3 should be written as if it is the new
to-be-published RFC. You should assume the draft is the RFC that
obsoletes RFC 4756 and explain what motivated some changes and
extensions.  
This leads to a few editorial changes, some of which are suggested
below.

s/issues with RFC 4756/changes from RFC 4756 (in the section 3 heading)

- page 5, section 3.1
Consider presenting what this document defines first, and finish with
the changes from previous RFCs.  

Example:
--- old text
   Currently, the 'group' attribute and the FEC grouping semantics
   defined in [RFC3388] and [RFC4756], respectively, are used to
   associate source and repair flows together.

   The 'group' attribute is used to group multiple repair flows with one
   or more source flows.  However, [RFC3388] prohibits an "m" line
   identified by its 'mid' attribute from appearing in more than one
   "a=group" line using the same semantics.  This limitation prevents us
   from indicating specific associations between the source and repair
   flows by using an "a=group:FEC" line per FEC Framework instance.  For
   example, for the scenario sketched in Figure 1, [RFC3388] mandates us
   to write

        a=group:FEC S1 S2 R1 R2

   Clearly, this "a=group:FEC" line does not say anything specific about
   which repair flows are protecting which source flows.

   A new work ([I-D.ietf-mmusic-rfc3388bis]) is currently in progress in
   the MMUSIC WG to remove this limitation in [RFC3388].  However,
   [RFC4756] also needs to be updated according to the FEC Framework
   requirements.

--- new text
   The FEC grouping semantics and 'group' attribute
   defined in this document and [RFC3388bis], respectively, are used to
   associate source and repair flows together.

   This document specifies how the SDP 'group' attribute is used to 
   group multiple repair flows with one or more source flows.  
   [I-D.ietf-mmusic-rfc3388bis] updates [RFC3388]
   to allow an "m" line identified by its 'mid' attribute to appear in
   more than one "a=group" line using the same semantics. This change
   allows us a sender to indicate the specific associations between the
   source and repair flows by using an "a=group:FEC" line per FEC
   Framework instance. 

// change the example to show the above and how the 3388bis helps

   This document updates [RFC4756] to allow the source and repair flows
   to be associated in SDP.

--- hope this helps convey what the text should look like expressing the
same things.

- section 4.1, bottom of page 6, first 2 paragraphs of page 7
This is where having some formal MUST requirements for compliant
implementations would be beneficial.

Change:
   If there are more than one
   repair flows included in an FEC group, they are considered to be
   additive.  Repair flows that are in different FEC groups are non-
   additive.

Into something like:
   Repair flows included in the same FEC Group MUST be additive. And
   repair flows that are not additive MUST be indicated in separate
   SDP FEC group lines.

- page 8, section 4.2
s/MUST/must in "we MUST write" 
(you have now a formal requirement in section 4.1)

- page 8, section 4.3
Change:
< Instead, the 'ssrc-group' attribute MUST be used.
With
> This document extends [RFC 5576] in two ways.  First we define how FEC
is applied to source and repair flows for SSRC multiplexed streams using
the 'ssrc-group' attribute.  We then specify how additivity of the
repair flows are expressed for SSRC multiplexed streams.

- page 8, last paragraph of section 4.3
Same comment as above for the "a=group" lines: it would be good to have
2 MUST requirements to indicate that additive repairs flows MUST be on
the same a=ssrc-group lines while non-additive ones MUST be on separate
lines.

- page 9, section 4.4., last paragraph at the bottom of page 9
I would not point to RFC4756 but instead point to this draft (from my
perspective, it does not make much sense to ask implementers to first
check that there is no ambiguity with the previous RFC.

- page 10, para 3:
Same comment as above.

- section 4.4 and backward compatibility
Given the new tokens you define (FEC-XR), there is no backward
compatibility issues. Section 4.4 explains how to cope with situations
when the remote party only understands RFC 4756.
Should this section be called "SDP Offer/Answer and backward
compatibility considerations"?

- aBNF?
Would it be beneficial to have a new BNF for the SDP attributes you
extend?
e..g

       group-attribute    = "a=group:" semantics  ; from [RFC3388bis]
                             *(space identification-tag)
        semantics          = "LS" / "FID" / 
                             "FEC" /               ; from RFC 4756 for
backward compatibility
                             "FEC-XR"               ; this RFC

> -----Original Message-----
> From: Jean-Francois Mule
> Sent: Wednesday, October 14, 2009 10:10 AM
> To: mmusic <at> ietf.org
> Cc: 'draft-ietf-mmusic-rfc4756bis <at> tools.ietf.org'; Joerg Ott
> Subject: WGLC on draft-ietf-mmusic-rfc4756bis-03
> 
> This is to start a 2-week working group last call on draft draft-
> ietf-mmusic-rfc4756bis-03, http://tools.ietf.org/html/draft-ietf-
> mmusic-rfc4756bis-03.  The comment period will end on Wednesday
> October 28.
> 
> Please send your comments to the mmusic list and the authors.
> 
> Thank you,
> Jean-Francois.
> 

Gmane