Re: draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05)

OK, I talked to Robert and I propose to change the draft from obsoleting
4756 to updating it (there is no "deprecated" keyword for the drafts).

There will be a note in section 3.1:

   This document introduces the changes required in the FEC grouping
   semantics and updates [RFC4756].  New implementations SHOULD use the
   new semantics introduced in this document whenever possible, but they
   may need to use [RFC4756] semantics when backward compatibility is
   desired, as described in Section 4.4.

Before we go ahead with the revision, please let me know if you are not
OK with this change. If there are no objections, we will move forward
with this change.

Thanks,
-acbegen

> -----Original Message-----
> From: Kevin P. Fleming [mailto:kpfleming <at> digium.com]
> Sent: Thursday, January 28, 2010 6:29 PM
> To: Ali C. Begen (abegen)
> Cc: Robert Sparks; mmusic <at> ietf.org; fecframe <at> ietf.org
> Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD
> Review:draft-ietf-mmusic-rfc4765bis-05)
> 
> Ali C. Begen (abegen) wrote:
> 
> > OK, right. "FEC" semantics are not defined in the new draft. If a
new

Re: Review of draft-saito-mmusic-sdp-ike-06

Eric,

Thank you very much for your comments again.
My comments inline..

(2009/12/27 5:38), Eric Rescorla wrote:
> At Tue, 22 Dec 2009 00:36:49 +0900,
> Makoto Saito wrote:
>>> My skepticism is that setting up a VPN for applications like this
>>> seems like overkill. VPNs have a bunch of ancillary security
>>> implications that aren't really necessary for these applications.
>>> It's important to remember that IPsec provides not only a network
>>> connectivity function but also a firewalling function.  (RFC 4301 S 2.1),
>>> and I worry that we're confusing these two to some extent. Consider
>>> the last case, the gaming system. In this case, we don't want to
>>> open a generic VPN connection, we want to open a connection directly
>>> to the gaming up. Why is IPsec a good mechanism here? The
>>> other examples seem to raise the same issue.
>>
>> Actually, joining the same local network makes DLNA perform very
>> effectively.
>>
>>    We are particularly focusing on LAN-based applications
>> so that it is not necessarily an overkilling to set up VPN for those
>> applications. For example, DLNA is used to share private contents
>> inside the LAN but it doesn't have sufficient security mechanisms
>> for the use over the Internet. So we think VPN is a simple solution
>> for that purpose. Anyway, we already have the implementation for
>> this application and start to deploy them.
>

new version draft mmusic-sctp-sdp-05

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

Re: new version draft mmusic-sctp-sdp-05

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

Re: new version draft mmusic-sctp-sdp-05

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

MMUSIC chair changes

All -

After an incredible 13 years chairing MMUSIC, Jeorg Ott is taking a  
well-deserved break.
His unwavering vision and guidance in the development of SDP has been  
a crucial part of its success.
Please join me in expressing thanks and appreciation for all he's  
helped accomplish in this time.

Tom Taylor has agreed to join as an MMUSIC co-chair with Jean-Francois  
going forward.
Tom is also continuing to work with AVT as WG secretary which will  
further increase coordination between
these two groups.

Welcome Tom!

RjS

Re: draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05)

Hi Ali -

Please submit the revised document.

RjS

On Feb 2, 2010, at 10:25 AM, Ali C. Begen (abegen) wrote:

> OK, I talked to Robert and I propose to change the draft from  
> obsoleting
> 4756 to updating it (there is no "deprecated" keyword for the drafts).
>
> There will be a note in section 3.1:
>
>   This document introduces the changes required in the FEC grouping
>   semantics and updates [RFC4756].  New implementations SHOULD use the
>   new semantics introduced in this document whenever possible, but  
> they
>   may need to use [RFC4756] semantics when backward compatibility is
>   desired, as described in Section 4.4.
>
> Before we go ahead with the revision, please let me know if you are  
> not
> OK with this change. If there are no objections, we will move forward
> with this change.
>
> Thanks,
> -acbegen
>
>
>> -----Original Message-----
>> From: Kevin P. Fleming [mailto:kpfleming <at> digium.com]
>> Sent: Thursday, January 28, 2010 6:29 PM
>> To: Ali C. Begen (abegen)
>> Cc: Robert Sparks; mmusic <at> ietf.org; fecframe <at> ietf.org
>> Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD
>> Review:draft-ietf-mmusic-rfc4765bis-05)
>>
>> Ali C. Begen (abegen) wrote:
>>
>>> OK, right. "FEC" semantics are not defined in the new draft. If a
> new
>>> implementation wants to be able to speak to 4756 endpoints, it will
> need
>>> 4756. Then I guess you are disagreeing that we are obsoleting 4756.
>>>
>>> Well, I am not sure what is the right term here. At that time, I was
>>> told "obsoleting" was the right choice. To me, RFC 4756 will still
> be
>>> available for anybody who wants to be backward compatible anyway.
> So, I
>>> did not think it would be a problem. But, if you say it is a
> problem, I
>>> can't argue with that.
>>
>> The correct word, in English at least, is 'deprecated'. The previous
>> version is still valid, but is not recommended for new
> implementations.
>>
>> --
>> Kevin P. Fleming
>> Digium, Inc. | Director of Software Technologies
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> skype: kpfleming | jabber: kpfleming <at> digium.com
>> Check us out at www.digium.com & www.asterisk.org

Re: draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05)

Here is the new version.
http://www.ietf.org/id/draft-ietf-mmusic-rfc4756bis-06.txt 

Cheers, acbegen.

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks <at> nostrum.com]
> Sent: Thursday, February 11, 2010 3:35 PM
> To: Ali C. Begen (abegen)
> Cc: Kevin P. Fleming; mmusic <at> ietf.org; fecframe <at> ietf.org
> Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD
Review:draft-ietf-mmusic-rfc4765bis-05)
> 
> Hi Ali -
> 
> Please submit the revised document.
> 
> RjS
> 
> On Feb 2, 2010, at 10:25 AM, Ali C. Begen (abegen) wrote:
> 
> > OK, I talked to Robert and I propose to change the draft from
> > obsoleting
> > 4756 to updating it (there is no "deprecated" keyword for the
drafts).
> >
> > There will be a note in section 3.1:
> >
> >   This document introduces the changes required in the FEC grouping
> >   semantics and updates [RFC4756].  New implementations SHOULD use
the
> >   new semantics introduced in this document whenever possible, but
> > they
> >   may need to use [RFC4756] semantics when backward compatibility is
> >   desired, as described in Section 4.4.
> >
> > Before we go ahead with the revision, please let me know if you are
> > not
> > OK with this change. If there are no objections, we will move
forward
> > with this change.
> >
> > Thanks,
> > -acbegen
> >
> >
> >> -----Original Message-----
> >> From: Kevin P. Fleming [mailto:kpfleming <at> digium.com]
> >> Sent: Thursday, January 28, 2010 6:29 PM
> >> To: Ali C. Begen (abegen)
> >> Cc: Robert Sparks; mmusic <at> ietf.org; fecframe <at> ietf.org
> >> Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD
> >> Review:draft-ietf-mmusic-rfc4765bis-05)
> >>
> >> Ali C. Begen (abegen) wrote:
> >>
> >>> OK, right. "FEC" semantics are not defined in the new draft. If a
> > new
> >>> implementation wants to be able to speak to 4756 endpoints, it
will
> > need
> >>> 4756. Then I guess you are disagreeing that we are obsoleting
4756.
> >>>
> >>> Well, I am not sure what is the right term here. At that time, I
was
> >>> told "obsoleting" was the right choice. To me, RFC 4756 will still
> > be
> >>> available for anybody who wants to be backward compatible anyway.
> > So, I
> >>> did not think it would be a problem. But, if you say it is a
> > problem, I
> >>> can't argue with that.
> >>
> >> The correct word, in English at least, is 'deprecated'. The
previous
> >> version is still valid, but is not recommended for new
> > implementations.
> >>
> >> --
> >> Kevin P. Fleming
> >> Digium, Inc. | Director of Software Technologies
> >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> >> skype: kpfleming | jabber: kpfleming <at> digium.com
> >> Check us out at www.digium.com & www.asterisk.org

SDP Alternate Connectivity (ALTC) Attribute (IPv4/IPv6)

Dear all,

We have sumbitted a new draft to define the ALTC attribute. In particular, ALTC may be used to carry multiple
IP addresses of differnts faimilies in SDP. 

Comments are more than welcome.
Cheers,
Med

-----Message d'origine-----
De : i-d-announce-bounces <at> ietf.org [mailto:i-d-announce-bounces <at> ietf.org] De la part de Internet-Drafts <at> ietf.org
Envoyé : vendredi 12 février 2010 10:45
À : i-d-announce <at> ietf.org
Objet : I-D Action:draft-boucadair-mmusic-altc-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
	Author(s)       : M. Boucadair, et al.
	Filename        : draft-boucadair-mmusic-altc-00.txt
	Pages           : 15
	Date            : 2010-02-12

This memo proposes a mechanism which allows to carry multiple IP
addresses, of different address families (e.g., IPv4, IPv6), in the
same SDP offer.  The proposed attribute solves the backward
compatibility problem which plagued ANAT, due to its syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boucadair-mmusic-altc-00.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.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the
addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

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

I-D ACTION:draft-ietf-mmusic-media-loopback-12.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-12.txt
	Pages		: 38
	Date		: 2010-2-16
	
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-12.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