Subject: [RPSEC] Discontiguous Deployment (Show of Hands)....

From: Russ White <[email-masked]>
Date: Fri, 28 Jul 2006 17:56:19 -0400

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

- --
[email-masked] CCIE <>< Grace Alone

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: "Tony Li" <[email-masked]>
Date: Fri, 28 Jul 2006 16:35:23 -0700

> with a common understanding of what it is we are trying to 

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

---

From: "Marcus Leech" <[email-masked]>
Date: Fri, 28 Jul 2006 19:37:35 -0400

> well deal with it.  Make it a MUST, because it's a practical necessity
Completely agree with this.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Jul 2006 11:35:24 +0200

> 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.

> shouldn't attach any requirements to that statement.

This would be my choice.

Iljitsch

---

From: Blaine Christian <[email-masked]>
Date: Sat, 29 Jul 2006 07:59:48 -0700

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

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

No

> 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.

> shouldn't attach any requirements to that statement.

No

> o Discontiguous deployment should not be included in the  

No

> with a common understanding of what it is we are trying to actually  

Yes

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEyogDER27sUhU9OQRAkITAKD7SxEGvZ9R50wwNRqS+pDHnqmJnACglE8k
> W8Q1XNI71l188RuaFDFfIcY=
> =NilE
> -----END PGP SIGNATURE-----
>

---

From: "Tony Li" <[email-masked]>
Date: Sat, 29 Jul 2006 09:43:02 -0700

> 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

---

From: Cat Okita <[email-masked]>
Date: Sat, 29 Jul 2006 14:29:53 -0400 (EDT)

> 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.

> 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."

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Jul 2006 22:23:27 +0200

> solutions will be evaluated on the amount of benefit that they  

I strongly believe that any words that don't make a (potential)  
material difference in the real world are meaningless and are  
therefore best not uttered in written or spoken language.

So if we say that we require discontiguous deployment while at the  
same time we know that discontiguous deployment is a certainty,  
that's a waste of electrons. Worse, this invites speculation about  
the meaning of the requirement down the road.

On the other hand, we can say that we require dicontiguous deployment  
and then say what we take that to mean, or we can say that  
discontiguous deployment is important and invite people who come up  
with solutions to offer insights in the types of discontiguous  
deployment they feel should/shouldn't and can/can't be supported by  
their solution.

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 29 Jul 2006 22:09:31 +0200

MUST, no other alternative

Tom Petch

---

From: Russ White <[email-masked]>
Date: Sun, 30 Jul 2006 08:25:40 -0400

>> 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

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

- --

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Jul 2006 10:32:18 -0400

>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/

>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

---

From: "Bora Akyol" <[email-masked]>
Date: Mon, 31 Jul 2006 17:50:43 -0700

MUST HAVE

> -----Original Message-----
> From: Russ White [mailto:[email-masked]] 
> Sent: Friday, July 28, 2006 2:56 PM
> To: [email-masked]
> 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
>