Re: [Ieprep] on the ieprep charter
"Robert G. Cole" <robert.cole@jhuapl.edu> Thu, 27 July 2006 19:34 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bcb-0004RC-Cz; Thu, 27 Jul 2006 15:34:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Bca-0004Qr-21 for ieprep@ietf.org; Thu, 27 Jul 2006 15:34:12 -0400
Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BcY-0008MQ-PM for ieprep@ietf.org; Thu, 27 Jul 2006 15:34:12 -0400
Received: from ([128.244.96.244]) by pilot.jhuapl.edu with ESMTP id 5502123.2400938; Thu, 27 Jul 2006 15:33:39 -0400
Message-ID: <44C9160F.1060001@jhuapl.edu>
Date: Thu, 27 Jul 2006 15:37:51 -0400
From: "Robert G. Cole" <robert.cole@jhuapl.edu>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] on the ieprep charter
References: <44B4F17B.70105@jhuapl.edu> <80703C4C-C585-4601-9518-270A3A6A49CC@cisco.com> <44C9089E.3050802@jhuapl.edu> <B8C892A4-F711-4928-8EDA-FD7E717B702F@cisco.com>
In-Reply-To: <B8C892A4-F711-4928-8EDA-FD7E717B702F@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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
Is this something that is or should be captured within the text of the IEPREP charter, i.e., objectives for paritioning work into protocols at UNIs and NNIs and behaviors (where appropriate) within network interiors? Bob Fred Baker wrote: > 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
- [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Robert G. Cole
- Re: [Ieprep] on the ieprep charter Howard C. Berkowitz
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Nguyen, An P CIV NCS NC2
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Howard C. Berkowitz
- Re: [Ieprep] on the ieprep charter Fred Baker
- RE: [Ieprep] on the ieprep charter (UNCLASSIFIED) Rex Buddenberg
- Re: [Ieprep] on the ieprep charter ken carlberg
- [Ieprep] Question about the IEPREP Recharting Pro… Hannes Tschofenig
- Re: [Ieprep] on the ieprep charter Rex Buddenberg
- Re: [Ieprep] on the ieprep charter Fred Baker
- Re: [Ieprep] on the ieprep charter Janet P Gunn
- Re: [Ieprep] on the ieprep charter ken carlberg
- Re: [Ieprep] Question about the IEPREP Recharting… ken carlberg
- Re: [Ieprep] Question about the IEPREP Recharting… Hannes Tschofenig