Re: [mpls] A BNF specification for RSVP-TE

[<julien.meuric at orange-ftgroup.com>]

Hi Adrian.

Here are a few comments on your ID.

**********
There is no ToC. Adding one might help to understand why the "Operators"
section is numbered 2.2 and not 2.1.5 (I'm a bit lost here).
**********
Section 2.2.1: you define the assigment operator by saying both sides
are "equivalent". I feel this very notion of "equivalence" is not
specified enough in our context of grammar definition and the operation
described is "stronger" than a usual equivalence noted "~". However, as
a non native, I know my interpretation is biased. Wouldn't a definition
relying on terms such as "synonymous", "equal", "identical",
"substituable"... (sure you'll find better words than me) make it
sharper?
**********
Section 2.2.3: nesting appears only as an example. I would find it more
consistent if the sentence "The optional operator can be nested" were
moved into the paragraph "Meaning".
**********
Section 2.2.4: the encoding is defined by a full sentence (including
subject, verb...), thus creating an exception in the form of the
document. (Would I have raised this if the author was different? ;-) )
**********
Section 2.2.5: my 1st reaction when reading the example is what you say
right after about grouping using round braquets instead of square ones.
The direct consequence of your example is that the operator "..." is
also defined for nil, which was not obvious before.

Second reaction: why those outer square brackets? Grouping could have
been used (even if useless), but why this double level of optionality? I
find it rather confusing and would have prefered:
- either "[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ..."
- or "[  ( <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ) ... ]"

Side question: I'm sure you're correct on "more clear" at the end of the
section, but your humble servant definitely requires an English grammar
lesson to understand why you prefered it to "clearer".
**********
Section 2.2.6, note 1: "grouping [...] is RECOMMENDED as a solution for
multi-alternates" while section 2.2.4 says about multi-alternates:
"explicit grouping [...] or an intermediary MUST be used". OPTIONAL can
be considered, but I'd favor MANDATORY; anyway consistency MUST be
achieved whithin the ID.
**********
Section 2.4: to depict the possible misinterpretation due to line
breaks, you'd better add an example such as:
<flow descriptor list> ::=  <empty> | <flow descriptor list>
                            <flow descriptor>
where the reader is really tempted by formulation "b" because of the
line break, while precedence leaves only "a" as an option.
**********
Section 5: I'd have swapped "defective" and "incompatible" in the last
paragraph since security attacks applies to the (former) former, not to
the (former) latter.
**********

Cheers,

Julien


-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of
Adrian Farrel

Hi,

This draft provides a specification of the BNF we already use in RSVP-TE
and 
makes it available for use in future RSVP-TE extensions.

I intend asking that this draft progress in the standards process
relatively 
soon.

Please review and comment as soon as possible.

Thanks,
Adrian
----- Original Message ----- 
From: <Internet-Drafts at ietf.org>

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
> Title           : Reduced Backus-Naur Form (RBNF) A Syntax Used in
Various 
> Protocol Specifications
> Author(s)       : A. Farrel
> Filename        : draft-farrel-rtg-common-bnf-06.txt
> Pages           : 12
> Date            : 2008-10-24
>
> Several protocols have been specified using a common variant of the
> Backus-Naur Form (BNF) of representing message syntax. However, there
> is no formal definition of this version of BNF.
>
> There is value in using the same variant of BNF for the set of
> protocols that are commonly used together. This reduces confusion and
> simplifies implementation.
>
> Updating existing documents to use some other variant of BNF that is
> already formally documented would be a substantial piece of work.
>
> This document provides a formal definition of the variant of BNF that
> has been used (that we call Reduced BNF), and makes it available for
> use by new protocols.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-06.txt

_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls