Subject: Draft Meeting Minutes

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 9 Aug 2000 09:16:01 -0400

Here are the draft minutes for our meeting last week.  Please indicate any
errors or omissions.

Reported by Tom Taylor.

The Media Gateway Control Working Group (Megaco) met on Thursday afternoon,
Aug. 3, beginning at 3:30, with Tom Taylor as Chair.  About 120 people
attended.  The meeting did not fill its entire two hour slot.

1. Agenda
=========

The proposed and actual agenda was as follows:

    1. Agenda bashing                    5 min
    2. Status report -- work in progress        15 min
    3. Status report -- interop                5 min  Brian Rosen
    4. ISDN                               10 min  Bart van Doorselaer
    5. CAS package issues                     10 min  Michael Brown
    6. Auditing of ephemerals                 10 min
    7. SDPng requirements              5 min
    8. IETF/ITU operating  agreement    15 min

2. Status Report
================

The Chair presented a report on the status of work on Megaco/H.248,
organized under the headings of "Base Protocol Status", ITU-T Work In Hand",
"TIPHON Work In Hand", and "IETF Megaco Work In Hand".

2.1 Base Protocol Status
------------------------

Draft-ietf-megaco-protocol-08.txt and -megaco-errata-03.txt were approved as
Standards Track RFCs in May.  As of the meeting date, they were at top of
RFC Editor's queue, and should therefore be assigned RFC numbers shortly.

The ITU-T formally decided H.248 in June.

IETF Last Call on draft-ietf-megaco-merged-01.txt is complete.  It was
expected to be approved by the IESG as a standards-track RFC in the week
following IETF 48.  Since it is simply the merged content of the other two
RFCs, it will obsolete them when it is published.

Two errors have been identified so far:
  - conflict between the TDM Circuit package and Annex C
  - token "EB" used for both EmbedToken and EventBufferToken.
The list has also brought up a large number of points of clarification.

There was a discussion on how we would document these points.  It was agreed
(subject to ratification by the list) that we would rely on ITU-T
documentation as presented in the H.248 Implementor's Guide.  Specifically,
we would publish the draft Implementor's Guide as an I-D.  When Study Group
16 approves the document, we will publish a short RFC pointing to it.  The
ITU-T makes Implementor's Guides publicly available on the web at no cost.

The Chair noted that list discussion included some proposals for changes to
the protocol.  Since Megaco/H.248 has now been fully approved, no changes
are possible to this version of the protocol.

2.2 ITU-T Work In Hand
----------------------

The Chair listed the following SG 16 Annexes scheduled for November
decision.  WG Last Call has been issued on them.
One general comment was received: make the I-D titles more descriptive.

Packages:
  Annex F: facsimile, text conversation, call discrimination
   - comments (Mule/Parsons, 7/25-26/00)
  Annex G: display, key, keypad, label key, function key, indicator, soft
key, ancillary input
   - one error noted (Blatherwick, 7/31/00)
  Annex J: dynamic tone generation
  Annex K: generic announcement
   - a meeting participant noted a comment which the Chair had overlooked.

New transports:
  Annex H: SCTP
   - correction noted (Xie, 7/13/00)
  Annex I: ATM
   - I-D abstract typo noted (Xie, 7/11/00)

It was agreed that we would consolidate these annexes into two documents
(packages, transport alternatives) for IETF Last Call and publication as
Standards Track RFCs.  The errors noted in WG Last Call will be reported to
the SG 16 Rapporteur's meeting being held in Portland, OR, the week of Aug.
21-25.

The Chair listed the following further ITU-T work items:

In Study Group 16, for November determination, Feb'01 decision:

  Annex L: Error Codes
  Annex M: Advanced Audio Server packages.

On this latter, the Chair noted a potential Nortel Networks IPR claim on the
original submission to the IETF (draft-cromwell-...), but could not say
whether this survived in the current Study Group 16 document.  He agreed to
follow IETF rules on disclosure if and when Annex M comes back to the IETF.

As noted already, Study Group 16 will also maintain an H.248v1
"Implementor's Guide" (i.e. bugs and clarifications) as a living document.
The first draft of this document should appear out of the Portland
Rapporteur's meeting, and the first approved version out of the November
Study Group meeting.

Study Group 16 has applied Annex G packages in H.323 Annex L "Stimulus
Signalling", where H.248 content is embedded within messages passed between
the Gatekeeper and the H.323 stimulus set.  (For November decision.)

In ITU-T Study Group 11, two different pieces of work are in progress:

  Question 9, for December determination:
   New Recommendation Q.5x, package(s) for H.248
   control of signal processing network equipment.
  Contact: Larry Forni ([email-masked])

  SG 11 BICC (Q. ??, for ?? determination)
   Work on Bearer-Independent Call Control (BICC) related packages.
  Contact: Christian Groves ([email-masked])

2.3 TIPHON Work In Hand
-----------------------

ETSI TIPHON Working Group 6 is working on a protocol conformance statement
(PICS) for a very limited subset of the protocol -- just enough for a basic
call through a trunking gateway.  For the latest draft document, see

  http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/

Contact: Klaus Sambor([email-masked])

2.4 Megaco Work In Hand
-----------------------

The Chair listed the following drafts reflecting work items of the group.

draft-ietf-megaco-mib-00.txt (Standards Track)
 - main remaining charter item
 - awaiting inputs from Brown et al
 - awaiting ideas out of interop event.
A new draft of this document was promised within the next month.

draft-ietf-megaco-naspkg-00.txt (Standards Track)
 - expert resource located, more complete draft in next month.

draft-ietf-megaco-ipphone-02.txt (Informational)
 - recycled document to be submitted for WG Last Call in the next month.

draft-ietf-megaco-r2package-01.txt
 - WG Last Call issued, issues raised re CAS in general and this document in
particular
 - proposed to constitute CAS design team to settle.

It was at about this point that Scott Bradner intervened to point out that
Megaco was attempting to move beyond its charter.  The Working Group cannot
take on new work items unless they fall within that charter.  Once the
charter has been completed, what happens to the Working Group is a matter
for discussion between the WG Chair, our Area Director, the IESG at large,
and the IAB.  The Megaco E-mail list should continue regardless of the fate
of the Working Group itself, and IETF procedure allows the submission of
non-WG-initiated drafts for advancement to RFC status.

Subject to that reminder, the Chair noted the following individual
submissions to Megaco:

draft-bouwen-megaco-isdn-00.txt
 - alternatives for ISDN signalling transport; ISDN D-channel data
The Chair was corrected on this -- a more recent draft is available (see
below).

draft-brown-supplpkgs-00.txt
 - more call progress tones (two packages)
 - analog line enhanced alerting package
 - trunk signalling packages (robbed bit, MF)

A comment was raised on this draft, to the effect that the proposed tone
identifiers needed clearer documentation so that parties outside of North
America could judge their applicability.  Michael Brown
([email-masked]) indicated that the document was to be
reissued and that it would be split into three parts.  (See further
discussion of channel-associated signalling below.)

draft-hss-megaco-r1package-00.txt
 - R1 signalling (international counterpart to MF)

draft-sharp-megaco-t1rbsapp-00.txt (expired)
 - applicability statement for robbed bit signalling

Also note draft-rajeshkumar-mmusic-sdp-atm-02.txt (SDP for ATM connections).
The intent is to complete work on this document within the next month or
two.  Comments should be made now.  Brian Rosen ([email-masked])
committed to follow up and close the loop with a Megaco package for ATM.

3. Interop Event Status Report
==============================

Brian Rosen presented one chart giving all the essential details regarding
the Megaco/H.248 interoperability event to be held this month.  [Brian,
could I have it?]  Between ten and twenty implementations are expected,
representing both MGs and MGCs.  As Brian reported, the NDA form was
available within a day of the meeting.

4. ISDN (draft-bouwen-megaco-isdn-??.txt)
=========================================

Bart Van Doorselaar (XXXXXX) noted that the draft had been recycled to take
out the discussion of signalling transport in Megaco.  Nevertheless, the
issues of signalling channel management and D-channel data remained open.
Brian Rosen encouraged Bart and his co-authors to submit detailed package
proposals.  Scott Bradner asked whether the ITU-T might have related work in
hand.  Christian Groves suggested that the group in Study Group 11 dealing
with ISDN might be the right place to do the work.

5. Channel-Associated Signalling
================================

Michael Brown gave a brief presentation of the the issues associated with
channel-associated signalling (CAS) packages.  He and others felt that the
approach presented in the R1 and R2 package documents was overly
repetitious, and that it should be possible to define reusable events and
signals common to multiple signalling systems.  The authors of those
documents had responded on the list to say that they had not seen enough
commonality to be worthwhile isolating.  In any event, it appears desirable
to make CAS package definition a matter of focussed discussion amongst
interested parties.  The action is upon the Chair to invite these parties to
submit their names and then work together to come up with a common view.

6. Auditing Of Ephemerals
=========================

In the original draft agenda, this portion of the meeting was to be devoted
to issues raised on the list.  The Chair observed that list discussion did
not lend itself to easy summarization, because there were a lot of small
issues rather than a few large ones.  He had identified one recent issue
which could be followed up: the question of how the MGC could find out what
kinds of ephemerals the MG supported in advance of instantiation.  His
summary of list discussion was as follows:

Issue: how to tell what kind of ephemerals the MG supports, in advance of
instantiation.

Subsidiary issues:
 - whether auditCapability of ROOT returns packages which apply
   to individual terminations rather than the MG as a unit

 - whether there are constraints on the combinations of packages
   supported on a given (ephemeral) termination

 - naming patterns associated with specific types of ephemerals

 - (implicit) whether naming pattern is a meaningful concept with
   binary encoding

Potential solutions:
 - favourable definition of auditCapability of ROOT
 - naming pattern property
 - transport-specific ROOT packages, including naming patterns.

It was noted in subsequent discussion that the original proposal for a
naming pattern property had been turned down at the ITU-T not because binary
naming patterns are implausible, but because the ASN.1 expression of naming
patterns had not been formulated and it was considered too risky to attempt
the task at the last minute.  Now that the pressure is off, the job can be
done.  Brian Rosen expressed an interest in submitting a proposal.

On the general issue, Brian suggested that the Chair had presented a good
summary, but that resolution would have to be done on the list.

7. SDPng
========

The Chair noted that MMUSIC is beginning to study requirements for a
protocol to support session negotiation as opposed to simple session
description.  They have dubbed this work "SDPng".

A first cut at requirements has been presented in
draft-kutscher-mmusic-sdpng-req-00.txt.  Related material has been assembled
at
http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/

Megaco is a potential customer (in Megaco/H.248v2), recalling that we had to
add a fair amount to SDP to achieve what we needed.

Discussion in a small group following the MMUSIC meeting had brought about
general agreement that there was a fairly fine balance between meeting the
real requirements and creating something overly complex.  The Chair
presented a summary of those requirements which originated with Mark Handley
(XXXX), a participant in that discussion:

 - Ability to indicate when a given parameter is required and when it can
safely be ignored if not supported or understood.

 - Ability to indicate whether a given proposal applies to send direction,
receive direction, or both.

 - Ability to provide multiple formats and indicate whether the intent is
"support all" or "choose one".

 - Ability to group: equivalent of multipart/related and
multipart/alternative.

Note that others would consider this list a good start but not quite
complete.

Flemming Andreasen ([email-masked]) and Michael Brown both expressed their
concern over what introduction of a new protocol would do to existing SDP
implementations.

8. Cooperation With Other Standards Bodies
==========================================

In May the Chair had presented to the list a draft agreement for continued
cooperation with Study Group 16 and other Study Groups.  In reprise of this
topic, he proposed to leave aside the legalese and have the meeting consider
just the principles of any agreement.  He presented four charts enumerating
these proposed principles.

8.1 Considerations
------------------

The first chart presented the considerations which should be behind any
agreement.

(1) IETF members have a continuing interest in free access to H.248
documentation as H.248 evolves.  Almost certainly they wish to participate
as equal partners in that evolution.

(2) There is a small probability that ITU-T reorganization this fall may
place the Question dealing with H.248 (currently Q. 14/16) under new senior
management.  Thus any agreement for cooperation with this Question should be
finalized only after the WTSA finishes its work.

(3) The IESG may choose to reorganize/disband Megaco.  Hence as much as
possible, any agreement should be drafted to be independent of Megaco's
existence.

(4) Other groups doing H.248 related work may not want to cooperate as
closely with Megaco as SG 16.

There was no discussion of these points.

8.2 Keeping Each Other Informed
-------------------------------

The minimum requirement for any agreement is that the signatories agree to
keep each other informed about any Megaco/H.248-related work they plan to
undertake.

Corollary: the IETF must provide a designated point of contact for
notifications.

Discussion: Scott Bradner noted that the minimum aim of any agreements
between the IETF and other bodies should also include the encouragement of
cross-publication of the resulting work.  This could be by means of
Informational rather than Standards Track RFCs.

8.3 Base Protocol Evolution
---------------------------

Chart contents:

We want agreement with Q. 14/16 and its successor that:

 - we work with them as equal partners in developing any new versions of the
base protocol;

 - WG Last Call resolution precedes ITU-T determination;

 - once any new version has been determined, it is frozen except for bug
fixes and clarifications;

 - IETF Last Call and IESG approval occur in the interval between
determination and decision;

 - in principle, the document approved by the IESG is the same as the
document decided by the ITU-T (i.e. we do not have to keep a separate errata
document as we did this time around).  The ITU-T naturally retains the right
to make last-minute modifications based on members' comments or newly-found
errors.

Discussion: Scott Bradner and Greg Ratta indicated that discussion of this
chart was moot.  Any continuing agreement with the ITU-T should have broader
scope than that of a particular Working Group and a particular Question.
Moreover, ITU-T procedures may change significantly in the wake of the
meeting of the governing body next month.

8.4 Packages
------------

Chart contents:

We want agreement with other standards groups that:

 - they will coordinate work on packages with us to minimize duplication of
effort;

 - we will be given a chance to review packages that they are working on
when we have relevant expertise, and our comments will be taken into
account;

 - our respective processes will be coordinated to allow for that review.

Discussion:

Michael Kallas noted that the strong relationship between many packages
points to a need for continuing coordination.  Christian Groves in response
recalled that the Megaco E-mail list will continue.  As for the matter of
consultation, package work actually involves two issues: style, and content.
The originator of a package should control the content.  An expert adviser
could rule on style.  Further discussion reiterated the importance of
maintaining Megaco as a continuing list.  Scott Bradner summed up by
recalling that IANA registration rules could include review by a designated
expert.  This procedure is recommended when some degree of control over the
registered material is desired.  The alternative is to base registration on
publicly-reviewed specifications.

9. Adjournment
==============

The Chair adjourned the meeting with a word of thanks to all who had
faithfully supported the work of Megaco.  He noted that it might be the last
time we met.

Tom Taylor
Lead Standards Developer
[email-masked]
Phone and FAX: +1 613 736 0961

---

From: Thomas LEVY <[email-masked]>
Date: Wed, 30 Aug 2000 16:43:02 +0200

Tom-PT Taylor wrote :

> ....

Tom,

I have the meaning that after Megaco/H.248 has been fully approved, the Megaco
IETF WG will be closed (refer Goals and Milestones).
So, how changes to the protocol could be discussed inside IETF after this step?

Sincerely,

Thomas LEVY,