FW: APC-1711, 1712 review

[Nancy-M Greene]

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 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
> 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
>
>