Subject: [Ieprep] requirements document(s)

From: Ken Carlberg <[email-masked]>
Date: Tue, 17 Sep 2002 15:17:58 +0100

hello,

this relates to Kimberly's recent posting

In the past, there has pretty much been a single requirements draft that 
has evolved into different forms.  the first one was put forward by Fred 
Baker and was pretty much aimed at IEPS (sort of a narrow scope). 
subsequent efforts from Hal Folts and Cory Beard (and the merging of the 
two) also represented a single requirements draft.  however, there still
seemed to exist concerns and questions about the single document.

over the past few weeks, Ran Atkinson and I have taken a different
approach and put together two system requirements drafts as candidates
for the group to consider as formal work items.  the first is a 
general requirements draft -- this draft should be broad enough to
cover a wide variety of applications (from telephony to the I-Am-Alive
database app used in Japan).  the second draft is an *extension* to the
first and is focused on IP telephony.

my feeling/hope is that the second then becomes the second domino that 
produces the need for Henning's even more focused requirements draft for 
SIP requirements.  so, we sort of end up with something like...

   General-System-Requirements (IEPREP) {Carlberg & Atkinson}
       |       
       +--IP Telephony Requirements (IEPREP) {Carlberg & Atkinson}
            |
            +--IEPREP SIP Requirements (IEPREP?/Sipping?) {Schulzrinne}

There is also a User Requirements draft separate from the above that has
been put together and is under review by the authors.

questions that exist are:
  - does this address to some degree Kimberly's previous posting?
  - do we have something that different groups (MLPP, GETS-NS/EP,
    IEPS, I-Am-Alive, etc.) can relate to?  ie, is the approach we 
    took reasonable and satisfactory to the group?

the drafts that Ran and I worked on are very slim.  we wanted to just
focus on the basics and place any additional background info into the
User Requirements and Framework drafts.  I've requested the I-D
submission manager post our drafts at the usual place.  in the meantime,
barring any hiccups, the drafts can found here.

http://www.g11.org.uk/~carlberg/ieprep/draft-ietf-carlberg-ets-general-00.t
xt
http://www.g11.org.uk/~carlberg/ieprep/draft-ietf-carlberg-ets-telephony-00
.txt

regards,

-ken

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

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 17 Sep 2002 10:35:27 -0700

On Tuesday 17 September 2002 07:17 am, Ken Carlberg wrote:

Ken,

I like your approach.  Some feedback comments.

>    General-System-Requirements (IEPREP) {Carlberg & Atkinson}

This is good.  There are a variety of internet-based applications that work 
well for emergency services (many better than over circuit switch).  So you 
should have this general, application-independent treatment.   As I read your 
I-D, I bounced against my mental plowshares --> swords checklist which has 
four deltas between normal internet practice and what we need for emergency 
services:
	- higher availability.  Your draft doesn't mention this at all.  3 
principles of high availability engineering include 1) provisioning of 
alternate routes, 2) reliable crossover (inherent in connectionless IP) and 
3) detection of faults as they occur (monitoring).  
	- security.  You correctly focussed on the authenticity and confidentiality 
