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

["Adrian Farrel" <adrian at olddog.co.uk>]

Julien,

Thanks for reading.

> 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).

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 :-)

> **********
> 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?

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

I shall use "is set equal to"

> **********
> 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".

I can do that.

> **********
> 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? ;-) )

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

> **********
> 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.

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

> 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> ) ... ]"

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.

> 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".

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".

> **********
> 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.

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"

> **********
> 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.

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.

> **********
> 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.

OK

Thanks,
Adrian 

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