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@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961