Magnus is right that the reference to 4234 should not be included in this
document. It will be removed.
The text in section 2 should apply. Viz.
The message formats in this document are specified using Backus Naur
Format (BNF) encoding. The BNF used is very simple and is modeled on
that used in the Resource Reservation Protocol (RSVP) [RFC2205], the
Traffic Engineering extensions to RSVP (RSVP-TE) [RFC3209], and the
Generalized Multiprotocol Label Switching (GMPLS) extensions to
RSVP-TE [RFC3473].
I understand that the position we are in is not perfect. There are many RFCs
and I-Ds in progress that use the same variant of BNF yet that variant is
not documented anywhere and no tools exist to check it.
We could criticise the IESG going back ten years for this situation, but I
don't think that would be of any value at all.
It is clear that we will not reform the use of BNF in the RSVP documents in
order to make it conform to any of the published BNF variants. It is also
clear to the PCE working group that it is correct to use the identical form
of BNF in PCEP as is used in RSVP.
On June 13, Ross wrote to Chris...
> Apparently draft-ietf-pce-pcep uses the same formal definition language as
> RFC 2205 (the original RSVP specification from 1997) and all subsequent
> RSVP related specifications. This has
> therefore become the standard formal language for related protocol specs.
> It is pretty clear that there is a significant
> advantage to use the same formal definition language that implementers in
> this technology area are used to.
> However, we haven't found any document which defines this formal language
> that we have been using for years.
> This leads to two questions:
>
>- First of all, for the purpose of your discuss, it would seem that
> the best reference would be RFC2205 itself. Thus the text to add to
> draft-ietf-pce-pcep would be something like:
>
> This document uses the same formal definition language as
> was used in RFC2205 and other subsequent RSVP-related
> protocols.
> Is this okay to clear your discuss?
>- Secondly, we are asking whether anyone would like to write a
> formal specification of this language. Can you suggest a volunteer,
> or would you like to do this?
I see in my email folder a follow-up from Ross to Chris on this topic on
June 24th. But I don't have any replies.
Can we please not bat this one around any more? The choice is simple between
the following three options:
1. Allow the I-D to go forward with just the fix to the
4234 reference
2. Allow the I-D to go forward as per option 1 with the
commitment to write an I-D defining the BNF variant.
This option cannot stand unless a volunteer author is
found.
3. Require that the I-D is held up until an I-D is written
defining the BNF variant. This option cannot stand
unless a volunteer author is found.
Thanks,
Adrian
----- Original Message -----
From: "Magnus Westerlund" <[EMAIL PROTECTED]>
To: "Chris Newman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, September 02, 2008 10:43 AM
Subject: Re: COMMENT: draft-ietf-pce-pcep
Chris Newman skrev:
> Comment:
> Referencing other documents that use BNF without a reference to the
> original definition of BNF is probably a worse solution than no
> reference. I think it would be better to reference a real definition
> of the language, such as one of the older references here:
>
> http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form
>
> However, the change makes it clear the authors want to use a formal
> language without definition so it's not worth my time to argue the
> point further.
>
> My previous DISCUSS:
>
> This document uses a formal language (BNF) without providing a reference
> to a document that defines that formal language. Please provide a
> reference.
>
>
Hi Chris,
This was a discuss that I am supporting and I do hope that you wouldn't
drop it. The IESG has for many years been clear on that when it comes to
formal syntax we do require a normative definition of it.
http://www.ietf.org/IESG/STATEMENTS/syntax-format-def.txt
http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt
Especially now that the latest version contains a reference to RFC 4234
(should be updated to 5234) and then uses definitions that doesn't
follow that syntax. Which from my perspective is a discuss in itself.
So, I would suggest that you put that discuss or let me inherit it.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED]
----------------------------------------------------------------------
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
