Discontiguous Deployment (Show of Hands)....

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I would call for a hum, but we can't hear it, of course, on
email,
so.... Please state your answer to the following:

o Discontiguous deployment should be included as a
capability any
proposed mechanism SHOULD have.

o Discontiguous deployment should be included as a
capability any
proposed mechanism MUST have.

o We should say something about discontiguous deployment,
but we
shouldn't attach any requirements to that statement.

o Discontiguous deployment should not be included in the
requirements at
all.

I'd just like to settle where we are, so we can actually
work on wording
with a common understanding of what it is we are trying to
actually word.



Russ

- --
riwcisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFEyogDER27sUhU9OQRAkITAKD7SxEGvZ9R50wwNRqS+pDHnqmJnACg
lE8k
W8Q1XNI71l188RuaFDFfIcY=
=NilE
-----END PGP SIGNATURE-----

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

 

> o Discontiguous deployment should be included as a
capability any
> proposed mechanism SHOULD have.
> 
> o Discontiguous deployment should be included as a
capability any
> proposed mechanism MUST have.
> 
> o We should say something about discontiguous
deployment, but we
> shouldn't attach any requirements to that statement.
> 
> o Discontiguous deployment should not be included in
the 
> requirements at
> all.
> 
> I'd just like to settle where we are, so we can
actually work 
> on wording
> with a common understanding of what it is we are trying
to 
> actually word.


One more time...

Discontiguous deployment is simply going to be a fact of
life.  Might as
well deal with it.  Make it a MUST, because it's a
practical necessity
anyway.

Tony



_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

On 28-jul-2006, at 23:56, Russ White wrote:

> o Discontiguous deployment should be included as a
capability any
> proposed mechanism SHOULD have.

> o Discontiguous deployment should be included as a
capability any
> proposed mechanism MUST have.

I think someone else already said this, but it bears
repeating:

It's unclear what discontiguous deployment means here.
Obviously, a  
solution that requires that AS N+1 can't deploy without
being  
required to interact with AS N directly isn't going to fly.
But the  
opposite situation, where a solution is unacceptable unless
the full  
security benefits are also available regardless of whether
any ASes  
in a path do or don't support the new mechanisms is
completely  
unrealistic.

So people in favor of one of the options above should first
define  
what level of discontiguous deployment we're talking about.

> o We should say something about discontiguous
deployment, but we
> shouldn't attach any requirements to that statement.

This would be my choice.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

On Jul 28, 2006, at 2:56 PM, Russ White wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I would call for a hum, but we can't hear it, of
course, on email,
> so.... Please state your answer to the following:
>
> o Discontiguous deployment should be included as a
capability any
> proposed mechanism SHOULD have.
>

No

> o Discontiguous deployment should be included as a
capability any
> proposed mechanism MUST have.

Yes, but, to Iljitsch's point.  It may require a bit of
definition.   
I would like to put a "MUST" around forcing
uninvolved players to  
participate in new memory requirements etc...  In fact, I
thought we  
already had that in the draft.


> o We should say something about discontiguous
deployment, but we
> shouldn't attach any requirements to that statement.
>

No

> o Discontiguous deployment should not be included in
the  
> requirements at
> all.
>

No

> I'd just like to settle where we are, so we can
actually work on  
> wording
> with a common understanding of what it is we are trying
to actually  
> word.
>

Yes

> 
>
> Russ
>
> - --
> riwcisco.com CCIE <>< Grace Alone
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

>
>
iD8DBQFEyogDER27sUhU9OQRAkITAKD7SxEGvZ9R50wwNRqS+pDHnqmJnACg
lE8k
> W8Q1XNI71l188RuaFDFfIcY=
> =NilE
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> RPSEC mailing list
> RPSECietf.org
> https://
www1.ietf.org/mailman/listinfo/rpsec


_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

 

> It's unclear what discontiguous deployment means here.
Obviously, a  
> solution that requires that AS N+1 can't deploy
without being  
> required to interact with AS N directly isn't going to
fly. But the  
> opposite situation, where a solution is unacceptable
unless the full  
> security benefits are also available regardless of
whether any ASes  
> in a path do or don't support the new mechanisms is
completely  
> unrealistic.
> 
> So people in favor of one of the options above should
first define  
> what level of discontiguous deployment we're talking
about.


