This is a report on what has happened here in Oslo from the syntax design
team meeting Tuesday morning through the full working group meeting this
morning. The activities of later Tuesday and Wednesday were controversial,
so I am documenting them fairly extensively.
Syntax Design Team Meeting
The Tuesday morning syntax design team meeting had a number of proposals to
consider. We achieved two quick conclusions: not to consider ODL as our
syntax specification language, and to split the Audit command into two
separate commands, one to discover capabilities, the other to determine
existing status. With regard to the ODL contribution, I would like to take
note of the hard work which M. Anquetil and his colleagues put into devising
complete Megaco syntax specifications not only in ODL but also in ASN.1.
>From this beginning we went on to consider a key issue: capability
specification syntax, with the Ott and Huitema drafts as our prime source
material. We found that the proposal by Ott et al provided one advance on
SDP: the ability to include quantitative constraints. Matt Holdrege also
pointed out that Tag-Length-Value syntax in the Ott proposal as taken up in
the syntax draft by Rosen et al offered the advantage that it would be
simple for service providers to modify values in the MG's capability
database, the way they modify values for RADIUS. Christian Huitema and
Joerg Ott more or less agreed that their respective approaches were
equivalent with respect to the expression of mutually exclusive
alternatives.
At the point where we began to be very interested in the proposal by Ott et
al, we realized that, given that it was meant to be a substitute for SDP,
our development of it would be an infringement on the mandate of MMUSIC. We
ended up concluding that the constraints of the situation required us
instead to specify that the MGC MUST in the short term support two different
systems for media description and media capabilities: one based on SDP and
one to be specified by SG 16 and presumably kinder to H.245. The choice of
which system to use would be up to the MG and could be audited as an MG
capability. We would reserve room for evolution to a new capability
description protocol if one should be produced by MMUSIC.
As part of this discussion, we considered the general question of Megaco
syntax and whether it should be the Tag-Length-Value system proposed by
Rosen et al (which, it was noted, is actually X.409 encoding reinvented).
We were unable to come to a consensus on this topic. The meeting ended, as
you might expect, with a cry of despair from Brian Rosen.
Follow-Up Meeting
Another meeting was hastily organized, to take place Tuesday night. It was
organized after the first meeting had broken up and was announced by a note
on the bulletin board, which meant that word did not reach all members of
the design team in time for them to change their plans for the evening.
Most but not all of the twenty-odd people in the morning meeting also
attended the one in the evening. The evening meeting spent most of its time
on the text vs. binary encoding issue in all its variants. The clear
consensus of those present was that there were two irreconciliable camps:
the IETF consensus would be in favour of text, the SG 16 consensus in favour
of binary, regardless of benchmark results. This meant that we had an
impasse. The suggestion was made that we toss a coin. This seemed to be
the only credible way out of the impasse, so I did so. The "text encoding"
side came up. The meeting broke up immediately following this result.
Derivation Of EBNF
On Wednesday Brian Rosen and Glen Freundlich, acting in place of Bryan Hill,
started the work of implementing EBNF syntax descriptions in line with the
conclusions of the previous day. They had help from a number of individuals
along the way, but this was in effect an editorial exercise starting from
the EBNF in draft-ietf-megaco-protocol-01.txt and the parameters shown in
the H.GCP draft rather than any sort of design team meeting. The results as
presented in this morning's working group meeting were fairly complete.
Working Group Meeting
As per the previously published agenda, slightly rearranged, the meeting
covered three topics: syntax, transport, and packages. Discussion of work
plan fell off the end.
The syntax discussion began with my presentation of the design team results.
Here is my summary as presented to the working group meeting:
* Agreed: split Audit into two commands
* status discovery
* capability discovery
* Stymied: new media description and media capability syntax may
infringe on MMUSIC (and maybe CONNEG) charters. Hence to be equally fair to
SIP and H.323:
* MGC must support both SDP and SG 16-determined encoding of H.245
* MG may support either
* reserve possibility of migration to new syntax.
* Political impasse on encoding. Decided for text by flipping a coin.
Issue is relative value of development speed vs. performance.
The final point on encoding is problematic, in that the conclusion was
reached by a group that was convened without, some will maintain, adequate
notice. I hope that I did not improperly influence the working group by
presenting this point with the same authority as the earlier points. In any
event, the working group appeared to be pleased with the outcome.
This ends the controversial part of this summary of results. The rest will
be presented more briefly, pending Matt Holdrege's drafting of the minutes.
Syntax: discussed use of the application-level Authentication Header and
concluded that it would remain an option for use when IPSEC is unavailable.
The use of SDP and of other protocols for media description and media
capability description will be documented in separate RFCs, one per
protocol.
Transport: determined a consensus in favour of mandatory support of both TCP
and application layer framing in the MGC, with the choice being determined
by the MG when it initiates an association.
Packages: an editorial team (Mike Kallas and Christian Huitema) was
appointed to draft IANA considerations for adding new packages. Package
descriptions include termination properties as well as events and signals.
One RFC, normatively referenced from the base protocol document, will
document the basic Megaco starter set of packages; others can be added
through IANA according to the documented procedures. Study Group 16 can
also generate package descriptions, probably by adding them as annexes to
H.248 (AKA H.GCP).
I spoke in the meeting of going to working group and possibly IETF last call
in September, before the ITU commits H.248 to ballot. Less optimistic
individuals have suggested a joint Megaco/Q.14/16 meeting on the east coast
of North America, the week of Sept. 13. Discussions on this point are
welcome.
Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961
