Subject: RE: ATM Package for Megaco

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 31 May 2000 08:32:43 -0500

Just a gloss on this note: Scott Bradner and Allison Mankin have given their
blessing to letting Megaco do the detailed work on the stuff it needs.  We
can work the general principles through MMUSIC, then finish up on our own
list.

> -----Original Message-----
> From:	Joerg Ott [SMTP:[email-masked]]
> Sent:	Tuesday, May 30, 2000 4:07 PM
> To:	Rajesh Kumar
> Cc:	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: ATM Package for Megaco
> 
> Rajesh,
> 
> sorry for the response delay.  The Internet Drafts (which hopefully
> contain the
> authors' addresses) can be found at
> 
>  
> http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.t
> xt
> 
> Yes, I do believe that MMUSIC is the proper form for this kind of
> discussion
> (particularly if it involves extensions that are of broader
> applicability).
> MMUSIC should deal with all general aspects of SDP extensions and also 
> define/constrain how such extensions are to be done.  For very specific
> applications, however, the proper place for discussion 35 different
> relevant
> parameters which are not of broader applicability might be elsewhere
> (e.g. in the context of MEGACO) but the general constraints should not
> be violated.
> 
> So everything of general interest (and from my memory this probably
> applies
> to most/all of your proposal -- but don't quote me on this as its from
> memory :-)
> should be done in MMUSIC.
> 
> 
> > OK - I'll give this a shot. Who should I send the results to? The atmdsp
> mailing list?
> > The confctrl mailing list?
> 
> Both. 
> 
> Typically, lack of response means that people are busy or consider
> something
> not too important.  As we have several proposal on SDP for ATM,
> unimportance is
> less likely.  Nevertheless, it's probably not among people's top priority.
> 
> Also, note that we are working on SDPng (how it was called on a recent
> thread)
> to provide a better framework for capability description and negotiation.
> In this context, I promise to go through the document during our
> discussion
> cycles here and get you some further feedback; but please allow this to
> take
> a week or two)
> 
> I agree that it is important to move the stuff ahead.  As I stated before,
> I'd like to see the stuff coordinated with other work in this area and,
> if possible, also with the work on SDPng.  But for the latter, I am sort
> of
> the bottleneck right now (working on this :-)
> 
> You are *very* welcome to present and discuss the revisions in Pittburg
> at the next IETF.  I'll put this down in my agenda for some 20 minutes.
> Let
> me know if you need more.
> 
> Joerg
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 31 May 2000 10:17:18 -0400

At the moment, we hope that we can get ONE extension to SDP that works for
MGCP, Megaco and
SIP.  Besides the SDP update, MGCP and Megaco each need a package
definition, which is
also in progress.
 
So, as long as there are no conflicts, it would be best, I think, to keep
this an MMUSIC thing,
with cross posting of drafts to the Megaco and SIP lists (and also the MGCP
lists, non-IETF).
We will need an RFC for the Megaco package, which could be part of the SDP
update,
or could be a separate document.  At the moment, I'm thinking that it is
separate unless
we get both the MGCP and the Megaco package in there.  If we wanted the RFC
to be
standards track, it might be awkward to have the MGCP package in it.  So, I
propose that
Megaco do the package as a separate document, and MMUSIC do the SDP
extension on
a one-size-fits-all basis.  ISC will do the MGCP package.
 
Rajesh is working on a new version of the draft, with comments from several
folks.
I have a start at the Megaco package, and have a few comments to
incorporate.
We are contacting the nCube folks who had some ATM definitions in their
extension to RTSP and try to get them on-board.  We also are working to get
Scroggins/Brown at Nortel to propose updates to the Kumar draft to
incorporate
their concerns (hopefully without IPR baggage).
 
I'm kind of pushing to get this to a "last call" stage at the Pittsburgh
meeting, which
doesn't leave much room for the SDPng stuff.  That could be a problem.  On
the other
hand, we need it done asap for Megaco.  I may be too optimistic.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 9:33 AM
To: 'Joerg Ott'; Rajesh Kumar
Cc: [email-masked]; [email-masked]; Rosen, Brian;
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: ATM Package for Megaco

	-----Original Message----- 
From:   Joerg Ott [SMTP:[email-masked]] 
Sent:   Tuesday, May 30, 2000 4:07 PM 
To:     Rajesh Kumar 
Cc:     [email-masked]; [email-masked]; [email-masked];

	Rajesh, 

http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.txt
<http://www.dmn.tzi.org/ietf/mmusic/47/id/draft-sheedy-mmusic-rtsp-ext-00.tx
t>  

	Yes, I do believe that MMUSIC is the proper form for this kind of
discussion 
(particularly if it involves extensions that are of broader applicability). 
MMUSIC should deal with all general aspects of SDP extensions and also 
define/constrain how such extensions are to be done.  For very specific 
applications, however, the proper place for discussion 35 different relevant

	> OK - I'll give this a shot. Who should I send the results to? The
atmdsp mailing list? 

	Both. 

	Typically, lack of response means that people are busy or consider
something 
not too important.  As we have several proposal on SDP for ATM, unimportance
is 
less likely.  Nevertheless, it's probably not among people's top priority. 

	Also, note that we are working on SDPng (how it was called on a
recent thread) 
to provide a better framework for capability description and negotiation. 
In this context, I promise to go through the document during our discussion 
cycles here and get you some further feedback; but please allow this to take

a week or two) 

	I agree that it is important to move the stuff ahead.  As I stated
before, 
I'd like to see the stuff coordinated with other work in this area and, 
if possible, also with the work on SDPng.  But for the latter, I am sort of 
the bottleneck right now (working on this :-) 

	You are *very* welcome to present and discuss the revisions in
Pittburg 
at the next IETF.  I'll put this down in my agenda for some 20 minutes.  Let

	Joerg