Iljitsch,

I don't believe that this is actually relevant to a
requirements
discussion.
Given that partial, discontiguous deployment is a necessity,
the
solutions will be evaluated on the amount of benefit that
they provide.
Since contiguous paths will be in the minority, solutions
should
seriously consider what benefits that they can provide in
discontiguous
partial paths.

Tony



_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

On Fri, 28 Jul 2006, Russ White wrote:
> o Discontiguous deployment should be included as a
capability any
> proposed mechanism SHOULD have.
>
> o Discontiguous deployment should be included as a
capability any
> proposed mechanism MUST have.

Yes.

We can wrangle about what exactly 'discontiguous' means,
but I can't
picture a sane way to deploy a solution that doesn't allow
for a
staggered/graduated/limited deployment.

> o We should say something about discontiguous
deployment, but we
> shouldn't attach any requirements to that statement.
>
> o Discontiguous deployment should not be included in
the requirements at
> all.
>
> I'd just like to settle where we are, so we can
actually work on wording
> with a common understanding of what it is we are trying
to actually word.

s/common/closer to common/ ?

cheers!
============================================================
==============
"A cat spends her life conflicted between a deep,
passionate and profound
desire for fish and an equally deep, passionate and profound
desire to
avoid getting wet.  This is the defining metaphor of my life
right now."

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> o Discontiguous deployment should be included as a
capability any
> proposed mechanism MUST have.
> 
>> Yes, but, to Iljitsch's point.  It may require a
bit of definition.  I
>> would like to put a "MUST" around
forcing uninvolved players to
>> participate in new memory requirements etc...  In
fact, I thought we
>> already had that in the draft.

It looks like the list pretty much thinks MUST is the right
way to go,
and we're just to discussing what that MUST means (?). It
seems to me
that building the specific wording for the draft would take
this
question in....

I tend to agree with Tony that it's going to mean different
things for
different proposals, so we might just require that any
proposal discuss
how discontiguous deployments would work, and what the
tradeoffs are for
that specific proposal (?)....

Thoughts?



Russ


- --
riwcisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFEzKVDER27sUhU9OQRAoZ9AJ0S/UAkV4f7CZI1WbY8EzLcTsRb9wCb
BLPo
gEIrwX56dO/DRNe1rWBeIVo=
=a57p
-----END PGP SIGNATURE-----

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

At 5:56 PM -0400 7/28/06, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>I would call for a hum, but we can't hear it, of
course, on email,
>so.... Please state your answer to the following:
>
>o Discontiguous deployment should be included as a
capability any
>proposed mechanism SHOULD have.
>
>o Discontiguous deployment should be included as a
capability any
>proposed mechanism MUST have.

The current text requires (MUST) support for incremental
deployment, 
and requires the ability to configure a router for use of a
security 
mechanism on a oer-peer basis.  Thus it makes sense to
mandate 
support for non-contiguous deployment.  I didn't think that
was at 
issue/

>o We should say something about discontiguous
deployment, but we
>shouldn't attach any requirements to that statement.

This is the point I raised a week or so ago, i.e., it is not
easy to 
establish requirements for the security provided by a
mechanism in a 
non-contiguous deployment scenario, in a
mechanism-independent 
fashion.  So far our discussion on the list has not
indicated 
otherwise.

Steve

_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

 MUST HAVE

> -----Original Message-----
> From: Russ White [mailto:riwcisco.com] 
> Sent: Friday, July 28, 2006 2:56 PM
> To: rpsecietf.org
> Subject: [RPSEC] Discontiguous Deployment (Show of
Hands)....
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> I would call for a hum, but we can't hear it, of
course, on 
> email, so.... Please state your answer to the
following:
> 
> o Discontiguous deployment should be included as a
capability 
> any proposed mechanism SHOULD have.
> 
> o Discontiguous deployment should be included as a
capability 
> any proposed mechanism MUST have.
> 
> o We should say something about discontiguous
deployment, but 
> we shouldn't attach any requirements to that
statement.
> 
> o Discontiguous deployment should not be included in
the 
> requirements at all.
> 
> I'd just like to settle where we are, so we can
actually work 
> on wording with a common understanding of what it is we
are 
> trying to actually word.
> 
> 
> 
> Russ
>


_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec