Subject: A follow-up note on RBNF

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Nov 2008 20:16:57 -0000

Hi,

Immediately after I had spoken in the meeting, Dimitri asked me whether the 
I-D covers the BNF used in RFC 4875 (RSVP-TE for P2MP LSP).

The answer is yes. I have checked the BNF used in the RFC and it is covered 
by the syntax described in my I-D.

I do not, however, propose to include a reference to every existing RFC 
covered by this RBNF definition. But I do reference:
- the base protocol specs (e.g., 2205, 3209, 3473, 4204...)
- any specs from which I have taken examples.
I think that listing all existing RFCs covered would be of no particular 
help.

To take Eric's point a little further, we already have in the proto-shepherd 
write-up template...

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

This is the section that causes the Discusses to get raised. I have normally 
answered "No, but I have checked them manually" with the response "Against 
what did you check it?" from the IESG. I have not succeeded in saying 
"Against the BNF used in RFC 2205."

I agree that making this an RFC will create a reference that could be 
included as a normative reference, or could be not referenced at all. 
Authors choosing to not reference, would have to find their own way to 
persuade the IESG that shepherd had done the correct job.

Cheers,
Adrian

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: Eric Rosen <[email-masked]>
Date: Mon, 24 Nov 2008 10:42:57 -0500

Adrian> we already have in the proto-shepherd 
Adrian> write-up template...

Adrian> This is the section that causes the Discusses to get raised. I have
Adrian> normally answered "No, but I have checked them manually" with the
Adrian> response "Against what did you check it?" from the IESG. I have not
Adrian> succeeded in saying "Against the BNF used in RFC 2205."

But the  phrase "validate correctly in  an automated checker"  is not really
well-defined;  one  could  write   an  "automated  checker"  that  validates
everything and then answer yes to that question.

Alternatively, perhaps  you should  ask the  IESG to point  you to  the IETF
standard  specification of  BNF,  along with  the IETF-supported  validation
tool.  If  there are no  such things, it  doesn't really make much  sense to
require automated checking.

Whatever one might think  about the need for such a spec  and tool, it seems
to  me  that  the  production  of  this  specification  and  tool  (and  the
maintenance of the tool) is not  something that the routing area should take
up, as it doesn't seem to have anything to do with routing.

If the  IESG is saying that  in the absence of  any such spec  and tool, BNF
cannot  appear in any  RFC, probably  the best  thing to  do is  use english
instead.
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Nov 2008 22:02:38 -0000

Hi Eric,

> everything and then answer yes to that question.

Agreed.
But I guess the intent is obvious, and I have seen BNF errors escape both 
CCAMP and MPLS working groups and only get caught around IETF last call.

> require automated checking.

Eeek.
These things do exist.
Problem is, RSVP et al. do not comply with the standard.

> up, as it doesn't seem to have anything to do with routing.

Spec is already done now, so Routing Area has nothing further to do.

I agree about tools. I have no intention of building such a tool, although 
if one existed and was easy to use and freely available, I would check that 
my I-Ds parse correctly.

> cannot  appear in any  RFC, probably  the best  thing to do is use english

Agreed.
But I think they will let us go with the spec and without the tool.
So I hope that by turning this I-D into an RFC...
- the Routing Area will be entirely unimpacted except that a new
  reference is added to I-Ds that use this form of BNF
- I-Ds will get a smoother path to being RFCs
- no-one else has to do any additional work

Cheers,
Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 25 Nov 2008 01:31:17 +0100

adrian:

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Adrian Farrel
> Sent: Monday, November 24, 2008 11:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: A follow-up note on RBNF 
> 
> Hi Eric,
> 
> > But the  phrase "validate correctly in  an automated 
> checker"  is not 
> > really
> > Alternatively, perhaps  you should  ask the  IESG to point  
> you to  the 
> > IETF
> > tool.  If  there are no  such things, it  doesn't really 
> make much  sense 
> > to
> > Whatever one might think  about the need for such a spec  
> and tool, it 
> > seems
> > to  me  that  the  production  of  this  specification  and 
>  tool  (and 
> > the
> > maintenance of the tool) is not  something that the routing 
> area should 
> > take
> > If the  IESG is saying that  in the absence of  any such 
> spec and tool, 
> > BNF

if it improves the situation - even if formal validation tool is not
made available - 

AND 

it does not result in any backward compatibility issue

the question boils down to: are we making a style exercise or
documenting a description language to increase readability ?

note: we could even trial it on a given rtg area WG before mandating
full rtg area compliance.

-d.

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 24 Nov 2008 19:54:48 -0500

> full rtg area compliance.

The assumption that it would eventually become mandatory is a  
demonstration of the slippery slope Eric was talking about -- as I  
recall Adrian posited that RBNF would be opt-in, Eric riposted that  
RFC 2119 is also opt-in... except that for practical purposes it's  
mandatory.

--John

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Nov 2008 08:55:47 -0000

My contention is that we are already at the bottom of the slippery slope and 
we never knew it!  RBNF is a ladder to help us climb out.

There is already a "standard" specification for BNF in the IETF:

   [RFC5234] Crocker, D. (Ed.) and Overell, P., "Augmented BNF for
   Syntax Specifications: ABNF", STD 68, RFC 5234, January

Routing Area RFCs do not conform. Therefore new Routing Area I-Ds also do 
not conform.

But worse, there is already an IESG "expectation" that all BNF used in RFCs 
"conforms to some specification."

So, moving forward you have a choice:
- Don't use any BNF
   (we seem to find it useful)
- Use ABNF
   (that would make new I-Ds incompatible with old RFCs)
- Write drafts as normal with a reference to RBNF
   (I-Ds remain consistent with existing RFCs)
- Write drafts as normal without a reference to RBNF
   (I-Ds remain consistent with existing RFCs, but you
    have to negotiate with the IESG).

Dimitri raises the issue he raised in the meeting. That seems some sort of 
fear that the specification of RBNF would have an impact on the RFCs already 
published. Well, it doesn't. And it couldn't since they don't reference the 
specification. And anyway, the whole purpose is to produce a specification 
for the BNF that has already been used (read the draft!).

I am not sure I understand why we are having this discussion. The RBNF draft 
gives you the option to carry on writing I-Ds as you did before without any 
extra effort and no need to attempt to comply with anything. All you have to 
do to avoid painful Discusses is add a reference. Why does this cause you 
heartache? Especially as you continue to have the option to leave out the 
reference and experience life exactly as it is today.

Maybe we should see more comments from people who author or shepherd 
documents containing BNF?

Adrian

----- Original Message ----- 
From: "John G. Scudder" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, November 25, 2008 12:54 AM
Subject: Re: A follow-up note on RBNF

> demonstration of the slippery slope Eric was talking about -- as I  recall 
> Adrian posited that RBNF would be opt-in, Eric riposted that  RFC 2119 is 
> also opt-in... except that for practical purposes it's  mandatory.
>
> --John

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 25 Nov 2008 11:36:42 +0100

adrian:

> fear that the specification of RBNF would have an impact on 
> the RFCs already published. Well, it doesn't. 

I asked if any inconsistency has been found against RBNF(*) because if
some would exist, new I-Ds using RBNF would be incompatible with old
RFCs. The answer is: NO. Fine.

-> Question left is: can we simply agree to make this doc an RFC so as
have at least one mean to address the IESG expectation that all BNF used
in RFCs "conforms to some specification." 

-d.

(*) i didn't perform a full re-check (even if I read the draft).
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Tuesday, November 25, 2008 9:56 AM
> To: John G. Scudder; PAPADIMITRIOU Dimitri
> Cc: [email-masked]; [email-masked]