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

["James M. Polk" <[e-mail]>]

this is good with me

At 02:33 AM 8/28/2007, Magnus Westerlund wrote:
>Hi again,
>
>I have received some more comments. So here is 
>an updated version adding DIME documents and correcting origin of documents.
>
>
>Submission
>Date:           <tbd>, 2007
>
>From:           IETF Working groups TSVWG, NSIS, DIME, 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]>,
>Hannes Tschofenig <[e-mail]>,
>David Frascone <[e-mail]>
>
>Response
>Contact:        TSV WG ([e-mail])
>                 NSIS ([e-mail])
>                 SIPPING ([e-mail])
>                 SIP ([e-mail])
>                 DIME ([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 Q.3/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 DIME, 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 to anyone, allowing participants in 
>Q.3/13 to keep themselves 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 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.
>
>         The below two documents are proposed 
> work items accepted to become IETF WG items 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.
>
>
>
>SIPPING 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.
>
>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.
>
>DIME Working Group
>
>Work In Progress: draft-ietf-dime-diameter-qos-01.txt
>
>Title:
>   Diameter Quality of Service Application
>
>Abstract:
>   This document describes a Diameter application that performs
>   Authentication, Authorization, and Accounting for Quality of Service
>   (QoS) reservations.  This protocol is used by elements along the path
>   of a given application flow to authenticate a reservation request,
>   ensure that the reservation is authorized, and to account for
>   resources consumed during the lifetime of the application flow.
>   Clients that implement the Diameter QoS application contact an
>   authorizing entity/application server that is located somewhere in
>   the network, allowing for a wide variety of flexible deployment
>   models.
>
>Work In Progress: draft-ietf-dime-qos-parameters-00.txt
>
>Title:
>   Quality of Service Parameters for Usage with the AAA Framework
>
>Abstract:
>   This document defines a number of Quality of Service (QoS) parameters
>   that can be reused for conveying QoS information within RADIUS and
>   Diameter.
>
>   The payloads used to carry these QoS parameters are opaque for the
>   AAA client and the AAA server itself and interpreted by the
>   respective Resource Management Function.
>
>Work In Progress: draft-ietf-dime-qos-attributes-01.txt
>
>Title:
>   Quality of Service Attributes for Diameter and RADIUS
>
>Abstract:
>   This document extends the functionality of the Diameter Base protocol
>   and other Diameter applications with respect to their ability to
>   convey Quality of Service information.  The AVPs defined in this
>   document are also available for Remote Authentication Dial In User
>   Service (RADIUS).
>
>
>Non-WG Documents
>
>         Approved for publication: draft-carlberg-trip-attribute-rp-02.txt
>
>         Title:
>           TRIP Attribute for Resource Priority
>
>Abstract:
>    This document defines a new attribute for  the  TRIP  protocol.   The
>    attribute   associates   protocols/services   in  the  PSTN  offering
>    authorized  prioritization  during  call  setup  that  are  reachable
>    through  a TRIP gateway.  Current examples of preferential service in
>    the PSTN are Government Emergency Telecommunications  Service  (GETS)
>    in  the U.S. and Government Telephone Preference Scheme (GTPS) in the
>    U.K.  The proposed attribute for TRIP is based on the NameSpace.Value
>    tupple defined for the SIP resource Priority field.
>
>
>
>
>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


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