[NSIS] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications

[Janet P Gunn <[e-mail]>]

Magnus,

You might want to add-

draft-polk-tsvwg-signaled-domain-id-00.txt
and 
draft-polk-ecrit-local-emergency-rph-namespace-01.txt

(Both were on the agenda and discussed.)

And maybe
draft-carlberg-trip-attribute-rp-02 

(though I did not see it on the agenda)

Janet

PS,

My spelling checker says "Liaision" should be "Liaison", but it may be a 
US centric dictionary.
J
Magnus Westerlund <[e-mail]> wrote on 07/31/2007 
11:21:20 AM:

> Hi
> 
> This is the draft for a liaison response to be sent to SG 13 of the 
> ITU-T from the TSVWG, NSIS, SIP and SIPPING WGs. Please provide any 
> comments at the latest by the 14th of August. After that we will address 

> any raised comments and send the liaison to ITU-T before the end of 
August.
> 
> Submission
> Date:      <tbd>, 2007
> 
> From:       IETF Working groups TSVWG, NSIS, SIP and SIPPING
> 
> To:      Georges Sebek  <[e-mail]> ,
>       Keith Knightson <[e-mail]>
> 
> Cc:      Magnus Westerlund <[e-mail]>,
>                  Lars Eggert <[e-mail]>,
>                  James Polk <[e-mail]>,
>                  Martin Stiemerling <[e-mail]>,
>                  John Loughney <[e-mail]>
>                  Dean Willis <[e-mail]>,
>                  Keith Drage <[e-mail]>,
>                  Mary Barnes <[e-mail]>,
>                  Gonzalo Camarillo <[e-mail]>,
>                  Scott Bradner <[e-mail]>,
>                  Kimberly King <[e-mail]>,
>                  Scott Brim <[e-mail]>
> 
> Response
> Contact:   TSV WG ([e-mail])
>       NSIS ([e-mail])
>       SIPPING ([e-mail])
>       SIP ([e-mail])
> 
> Purpose:    Response to Liaison Request
> 
> Deadline:   None
> 
> Title: Response to liaison request from ITU-T Study Group 13 work on 
> emergency telecommunications
> 
> This is a response to the liaison request made by Q3/13 regarding 
> emergency telecommunications (REF: NGN-GSI/DOC – 60 Rev.2). We would 
> first like to apologize for failing to meet the deadline in responding. 
> We do hope that the late answer still can be of some use.
> 
> The liaison request was made to the following working groups (WG): 
> IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has 
> concluded. In addition to the WGs from which information was requested, 
> we also think that work performed by the SIP and SIPPING WG may be of 
> relevance.
> 
> Pursuant to ITU-T Study Group 13 request for information on relevant and 

> related work in the IETF regarding emergency communications, we list 
> below RFCs and works in progress that we feel may be of interest to your 

> group.  Some of the completed work is Informational, and others are in 
> the category of Standards Track.
> 
> Q.3/13 also requested that we keep you informed of any developments in 
> regards to emergency telecommunications. In those regards we would like 
> to make you aware that IETF mailing list participation and document 
> information is free and open for anyone. Allowing participants in Q.3/13 

