Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications
RFC 5511

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

Comment (2009-03-12)
No email
send info
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' **)
No email
send info
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.)

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection