Subject: I-D ACTION:draft-ietf-megaco-reqs-09.txt

From: [email-masked]
Date: Fri, 10 Dec 1999 08:07:48 -0500

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

        Title           : Media Gateway control protocol architecture and
                          requirements
        Author(s)       : N. Greene,  M. Ramalho,  B. Rosen
        Filename        : draft-ietf-megaco-reqs-09.txt
        Pages           : 45
        Date            : 09-Dec-99

TThis document describes protocol requirements for the Media Gateway control protocol between a Media Gateway Controller and a Media Gateway.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-megaco-reqs-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 10 Dec 1999 09:41:43 -0500

I propose WG Last Call based on this document, with the expiry two weeks
hence (24 December).

Changes from the previous version are as follows:

- removed reqt 5.6 c) Support general test capabilities, for example
loopbacks through the MG to test DSP operation.
It was agreed that inward loopbacks are outside the scope of the protocol -
they are not part of call control, so would be handled by some other
maintenance protocol. Thus the above requirement is deleted.

- reqt 5.7 a) - changed word call to connection

- table in section 11 - removed  wiretap

- reqt 11.1.3.1 a) rewording of 2nd bullet  on addressing - didn't mean
wildcarding, meant instead allowing the gateway to choose (part of) the
identifier

The references need to be completed still, and there may be an editor's note
or two that should still come out.

> -----Original Message-----
> From: [email-masked] [SMTP:[email-masked]]
> Sent: Friday, December 10, 1999 8:08 AM
> To:   [email-masked]
> Subject:      I-D ACTION:draft-ietf-megaco-reqs-09.txt
>
> TThis document describes protocol requirements for the Media Gateway
> control protocol between a Media Gateway Controller and a Media Gateway.
>
> Internet-Draft. << Message:  >>

---

From: Nancy-M Greene <[email-masked]>
Date: Wed, 15 Dec 1999 14:15:23 -0500

I've done my homework and filled in the references for the Megaco/H.248
requirements document (draft-ietf-megaco-reqs-09.txt) (thanks to those who
helped me fill them in):

> draft-ietf-megaco-reqs-09.txt references:
> 13.  References
> 
> [1]  S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
>      els", RFC 2119, March 1997.
> [2]  Draft ITU-T Recommendation Q.2630.1, AAL type 2 Signalling Protocol
> (Capability Set 1), ITU-T Meeting Report COM 11-R 149-E, July 1999
> [3]  ITU-T Recommendation H.341, Line Transmission of Non-Telephone
> Signals, May 1999.
> [4]  ATM Forum Technical Committee, af-vtoa-0083.001, Voice and Telephony
> Over ATM to the Desktop Specification, March 1999.
> [5]  ITU-T Recommendatio H.323v2, Packet-based Multimedia Comunications
> Systems (includes Annex C - H.323 on ATM), February 1998. 
> [6]  ATM Forum Technical Committee,  af-saa-0124.000, Gateway for H.323
> Media Transport Over ATM, May 1999.
> [7]  ITU-T Recommendation T.140, Protocol for Multimedia Application Text
> Conversation, February 1998.
> [8]  ITU-T Recommendation V.18, Operational and Interworking Requirements
> for DCEs Operating in Text Telephone Mode, February 1998.
> [9]  ITU-T Q.931, Digital Subscriber Signalling System No. 1 (DSS 1) -
> ISDN User-Network Interface Layer 3 Specification fro Basic Call Control,
> March 1993
> 
> Nancy
> --------------------------------------------------------------------------
> Nancy M. Greene 
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
> 
> 
> ----------
> From:         Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent:         Friday, December 10, 1999 9:41 AM
> To:   [email-masked]
> Subject:      Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
> 
> It was agreed that inward loopbacks are outside the scope of the protocol
> - they are not part of call control, so would be handled by some other
> The references need to be completed still, and there may be an editor's
> note or two that should still come out. 
>

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 23 Dec 1999 09:00:19 -0800

