transit policy syntax

[[e-mail]]

hi tony,

to change the gross syntax of a transit policy requires, among other
things, the introduction of a new type of routing information message.
right now there are 16 types to choose from, of which we've used two.
in order to understand or even distribute a new type of routing
information message, a route server or a policy gateway must be able
to recognize the message type.  this means making sure that route
servers and policy gateways obtain the software to understand the new
message type, before receiving any new messages of that type.  but
this problem is not unique to idpr; it is common to any communications
protocol.  the protocol must be able to parse a message before it can
do anything with it.

we have tried to make the transit policy very flexible.  i expect the
major changes in syntax to occur in the offered services portion of
the transit policy.  each offered service description is prefaced by
an identifier and a field indicating the length of the description.
this allows a route server to skip over offered services it does not
understand.

if people believe that the other components of a transit policy: UCIs,
source and destination domains and hosts, and applicable time periods
are not general enough and therefore likely to change, then perhaps we
should go to a syntax that lists each of these under a separate
category, so that adding a new category is easier than updating the
whole message type.  personally, i do not expect the gross syntax of a
transit policy to change very often if ever.  but perhaps i am being
overly optimistic.

m