APC-1711, 1712 review

Pete Cordell pete at TECH-KNOW-WARE.COM
Sun Oct 17 05:30:48 EDT 1999

I've attached a few comments below to clarify some of the issues raised by Abdallah...

Pete Cordell
pete at tech-know-ware.com

    -----Original Message-----
    From: Abdallah Rayhan <arayhan at NORTELNETWORKS.COM>
    Date: 14 October 1999 16:05
    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. 
    Just to reassure you, the level of ASN.1 understanding required to work with the definition in 1711 is fairly easy to acquire.  I would say slightly easier then ABNF, but then we're talking about fairly straight forward things in both cases so the differences are not really significant.  I've attempted to put a bit of a tutorial about ASN.1 in APC-1712.  I'm happy to expand this if it is felt to be desirable (I didn't want to go too far straight away in case the editors jumped on me!).  In short, if you know C, SEQUENCE == struct, CHOICE == union (except type in union is also stored), and each parameter is "name type" rather than "type name".  Each parameter can also be optional, in which case OPTIONAL appears at the end, and/or can appear multiple times, in which case the format is "name SEQUENCE OF type".  Knowing that you should be able to pick up the rest by looking at 1711.  (I for one learnt ASN.1 just by looking at examples of it.) 
    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. 
    PkgdName = LBRKT  PkgItemID [ PkgName ]  RBRKT 
    PkgName = LBRKT  "/"  ( ( "PE" EQUAL Name )  / "*" ) RBRKT 
    PkgItemID = ( ( "PI" EQUAL Name )  /   "*"  ) 

    This is one construct the ASN.1 definition has a lot of trouble with.  One proposal is just to make this an IA5String (in ASN.1 speak).  It can then be coded in the same way as ABNF1711.

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

    A similar comment applies to this also, i.e. making IA5String removes the problem.

    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. 

    The IA5String would also remove the need for the curly-wurlies around this.

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

    Right, extensions to the ASN.1 are implicit.  By that I mean that, every SEQUENCE and CHOICE can be extended.  That's way there are a few more braces and there are restrictions on what is untagged.  The encoding rules philosophy is that it should be possible to skip any parameter, and then re-start parsing the next parameter without losing parameters, and without interpreting tags as values and so on.

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

    I think I know what your referring to here, but I can't find it now that I look for it.  But basically, the order of tagged parameters after the last untagged parameter is not important.  It's a limitation of my ABNF skills that prevented me from being able to express both the multiplicity (if that's the right word for how many times a thing appears) and also say that it could appear in any order.

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

    John has put the wrong modifier type for this OCTET STRING.  It should be HEX OCTET STRING, which would result in the use of the two hex values per octet representation.  

    I don't think base64 is used in megaco, but the reason for changing the base64 padding character is using = is ambiguous.  It's not clear in the case when parsing parameters that have been added after the definition that the parser knows about whether the = are separating a tag from a value, or part of the value.  A simple way to resolve this is to change the padding character.  I think this is been done in some other protocol (can't remember which) and it's not difficult to do.  Even if you have a black box base64 encoder you can always fix it up later by doing if( last-char == '=' ) last-char = '?' and same for the next to last.

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

    If the correct modifier is used as described above, the revised form of this becomes 

    SP = 4 OCTET

    SN = 4 OCTET

    AD = 16*32( OCTET )


    These are some of the differences. If we review each PR, no PR in ABNF1711 
    will be saved. So I will stop here. 

    I don't 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. 

    I agree with you that at the moment we have a serious issue that megaco might become two protocols; one binary, one text.  I can also see that they may well diverge if we are not careful.  We probably differ on the best way to prevent that though :).

    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. 

    I'm not sure how you see the bin2text and text2bin working.  Perhaps you could explain this further.  

    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 ? 

    One reason the ASN.1 definition is having a tough time matching the ABNF is because its fundamental to the way it works to be consistent and avoid ambiguity.  By defining how parameters are encoded in a consistent way, and ensuring that that encoding allows them to be readily skipped when they are not understood means there's less (hopefully no) chance that you end up with something that's ambiguous, especially when a v1 implementation parses a v2 message etc. Fortunately, ABNF248 is already pretty consistent which is way its not an impossible task for the ASN.1.

    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 

    My over all feeling is that a lot of effort has been put in to the ASN.1 close to the ABNF.  I'll admit it doesn't result in exactly the same ABNF as 248, but I hope that we can still be part of the consensus forming process that defines the ABNF if the functionality is not changed.  Or put another way, I hope we are not precluded from being able to suggest changes to the ABNF because we are also trying to describe it in ASN.1.  I'm also aware that this approach was adopted to get us out of the text vs. binary black hole.  If this initiative fails then we are back to that, something that I would expect that none of us would want to go back to.  So let's work together and try and sort this out once and for all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19991017/85c30ffe/attachment-0001.htm>

More information about the sg16-avd mailing list