[Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

Fred Baker <fred@cisco.com> Wed, 15 November 2006 23:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUSh-00018H-Mj; Wed, 15 Nov 2006 18:46:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUSf-000170-LM; Wed, 15 Nov 2006 18:46:33 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkUSe-0005D3-9Z; Wed, 15 Nov 2006 18:46:33 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 15:46:31 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAFNkV7g008289; Wed, 15 Nov 2006 15:46:31 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAFNkVio017344; Wed, 15 Nov 2006 15:46:31 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:46:31 -0800
Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:46:30 -0800
In-Reply-To: <tslhcxihmw3.fsf@cz.mit.edu>
References: <E1GfLJY-0003B5-Pg@ietf.org> <tslhcxihmw3.fsf@cz.mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B888BD3F-5A98-439D-8909-5971D2096F23@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Wed, 15 Nov 2006 15:46:29 -0800
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 15 Nov 2006 23:46:30.0968 (UTC) FILETIME=[46770380:01C70910]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3399; t=1163634391; x=1164498391; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20Re=3A=20WG=20Review=3A=20Recharter=20of=20Internet=20Emergenc y=20Preparedness=20(ieprep) |Sender:=20; bh=JjFl7XAHleW/ilkdlaDrgOEjF8SA8q/4pxaoGEki844=; b=p3hiRM4Sj/F800SSBmUNPqs6zWLYIQ5y+fkFENMhSa5vpaWZKIqoSn6sCd11USsfcGilWhJI iTCgcRA9QsfaA5koyEOzcPd4MDnJBUa7rcPa8yTYBW2gf7lD+DgDPgV7;
Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: Kimberly King <kimberly.s.king@saic.com>, ietf@ietf.org, ieprep@ietf.org, Scott Bradner <sob@harvard.edu>
Subject: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
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

> I don't believe the new charter of ieprep working group belongs in  
> the IETF... the work that remains belongs somewhere else--probably  
> the ITU-T.

Let's address this directly.

ITU-T gave us a set of requirements in
    [3]  "Description of an International Emergency Preference Scheme
         (IEPS)", ITU-T Recommendation  E.106 March, 2000.

    [4]  "Description for an International Emergency Multimedia  
Service",
         ITU Draft Recommendation F.706, February, 2002.

    [5]  "Call Priority Designation for H.323 Calls", ITU Recommendation
         H.460.4, November, 2002.

    [6]  ITU, "Multi-Level Precedence and Preemption Service, ITU,
         Recommendation, I.255.3, July, 1990.

We had to rewrite them, resulting in

> http://www.ietf.org/rfc/rfc3523.txt
> 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology
>      Terminology. J. Polk. April 2003. (Format: TXT=10190 bytes)  
> (Status:
>      INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc3689.txt
> 3689 General Requirements for Emergency Telecommunication Service
>      (ETS). K. Carlberg, R. Atkinson. February 2004. (Format:  
> TXT=21680
>      bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc3690.txt
> 3690 IP Telephony Requirements for Emergency Telecommunication Service
>      (ETS). K. Carlberg, R. Atkinson. February 2004. (Format:  
> TXT=13919
>      bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc4190.txt
> 4190 Framework for Supporting Emergency Telecommunications Service
>      (ETS) in IP Telephony. K. Carlberg, I. Brown, C. Beard. November
>      2005. (Format: TXT=69447 bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc4375.txt
> 4375 Emergency Telecommunications Services (ETS) Requirements for a
>      Single Administrative Domain. K. Carlberg. January 2006. (Format:
>      TXT=17037 bytes) (Status: INFORMATIONAL)

We also specifically addressed their requirements (in tsvwg)  
operationally:

> http://www.ietf.org/rfc/rfc4542.txt
> 4542 Implementing an Emergency Telecommunications Service (ETS) for
>      Real-Time Services in the Internet Protocol Suite. F. Baker,  
> J. Polk.
>      May 2006. (Format: TXT=99770 bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc4594.txt
> 4594 Configuration Guidelines for DiffServ Service Classes. J.
>      Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044  
> bytes)
>      (Status: INFORMATIONAL)
>
> http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-class-aggr
>   "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 22-Oct-06
> and
> http://tools.ietf.org/html/draft-baker-tsvwg-admitted-voice-dscp
>   "An EF DSCP for Capacity-Admitted Traffic", Fred Baker, 6-Oct-06

The last two are in last call and in discussion in tsvwg respectively.

The remaining requirements, as I understand them, relate to more  
traditional internet applications: the delivery of email within a  
stated interval, reliable file transfer at a stated rate in the  
presence of imperfect links and competing traffic deemed by the  
administration to be of lower importance, instant messaging, and so on.

What is the argument by which you come to believe that traditional  
internet transports and applications that are standardized in the  
IETF are properly moved to other standards bodies?

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