AW: [Xorp-hackers] Config Var <-> Config mode

[Pavlin Radoslavov]

To: "Patrick Preuss" <deathdealer@gmx.net>
cc: "'Kristian Larsson'" <kristian@juniks.net>, xorp-hackers@xorp.org
Fcc: +outgo
Subject: Re: AW: [Xorp-hackers] Config Var <-> Config mode 
In-Reply-To: Message from "Patrick Preuss" <deathdealer@gmx.net> 
   of "Wed, 02 Nov 2005 21:12:59 +0100." <001401c5dfe9$d257a360$841cbb50@dedus737> 
--------
A number of issues have been brought in this thread, so here is a
summary (per issue) with a reply:

* The configuration should support ";" at the end of each line
  statement (as Juniper does).

  The ";" is already supported as statement separator. E.g.:

interfaces {
    interface rl0 {
        description: "control interface"; default-system-config;
    }
}

  However, the configuration "show" command does not print ";" at
  the end of each statement. If printing ";" at the end of each
  statement when showing or saving the configuration is desired, we
  can apply this change.

  Also, I presume you refer only to the configuration files, because
  Juniper doesn't support ";" as a command separator inside the
  cli. Nevertheless, we think that supporting ";" inside the cli can
  be useful, e.g.:

Xorp> show host os; show host date<RET>

  but this will require non-trivial changes to implement it.

* Accept configuration statements like "varname value" in
  addition of "varname: value" so it is more Juniper-like.

  We will consider this and we will look more carefully into it.

* "Currently you cannot cut and past the config"

  True, because we never claimed we are Juniper-compatible.
  Furthermore, note that even if we support the "varname value"
  syntax, you still won't be able to use the Juniper configuration
  as-is because of other differences like the structure of the
  configuration tree.

* A statement that contains only the name of a bool variable should
  imply that its value is true. The deletion of that variable should
  imply its value becomes false.

  We have been thinking about something like this within the context
  of the "disable" bool flag. Right now you have to specify
  "disable: true" to disable an entity. To do it as Juniper does it
  we could need only a statement like "disable".

* The subject of the "create" and "set" has been brought in the
  past, and I think there is an open bugzilla entry about this.
  There are arguments for keeping them separately, but lets not have
  the discussion again at this time. We will come back to it at
  some later stage.

* Specifying a list of prefixes within a single variable is not
  practical:
network4-list {
    elements: "1.0.0.0/24,1.0.1.0/24"
}
  and similar to Juniper we should use instead:
prefix-list test {
    1.0.0.0/24;
    2.0.0.0/24;
}

  We agree with this and we need to do something about it.


If I have missed something in this thread, it was unintentional so
please specify it again.

Pavlin