Subject: [Megaco] Draft Megaco Minutes

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 14 Dec 2001 18:46:06 -0500

Here are the draft Megaco meeting minutes.  I will send final minutes to the
IETF in one week.

Draft Minutes
Media Gateway Control (Megaco)
52nd IETF

The Megaco Working Group met on Wednesday afternoon, December 12, from
1400-1500, under the Chairmanship of Tom Taylor <[email-masked]>.
45 people attended.

Slides presented at the meeting have been placed at
   ftp://standards.nortelnetworks.com/megaco/docs/Current/IETF/Megaco-SLC/

1. Agenda
   ======

The proposed agenda was as follows:

 1 min:		Agenda Bashing
 5 min:		draft-tappenden-atm-AAL2-package-00	Chris Tappenden
45 min:		H.248v2 new features proposed by SG 16
Remainder:	H.248v2 new features proposed by Megaco

The agenda was accepted as proposed.  In the event, there was no time for
the final item.

2. draft-tappenden-atm-AAL2-package-00
   Chris Tappenden <[email-masked]>
   =============================================

This draft proposes a procedure for setting up an AAL2 connection and a
package to support that procedure.  Chris asked for an indication of
interest in the work.  He got two or three responses.  Work will continue
off-line.

3. H.248 Version 2 New Features
   ============================

Documentation
-------------

The complete text of draft H.248v2 is provided in
draft-ietf-megaco-h248v2-00.txt.  It is also available as an MS Word or PDF
document with markup at
   ftp://standards.nortelnetworks.com/megaco/docs/Current/ITU-SG16/
Note that the markup does not distinguish between version 2 features and
unapproved Implementor's Guide items.

Summary:
-------

The Chair opened the discussion with some general remarks on the ITU-T view
of protocol evolution and the need to make the transition as painless as
possible.  He raised the question of what the IETF should do with
Megaco/H.248 v1.  The final outcome of that discussion is that a new RFC
will be requested in February, based on draft-ietf-megaco-3015corr-xx,
including all Implementor's Guide corrections approved through that date.

The Chair then went through the new features added to this point in H.248v2.
The intent of the review was not to review the features in detail, but to
identify any issues with them and to decide if any should be omitted from
H.248v2.  During this review, the need to revisit the details of several of
the features was noted.  The meeting also rejected at this point the
proposed text in the table of section 7.2.9 which would provide a union of
responses to an ALL wildcard of context audits, without using the W- tag or
its binary equivalent.  At the end of the meeting a poll was taken: of those
strongly in favour of a given feature, and those strongly opposed.  On the
basis of these polls, it was concluded that there was a definite preference
to omit the context package feature from H.248v2.  The remaining features
are acceptable.  The Chair will seek consensus for this position on the
list.  

General
-------

This part of the discussion was introduced by the Chair's slide entitled
"H.248v2 General Remarks".  With regard to Megaco/H.248v1, the Chair
suggested that the alternatives were to freeze content as of the issuance of
H.248v2, continue to update version 1 documentation even after that date by
back-propagating applicable corrections from the H.248v2 Implementor's
Guide, and possibly take version 1 to Draft Standard when deployment
experience made this sensible.  Immediate discussion brought out the points
that:
 - talk of a "freeze" was nonsensical, since we are dealing with corrections
and clarifications rather than new content
 - the real issue is when to issue a consolidated version 1 document for the
convenience of the industry, since corrections will continue to accumulate
for the indefinite future
 - in any event, carriers want Megaco to maintain its identity with H.248.

Peter Blatherwick <[email-masked]> and Brian Rosen
<[email-masked]> questioned whether new features had to be
introduced at this time.  Instead, we should follow the Draft Standard
process.  We should try to negotiate synchronized release of a maintenance
update of H.248 with the ITU-T.  Without deployment experience, we cannot
judge whether the proposed new features are really required.

Regardless of what we do (Brian added), we and the ITU-T must remain in
synchronism.  It is important to publish the changes which have been
introduced by the Implementor's Guide.  However, the range of uses for the
protocol is shrinking.  Given that it was developed so quickly, making
additions to it without the benefit of deployment experience is asking for
trouble.

Context Properties
------------------

The Chair introduced discussion of this feature by advising the meeting that
his arguments presented at the Dublin meeting had drawn the response that SG
16 was willing to drop the feature from H.248v2 if Megaco so wished.
However, the Chair emphasized, this was not a "done deal" and the meeting
and list are free to comment on the matter.

The Chair presented charts showing the impact of the feature on the
specification.
In the text, it affects sections 6.2.3, new 7.1.19, 12, and 12.1.2.  It also
affects section 7.2.9, although the new content in this section was covered
under "Property-Specific Audits".  The syntax effects are additions to
productions ContextRequest and ContextAttrAuditRequest for binary, and to
productions contextProperty  and contextAuditProperties for text.  The Chair
identified a philosophical issue: that allowing packages for contexts could
result in distortion of the protocol.

Brian Rosen elaborated this concern.  Packages are eventually realized on
terminations.  If packages are also defined for contexts, it is possible to
arrive at contradictions or ambiguities.  He added that package designers
would always have to face the decision of whether a given property belonged
on a termination or on the context.  Peter Blatherwick supported Brian and
suggested that the existing arrangement represents a desirable separation of
concerns within the protocol.

The Chair invited Roni Even <[email-masked]> to give his opinion,
given Roni's contributions toward application of Megaco/H.248 to MCU
decomposition.  Roni indicated that context packages were nice to have, but
termination based solutions are also possible.

Signal On ROOT
--------------