It's sad to see that all my comments regarding the NAS section have been
ignored again. So let's go through them one more time and I'll try to put
more detail into my comments.

At a high level, NAS requirements should be set by the NAS requirements
working group. That's where the experts are. Also, it's easy to see that
there are NO specific NAS requirements for MEGACO. For the basic purposes
of MEGACO, a NAS is no different than a VoIP gateway. I can see how you may
want to do some special things with special packages, but nothing in the
base protocol needs to be NAS specific.

So let's go through the NAS requirements step by step...

A. Callback. This is all that's listed. There are many aspects to callback
which are covered by RADIUS and are a part of the new AAA requirements. If
all you can list is callback, you should remove this requirement and leave
it up to AAA where it belongs.

B. Modem types. This is also handled by RADIUS and AAA. The MG contacts the
AAA server to instruct it on which modem to use. Remember that the MGC and
MG are not necessarily in the same management domain. But the MG DOES trust
it's AAA server. So that is where the information must come from and it
works best if it is transmitted directly. If you introduce a proxy, you
introduce a lot of difficulties. The AAA WG is trying to deal with the
difficulties of proxy and we shouldn't jump ahead of them.

C. D. E. F. These requirements can and should be covered by a single
sentence. The Protocol must be able to support Q.931 IE's. F already kind
of says this. Please be succint and less tutorial. Q.931 IE's are a basic
requirement of all MG's. Not just NAS's.

 >g.   Ability for the MGC to direct the NAS to connect to a specific tun-
 >     nel, for example to an LNS, or to an AAA server.

There are a multitude of tunnel types on the Internet. L2TP, IPsec, IPinIP,
IPSRA, RSIP, GRE, PPTP, ATMP, etc. These tunnel types are not all the same.
They are handled in different IETF working groups that have defined their
operation and their setup. The MEGACO WG should not be dictating how
tunnels get set up. Working groups such as L2TPEXT have defined RADIUS to
setup their tunnels.

H. This is already covered in the VoIP section. Reproducing requirements is
just adding confusion.

You mention that wiretapping has been removed, yet it is still in 11.2.1 D.
Whether the MEGACO protocol allows wiretap or not, I don't think we want
this specific requirement in an RFC. This was discussed at the Washington
plenary.

Lastly, I think this document should go through a more lengthy last call
since we are in the holiday time. We've gone into detail at the last two
meetings on the protocol itself and this requirements document doesn't
accurately reflect that.

At 09:41 AM 12/10/99 -0500, Tom-PT Taylor wrote:

>-----Original Message-----  From:   [email-masked]
>[SMTP:[email-masked]]  Sent:   Friday, December 10, 1999 8:08
>AM  To:     [email-masked]  Subject:        I-D
>ACTION:draft-ietf-megaco-reqs-09.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.  This draft is a work item of the Media Gateway Control
>Working Group of the IETF.
>
>         Title           : Media Gateway control protocol architecture
> and                            requirements          Author(s)       : N.
> Greene,  M. Ramalho,  B. Rosen          Filename        :
> draft-ietf-megaco-reqs-09.txt          Pages           :
> 45          Date            : 09-Dec-99
>
>control protocol between a Media Gateway Controller and a Media Gateway. A
>URL for this Internet-Draft
>is:
><http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>http://w
>ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username  "anonymous" and a password of your e-mail address. After logging
>in,  type "cd internet-drafts" and then          "get
>draft-ietf-megaco-reqs-09.txt".
>
>A list of Internet-Drafts directories can be found
>in  <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html  or
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-
>sites.txt
>
>Send a message to:          [email-masked].  In the body
>type:          "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt".
>
>NOTE:   The mail server at ietf.org can return the document
>in          MIME-encoded form by using the "mpack" utility.  To use
>this          feature, insert the command "ENCODING mime" before the
>"FILE"          command.  To decode the response(s), you will need
>"munpack" or          a MIME-compliant mail reader.  Different
>MIME-compliant mail readers          exhibit different behavior,
>especially when dealing with          "multipart" MIME messages (i.e.
>documents which have been split          up into multiple messages), so
>check your local documentation on          how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail
>reader  implementation to automatically retrieve the ASCII version of
>the  Internet-Draft. << Message:  >>

