FW: APC-1711, 1712 review
ngreene at NORTELNETWORKS.COM
Fri Oct 15 09:11:14 EDT 1999
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 M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene at nortelnetworks.com
> From: Rayhan, Abdallah [CAR:5N00:EXCH]
> Sent: Thursday, October 14, 1999 11:01 AM
> To: megaco at 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
> 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
> 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
> 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
> 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
> the different PRs but then found myself marking almost every one.)
> - Tagging every value.
> PkgdName = LBRKT PkgItemID [ PkgName ] RBRKT
> PkgName = LBRKT "/" ( ( "PE" EQUAL Name ) / "*" ) RBRKT
> PkgItemID = ( ( "PI" EQUAL Name ) / "*" )
> 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.
> RequestedActions = LBRKT RequestedAction [ "E" EQUAL
> SecondEventsDescriptor ]
> [ "SG" EQUAL SignalsDescriptor ] [ "IC" ] RBRKT
> 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
> As a matter of fact, it changes the syntax into something different.
> -ABNF1711 enforces ordering of descriptors and parameters while the
> 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.,
> NotifyReply = LBRKT TerminationID [ "ER" EQUAL ErrorDescriptor ] RBRKT
> You always have TerminationID regardless of whether it is NotifyReply
> error or not,
> and ErrorDescriptor is tagged.
> notifyReply = NotifyToken ( commandError | [EQUAL TerminationID])
> commandError = EQUAL TerminationID LBRKT errorDescriptor RBRKT
> TerminationID is optional in pure notify reply and mandatory in notify
> 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 ?
> 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
> 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
> that is equivalent to ABNF248 syntactical and semantical wise. Otherwise,
> approach is unproductive and waste of effort trying to verify every PR of
> In addition to that, if we assume that the ASN.1 is ok and the ASN.12ABNF
> ok, from what I saw both are not, is there any guarantee that when they
> the ASN.1, that will not introduce problems into the ABNF ? My feeling is
> 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
> with ABNF248; we know the ins and outs of it; and we know how to fix any
> 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.
> Abdallah Rayhan
More information about the sg16-avd