We are getting discussion of the Red Bank contributions on the megaco list. I am crossposting these discussions to the ITU-T SG16 list. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

---------- From: Rayhan, Abdallah [CAR:5N00:EXCH] Sent: Thursday, October 14, 1999 11:01 AM To: megaco@standards.nortelnetworks.com Subject: APC-1711, 1712 review

I took a pass through APC-1711 and APC-1712 and I would like to post my analysis on the mailing list. I don't claim my analysis to be complete, however I tried to point out the main problems I came across while reading APC-1711 ABNF. My primary goal is the final ABNF and not the ASN.1 for two reasons. First, I am not an ASN.1 expert, so I would leave critiquing it to the ASN.1 experts. Second, it would be a big distraction to the IETF having the MEGACO ABNF at an advanced stage with a set of testbenches (ANNEX G). Hence, I will try to focus on APC-1711 ABNF which I call ABNF1711 and MEGACO/H.248 ABNF which I call ABNF248.

To start with I have noted that the ABNF1711 does not take the ABNF248 as is but modifies it to suite ASN.1 encoding ( is ASN.1 so restrictive that it does not allow ABNF248 syntax ? ) These discrepancies are found in: (I started noting the different PRs but then found myself marking almost every one.)

- Tagging every value. ABNF1711: PkgdName = LBRKT PkgItemID [ PkgName ] RBRKT PkgName = LBRKT "/" ( ( "PE" EQUAL Name ) / "*" ) RBRKT PkgItemID = ( ( "PI" EQUAL Name ) / "*" )

ABNF248: pkgdName = [ (PackageName | "*") SLASH ] (ItemID | "*" ) PackageName = NAME ItemID = NAME

You need "PE=" before package name and "PI=" before ItemID. These differences appear in many production rules.

- Extra brackets as illustrated in the previous example. In ABNF1711, there is a curly bracket before and after PkgdName while ABNF248 does not have that. This is all over ABNF1711.

- Extensions do not appear any where in ABNF1711 while they are a major feature of ABNF248.

-ABNF1711 changes the syntax of the MEGACO constructs.

ABNF1711: RequestedActions = LBRKT RequestedAction [ "E" EQUAL SecondEventsDescriptor ] [ "SG" EQUAL SignalsDescriptor ] [ "IC" ] RBRKT

ABNF248: requestedActions = requestedAction LWSP [COLON LWSP embeddedSignalEvents ] [COLON LWSP InterceptToken ] embeddedSignalEvents = firstEmbedding [COMMA firstEmbedding]

as you can see the first level of embedding (firstEmbedding) is chopped in ABNF1711. As a matter of fact, it changes the syntax into something different.

-ABNF1711 enforces ordering of descriptors and parameters while the ABNF248 does not. This issue was raised before and the resolution was made to enforce no order since there is no relationship between descriptors, e.g., modems or muxes, whichever comes first does not affect the other.

- ABNF248 uses COMMA as a separator for commands, descriptors and parameters. This concept is gone in ABNF1711.

- ABNF1711 changes the syntax and the semantics of MEGACO, e.g., ABNF1711: NotifyReply = LBRKT TerminationID [ "ER" EQUAL ErrorDescriptor ] RBRKT You always have TerminationID regardless of whether it is NotifyReply error or not, and ErrorDescriptor is tagged.

ABNF248 notifyReply = NotifyToken ( commandError | [EQUAL TerminationID]) commandError = EQUAL TerminationID LBRKT errorDescriptor RBRKT TerminationID is optional in pure notify reply and mandatory in notify error. ErrorDescriptor is not tagged.

Also, ABNF1711: SecurityParmIndex = ( 1( BASE64 ) BASE64END ) SequenceNum = ( 1( BASE64 ) BASE64END ) AuthData = ( 5( BASE64 ) BASE64END ) BASE64 = 4( BASE64CHAR ) BASE64END = 4( BASE64CHAR ) / ( 3( BASE64CHAR ) "?" ) / ( 2( BASE64CHAR ) "??" ) Where did "?" and "??" come from ?

ABNF248: SecurityParmIndex = 8(HEXDIG) SequenceNum = 8(HEXDIG) AuthData = 32*64(HEXDIG)

These are some of the differences. If we review each PR, no PR in ABNF1711

will be saved. So I will stop here.

I dont know if the kind of constraints ABNF1711 enforces on the ABNF are due to to the ASN.1 encoding constraints or because of ASN.12ABNF. Whatever the reasoning is, APC1711 should focus on completing the ASN.1 description and generate similar testbenches as in the MEGACO I-D either binary or text, or both. The binary will be definitely different than the text because of tagging, however the text should be same as the test benches written so far. In theory, bin and text should reflect the same protocol and should introduce the least entropy into the syntax.

My recommendation is that rather than writing ASN.12ABNF tool, APC1711 should write examples that use the ASN.1 and bin2text and text2bin tools in order to test the ASN.1 encoding. Once that is out of the way and we know that the ASN.1 is ok, we could look into tools like ASN.12ABNF presuming that it would generate ABNF that is equivalent to ABNF248 syntactical and semantical wise. Otherwise, ABNF1711 approach is unproductive and waste of effort trying to verify every PR of ABNF1711.

In addition to that, if we assume that the ASN.1 is ok and the ASN.12ABNF is ok, from what I saw both are not, is there any guarantee that when they change the ASN.1, that will not introduce problems into the ABNF ? My feeling is that it would be a source of confusion and we would need to review the ABNF and

probably hand craft some PRs to make it consistent and ambiguous free. If that is that is the case, why should we throw out ABNF248 which we have tested and have a high degree of confidence in. We are very familiar with ABNF248; we know the ins and outs of it; and we know how to fix any problem without disturbing the rest of the grammar. How would ABNF1711 do that ?

As for ASN.1, it is not compatible with the standard. This means that ASN.1 compilers can not produce a correct code.

regards Abdallah Rayhan