with the obvious notions that solutions belong in applications (e.g. digital 
signature of the I'm Alive e-mail).  In general, good job.
	- QoS control.  Also good job -- priority access to the internet plumbing 
... while the system is being stressed is an important requirement.  
	- reach to mobile platforms.  Here a lot of the network layer solutions 
(e.g. diff-serv, QoS control, IP multicasting) need to work at the data link 
layer as well.  For example, an authorized priority user might be using a PDA 
that's linked to the world via an 802.11 LAN at the border -- but the 802.11 
protocols don't allow for priority access to the LAN for urgent traffic.  
>        +--IP Telephony Requirements (IEPREP) {Carlberg & Atkinson}
	If I read your structure correctly then we could list other emergency 
service applications here.  Such as
          +-- Remote sensor reporting (e.g. wx, chem, bio, nuc)
          +-- command & control apps (what the emergency services have called 
Computer aided dispatching and what the military calls command & control 
systems (e.g. GCCS)
          +-- Common Alerting Protocol .. more below*
While the number of emergency services apps may be legion, we can profitably 
list a few obvious ones.
>             +--IEPREP SIP Requirements (IEPREP?/Sipping?) {Schulzrinne}

What I don't know where to fit on your structure is what I call the Good 
Housekeeping Rules.  You got to some of these:

	- the toaster division.  End systems have LAN interfaces.  Exploit e-mail 
(with authenticity, confidentiality solutions), QoS control, SNMP monitoring.

	- the common sense division.  Build loosely coupled applications, 
authenticate everything, avoid bit-bloat apps, exploit multicasting and 
cacheing to max efficiency of what bandwidth you might have available in a 
stressed situation.  

References:

>>For more information about the Common Alerting Protocol, visit
>><http://www.incident.com/cap/>.

Common Alerting Protocol is a project among emergency services workers, 
headed up by Art Botterel, Art Botterell <[email-masked]>

The work is definitely internet-informed and XML based.  It recognizes many 
of the same requirements (e.g. object level authenticity).

Critique any help?

-- 
b

---

From: senthil ayyasamy <[email-masked]>
Date: Tue, 17 Sep 2002 21:38:02 -0700 (PDT)

> (IEPREP?/Sipping?) {Schulzrinne}

1. Is their any particular reason for documenting SIP
and IP telephony requirements separately?

2. Both the drafts doesnt talk about requirements for
CODEC negotiation which is essential for ieprep.

3. If i understand kimberley's mail, the drafts should
also focus on specific requirements for various SIP
end points, media gateways, telephone signaling end 
points(?)

4. The proceeding shows only minutes of the interim
meeting. Hence, I dont know what the group is
currently focusing on..esp sipping/ieprep interactions.

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 18 Sep 2002 09:56:42 +0100

>3) detection of faults as they occur (monitoring).  

we can add some verbage (either in the Introduction or Issues) that talks 
about "higher availability" being a motivation in the effort.  in my view,
higher availability is a function concerned with contention of resources 
with different types of traffic (ie, emergency-related flows versus other 
flows).  if a contracted SLA existed with a provider to simply segment and 
forward labeled emergency flows along a traffic engineered path, then the 
contention issue is bypassed and 'sufficient' availability exists.  note
that the traffic engineered 'virtual' path may be along the same route
as other traffic.

also, contention may not be along a path.  it may be within the resources
of a server (eg, buffer space for email; and note that the non-interactive
quality of email can survive contention along a path quite well with TCP).
so given the draft you cited at the begining, we need to be careful not to
apply requirements to other applications that may not care or relate to 
it.
this is why we pushed mentioning of alternate paths to the Telephony
requirements draft.

note: I know we bent this rule a bit with the conditional requirement
about signaling, but I only want to do that once and not have a series
of conditional requirements.

>... while the system is being stressed is an important requirement.  

the word priority tends to bring about a fair amount of debate at times,
so we purposely left the word out.  I'd like to think we articulated
requirements about labels and distinguishing traffic that allow one to 
travel down that path if they so choose -- with the expectation that such 
a path would be accomplished via business contracted SLAs.

>protocols don't allow for priority access to the LAN for urgent traffic. 

ok. and I assume we are in agreement that suggested requirements/solutions
on layer-2 technologies & protocols will be out of scope of the IETF.

>While the number of emergency services apps may be legion, we can 
profitably

correct, in that by segmenting requirements in separate drafts, we have
a better chance of getting specific core requirements accepted by both
this working group and the IESG as opposed to being bogged down trying to 
get consensus in one large encompassing document.  hence, discussion on
your remote sensor reporting does not hinder what we may agree on regarding
IP telephony.

>cacheing to max efficiency of what bandwidth you might have available in 
a

i guess the question you may want to ask yourself is what is the problem
you're trying to solve?  if new requirements outside of labeling and
associated security arise, then these would be things to articulate.  if
existing requirements satisfy what you need done, then perhaps a 
framework is what needs to be put together to focus the objects and 
solution to be pursued.

> of the same requirements (e.g. object level authenticity).

thanks.  I am familier with the work, though its been a while since I've
looked at it.

> Critique any help?

yes, constructive feedback is always welcome

-ken

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 18 Sep 2002 10:20:16 +0100

> and IP telephony requirements separately?

SIP itself is just a part of IP telephony.  I wanted to add the value-added
requirement of alternate path routing, which would be out of scope of SIP. 
Hence, a more focused set of requirements to satisfy alternate path
routing *could* be in the form of articulating requirements for TRIP.

also, Hennings work predates our effort and should stand on its own.
Hopefully, our requirements draft simply adds more strength to why 
Henning's SIP requirements needs to exist.

finally, one may argue that Henning's draft should be a SIPPING draft,
while our Telephony requirements would be just an IEPREP item.

> CODEC negotiation which is essential for ieprep.

by this I assume you mean downward or alternate negotiation during times
of contention of resources?  this could be added as a value added
requirement in the Telephony draft.  note that discussion of this topic
would be out of scope of Henning's work, hence the need to keep the two
drafts separate :-)

> end points, media gateways, telephone signaling end 

such as?  I prefer not to speculate, but rather respond to suggested
requirements that go beyond what we have put forth.

> currently focusing on..esp sipping/ieprep interactions.