> to keep them selves informed of any developments. If Q.3/13 desire to 
> get further information about specific ongoing work, then please send a 
> liaison request to the responsible WG for those specific documents.
> 
> The following list is divided under the associated working groups from 
> which the work has been done within the IETF.
> 
> 
> SIP Working Group
> 
> RFC 4411
> 
> Title:
>     Extending the Session Initiation Protocol (SIP)
>     Reason Header for Preemption Events
> 
> Abstract:
>    This document proposes an IANA Registration extension to the Session
>     Initiation Protocol (SIP) Reason Header to be included in a BYE
>     Method Request as a result of a session preemption event, either at 
a
>     user agent (UA), or somewhere in the network involving a
>     reservation-based protocol such as the Resource ReSerVation Protocol
>     (RSVP) or Next Steps in Signaling (NSIS).  This document does not
>     attempt to address routers failing in the packet path; instead, it
>     addresses a deliberate tear down of a flow between UAs, and informs
>     the terminated UA(s) with an indication of what occurred.
> 
> RFC 4412
> 
> Title:
>     Communications Resource Priority for the Session Initiation
>     Protocol (SIP)
> 
> Abstract:
>     This document defines two new Session Initiation Protocol (SIP)
>     header fields for communicating resource priority, namely,
>     "Resource-Priority" and "Accept-Resource-Priority".  The
>     "Resource-Priority" header field can influence the behavior of SIP
>     user agents (such as telephone gateways and IP telephones) and SIP
>     proxies.  It does not directly influence the forwarding behavior of
>     IP routers.
> 
> 
> 
> SIPPING Working Group
> 
>     The below two documents are proposed work items not yet accepted as
>     IETF WG items but are likely of interest as they update RFC 4412.
> 
> Work In Progress:   draft-polk-sip-rph-in-responses-00
> 
> Title:
>     Allowing SIP Resource Priority Header in SIP Responses
> 
> Abstract:
>     The Session Initiation Protocol (SIP) Resource Priority Header
>     (RPH), in its current form, is ignored in SIP responses.  This was a
>     design choice during RFC 4412's development. This is now considered
>     a bad design choice in certain scenarios.  This document corrects
>     RFC 4412's communications model by optionally allowing a SIP server
>     or user agent client to process the Resource-Priority Header in a
>     response.
> 
> Work In Progress:   draft-polk-sip-rph-new-namespaces--00
> 
> Title:
>     New Session Initiation Protocol Resource-Priority Header Namespaces
>     for the Defense Information Systems Agency
> 
> Abstract:
>     This document creates additional Session Initiation Protocol
>     Resource-Priority header namespaces, to be IANA registered.  This
>     document intends to update RFC 4412, as a Proposed Standard document
>     if published by the RFC-Editor.
> 
> IEPREP Working Group
> 
> RFC 3487
> 
> Title:
>     Requirements for Resource Priority Mechanisms for the
>     Session Initiation Protocol (SIP)
> 
> Abstract:
>     This document summarizes requirements for prioritizing access to
>     circuit-switched network, end system and proxy resources for
>     emergency preparedness communications using the Session Initiation
>     Protocol (SIP).
> 
> RFC 3689
> 
> Title:
>     General Requirements for
>     Emergency Telecommunication Service (ETS)
> 
> Abstract:
>     This document presents a list of general requirements in support of
>     Emergency Telecommunications Service (ETS).  Solutions to these
>     requirements are not presented in this document.  Additional
>     requirements pertaining to specific applications, or types of
>     applications, are to be specified in separate document(s).
> 
> RFC 3690
> 
> Title:
>     IP Telephony Requirements for
>     Emergency Telecommunication Service (ETS)
> 
> Abstract:
>     This document presents a list of requirements in support of 
Emergency
>     Telecommunications Service (ETS) within the context of IP telephony.
>     It is an extension to the general requirements presented in RFC 
3689.
>     Solutions to these requirements are not presented in this document.
> 
> RFC 4190
> 
> Title:
>     Framework for Supporting Emergency Telecommunications
>     Service (ETS) in IP Telephony
> 
> Abstract:
>     This document presents a framework for supporting authorized,
>     emergency-related communication within the context of IP telephony.
>     We present a series of objectives that reflect a general view of how
>     authorized emergency service, in line with the Emergency
>     Telecommunications Service (ETS), should be realized within today's
>     IP architecture and service models.  From these objectives, we
>     present a corresponding set of protocols and capabilities, which
>     provide a more specific set of recommendations regarding existing
>     IETF protocols.  Finally, we present two scenarios that act as
>     guiding models for the objectives and functions listed in this
>     document.  These models, coupled with an example of an existing
>     service in the Public Switched Telephone Network (PSTN), contribute
>     to a constrained solution space.
> 
> RFC 4375
> 
> Title:
>     Emergency Telecommunications Services (ETS) Requirements
>     for a Single Administrative Domain
> 
> Abstract:
>     This document presents a list of requirements in support of 
Emergency
>     Telecommunications Service (ETS) within a single administrative
>     domain.  This document focuses on a specific set of administrative
>     constraints and scope.  Solutions to these requirements are not
>     presented in this document.
> 
> 
> TSV Working Group
> 
> RFC 4542
> 
> Title:
>     Implementing an Emergency Telecommunications Service (ETS)
>     for Real-Time Services in the Internet Protocol Suite
> 
> Abstract:
>     RFCs 3689 and 3690 detail requirements for an Emergency
>     Telecommunications Service (ETS), of which an Internet Emergency
>     Preparedness Service (IEPS) would be a part.  Some of these types of
>     services require call preemption; others require call queuing or
>     other mechanisms.  IEPS requires a Call Admission Control (CAC)
>     procedure and a Per Hop Behavior (PHB) for the data that meet the
>     needs of this architecture.  Such a CAC procedure and PHB is
>     appropriate to any service that might use H.323 or SIP to set up
>     real-time sessions.  The key requirement is to guarantee an elevated
>     probability of call completion to an authorized user in time of
>     crisis.
> 
>     This document primarily discusses supporting ETS in the context of
>     the US Government and NATO, because it focuses on the Multi-Level
>     Precedence and Preemption (MLPP) and Government Emergency
>     Telecommunication Service (GETS) standards.  The architectures
>     described here are applicable beyond these organizations.
> 
> Work In Progress:   draft-ietf-tsvwg-emergency-rsvp-03.txt
> 
> Title:
>     Resource ReSerVation Protovol (RSVP) Extensions for
>     Emergency Services
> 
> Abstract:
>     An Emergency Telecommunications Service (ETS) requires the ability 
to
>     provide an elevated probability of session establishment to an
>     authorized user in times of network congestion (typically, during a
>     crisis). When supported over the Internet Protocol suite, this may 
be
>     facilitated through a network layer admission control solution, 
which
>     supports prioritized access to resources (e.g., bandwidth). These
>     resources may be explicitly set aside for emergency services, or 
they
>     may be shared with other sessions.
> 
>    This document specifies RSVP extensions that can be used to support
>     such an admission priority capability at the network layer. Note 
that
>     these extensions represent one possible solution component in
>     satisfying ETS requirements. Other solution components, or other
>     solutions, are outside the scope of this document.
> 
> NSIS Working Group
> 
> Work In Progress: draft-ietf-nsis-qos-nslp-14.txt
> 
> Title:
>     NSLP for Quality-of-Service Signaling
> 
> Abstract:
>     This specification describes the NSIS Signaling Layer Protocol
>     (NSLP) for signaling QoS reservations in the Internet.  It is in
>     accordance with the framework and requirements developed in NSIS.
>     Together with GIST, it provides functionality similar to RSVP and
>     extends it.  The QoS NSLP is independent of the underlying QoS
>     specification or architecture and provides support for different
>     reservation models. It is simplified by the elimination of support
>     for multicast flows. This specification explains the overall
>     protocol approach, design decisions made and provides examples.  It
>     specifies object, message  formats and processing rules.
> 
> -- 
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis