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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf