Re: [Ieprep] on the ieprep charter

Fred Baker <fred@cisco.com> Thu, 27 July 2006 19:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BP6-0005E4-Mj; Thu, 27 Jul 2006 15:20:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BP5-0005BP-1G for ieprep@ietf.org; Thu, 27 Jul 2006 15:20:15 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BP3-0006iF-Mp for ieprep@ietf.org; Thu, 27 Jul 2006 15:20:15 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Jul 2006 12:19:51 -0700
X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="436808888:sNHT2665094970"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RJJpaL026100; Thu, 27 Jul 2006 12:19:51 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6RJJoYr010340; Thu, 27 Jul 2006 12:19:50 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:19:50 -0700
Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 12:19:50 -0700
In-Reply-To: <44C9089E.3050802@jhuapl.edu>
References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <B8C892A4-F711-4928-8EDA-FD7E717B702F@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] on the ieprep charter
Date: Thu, 27 Jul 2006 12:19:49 -0700
To: "Robert G. Cole" <robert.cole@jhuapl.edu>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 27 Jul 2006 19:19:50.0247 (UTC) FILETIME=[A1707F70:01C6B1B1]
DKIM-Signature: a=rsa-sha1; q=dns; l=2237; t=1154027991; x=1154891991; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20<fred@cisco.com> |Subject:Re=3A=20[Ieprep]=20on=20the=20ieprep=20charter; X=v=3Dcisco.com=3B=20h=3DhF46nYRTNqWFkPqT/8l/+JDUBL8=3D; b=U0wD7in9CbqngUIcaNQWuYZdNXe4mMkhRp02R4LRIlEbvf48CvGVNN4wTtkQ4pvQ7ouX4Iij ERIPvdT/vpJI1CwRgNGajOnHR7yvAIq8HJqABT+nxkeo2w6D8VfFFWzu;
Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

On Jul 27, 2006, at 11:40 AM, Robert G. Cole wrote:
> "There is enough similarities in the needs of these broad industry  
> segements with respect to communications requirements/needs in  
> emergency situations that:
>
> a) Protocols can be enhanced (or in some cases developed) to handle  
> the similarities, while
>
> b) Differences are relegated to implementations or behavior  
> descriptions."

Yes, that is my opinion. Just an opinion, mind you. But I should  
think that a common UNI and NNI signaling mechanism could be  
described that enabled every implementation (regardless of nation or  
type of network) to classify requests in an appropriate manner  
(routine or whatever other level might apply, and whether the  
customer was authorized to make the request) and then implement what  
needs to be done. In some networks, for some services such as VoIP  
and Video/IP, that will include preemption; in other networks, the  
same services will include trunk queuing or other approaches. For  
other services, such as preferring some elastic traffic over others  
and the transitive trust issues in delivering an email within a short  
stated interval, other considerations may also come into play.

Note that I carefully separated that into three broad categories:  
UNI, NNI, and everything else. "everything else" is within a network,  
and I think that is the network's problem although I may have some  
suggestions. NNI may be able to be handled by SLAs, although one  
could argue that the entire discussion here is regarding edge  
conditions in SLAs. It is the UNI that concerns me the most, as it  
tends to be the place where the biggest problems occur, and where  
problems occur at NNIs they can be treated as a variety of aggregated  
UNI. It is the NNI and the UNI that are most in view in RFC 4542.

One thing to consider is that the intra-network case and the NNI case  
are somewhat specialized( we are simply looking at IP traffic,  
usually in an aggregated form), while the UNI crosses a variety of  
types of products including SMTP servers, telephones and telephone  
middleware, etc ad nauseum. I think the UNI is the most interesting  
and important case.

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep