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

[Fred Baker <fred at cisco.com>]

> 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?

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf