ietf
[Top] [All Lists]

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

2009-02-05 14:04:03


--On Thursday, February 05, 2009 5:14 PM +0000 Adrian Farrel
<adrian(_at_)olddog(_dot_)co(_dot_)uk> wrote:

John,

Good of you to write. It has been a while since I received an
email from you.

Having spent several years working with formal and semi-formal
definitions of programming language and being fairly
unsatisfied with IETF trends in the area, I had hoped to
avoid looking at this spec.  No such luck, obviously.

Well, who knows who constrains you to certain acts? :-)

I have been trying for several years to narrow the number of
things I try to worry about in the IETF so as to concentrate
efforts on those for which I have time.  My own choice, clearly.

I presume this is not what you intended, but you have just
made a powerful argument for:

Why make that presumption?
It is pretty much explicit in the draft.

I was trying to suggest that, despite the draft's, and Last
Call, presumably of Proposed Standard, it might be more
appropriate to publish this as Informational, defining "RBNF"
for the context of a list of specific specifications and their
derivatives.  That doesn't require standards-track unless we do
want to recommend it.

(1) Adding a clear statement to this that says, approximately,
"this is intended to document a BNF variant that was used in
some protocols instead of ABNF, for reasons that seemed
appropriate at the time.

Yes, this form of BNF was used.

I know.

I am not sure that it was instead of ABNF since it seems to
pre-date the completion of that work.
Who knows whether the reasons seemed appropriate at the time?
And who cares?

ABNF has been around, and actively used in the IETF, for a very
long time.  During most of that time, specifications that used
it simply references 822, which contains a plausible definition.
The only thing that changed with the publication of RFC 2234 in
1997 were that the specification expanded a bit and got a little
better defined and the appropriate reference changed from 822 to
2234/4234/5234/STD68.  I think it is worth caring about because
it sets a context for this different form: unlike protocol
standards, there is little reason for the IETF to support or
permit multiple metalanguage standards unless one can be clearly
shown to be superior for a particular situation.  You have not
made the assertion that none of those specs could have been
written with ABNF instead without loss of quality, only that
changing them over at this point would be more trouble than it
is worth (a conclusion with which I agree).

...
RBNF
is not recommended for new protocol specifications unless it
is necessary to preserve compatibility and reduce confusion
relative to existing ones.

I am neither recommending or not recommending its wider use.

And I am suggesting that, if this is going to be a
standards-track document, such a recommendation is a
requirement.  That is a special case of the requests from others
for an applicability statement.

I am recommending the positive of your statement. That is,
that RBNF should be used for new protocol specifications that
extend or are compatible with existing specifications that use
RBNF.

If you would be comfortable inserting "only" in that sentence,
we would be in agreement, both about what is needed and what
should be said.

Given several people have asked what my intention is with
regard to the use of RBNF in new documents, I feel it is
helpful to include specific statements. Currently, I have:

   RBNF as defined in this document is primarily applicable
for the
   protocols listed in the previous section. The specification
may be
   used to facilitate the interpretation of the pre-existing
RFCs that
   are referenced. It should also be used in the specification
of
   extensions to those protocols.

   RBNF could also be used for the specification of new
protocols. This
   is most appropriate for the development of new protocols
that are
   closely related to those that already use RBNF. For
example, PCEP is
   closely related to RSVP-TE and when it was developed, the
PCE working
   gorup chose to use the same form of BNF as was already used
in the
   RSVP-TE specifications.

   If a wholly new protocol is being developed and is not
related to a
   protocol that already uses RBNF, the working group should
consider
   carefully whether to use RBNF or to use a more formally
specified and
   broader form of BNF such as ABNF [RFC5234].

   The use of RBNF to specify extensions to protocols that do
not
   already use RBNF (i.e., that use some other form of BNF) is
not
   recommended.

You feel I should be clearer?

While I believe that a stronger statement would be both more
appropriate and simpler to write, I could live with the above.

(2) Publishing as Informational or direct-to-Historic.

How can it be Historic given that the protocols that use RBNF
are not Historic? I think that would be silly.

I think Informational would be more appropriate for that and
other reasons.  On the other hand, "silly" has not been a bar to
IETF decisions in recent years :-(

Should it be Informational? Well, if it only provided an
explanation of published RFCs, I'd be happy. But the flow is
as follows:
- extensions to protocol documents will often be standards
track
- extensions to existing protocols should use the same formal
  language as the base documents
- if a specification uses a formal language, the definition of
that
  language is normative
- downrefs are discouraged

And that takes us down the usual path, e.g., questions about how
one tests interoperability of a metalanguage specification?
Perhaps we should be testing meta-interoperability, but I don't
know what that is.


Hmmm. Looks like you are right about the date of 822.
Unfortunate that the RFC Editor index does not show 2234
obsoleting or updating 822.

Mutter.  It really doesn't because the metalanguage defined in
822 is correct for 822, presumably correct for documents and
reference 822 for the metalanguage, and slightly different from
the metalanguage specified by 2234/ 5234.  But maybe the
relationship is such that it should be identified as "updates"
because we have no better mechanism.

Glad you agree that we should publish a description of RBNF.

I think having these things floating around undocumented is a
big mistake.  Indeed, I believe that the specs that use what you
are called RBNF should never have been published without a clear
definition.  If is a bit too late to fix that now.
 
However, if you are documenting existing practice for
understanding and compatibility, rather than encouraging use
of this form, the use of strongly normative RFC 2119 language
directed to new uses seem inappropriate.

Well, there *will* be new uses.
It would be wrong IMHO for an extension to RSVP to vary from
the BNF used in RFC2205 whatever the history.
So, given that there will be new uses, we need to constrain
those uses to do the right thing.
2119 provides a way of laying it on thick enough that some
people might pay attention.

The way to get people to pay attention is for the IESG to make
firm decisions about requirements and publicize them.  If they
do that, then it doesn't make any difference what category this
document is published in, only that it be published.  If they
are not willing to do that, then I'm skeptical about the
attention.

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

While I am very sympathetic to this position and the
explanation made there (actually, all it says is "would
require a lot of work" which strikes me as more of an
assertion than an explanation),

I am perfectly willing to have someone disprove me by doing
the work.

Sorry.  I completely agree that it would be a lot of work (and I
have enough experience with such conversions to be able to
judge).  I am also convinced, based on the same experience, that
the odds of an error-free conversation are too low to be
tolerable.  I was merely pointing out that you had not
_explained_ the reason for not converting, merely asserted that
it would be a lot of work.  I was not disputing the assertion.

...
Just jumping in before the tirade :-)

It would have been possible to write a spec for RBNF as a
variation from ABNF. Doing so would require that I fully
understood ABNF *and* that I was certain to have caught all of
the differences. Writing a spec for RBNF as it stands was
somewhat simpler (for me).

And maybe we need to be pragmatic about this and say "some spec
for RBNF is clearly better than no spec for RBNF and this is all
that resources are going to permit".   I can live with that if
we are explicit about it.
 
<tirade>
...
While this horse has left the barn, I believe it is
irresponsible for the IETF to publish a document that uses a
metalanguage without a precise definition of that metalanguage
(either inline or by reference).

Which is largely why this document exists.
Protocol extension documents are being written, they use the
same metalanguage as the base specs. This should be documented
and be a normative reference.

As I tried to say above, we are in complete agreement on that
subject.
...

Finally, the name of this thing is misleading at best.  BNF is
_very_ minimal and this is, in no sense, "reduced" BNF.
Perhaps it is "reduced extended BNF", "reduced variant
near-subset extended BNF", or "slightly extended BNF", but
"reduced BNF it is not".

Then suggest a new and practical name.
I wanted to avoid "Routing Area BNF"
And I don't care what the BNF is called.
I would even be happy to call it "A metalanguage sometimes
used"

I'm not good at names and would prefer to leave this to others.
But I don't think we should call it "reduced" relative to
something that is smaller than it is.  And I think we would be
better off with a title that is as specific to function as
possible.

best,
    john

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>