Re: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form(RBNF) A Syntax Used in Various Protocol Specifications) toProposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Tom,

A) The start of this I-D seems a little coy - 'various protocol specifications' 'several protocols' - and this is reflected in the Abstract and Introduction. Reading between the lines, this seems to have had its genesis in the 'Sub-IP Area' specification; nothing wrong with that, but the coyness seems misplaced.

Coyness is my speciality. This is a cultural thing, I fear - we can't all be brash Americans no matter how much we aspire to it ;-)

I won't finger the "Sub-IP Area". But I will note that all the RFCs concerned are in the Routing Area.

More generally, I think that this I-D cries out for an Applicability Statement. It makes brief reference to RFC5234 but contains no guidance that I can see as to when this standard should be used or when RFC5234 should be. The IETF has a history of producing multiple standards and letting the market decide but I
think that we do a better job when we give guidance.

Agreed.
I have added a brief Applicablity Statement in a new Section 1.3.
It is clear to me what the applicability is for:
- interpretation of existing protocols that use RBNF
- extensions to existing protocols that use RBNF
- new protocols that are "closely associated" to existing protocols
  that use RBNF.

It is also clear to me that RBNF is not recommended for protocols that already use some other form of BNF.

As far as I am concerned, the use of RBNF for the development of any other new protocol is a choice for the working group concerned and out of scope for me. However, I have included text that leans toward using ABNF.

B) Coyness again, in its definitions
'The basic building blocks of BNF are rules and operators'
but what is a rule?  RFC5234 eg says

"A rule is defined by the following sequence:
        name =  elements crlf"

and I think that something similar is needed here (or else make RFC5234 a
normative reference:-)

Again I am coy. I wonder if it a virtue or a vice.

I think you are a little precipitous in your judgement (I am being coy in my criticism of you ;-)

The first sentence of section 2 is (as you quote) "The basic building blocks of BNF are rules and operators."

The second sentence is
 "At its
  simplest form, a rule in the context we are defining is a protocol
  object that is traditionally defined by a bit diagram in the protocol
  specification."

So I think you are being overly enthusiastic to ask so quickly what a rule is.

I don't propose any change for this.

C) In a similar vein, to me, and perhaps to many in the IETF, it is RFC5234 or its precursors that represent the 'standard' meta-syntactic language. Some comparison of the functionality would be helpful, as an informative Appendix.
Is this a proper subset, if not, then where?

This was considered and rejected as the I-D was being written.

5234 might be the default/standard form of BNF in the IETF *now* but we are dealing in protocols that pre-date 5234. Indeed they pre-date (just) ABNF right back to 2234.

The Introduction explains why 5234 cannot be used in this case because of the cost of updating existing RFCs.

The question becomes how to work with the sentence:
  Unfortunately these specifications are not based on any specific
  formal definition of BNF and differ slightly from the definitions
  provided in other places.

My view was that it is necessary to provide a specification of RBNF for the uses identified. Such a definition should be stand-alone and does not require any comparison with any other form of BNF. Such a comparison would be a lot of work for (I believe) zero gain.

So, I don't propose to make any changes for this.

D) As s.2.4 says.

'Precedence is the main opportunity for confusion in the use of BNF.'

I think this should go further.  The underlying reason IMO is because the
concatenation mechanism, the one with no operator, takes precedence over the alternative operator, and this is counter-intuitive. RFC5234 spells this out
' Use of the alternative operator, freely mixed with concatenations,
  can be confusing.'
and, IPR permitting (I note that this was submitted pre-5378 but any revision
would not be:-), I suggest incorporating such text.

OK. Added a line on this.

Cheers,
Adrian
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]