[HICCUP] IETF-Announce Digest, Vol 36, Issue 11

Ed Jankiewicz <edward.jankiewicz@sri.com> Tue, 17 April 2007 16:08 UTC

Return-path: <hiccup-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqEQ-0004qM-RO; Tue, 17 Apr 2007 12:08:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqEP-0004q9-HX for hiccup@ietf.org; Tue, 17 Apr 2007 12:08:37 -0400
Received: from mailgate-internal1.sri.com ([128.18.84.103]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdqEN-0003jv-Kg for hiccup@ietf.org; Tue, 17 Apr 2007 12:08:37 -0400
Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 17 Apr 2007 16:08:34 -0000
Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2007041709083432139 for <hiccup@ietf.org>; Tue, 17 Apr 2007 09:08:34 -0700
Received: from [127.0.0.1] (static-68-236-201-128.nwrk.east.verizon.net [68.236.201.128]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JGN00MJIGU99BXG@mail.sri.com> for hiccup@ietf.org; Tue, 17 Apr 2007 09:08:34 -0700 (PDT)
Date: Tue, 17 Apr 2007 12:08:34 -0400
From: Ed Jankiewicz <edward.jankiewicz@sri.com>
To: hiccup@ietf.org
Message-id: <4624F102.40109@sri.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Subject: [HICCUP] IETF-Announce Digest, Vol 36, Issue 11
X-BeenThere: hiccup@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Harnessing IP for Critical Communications Using Precedence \(HICCUP\) list" <hiccup.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hiccup>, <mailto:hiccup-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hiccup>
List-Post: <mailto:hiccup@ietf.org>
List-Help: <mailto:hiccup-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hiccup>, <mailto:hiccup-request@ietf.org?subject=subscribe>
Errors-To: hiccup-bounces@ietf.org

redundant if you follow IEPREP but of interest.

    4. Document Action: 'A Framework for Supporting Emergency
       Telecommunications Services (ETS) Within a Single Administrative
       Domain' to Informational RFC  (The IESG)



Message: 4
Date: Mon, 16 Apr 2007 21:27:59 -0400
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: 'A Framework for Supporting Emergency
	Telecommunications Services (ETS) Within a Single Administrative
	Domain' to Informational RFC
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>rg>,	ieprep chair
	<ieprep-chairs@tools.ietf.org>rg>,	ieprep mailing list <ieprep@ietf.org>rg>,
	RFC Editor <rfc-editor@rfc-editor.org>
Message-ID: <E1HdcUB-0001JP-Et@stiedprstage1.ietf.org>

The IESG has approved the following document:

- 'A Framework for Supporting Emergency Telecommunications Services (ETS)
    Within a Single Administrative Domain '
    <draft-ietf-ieprep-domain-frame-08.txt> as an Informational RFC

This document is the product of the Internet Emergency Preparedness
Working Group.

The IESG contact persons are Jon Peterson and Cullen Jennings.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-frame-08.txt

Technical Summary

This document presents a framework discussing the role of various
protocols andmechanisms that could be considered candidates for supporting
Emergency Telecommunication Services (ETS) within a single administrative
domain.  Comments about their potential usage as well as their current
deployment are provided to the reader.  Specific solutions are not
presented.

Working Group Summary

The IEPREP WG supported the advancement of this document.

Protocol Quality

This document was reviewed for the IESG by Jon Peterson.

Note to RFC Editor

Section 3.1

OLD:
   A more ambitious way of supporting the mobile user is through the use
   of the Mobile IP (MIP) protocol.  In this case and at the IP level,
   foreign networks introduce the concept of triangle routing and the
   potential for multiple access points and service context within a
   subnetwork.  In addition, policy plays a critical role in dictating
   the measure of available services to the mobile user.

   The beaconing capability of MIP allows it to offer a measure of
   application transparent mobility as a mobile host (MH) moves from one
   subnetwork to another.

   However, this feature may not be available in
   most domains.  In addition, its management requirements may
   discourage its widespread deployment and use.  Hence, users should
   probably not rely on its existence, but rather may want to expect a
   more simpler approach based on DHCP as described above.  The subject
   of mobile IP is discussed below in Section 4.
NEW:
   A more ambitious way of supporting the mobile user is through
   the use of the Mobile IP (MIP) protocol. MIP offers a measure of
   application transparent mobility as a mobile host moves
   from one subnetwork to another while keeping the same stable
   IP address registered at a global anchor point. However, this
   feature may not always be available or in use. In any case,
   where it is in use, at least some of the packets destined to
   and from the mobile host go through the home network.




------------------------------

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce


End of IETF-Announce Digest, Vol 36, Issue 11
*********************************************


_______________________________________________
HICCUP mailing list
HICCUP@ietf.org
https://www1.ietf.org/mailman/listinfo/hiccup