Subject: RE: [Ieprep] problem context

From: "Folts, Harold" <[email-masked]>
Date: Fri, 22 Nov 2002 09:53:09 -0500

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Friday, November 22, 2002 7:38 AM
> To: King, Kimberly S.
> Cc: [email-masked]'
> Subject: Re: [Ieprep] problem context
> 
> Item (3) describes military communications rather than emergency 
> communications.
> Military communications might (and do) have varying degrees of urgency
> and precedence, but they aren't emergency communications.  Examples of
> emergency communications would be from civilian organisations such as
> Fire, Police, or FEMA.  Military networks might happen to carry some
> messages related to a natural disaster, but that does not make such 
> networks
> IEprep networks.
> 

Ran,

I agree that ieprep should be only considering emergency communications in
direct support of emergency and disaster relief operations. This has been
defined as ETS (emergency telecommunications service).

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

---

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 22 Nov 2002 10:07:56 -0500

Ran,

The context situation is good but the example should be changed.  I'll
change the example of that context to a FEMA-like mobile router with its RF
connection.

Kimberly

---

From: "Gunn, Janet" <[email-masked]>
Date: Wed, 27 Nov 2002 10:15:00 -0500

Well, I work on a program funded by NCS.  So that (the issues I deal with on
that program, not the fact that it is funded by NCS) has an influence on my
"point of view".  

But what I say is a reflection of the "concerns of Janet Gunn, private
individual".  I do NOT claim to represent the "concerns of NCS".

I thought that was SUPPOSED to be the premise of the IETF, that we express
our own opinions, not those of our employers, funders, etc.

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 7:53 PM
To: Gunn, Janet
Cc: ieprep
Subject: Re: [Ieprep] problem context

I'm not quite sure which of these (or maybe some other items) is the 
focus
of the concern at NCS, and which of these is the focus of the concern at
DISA Centre for Standards.  It would help if those perspectives could 
be made
more clearly.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Gunn, Janet" <[email-masked]>
Date: Wed, 27 Nov 2002 11:33:12 -0500

Personally (not representing any organization's "concerns"), I am basically
neutral as to whether the appropriate solution is at the IP layer, or the
application (e.g., SIP) layer . Similarly, I would be comfortable with
whatever "level" of gateway (router, SIP gateway, application gateway) is
most effective.   At least for VOIP (and probably for video feeds, etc.) the
application/SIP layer is probably more promising.

If a problem develops (I don't think it is a problem today, but I am not
convinced it is IMPOSSIBLE to have a problem) with elastic applications, it
might be more appropriate to address the solution at a lower level.

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 7:53 PM
To: Gunn, Janet
Cc: ieprep
Subject: Re: [Ieprep] problem context

On Tuesday, Nov 26, 2002, at 18:32 America/Montreal, Gunn, Janet wrote:
> It seems to me that MLPP is a technical solution to solve a particular
> problem in a (fixed) circuit switched network.
>
> Just as eMLPP is a different technical solution to solve a similar 
> problem
> in a (mobile) circuit switched network.
>
> I am not sure that it makes sense to REPLICATE either MLPP or eMLPP in 
> an IP
> network.
>
> However, it may very well be useful to identify an (IP specific) 
> technical
> solution that solves the same basic problem.
>
> And it would DEFINITELY be useful to identify ways of interoperating 
> with
> MLPP and eMLPP across the relevant gateways.

There are at least 2 (maybe more) different layers that one can use to 
consider this
question:  application-layer (e.g. SIP servers) and IP-layer.  I am 
very unclear
which of these is meant.  Some folks use "gateway" to mean a SIP 
gateway,
some to mean another application-layer gateway, and some to mean an IP 
router.

If we look at this as an IP-layer issue, then DiffServ/IP-ToS is an 
approach that
can work *within a single administrative domain*.  The security issues 
(e.g.
DDOS attack using IP ToS bits) are primarily a problem on an 
inter-domain
boundary.  Within a single administrative domain, the authorities for 
that
domain can use domain-specific policies and mechanisms to mitigate their
operational risk.

If we look at this as a SIP issue, then it seems like the main concern 
might
be to ensure that whatever markings are associated with a telephone call
are preserved (or modified only as appropriate at an administrative
boundary -- example:  country X might by policy disregard/remove 
markings
originating on an international call from country Y).  Because of our
layered architecture, having a call marked with some bit pattern inside
SIP does NOT automatically imply any change from best-effort handling by
the IP-layer.  It would not prohibit it, but neither would it 
automatically
imply such.