Re: [RRG] Fwd: I-D ACTION:draft-irtf-rrg-design-goals-00.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Comments on the design goals.

As a meta-issue I didn't see many requirements on operations and 
management aspects, but some of those are implictly lurking beneath 
the "deployability" subsection.  But I couldn't think of anything 
right now that would need to be added...

substantial
-----------

   RFC 1958 [RFC1958] provides an excellent list of the original
   architectural principles of the Internet.  We incorporate them here
   by reference, as part of our desired design goals.

==> I do not think this is sufficient.  RFC1958 seems include two kinds of
material; general principles and discussion and specific guidelines. 
Are you referring to the both or just the latter?  However, even the 
specific guidelines use a different encoding for 'Priorities' so a) 
it's not clear what the RFC1958's design goals are wrt this document, 
and b) it's not clear what their priorities are.

If we want to include design goals from RFC1958 I believe it's 
necessary to at least mention them one by one as bullet points and 
assign them priorities or specify a prioprity mapping function.

3.6.  Decoupling location and identification
...
Solutions to both problems, i.e. (1) the decoupling of
   host location and identification information and (2) a scalable
   global routing system (whose solution may, or may not, depend on the
   second decoupling) are needed and it is required that their solutions
   are compatible with each other.

==> the only requirement (using the language described in section 1.2) I see
in this subsection that that the solutions are compatible with each 
other. Is that the intent?  In particular was 'are needed' above meant 
to be some priority?  What does solution compatibility requirement 
even mean (in practice)?

3.7.  First-class elements

   If a solution makes use of a mechanism, it is strongly desired that
   the mechanism be a first-class element in the architecture
   [FirstClass].  More specifically, if a tunneling mechanism is used to
   provide network layering, connectivity virtualization, or a
   connection-oriented mode, then it is strongly desired that the
   tunneling mechanism be a first-class element in the architecture.

==> I don't disagree with this, yet I wonder why this is listed as a goal. 
Some justification should be added.  This seems written like an 
implementation detail.  Maybe what you actually have as a goal is 
something else, e.g., that mechanisms of the architecture should be 
usable by other pieces of the architecture.

3.9.  Routing security

   Currently, the routing subsystem is secured through a number of
   protocol specific mechanisms of varying strength and applicability.
   Any new architecture is required to provide at least the current
   level of security.

==> is the 'current level of security' intended to be a punt?  As we've seen
on RAM/arch-d lists, some people feel that RFC4218 described the current
level, yet others seemed to disagree with that.  Should this be stated more
clearly, or do we want to defer the debates on what the 'current level of
security' is until later?

3.10.  Deployability

   Since solutions that are not deployable are simply academic
   exercises, solutions are required to be deployable.  Furthermore,
   given the extensive deployed base of today's Internet, a solution is
   required to be incrementally deployable.

==> I don't think this is quite explicit enough.  'Required to be
deployable' -- deployable by whom?  That's a very critical question.  All
sorts of solutions can be proposed which are deployable by some
organizations involved in the network, but whether those have any incentive
to deploy it is another question altogether.  Did you mean to include the latter
(incentives and actual deployments) in your requirement?
The same applies to incremental deployments.

I don't think there is much use in designing solutions that are 
deployable, even incrementally deployable, if those people who would 
need to deploy them are not interested in doing so.  Rather I'd like 
to require that those people who feel the pain will also need to take 
responsibility of mitigating it, not try to push it around to someone 
else.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg