>>>>> "Margaret" == Margaret Cullen <[log in to unmask]> writes:

    Margaret>    Margaret On Aug 21, 2015, at 10:38 AM, Sam Hartman
    Margaret>    <[log in to unmask]> wrote:

>      Story 1: If MIT and Camford want to do a highly
> trusted project and don't trust the level at which JISC
> and Internet two run the APC, they can establish local
> ypeering between them.  Assuming they do plan to follow
> the rules of the existing APC, they should be able to use
> the existing APC.  Forcing them to create a new APC
> increases the cost of these sorts of shortcut links.

    Margaret>    Does this story assume that MIT and Camford are both
    Margaret> currently members of the APC?  Are you assuming that they
    Margaret> would stop peering for this access if/when one of them
    Margaret> leaves the original APC for any reason?  

This story does, but there's a story in the APCs mail that doesn't.

    Margaret> this example, because I think that either MIT and Camford
    Margaret> are either trying to create a separate APC, in which case
    Margaret> they should create one (which isn't complex at a technical
    Margaret> level, at least), or they are trying to create a small
    Margaret> community for their own purposes, the legal requirements
    Margaret> of which are dictated by the APC agreements, in which case
    Margaret> they should create a COI within the APC.  What am I
    Margaret> missing?  

We disagree about how complex creating an APC is.
Also, I claim in the APCs mail that we have a design goal of minimizing
the number of APCs in the world.
Creating an APC in this situation would not be consistent with that.

I don't understand how creating a COI would help.
The goal here is to use the local peering for

    Margaret> For all of your examples, it would be extremely
    Margaret> helpful to me if you could tell me what information
    Margaret> records (routing records and community records) you would
    Margaret> expect the nodes involved to exchange, and what filters
    Margaret> you think they would set up to accomplish these things, in
    Margaret> more concrete terms.

I can do that in a bit.
Unfortunately our discussions about COIs have gotten me confused and I'm
not sure COIs work well in either your model or mine.
Also, I'm pondering whether you are right that we want to separate APC
membership from routing and trying to figure out  the engineering
tradeoff.
So, I have about 3 models running around in my head at the moment plus
my understanding of your model.
I'd like to get down to one model plus my understanding of your model
before presenting examples.
I'm trying to do that as fast as I can.


>      Story 2: In more complex configurations it is
> desirable to set up a new APC for the cases in story 1.
> Using an existing APC is nice and simple, but is only
> appropriate if all traffic for that APC should go over the
> peering and if the rules of that APC will be met.  Imagine
> a case where there are conflicting security requirements.
> Perhaps the base APC uses some ISO security standard for
> how people maintain records focused on preserving privacy.
> The US government has a different FIPS focused on
> maintaining long-term accountability that is incompatible
> with the base APC.  MIT and Camford want to cooperate on a
> project requiring the FIPS rules.  They can't simply
> re-use the base APC.  It might appear that Story 2 is a
> sufficient technical solution to story 1.  I don't think
> so because there's significant administrative complexity
> in setting up an APC far beyond the technical complexity.

>      In this case, one of MIT or Camford may want to
> override the set of APCs that are appropriate for a
> existing external COI in the context of reaching the
> Camford or MIt realms.  Note that if they want to remove
> the base APC from what's permitted for the COI, then you
> need to be able to manipulate the set of permitted APCs on
> a target realm within a COI level, not just a COI level.

    Margaret>    I don't fully understand this story.  In particular, I
    Margaret> do not understand the last sentence, at all.  I understand
    Margaret> how MIT and Camford could set up their own APC and agree
    Margaret> to follow FIPS rules (as formally or informally as they
    Margaret> like) and/or how Camford could join an existing APC put
    Margaret> together by Internet-2 (for example) that involves a
    Margaret> contractual obligation to follow some FIPS-related rules.
    Margaret> But, I don't understand why there is any complexity in
    Margaret> either of those cases.  If you are only talking (I hope)
    Margaret> about MIT and Camford using the new APC for their own
    Margaret> purposes, why do you need to jump through hoops to use the
    Margaret> same COI?  It sounds like you are trying to say that MIT
    Margaret> (or specifically the people who run the MIT trust router)
    Margaret> are trying to backdoor Camford into a COI that is defined
    Margaret> (elsewhere) to only include members of a particular APC,
    Margaret> even though Camford doesn't belong to that APC.  If so, I
    Margaret> have a number of concerns about that€ Is that
    Margaret> what you are trying to do?  Margaret

Yes.
There's a COI that generally includes Camford using the base APC.
MIT would like to override that COI to use the new APC when talking to
Camford and would like to make the base APC not acceptable for talking
to Camford as part of the override.

--Sam