Latest and final draft of ripe-81++

 Laurent Joncheray <lpj at merit.edu> writes:
  * > Please highlight all ambiguouities then. In fact, how about just for
  *
Firstly, I would like to say that for the ripe-81++ document we HAVE
consensus as far as I can tell. Jimi agreed an order. Jessica did
almost all the syntax for this as well and I just wrote it down.
However, to your personal comments.
 	
  * 	Sorry, i was wrong. It's not ambiguous, just difficult to parse.
  * 
Okay and this for sure maybe true but this at the end of the day
sometimes has to happen for the "sake" of clarity. I am sure you can
code this whatever so I am not too worried now you say this.

  * > once working together rather than at odds all the time ?
  * 
  * 	Oh well, it's monday morning, lets try... What we'd like to see
  * in the syntax:
  * 	(a) - compatible with as-in/as-out syntax (all as-in/out line should be
  * interas-in/out compliant. The comtrary is FALSE - unfortunatly :)

Well - here we are at the old chesnut again. I dont think there is
anywhere to go with this one. The only side effect of interas-inj/out
is the fact you may have to "occasionally" duplicate some of the
information.

  * 	(b) - readable (sugar like from, accept, etc...)

Well there is sugar - are you saying there is not enough. This was
proposed my Jessica so I sort of thought this is what you wanted.
Anyway, the point is very moot now anyway.

  * 	(c) - allow a list of couples (peer, preference). DISCLAIMER: i know
  * that this notion has been refused during the last RIPE meeting but i'd
  * like the syntax to allow it (even if the user is not allowed to used it)
  * so if sometime the 'tie people' change their mind we can easily move to
  * a new syntax.

Well leave it in your parser if you like. Unfortunately, we have a
process of agreement and we'll have to stick to it. If anything is to
really progress you always need this.

  * 	(d) - can be adapted to new protocols.
  * 
  * The your syntax has the following problems (IMHO)
  * 
  * 	difficult to parse. Example:
  * 
  * interas-in: from AS1104 192.87.45.254/32 accept AS786 AS987
  * interas-in: from AS1104 192.87.45.32/32 (pref=MED) accept AS786 AS987
  * 
  * In the first example the ip address is a local address, in the second
  * one the ip address is a neighbor address. Only the '(pref=MED)' makes the
  * difference.
  * 
Oohh I see what you mean. However, this ONLY arises from the fact that
the [<local-rid>] [<neighbor-rid>] are defined as optional. Something
you at Merit specifically wanted. I am happy to have these enforced.
This easily clear this up.

  * 	(c) is a paint to implemant.
  * 
  * 	My code implement (c) and it's kind of stupide to remove this
  * functionality even it's not used *now*. So if you can come up with a syntax
  * conforming to those points i am ready to change my parser :)
  * 
As I said leave it in if you like. Will not be used and not added to
the syntax definition todo but could be later so up to you.

  * 		Laurent
  * 
  * PS: BTW can we get rid of the /32? We all know that's an IP *host* address.
  *
Well I guess this could be lifted but for me it makes no odds either
way. In one sense it sort of makes the user realise that his host
address really is these days. Again we could just make the /32
optional - I am not bothered at this point. 

		--Tony. 







-------- Logged at  Tue Aug 23 16:03:13 MET DST 1994  ---------