Subject: [Ieprep] (no subject)

From: Scott Bradner <[email-masked]>
Date: Fri, 28 Jun 2002 21:02:23 -0400 (EDT)

Fred sed:
> It seems to me that the requirements draft should be talking about the 
> problem to be solved ("we need the phones and certain sites to be 
> accessible be emergency workers when things are falling apart"), and if it 
> mentioned solutions at all ("overprovisioning" or "QoS"), it should mention 
> them as examples of a solution which can fix the problem being addressed, 
> discussion of which can help identify requirements remaining to be addressed.

I think this is correct, but ieprep might also need to say what it
means to have phones be "accessible [to] emergency workers"

	there is an a authentication part to this
	there is a privacy part to this
	there is a functionality part to this (e.g., what finctions are needed
		to say that a phone is "accessible")
	there is a quality part to this ( e.g., what are the 
		characteristics of the required network-level functons, 
		e.g., what qos variables, latency, bandwidth, loss, etc, 
		apply, and how shoudl they be thought about

	there are other parts I'm sure

Scott

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Jun 2002 21:31:11 -0400

> 	there are other parts I'm sure

Scott,

	I don't think you've got exactly the right list.  If I could tweak it
a bit, I would make your list read more like this:
		- security requirements:
			- user authentication
			- network integrity
			- user data confidentiality
		- network availability
			- routing integrity & availability (a path exists)
			- capacity (enough bandwidth exists for IEPS needs;
						subsumes packet loss)
		- network properties
			- jitter (maybe; I don't see that its needed, but maybe)
			- other
		- ...

	Things in your list above that aren't high-level requirements, but 
instead
are really implementation/deployment strategies/details include:
		- QoS variables (no need for QoS if have overprovisioned capacity)
		- latency (varies by distance anyway and codecs/apps can adapt
				to large latency; see addition above of jitter which is
				more nearly relevant)

	Now it is helpful to have an array of informational documents 
describing
possible deployment strategies (using existing IETF standards).  An 
existing
example is suggestions on configuring QoS with DiffServ, for operators 
who
choose to participate in IEPS and also under-provision some part of the 
network
and want to use DiffServ as part of their implementation approach.  
However,
that other information ought be packaged *outside* the requirements 
document
and kept purely optional to deploy.

Ran
[email-masked]