On 3/21/12 3:56 PM, "Robert Raszuk" <rob...@raszuk.net> wrote:

>
> > On 2012-03-21 16:50, Brian Dickson wrote:
>> ...
>> Doing so would require, at a minimum, stopping forward progress on
>> -protocol docs, until the -reqs- and -threat- are adequately addressed.
>
>On 2012-03-21 20:33, Russ White wrote:
> > ...
> > Given these failures, maybe it's time to start with requirements
> > (rather than a solution) first, and see if we come to a better
> > outcome.
>
>On 2012-03-21 20:40, Eric Osterweil wrote:
> >
> > +1
>
>
>Having a reasonable requirements document which defines what is that
>should be protected seem like a very reasonable thing. Clearly for some
>who "make/made decisions on the protocol" this may be a bit
>uncomfortable as their design choices now would need to compete with
>design proposals from others.
>
>The requirement should explicitly list elements to provide ability for
>gradual deployment .. maybe co-existence for some time. Clearly ideas of
>removing AS_PATH or AS4_PATH and replacing it with PATH_SIG are not
>really helping gradual deployment.
>
>Decent requirement document should also specifically prohibit use of any
>tools which can be controlled by politicians/courts to decide who stays
>in the internet and who becomes uncomfortable and needs to be cut out.

OK, so we have existence proofs that DNS based solutions are out .... ;^)

I think it wise before making strategic decisions based upon such
requirements, one should carefully examine what the real risk scenarios
are, what techniques might mitigate them, and then examine if the
remaining risks are substantially different than those that already exist
in the system. 

So far, most of the concerns I have heard are no different than any other
globally distributed hierarchical system where individual components are
subject to local laws.

Dougm



_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to