Subject: Re: [Pce] Fwd: New Version Notification for draft-cmfg-pce-pcep-grammar-00.txt

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 16:23:00 +0200

Hi,
	I'm trying to figure out where the scope of this draft might end up.
Do you think its scope will just be limited to (a) PCEP clarifications
or will it also cover both (b) RBNF clarifications & changes?

If it's (a) & (b) then it probably makes most sense to break each into
their own documents as RBNF clarifications & changes have applicability
beyond PCE, i.e., RSVP and RSVP-TE.

Lou

PS I think you're wrong on Exclusive Rules.  For example:
- when two options are mutually exclusive
 <option-list>::=<option1>|<option2>
-  and at least one is mandatory
 <message>:= <...>
             <option-list>
             <...>

-  and both are optional
 <message>:= <...>
             [<option-list>]
             <...>

On 7/8/2013 11:58 AM, Ramon Casellas wrote:
> Dear all,
> 
> "Encouraged" by our beloved WG co-chair Julien ;-) we have submitted a
> new I-D that discusses the issues that we have recently mentioned in the
> list, concerning the implementation of a set of PCEP extensions and the
> problems we have identified (such as Errata, object ordering and naming
> issues, lack of consistency, ambiguous grammars, etc.).
> 
> Although the final objective would be to facilitate interoperability and
> to clarify the integration of independent normative documents by
> publishing an informational document, right now our main goal is to
> document the identified issues in published RFCs (and other also
> relevant drafts), and to clearly state the motivations behind this work.
> We have requested a 5 min slot to present them to the working group and
> to get feedback about WG potential interest.
> 
> Note that, although there are already some suggestions within the
> document, our intention is to include get feedback by other implementors
> and work towards an agreement about the suggested RBNF notation.
> 
> Feedback and comments welcome,
> 
> Thanks and best regards
> Ramon of behalf of authors and contributors.
> 
> 
> 
> 
> -------- Mensaje original --------
> Asunto: 	New Version Notification for draft-cmfg-pce-pcep-grammar-00.txt
> Fecha: 	Mon, 08 Jul 2013 02:36:37 -0700
> De: 	[email-masked]
> Para: 	Adrian Farrel <[email-masked]>, Oscar Gonzalez de Dios
> <[email-masked]>, Cyril Margaria <[email-masked]>, Ramon
> Casellas <[email-masked]>
> 
> 
> 
> A new version of I-D, draft-cmfg-pce-pcep-grammar-00.txt
> has been successfully submitted by Ramon Casellas and posted to the
> IETF repository.
> 
> Filename:	 draft-cmfg-pce-pcep-grammar
> Revision:	 00
> Title:		 Current issues with existing RBNF notation for PCEP messages and extensions
> Creation date:	 2013-07-08
> Group:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-cmfg-pce-pcep-grammar-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-cmfg-pce-pcep-grammar
> Htmlized:        http://tools.ietf.org/html/draft-cmfg-pce-pcep-grammar-00
> 
> 
> Abstract:
>    The PCEP protocol has been defined in [RFC5440] and later extended in
>    several RFCs.  This document aims at documenting inconsistencies when
>    implementing a set of extensions and at providing a reference,
>    complete and formal RBNF grammar for PCEP messages, including object
>    ordering and precedence rules.
> 
>                                                                                   
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 01 Aug 2013 16:44:25 +0200

Lou, all

Please see inline

> beyond PCE, i.e., RSVP and RSVP-TE.
Undecided. Talking to Adrian as the main author of the RBNF RFC, the 
idea is that if PCEP work justifies extending RBNF for convenience, 
there could be a RBNFbis

>   <option-list>::=<option1>|<option2>
ok
> -  and at least one is mandatory
[Ramon] Did you miss repetition here? <option-list>...  if yes, that 
allows option1 or option2 to be repeated more than once . If no, we want 
to allow option1 followed by option2
In other words, exclusive or is not mutually exclusive, it's a or b or a 
followed by b

>               [<option-list>]
[Ramon]

The idea is
a || b = <a> | <b> | <a><b>
<a> || <b> || <c> = <a> | <b> | <c> | <a> <b> | <a> <c> | <b> <c> | <a> 
<b> <c>

For example
<path> ::= <ERO> [ <attributes> ]
<attributes> ::= <at1> || <at2> || <at3> || ..
if one of them can be repeated then introduce a list <at4-list>. This 
guarantees order also

Thanks
R.

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 01 Aug 2013 16:48:43 +0200

> allows option1 or option2 to be repeated more than once . If no, we 
> want to allow option1 followed by option2
> In other words, exclusive or is not mutually exclusive, it's a or b or 
> a followed by b
Err: I meant "sequential or"

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 2 Aug 2013 08:36:28 +0000

Ramon,

couple of  questions here:
On Aug 1, 2013, at 16:44 , Ramon Casellas <[email-masked]> wrote:

> <a> || <b> || <c> = <a> | <b> | <c> | <a> <b> | <a> <c> | <b> <c> | <a> <b> <c>

1/ oder is important (<a> || <b> is different from <b> || <a>)?

2/ repetitions are not allowed, right? I mean,  one of the resulting combinations of <a> || <b> cannot contain twice the the same term  

cheers
G

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 02 Aug 2013 11:07:15 +0200

> 1/ oder is important (<a> || <b> is different from <b> || <a>)? 
Yes; imho it is inline with default RBNF behavior regarding ordering
> 2/ repetitions are not allowed, right? I mean, one of the resulting 
> combinations of <a> || <b> cannot contain twice the the same term 
> cheers G 
Correct; although allowing repetitions is trivial, introducing a list, 
provided that your intent is to have repetition grouped, e.g.;

<path> ::= <ERO> (<BANDWIDTH> || <metric-list> || <Z>...)

ERO - BANDWIDTH - Z  or ERO - METRIC - METRIC - METRIC  are successfully 
parsed

Thanks
R.