updating the latest on-line proceedings is an issue for the IEPREP 
co-chairs.

-ken

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 18 Sep 2002 09:36:41 -0700

On Wednesday 18 September 2002 01:56 am, Ken Carlberg wrote:
> >alternate routes, 2) reliable crossover (inherent in connectionless IP)
>
> and
>

Ken, I recommend that we parse this into two bins:
	- 'non-availability' due to congestion.  For which you have good QoS control 
handle (the labeling).
	- non-availability due to broken stuff.  Here availability and survivability 
are closely related -- Ao relates to equipment that breaks itself (e.g. a 
fried power supply) and survivability relates to equipment that's broken by a 
Bad Guy.  Either way, the equipment's busted and any emergency system needs 
to deal with it (both by exploiting workarounds and by priority restorals).  

I maintain that these are two logically different problems, both important to 
us.  Certainly from the solution side, we have different remedial tools:

High Ao requires 1) redundant connectivity, 2) reliable crossover and 3) 
monitoring.  

QoS control requires 1) ability of the system to differentiate between 
emergency traffic and the great unwashed Internet traffic, 2) ability to 
afford the emergency traffic the service it needs (i.e. better than best 
effort), and 3) ability to police the system to prevent grade creep.  In my 
repair kit, this is a quite different set of tools than the ones I use to 
work on high Ao.

Side note.  I don't think this is a problem in your draft, but some folks (US 
Defense Science Board to name one) get Ao and Security all mixed up.  I put 
security into a third bin alongside Ao and QoS control.

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 18 Sep 2002 09:48:17 -0700

I said:

> >(e.g. diff-serv, QoS control, IP multicasting) need to work at the data
>link layer as well.  For example, an authorized priority user might be using 
a PDA that's linked to the world via an 802.11 LAN at the border -- but the
802.11 protocols don't allow for priority access to the LAN for urgent 
traffic.

> on layer-2 technologies & protocols will be out of scope of the IETF.

Yes and no.  First, we agree that this represents a bunch of Layer 2 issues.

Traditionally IETF has stayed out of that territory, generally leaving that 
field to IEEE.  And there's a great deal of inertial resistance to rethinking 
that.  In general, I agree.

What I disagree on is that I believe we need some kind of standards-defined 
interface between Layers 3 and 2.  (Phil Neumiller and I have had some of 
this discussion in the MANET list on what Phil calls the 'soft underbelly'.)
	There are one-off solutions here -- multicast IP traffic is recognized by 
ethernet switches equipped with IEEE 802.1p and then multicast over the  
switch's fanout.  What we need is a generalization of what you might call an 
API that allows these IP functions to be reflected in the data link layer:
	- QoS labels (e.g. DSCP)
	- IP multicasting
I'm less concerned about wired LANs here than I am about either wireless LANs 
(at the border of the internet) or radio-WANs (in it's interior).  It's here 
that we need to get the plumbing properly tuned and there's no community with 
more at stake to getting that right than the emergency service gang.

Help?

---

From: senthil ayyasamy <[email-masked]>
Date: Wed, 18 Sep 2002 18:26:27 -0700 (PDT)

> of contention of resources?  

Exactly. We discussed them sometime before in 
this list.

> such as?  

For example, if we want to request a priority service
or re-route a request, it can sometimes be done by
multiple elements. So, it will be nice, if we specify
the expected requirements of each media elements
separately.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 19 Sep 2002 10:06:54 +0100

>API that allows these IP functions to be reflected in the data link layer:

ok, understood.  within the current charter of IEPREP, its realization
would need to be in the form of a requirement.  

its something that will probably require additional thought.  however, my 
initial impression is that making a requirement for an API is a bit odd.  
the effort probably needs to be done in a different working group, or 
require a charter of IEPREP (which is probably premature at this stage).  

just my 2 cents,

-ken

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 19 Sep 2002 10:29:15 +0100

> the expected requirements of each media elements

ok.  so if we follow the proposed model i put forth, the 'value added'
requirement for re-routing is placed in the IEPREP telephony requirements
draft.  in the case of SIP, we do have a means of routing at the 
application layer with TRIP.  so in a sense, we have a mechanism to 
achieve the re-routing in the IEPREP draft.

i don't know of any routing work proposed for megaco, but i haven't
had my coffee this morning yet to wake me up :-)

one question that arises is whether additional and more focused
requirement needs to be articulated in the IEPREP document or needs
to be placed in the IPTEL working group, where TRIP came from.  and
perhaps another question is whether such a requirement is needed, or
simply a proposed extension to the IANA recorded defined values for
TRIP needs to be proposed in the IPTEL group.

I'll need to give this more thought.

-ken