Subject: Re: [Ieprep] Re: Mike's scenario

From: [email-masked]
Date: Fri, 13 Dec 2002 12:35:59 EST

In a message dated 12/12/2002 4:34:56 PM Eastern Standard Time, 
[email-masked] writes:

> Nope.  If (A) pays for an IP access link, then (A) gets to set the policy on 
> their
> link.  A's ISP does not get the power to set the policy on that link 
> unilaterally
> (generally speaking; the details of the ISP's contract with A obviously 
> matters here).
> The government does not get the power to set the policy on that link 
> unilaterally either.
> 
> If the government wants to have influence over A's access link(s), it seems 
> to several
> of us that the government needs to have agreements with both A and A's 
> ISP(s).  Absent
> specific agreements with A *and* A's ISP(s), then the government simply 
> does not have
> any right to influence the policy deployed on A's access link.  An agreement
> between a government and an ISP might impact how that ISP does things 
> *inside
> the ISP's own network*, but that contract(with the ISP)'s scope could not 
> legitimately
> include anything belonging to an ISP's customer (e.g. CPE access router on 
> the access
> link that is owned/operated by the customer).
> 

[MAP]
I see where a lot of the problem is. Ran is not addressing the scenario of 
most interest to me (as a DoD contractor, not an NCS contractor). The NCS 
interest is mostly for authorized emergency use of the "public" 
infrastructure, with the practical problems as stated above, but, as Fred 
says, carriers would likely be more than happy to get an additional revenue 
stream from the government to do these things.

However, I am addressng the DoD interests, which are authorized emergency 
access mostly over DoD owned (or contracted) facilities. In this case, the 
government (DoD) is both "A" and "A's ISP". In this scenario, it needs 
procedures/protocols/whatever to meet the requirements that have been 
described in my draft as well as in presentations in SIPPING and IEPREP.

I described the case of the (civilian) call from Nairobi on a limited access 
going over satellite, which can certainly become congested if too many people 
independently try to make voice calls (as stated during the presentation), 
since this is exactly one of the valid cases for a military operation, which 
often occur in unplanned places. (This includes the US military going into 
other countries to lend humanitarian aid following a disaster.) But, I've 
quickly realized that it's best to not emphasize the "military" aspect of the 
use of this requirement and that it is best to include other possible 
applications in the problem set in order for the IETF to spend its time on 
possible solutions. I've tried to describe the scenarios without resorting to 
a lot of military application language, but I guess that has led to some 
confusion.

In a message dated 12/12/2002 4:34:56 PM Eastern Standard Time, 
[email-masked] writes:

> Instead, the repeated misunderstanding from NCS and its contractors is that 
> its
> sufficient to just have contracts with a few big ISPs.  With the Internet's
> de-centralised architecture (opposite to PSTN's centralised architecture),
> the set of agreements needed is pretty significantly larger than with the
> existing PSTN.
> 

[MAP] I really don't think the difficulty of contracting with many ISPs 
should be an issue here. I'm sure the people at NCS understand the situation. 
The only point here should be whether something can be defined which NCS can 
take to ISPs to ask for.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 15:32:58 -0500

On Friday, Dec 13, 2002, at 12:35 America/Montreal, [email-masked] 
wrote:
> [MAP]
> However, I am addressng the DoD interests, which are authorized 
> emergency access mostly over DoD owned (or contracted) facilities. In 
> this case, the government (DoD) is both "A" and "A's ISP".

My bad.  Terribly sorry, thanks for the correction.

> In this scenario, it needs procedures/protocols/whatever to meet the 
> requirements that have been described in my draft as well as in 
> presentations in SIPPING and IEPREP.

And this is explicitly a VoIP scenario or a any-kind-of-application 
over IP scenario ?

> I described the case of the (civilian) call from Nairobi on a limited 
> access going over satellite, which can certainly become congested if 
> too many people independently try to make voice calls (as stated 
> during the presentation), since this is exactly one of the valid cases 
> for a military operation, which often occur in unplanned places. (This 
> includes the US military going into other countries to lend 
> humanitarian aid following a disaster.) But, I've quickly realized 
> that it's best to not emphasize the "military" aspect of the use of 
> this requirement and that it is best to include other possible 
> applications in the problem set in order for the IETF to spend its 
> time on possible solutions. I've tried to describe the scenarios 
> without resorting to a lot of military application language, but I 
> guess that has led to some confusion.

Yes, but no real harm done.

There is one really really fundamental difference between a DISN-only 
scenario
or a DoD-only scenario and an NCS scenario:

	A DoD-only or DISN-only scenario has a single administrative domain.
	The civilian IEprep scenario has arbitrary numbers of administrative 
domains.

A direct result is that those 2 scenarios probably need totally 
different
system engineering approaches.  They might be able to reuse some 
mechanisms
here and there, but the overall deployment concept is significantly 
different.

For a single-domain approach, where some single policy can be applied 
all
over, then end-to-end DiffServ is an approach that the US DoD used in 
the
past in the DDN. Modulo the operational issues with "precedence creep" 
that
were described by Rex a while back, it should just work fine.  The IETF
redefined the IP ToS bits since then, but most products are generic 
enough
to implement at least the Precedence Bits from RFC-791 without any 
change
to anything (as in shipping code today from many vendors).  I can 
imagine
some desire to get the original precedence scheme documented publicly,
but if that's to be undertaken as an IETF standards activity, then it 
really
is a DiffServ WG matter.

Similarly, I can totally believe that DoD might have accounting needs 
for
its own networks.  But it is a pretty far stretch to go from those needs
to say that all civilian IEprep scenarios will need accounting.  And
I'd still like to understand more nearly what kinds of things this part
of the DoD community [1] is looking to perform accounting upon.  Details
would help a great deal.

So it would help a lot if the non-civilian participants on this list 
would
please clearly differentiate "civilian IEprep" scenarios from the 
"military"
scenarios.

Ran
[email-masked]

[1] US DoD is big enough that it probably doesn't have any single view 
on any topic.
Folks in various places espouse various policies, but DoD is big enough 
that almost
no policy really gets universally implemented.

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