Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications
draft-farrel-rtg-common-bnf-09

[Ballot comment]
Section 2.2.2:

Meaning:
    The objects or constructs MUST be present in the order specified.

This has an implicit assumption about reading left to right and upper line to lower line. Maybe one should be clearer on this.

Section 2.2.5:
Note 2:

I think you should include paranthesis around the second alternative to make the recursive statement clear. Seems to be breaking the recommendation from earlier.

[Ballot discuss]
Section 2.2.5:

It is not clear that the repetition operator is postfix. Can you please make an explicit statement about that.

Section 2.4:


    Concatenation has higher precedence than the Alternative operator.
    Thus, the text in [RFC2205] SHOULD be interpretted as shown in
    formulation a.

    Similarly (from the same section of [RFC2205])

            ::=
                                |
                           

    SHOULD be interpretted as

            ::=
                        (  ) |
                        (  )


The spec is fuzzily written here. It is clear from the definition which interpretation that is the correct one. Thus using SHOULD here is very confusing. If one has one correct interpretation then that needs to be used. So please change SHOULD to SHALL.

[Ballot comment]
I think it would be useful to mention somewhere in Section 1 the
biggest difference to ABNF: in ABNF (as defined in RFC 5234) the
terminals are integers (characters/bytes), while in RBNF they're
"objects" (some kind of message elements, but not individual bytes
or characters).

Thus, the two are not really interchangeable -- and it's not clear
that talking about e.g. converting existing specs to use ABNF even
makes sense (if the spec assumes that terminals are message elements,
then RFC5234 ABNF just won't work).

(Of course, it would be possible to specify RFC5234-like BNF notation
that allowed other kinds of terminals than integers, but that would
not be RFC5234 any more.)