The Chair indicated that this affects text in section 6.2.5, but has no
effect on syntax.  Brian Rosen expressed the opinion that this feature did
not do a lot of harm, but was objectionable on the general principle that it
was not necessary.

Property-Specific Audits
------------------------

This affects sections 7.1.12, 7.2.5, 7.2.6, and 7.2.9 of the text.  It
results in an extensive set of additions to the syntax, to the point where
this may be an issue in acceptance of the feature.

Brian Rosen pointed to this as a clear example of where the requirement is
not yet evident, and where deployment experience would show the real need.
Peter Blatherwick stated that the existing audit complexity is already too
much for the business sets in which he had an interest, and this just
worsens the problem.

Stream-Specific Topology
------------------------

This affects text in section 7.1.18 and adds a term to the TopologyRequest
and topologyTriple productions for binary and text respectively.  Brian
Rosen expressed his continuing dislike of topology as a context property,
but given its presence, supported the addition of the optional streamId
parameter.  He gave the example of a side conversation in a video
conference, where the side conference would use audio only.

ServiceChange Announcement Of Property Change
---------------------------------------------

This affects text in section 7.2.8, adds two new reason codes (916 Packages
Change and 917 Capability Change), and adds a term to the ServiceChangeParm
production.  The Chair saw an issue in the lack of text on how the MGC
controls the volume of messaging which could be triggered by changes.  Brian
Rosen suggested that this was an issue of intelligent implementation (e.g.
wildcarding of terminationIds affected).  The need for the feature would
become more evident with deployment experience, but there does seem to be a
requirement for a method to trigger audits.

Implicit Union Of Responses To Audit Of Context Properties With ALL Wildcard
----------------------------------------------------------------------------

This was introduced by text in the table of new section 7.1.19.  The Chair
pointed out that it is inconsistent with the operation of ALL wildcarding
for terminations, and duplicates the operation of W- tagging or its binary
equivalent.  The meeting agreed that this innovation was unacceptable.

Explicit Limits on Transaction Pending
--------------------------------------

This affects text in section 8.2.3, the version number of the root package
in Annex E.2, and introduces new properties in section E.2.1.  The Chair
pointed out that the changes in section 8.2.3 contain direct references to
package content in the body of the specification, an undesirable situation.
The meeting agreed that the proposal addresses a real problem, but there may
be better ways to solve it.  Alternative proposals should be offered on the
list.

New Text On Profile Definition
------------------------------

The Chair pointed out that this introduces a new chapter 13 and causes the
IANA Considerations chapter to be renumbered to 14.  New text on profiles
also appears in renumbered section 14.4.  The Chair also noted an updated
syntax for profile names which may have been the result of an Implementor's
Guide item.

Peter Blatherwick indicated that the new text is safe and acceptable as far
as it goes.  Additional information should eventually be added, but this
information deals with more controversial matters.  He would be making
further proposals on the list.  Brian Rosen suggested that the additional
work indeed needs to be done, but there is no rush for it.

-----

This terminated the review of specific features.  Polling of opinions then
took place, with the results as reported above.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Dan Elbert <[email-masked]>
Date: Mon, 17 Dec 2001 18:35:28 -0500

Hi
Is not clear if the RFC in February will include the accepted features from
version 2, or only the IG corrections.
If a new RFC is produced, what will be the value of the Megaco version as it
appears in the ServiceChangeVersion field ?
I don't remember this issue discussed in the ITU-T. 

Dan Elbert
RADVISION

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, December 14, 2001 6:46 PM
To: 'Scott Bradner'; 'Allison Mankin'
Cc: [email-masked]'
Subject: [Megaco] Draft Megaco Minutes

Draft Minutes

1. Agenda
   ======

 1 min:         Agenda Bashing

Documentation
-------------

Summary:
-------

General
-------

Context Properties
------------------

Signal On ROOT
--------------

Property-Specific Audits
------------------------

Stream-Specific Topology
------------------------

-----

Tom Taylor

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 17 Dec 2001 20:35:33 -0500

The intention is to produce two RFCs -- I already started the long Last Call
on H.248v2, and that will be one of them, with whatever is approved at the
SG 16 meeting in February.  The other will be v1 plus IG items only,
strictly for the convenience of implementors before they move on to v2.  I
think the Megaco text version should be 2 to match the ASN.1.

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Monday, December 17, 2001 6:35 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]'
Subject: RE: [Megaco] Draft Megaco Minutes

Hi

Dan Elbert
RADVISION

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, December 14, 2001 6:46 PM
To: 'Scott Bradner'; 'Allison Mankin'
Cc: [email-masked]'
Subject: [Megaco] Draft Megaco Minutes

Draft Minutes

1. Agenda
   ======

 1 min:         Agenda Bashing

Documentation
-------------

Summary:
-------

General
-------

Context Properties
------------------

Signal On ROOT
--------------

Property-Specific Audits
------------------------

Stream-Specific Topology
------------------------

-----

Tom Taylor

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 17 Dec 2001 20:35:33 -0500

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Monday, December 17, 2001 6:35 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]'
Subject: RE: [Megaco] Draft Megaco Minutes

Hi

Dan Elbert
RADVISION

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, December 14, 2001 6:46 PM
To: 'Scott Bradner'; 'Allison Mankin'
Cc: [email-masked]'
Subject: [Megaco] Draft Megaco Minutes

Draft Minutes

1. Agenda
   ======

 1 min:         Agenda Bashing

Documentation
-------------

Summary:
-------

General
-------

Context Properties
------------------

Signal On ROOT
--------------

Property-Specific Audits
------------------------

Stream-Specific Topology
------------------------

-----

Tom Taylor