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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Oct 2008 17:05:06 +0100

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: <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 24, 2008 5:00 PM
Subject: I-D Action:draft-farrel-rtg-common-bnf-06.txt

>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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Tue, 28 Oct 2008 17:50:14 +0100

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: [email-masked] [mailto:[email-masked]] 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.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Oct 2008 18:11:41 -0000

Julien,

Thanks for reading.

> Here are a few comments on your ID.

I can add a ToC.
One is not required in an I-D of this length, but if it would be helpful...

Operators is 2.2 so that section 2.2.1. does not need to be 2.1.5.1 :-)

adjective
1. equal in value, measure, force, effect, significance, etc.

I shall use "is set equal to"

I can do that.

Sorry, I will try to use less complete sentences in future documents that I 
write.

Hmmm. I'm not sure what you are saying.

> - or "[  ( <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ) ... ]"

Nearly all examples are taken from existing documents. I will add the 
reference to RFC 3473 so that people don't think this is *my* mistake.

> lesson to understand why you prefered it to "clearer".

In general, monosylabic adjectives use -er for comparatives, while 
polysylabic adjectives use "more."
However, sometimes, for stress or the feel of the sentence, one uses "more".

You're right that RECOMMENDED has the same level as SHOULD.

I'll make the text in both say that

"explicit grouping [...] or an intermediary MUST be used"

I agree that this would tempt people to the wrong thing.
Turns out there are no real examples of this misue that I can find, so I 
think I will not try to make the examples comprehensive, and rely on the 
rules.

OK

Thanks,
Adrian

---

From: <[email-masked]>
Date: Wed, 29 Oct 2008 10:43:11 +0100

Hello Adrian.

I snipped to remaining issues only and prefixed my comments with "[JM]".

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 

<snip>

I can add a ToC.

[JM] Coming from you, that kind of reason is rather weird... but you're the author. ;-)

<snip>

[JM] Sounds great! :-)  (Note that the exception I mentioned only applied among the "Encoding" sections, not the whole of the document.)

[JM] Sorry if my writing was confusing. I was refering to the last note of 2.2.5. Let me try to rephrase.
You're defining the operator "...". It applies to an object or a construct, but I first wondered on what set/domain (that word again?!) the function was defined. Indeed, the early specification doesn't state if this operator/function is defined for the empty construct or not. A piece of answer if provided in the last example: "[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ..." reveals that "..." can be applied to an empty construct as the optional part, marked by the square braquets, could be equal to the empty set.
Am I more clear now?

<snip>

Best regards,

Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Oct 2008 15:35:55 -0000

> You're defining the operator "...". It applies to an object or a 
> construct,
> but I first wondered on what set/domain (that word again?!) the function
> was defined. Indeed, the early specification doesn't state if this
> operator/function is defined for the empty construct or not. A piece of
> answer if provided in the last example:
> "[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK> ] ..."
> reveals that "..." can be applied to an empty construct as the optional
> part, marked by the square braquets, could be equal to the empty set.
>
> Am I more clear now?

OK.
I see what you are saying.

In fact, "..." does not apply to an empty construct. It applies to a 
construct that might be empty, but it is the construct that is repeatable, 
not the emptiness :-)

What comes out of this is that it would be helpful to describe exactly what 
"..." operates on.

I'll add that.

Cheers,
Adrian