Subject: Last Call: draft-farrel-rtg-common-bnf

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 6 Jan 2009 14:46:04 -0600

Adrian,

With regards to the BNF draft,
  it's easy to read and clear.

I'd suggest the following mods to section 2.4 on Precedence

Note:
     Precedence is the main opportunity for confusion in the use of this BNF.
     Authors are strongly RECOMMENDED to use grouping (Section 2.2.6) to prevent cases where an understanding of the preference rules is necessary to the reader.  Automated readers are REQUIRED to parce rules correctly with or without this extra grouping.

Also, in section 2.2.4. Alternatives,

the required example showing 
   <construct> ::= ( <ALT_ONE> | <ALT_TWO> ) | <ALT_THREE>

        or

          <intermediary construct> ::= <ALT_TWO> | <ALT_THREE>
          <construct> ::= <ALT_ONE> | <intermediary construct>

seems more complicated than the disallowed original

   <construct> ::= <ALT_ONE> | <ALT_TWO> | <ALT_THREE>

I'd vote for requiring the parcer to handle them all,
  but I feel like the disallowed one should be the preferred version.
    (This is different from the precedence grouping above
        because they are all the same precedence.)
    (Perhaps you are trying to make the parcer simpler at the expense of the human reader?)

Regards,

Stuart Venters

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Tuesday, January 06, 2009 2:00 PM
To: [email-masked]
Subject: routing-discussion Digest, Vol 39, Issue 1

Send routing-discussion mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/routing-discussion
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of routing-discussion digest..."

Today's Topics:

   1. FW: Last Call: draft-farrel-rtg-common-bnf (Reduced
      Backus-Naur Form	(RBNF) A Syntax Used in Various Protocol
      Specifications) to	Proposed Standard  (Ross Callon)

----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Jan 2009 14:04:18 -0500
From: Ross Callon <[email-masked]>
Subject: FW: Last Call: draft-farrel-rtg-common-bnf (Reduced
	Backus-Naur Form	(RBNF) A Syntax Used in Various Protocol
	Specifications) to	Proposed Standard 
To: <[email-masked]>, <[email-masked]>, <[email-masked]>,
	<[email-masked]>, <[email-masked]>
Cc: Ross Callon <[email-masked]>, David Ward <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

FYI.  This may be of interest to the CCAMP, MPLS, PCE and TSVWG WGs.

thanks, Ross

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of The IESG
Sent: 06 January 2009 13:56
To: IETF-Announce
Subject: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur
Form (RBNF) A Syntax Used in Various Protocol Specifications) to
Proposed Standard 

The IESG has received a request from an individual submitter to consider
the following document:

- 'Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol 
   Specifications '
   <draft-farrel-rtg-common-bnf-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-02-03. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
17681&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

------------------------------

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

End of routing-discussion Digest, Vol 39, Issue 1
*************************************************
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Jan 2009 23:14:43 -0000

Hi Stuart,

Thanks for reading.

>  it's easy to read and clear.

Thanks!

>     Authors are strongly RECOMMENDED to use grouping (Section 2.2.6)
>     to prevent cases where an understanding of the preference rules is
>     necessary to the reader.  Automated readers are REQUIRED to
>     parce rules correctly with or without this extra grouping.

This is reasonable.
I will work it into the existing text to make the first para of 2.4 read...

   Precedence is the main opportunity for confusion in the use of this
   BNF. Although precedence can be deduced from a "proper" reading of
   the BNF using the rules defined above and the precedence ordering
   shown below, authors are strongly RECOMMENDED to use grouping
   (Section 2.2.6) and ordering (Section 2.3.3) to avoid cases where the
   reader would otherwise be required to understand the precedence rules.

>    (Perhaps you are trying to make the parcer simpler at the expense of 

In fact, it was the more complicated cases that I was trying to avoid.
For example,

<a> ::= <b> <c> | <d> <e> | <f> <g>

is highly ambiguous.

We have some example cases...

           <flow descriptor list> ::=  <empty> |
                            <flow descriptor list> <flow descriptor>

where implicit grouping is used.

In fact, I can see that my rule is too strict.
As you point out
a ::= <b> | <c> | <d>
is not ambiguous.

Should I replace note 2 in Section 2.2.4 with...

     2. Multiple members of alternate sets can give rise to confusion.
        For example,

           <flow descriptor list> ::=  <empty> |
                                <flow descriptor list> <flow descriptor>

        could be read to mean that an instance of <flow descriptor> must
        be present or that it is optional.

        To avoid this type of issue, explicit grouping (see Section
        2.2.6), or an intermediary MUST be used. Thus:

          <construct> ::= <ALT_A> <ALT_B> | <ALT_C> <ALT_D>

        is not allowed and MUST be presented using grouping or using an
        intermediary construct. For example, and depending on intended
        meaning:

          <construct> ::= ( <ALT_A> <ALT_B> ) | ( <ALT_C> <ALT_D> )

          or

          <construct> ::= <ALT_A> ( <ALT_B> | <ALT_C> ) <ALT_D>

        or

          <intermediary X> ::= <ALT_A> <ALT_B>
          <intermediary Y> ::= <ALT_C> <ALT_D>
          <construct> ::= <intermediary X> | <intermediary Y>

          or

          <intermediary Z> ::= <ALT_B> | <ALT_C>
          <construct> ::= <ALT_A> <intermediary Z> <ALT_D>

Thanks,
Adrian