Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications
Note: This ballot was opened for revision 09 and is now closed.
(Ron Bonica) Yes
(Ross Callon) Yes
(Lars Eggert) Yes
(David Ward) Yes
Magnus Westerlund (was No Objection, Discuss) Yes
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.
(Jari Arkko) No Objection
(Lisa Dusseault) No Objection
(Pasi Eronen) No Objection
Comment (2009-03-05 for -** No value found for 'p.get_dochistory.rev' **)
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.)