---

From: Nancy-M Greene <[email-masked]>
Date: Thu, 23 Dec 1999 12:41:27 -0600

Matt,
Megaco/H.248 is a device control protocol. It is true that for NAS, we allow
the MG itself to contact the AAA server. Yet, there will be implementations
that would have the MGC contact the AAA server. The requirements in this
section allow for the development of a NAS package IN THE FUTURE, that would
allow the information returned from the AAA server to be passed down to the
MG. How this package would be written is NOT specified in this requirements
document.

As for your comment that ALL your comments regarding the NAS section have
been ignored, this is simply not true! Your comments have been discussed
several times on the mailing list. As editor, I have tried to come up with
compromise text again and again, and every time, you come back saying I
haven't yet succeeded in satisfying your wishes.

Perhaps it is time for the chair to step in and see if we have rough
consensus on the requirements document or not.

Your comment on 11.2.1 D is correct. 11.2.1 D will be removed from the
requirements document.

Also, I don't understand your comment that the requirements document should
change, based on recent discussions of the protocol. We did update the
requirements document based on discussion at the Washington meeting. Tom is
planning to put out a companion I-D that maps the Megaco/H.248 protocol
against the requirements document.

Nancy

> ----------
> From:         Matt Holdrege[SMTP:[email-masked]]
> Sent:         Thursday, December 23, 1999 12:00 PM
> A

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 23 Dec 1999 11:57:18 -0800

>haven't yet succeeded in satisfying your wishes.

Can you try addressing my NAS comments on A through H? I tried for detail
this time so hopefully you can do the same.

Otherwise perhaps Tom can just forward the draft to the IESG with a note
saying that there is not unanimous WG consent on the document.

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 23 Dec 1999 14:19:14 -0600

The IETF does not require unanimous consent, just consensus.  As far as I'm
concerned, the requirements document represents consensus.

> From: Matt Holdrege [SMTP:[email-masked]]
> Sent: Thursday, December 23, 1999 2:57 PM

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 23 Dec 1999 12:43:32 -0800

That's why I said forward it and note the comments.

BTW, you have (possibly) reached consensus in MEGACO. But the NAS section
of this draft is setting requirements for protocols of other working
groups. You don't truly have IETF consensus unless you get the other WG's
to agree.

At 02:19 PM 12/23/99 -0600, Tom-PT Taylor wrote:

>The IETF does not require unanimous consent, just consensus.  As far as
>I'm concerned, the requirements document represents consensus.
>-----Original Message-----  From:   Matt Holdrege
>[SMTP:[email-masked]]  Sent:   Thursday, December 23, 1999 2:57
>PM  To:     [email-masked]  Subject:        Re: I-D
> >As for your comment that ALL your comments regarding the NAS section
> have  >been ignored, this is simply not true! Your comments have been
> discussed  >several times on the mailing list. As editor, I have tried to
> come up with  >compromise text again and again, and every time, you come
> back saying I  >haven't yet succeeded in satisfying your wishes.
>
>Can you try addressing my NAS comments on A through H? I tried for
>detail  this time so hopefully you can do the same.
>
>Otherwise perhaps Tom can just forward the draft to the IESG with a
>note  saying that there is not unanimous WG consent on the document.

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 23 Dec 1999 15:05:25 -0600

We are setting requirements only for ourselves.  Other WGs can ignore the
Megaco capability when they write their applicability statements, if they
want.

> From: Matt Holdrege [SMTP:[email-masked]]
> Sent: Thursday, December 23, 1999 3:44 PM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   [email-masked]