From pkyzivat@alum.mit.edu Mon Jan 14 13:59:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE421F8B19 for ; Mon, 14 Jan 2013 13:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKEYdBu6Lnd5 for ; Mon, 14 Jan 2013 13:59:07 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 1971421F8B0A for ; Mon, 14 Jan 2013 13:59:06 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id noWf1k0041ZXKqc54xz6QS; Mon, 14 Jan 2013 21:59:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id nxz61k00g3ZTu2S3hxz6SP; Mon, 14 Jan 2013 21:59:06 +0000 Message-ID: <50F47FA9.6020003@alum.mit.edu> Date: Mon, 14 Jan 2013 16:59:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ECRIT References: <20130114210019.15005.16280.idtracker@ietfa.amsl.com> In-Reply-To: <20130114210019.15005.16280.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130114210019.15005.16280.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358200746; bh=Vy8IppPWb2q27WsfvezhFRPLJXaIzaqoFRNhZUseNxg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VuCg5V8B3I9jsayLTk4jt4hq7GEiDHLlh+jRFlvjOs9Uzz9SUaaC68yr3jp+KUn2P 4QwMuRFB+v4SZHazOmqy1M69zsraUCqwUSi0lL48Ztj4+kiUdvksr5AQH6pjuy7Kta cr+OWLFM+95mK0LqZVr2wXe1f3yMq2NfdOplRAZZ/6HcX6MHfAsS1xUyhr4vameok/ R+BQyHOXfYGoAHdqMyD1NZQMsBXn0lixmnnOBL0BxYRTN0nZhb2ZAQTKyhUxX1VsNY JpgQ2TkJdGxJX4bvBGljiDT8ycukEex0D+hGxu2cbAGSXKZ5SYaa7Kh8Rab6e5wpDp mZritnlh0Hy3Q== Subject: [Ecrit] FYI: IESG has approved draft-ietf-sipcore-priority-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:59:08 -0000 You might be interested. Thanks, Paul -------- Original Message -------- Subject: [sipcore] Protocol Action: 'IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field' to Proposed Standard (draft-ietf-sipcore-priority-00.txt) Date: Mon, 14 Jan 2013 13:00:19 -0800 From: The IESG To: IETF-Announce CC: sipcore mailing list , sipcore chair , RFC Editor The IESG has approved the following document: - 'IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field' (draft-ietf-sipcore-priority-00.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-priority/ Technical Summary This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. This header field was defined in [RFC3261], section 20.26. It was clearly specified in a way that allows for the creation of new values beyond those originally specified; however, no registry has been established for it. Working Group Summary This work was initiated because the ECRIT WG had a need to define a new value for the Priority header field, for use in new document draft-ietf-ecrit-psap-callback. RFC 3261 was written to allow such extensions, but had no mechanism to manage extensions. The chairs of ECRIT and SIPCORE and the ADs discussed this and considered various mechanisms to move forward. The alternatives considered were: - construct the ECRIT document as an update to RFC 3261, extending the syntax of the Priority header field. - construct the ECRIT document as an update to RFC 3261, introducing an IANA registry for Priority header field values, populating it with those values defined in RFC 3261 and also the desired new value. - publish a new draft, in the SIPCORE WG, that updates RFC 3261, introducing an IANA registry for Priority header field values, and populating it with those values defined in RFC 3261. Then the ECRIT WG can modify their document to register the new value in accord with the new registration procedures. We concluded that the last approach was the cleanest one. This draft is result. Document Quality Are there existing implementations of the protocol? This defines no new protocol. draft-ietf-ecrit-psap-callback is progressing in parallel and will make use of the new registration mechanism. Have a significant number of vendors indicated their plan to implement the specification? N/A Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? The document is very simple, so didn't require great effort to review. The primary commenters on the draft were Christer Holmberg and Keith Drage. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Robert Sparks RFC-Editor Note: Please make the following three changes to version -00 of this draft) Change 1 (replaces text): OLD: This document adds a new registry, "Priority Header Field Values." NEW: This document adds a new sub-registry, "Priority Header Field Values" to the "Session Initiation Protocol (SIP) Parameters" registry page. Change 2 (only adds text): OLD: The policy for registration of values in this registry is "IETF Review," as that term is defined by [RFC5226]. NEW: The policy for registration of values in this registry is "IETF Review," as that term is defined by [RFC5226]. This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. Efforts considering adding a Priority value should consider whether the SIP Resource-Priority [RFC4412] or even a different protocol would be more appropriate for achieving their requirements. Change 3 : Please add an informational reference to RFC4412. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From brian.rosen@neustar.biz Tue Jan 15 08:49:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3881E21F85D6 for ; Tue, 15 Jan 2013 08:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POf+zy04-bbP for ; Tue, 15 Jan 2013 08:49:44 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24A21F8585 for ; Tue, 15 Jan 2013 08:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1358268575; x=1673622862; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=JlbzBxJv5zfkr7gn37vvk0xmvCMsWuJWpoPp0eid/9A=; b=dfgSvZRPNwaJvew1RWhqVerWBII1J8vzeoLO6Ain8tZIoPbmIbVBPV/ir5ESUR SlEvmoa51mwxjtDpIiccMfgw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP id J041123128.13960486; Tue, 15 Jan 2013 11:49:34 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 15 Jan 2013 11:49:40 -0500 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Tue, 15 Jan 2013 11:49:39 -0500 Thread-Topic: [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) Thread-Index: Ac3zQE9j57U9wNGZRR6RYPLj7+M0Ew== Message-ID: References: <20130115154532.11812.87070.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 29ZmGk/RbzYRxBDhZ1AIsA== Content-Type: multipart/alternative; boundary="_000_D1F59F4F6ED645A29FC6FE25FA7B7868neustarbiz_" MIME-Version: 1.0 Subject: [Ecrit] Fwd: [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:49:45 -0000 --_000_D1F59F4F6ED645A29FC6FE25FA7B7868neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's finally done. When the RFC Editor publishes this, -phonebcp will be p= ublished. Brian Begin forwarded message: From: The IESG > Subject: [MMUSIC] Protocol Action: 'An Extension to the Session Description= Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' = to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) Date: January 15, 2013 10:45:32 AM EST To: IETF-Announce > Cc: mmusic chair >, mmusic mailing list >, R= FC Editor > The IESG has approved the following document: - 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' (draft-ietf-mmusic-media-loopback-27.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ Technical Summary This document provides extensions to the Session Description Protocol (SDP) and the Real-time Transport Protocol (RTP) for enabling looping of sent media. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. The extension defined herein adds new SDP media types and attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. Working Group Summary The first version of the document was available at the end of 2004. Since that time, the working group has been discussing a number of issues toward getting the consensus that is believed to be achieved in version 22. The description of a latching mechanism to traverse NATs and firewalls was discussed and decided to be removed from the actual document in favor of standard NAT traversal techniques such as ICE/STUN/TURN. Document Quality At least four implementations of this functionality are known. Four other vendors have indicated they plan to implement it. The document was WGLCed on version 16. Additionally, the PAYLOAD WG also conducted a thorough review of the same 16 version. As a result of these reviews, 34 changes were requested by, among others, Tolga Asveren, Dan Wing, Emil Ivov, Flemming Andreasen, and Miguel A. Garcia. These comments were subsequently introduced into versions 17 and 18. A new WGLC was issued on version 18, bringing a new set of comments by Flemming Andreasen, Magnus Westerlund, and Gunnar Hellstrom. These were addressed in version 19. At least Magnus Westerlund and Flemming Andreasen did a thorough review of the document as part of the WGLC on version 18. Version 18 was sent to the ietf-types mailing list for review on April 4, 2012. Bjorern Hoehrmann and Magnus Westerlund posted comments that were addressed in version 19. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Miguel A. Garcia is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D1F59F4F6ED645A29FC6FE25FA7B7868neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's finally done.  = When the RFC Editor publishes this, -phonebcp will be published.

Brian


Begin forwarded message:
From: The IESG <i= esg-secretary@ietf.org>
S= ubject: [MMUSIC] Protocol Action: 'An Extension to the Session Description Pr= otocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to = Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt)
<= /div>
Date: January 15, 2013 10:45:32 AM EST
To: IETF-Announce <ietf-announce@ietf.org>
Cc: mmusic chair <mmusic-chairs@tools.ietf.org>, mmusic mailing list <mmusic@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
=

The IESG has approved the following document:
- 'A= n Extension to the Session Description Protocol (SDP) and Real-time
&nb= sp; Transport Protocol (RTP) for Media Loopback'
 (draft-ietf= -mmusic-media-loopback-27.txt) as Proposed Standard

This document is= the product of the Multiparty Multimedia Session Control
Working Group.=

The IESG contact persons are Gonzalo Camarillo and Robert Sparks.
A URL of this Internet Draft is:
http://datatracker.ietf.org/do= c/draft-ietf-mmusic-media-loopback/




Technical Summar= y

This document provides extensions to the Session Description Proto= col
(SDP) and the Real-time Transport Protocol (RTP) for enabling loopin= g
of sent media. Media loopback is especially popular in ensuring thequality of transport to the edge of a given VoIP, Real-time Text or
Vid= eo over IP service. The extension defined herein adds new SDP media
type= s and attributes, which enable establishment of media sessions
where the= media is looped back to the transmitter. Such media sessions
will serve= as monitoring and troubleshooting tools by providing the
means for meas= urement of more advanced VoIP, Real-time Text and Video
over IP performa= nce metrics.

Working Group Summary

The first version of the d= ocument was available at the end of 2004.
Since that time, the working g= roup has been discussing a number of
issues toward getting the consensus= that is believed to be achieved in
version 22.

The description o= f a latching mechanism to traverse NATs and firewalls
was discussed and = decided to be removed from the actual document in
favor of standard NAT = traversal techniques such as ICE/STUN/TURN.

Document Quality

= At least four implementations of this functionality are known. Four
othe= r vendors have indicated they plan to implement it.

The document was= WGLCed on version 16. Additionally, the PAYLOAD WG
also conducted a tho= rough review of the same 16 version. As a result of
these reviews, 34 ch= anges were requested by, among others, Tolga
Asveren, Dan Wing, Emil Ivo= v, Flemming Andreasen, and Miguel A. Garcia.
These comments were subsequ= ently introduced into versions 17 and 18. A
new WGLC was issued on versi= on 18, bringing a new set of comments by
Flemming Andreasen, Magnus West= erlund, and Gunnar Hellstrom. These were
addressed in version 19.
At least Magnus Westerlund and Flemming Andreasen did a thorough reviewof the document as part of the WGLC on version 18.

Version 18 was s= ent to the ietf-types mailing list for review on April
4, 2012. Bjorern = Hoehrmann and Magnus Westerlund posted comments that
were addressed in v= ersion 19.

Personnel

Who is the Document Shepherd? Who is the= Responsible Area
Director?

Miguel A. Garcia is the Document Shep= herd. Gonzalo Camarillo is the
Responsible Area Director
___________= ____________________________________
mmusic mailing list
mmusic@ietf.= org
https://www.ietf.org/mailman/listinfo/mmusic
<= /div>
= --_000_D1F59F4F6ED645A29FC6FE25FA7B7868neustarbiz_-- From rbarnes@bbn.com Tue Jan 15 12:42:48 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6879B21F8431 for ; Tue, 15 Jan 2013 12:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z20jW12AvazT for ; Tue, 15 Jan 2013 12:42:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5421F8233 for ; Tue, 15 Jan 2013 12:42:47 -0800 (PST) Received: from ros-dhcp192-1-51-63.bbn.com ([192.1.51.63]:55786) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TvDLK-0008sy-2m; Tue, 15 Jan 2013 15:42:46 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: Date: Tue, 15 Jan 2013 15:42:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4F8C790D-0030-427B-9DF2-55D457D05F26@bbn.com> References: <20130115154532.11812.87070.idtracker@ietfa.amsl.com> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1499) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] [MMUSIC] Protocol Action: 'An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback' to Proposed Standard (draft-ietf-mmusic-media-loopback-27.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:42:48 -0000 On Jan 15, 2013, at 11:49 AM, "Rosen, Brian" = wrote: > It's finally done. When the RFC Editor publishes this, -phonebcp will = be published. >=20 > Brian >=20 >=20 > Begin forwarded message: >=20 >> From: The IESG >> Subject: [MMUSIC] Protocol Action: 'An Extension to the Session = Description Protocol (SDP) and Real-time Transport Protocol (RTP) for = Media Loopback' to Proposed Standard = (draft-ietf-mmusic-media-loopback-27.txt) >> Date: January 15, 2013 10:45:32 AM EST >> To: IETF-Announce >> Cc: mmusic chair , mmusic mailing list = , RFC Editor >>=20 >> The IESG has approved the following document: >> - 'An Extension to the Session Description Protocol (SDP) and = Real-time >> Transport Protocol (RTP) for Media Loopback' >> (draft-ietf-mmusic-media-loopback-27.txt) as Proposed Standard >>=20 >> This document is the product of the Multiparty Multimedia Session = Control >> Working Group. >>=20 >> The IESG contact persons are Gonzalo Camarillo and Robert Sparks. >>=20 >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ >>=20 >>=20 >>=20 >>=20 >> Technical Summary >>=20 >> This document provides extensions to the Session Description Protocol >> (SDP) and the Real-time Transport Protocol (RTP) for enabling looping >> of sent media. Media loopback is especially popular in ensuring the >> quality of transport to the edge of a given VoIP, Real-time Text or >> Video over IP service. The extension defined herein adds new SDP = media >> types and attributes, which enable establishment of media sessions >> where the media is looped back to the transmitter. Such media = sessions >> will serve as monitoring and troubleshooting tools by providing the >> means for measurement of more advanced VoIP, Real-time Text and Video >> over IP performance metrics. >>=20 >> Working Group Summary >>=20 >> The first version of the document was available at the end of 2004. >> Since that time, the working group has been discussing a number of >> issues toward getting the consensus that is believed to be achieved = in >> version 22. >>=20 >> The description of a latching mechanism to traverse NATs and = firewalls >> was discussed and decided to be removed from the actual document in >> favor of standard NAT traversal techniques such as ICE/STUN/TURN. >>=20 >> Document Quality >>=20 >> At least four implementations of this functionality are known. Four >> other vendors have indicated they plan to implement it. >>=20 >> The document was WGLCed on version 16. Additionally, the PAYLOAD WG >> also conducted a thorough review of the same 16 version. As a result = of >> these reviews, 34 changes were requested by, among others, Tolga >> Asveren, Dan Wing, Emil Ivov, Flemming Andreasen, and Miguel A. = Garcia. >> These comments were subsequently introduced into versions 17 and 18. = A >> new WGLC was issued on version 18, bringing a new set of comments by >> Flemming Andreasen, Magnus Westerlund, and Gunnar Hellstrom. These = were >> addressed in version 19. >>=20 >> At least Magnus Westerlund and Flemming Andreasen did a thorough = review >> of the document as part of the WGLC on version 18. >>=20 >> Version 18 was sent to the ietf-types mailing list for review on = April >> 4, 2012. Bjorern Hoehrmann and Magnus Westerlund posted comments that >> were addressed in version 19. >>=20 >> Personnel >>=20 >> Who is the Document Shepherd? Who is the Responsible Area >> Director? >>=20 >> Miguel A. Garcia is the Document Shepherd. Gonzalo Camarillo is the >> Responsible Area Director=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ietf-ipr@ietf.org Fri Jan 25 08:46:14 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C74921F8884; Fri, 25 Jan 2013 08:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTGEYMvDWhda; Fri, 25 Jan 2013 08:46:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2FE21F8878; Fri, 25 Jan 2013 08:46:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: br@brianrosen.net, jmpolk@cisco.com, andy@hxr.us, hgs@cs.columbia.edu X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130125164613.20774.42131.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 08:46:13 -0800 X-Mailman-Approved-At: Fri, 25 Jan 2013 09:57:20 -0800 Cc: marc.linsner@cisco.com, ecrit@ietf.org, ipr-announce@ietf.org Subject: [Ecrit] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 6443 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:46:14 -0000 Dear Brian Rosen, James M. Polk, Andrew Newton, Henning Schulzrinne: An IPR disclosure that pertains to your RFC entitled "Framework for Emerge= ncy Calling Using Internet Multimedia" (RFC6443) was submitted to the IETF Secretariat on 2013-01-15 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1948/). The = title of the IPR disclosure is "Qualcomm Incorporated's Statement about IPR relat= ed to RFC 6443.""); The IETF Secretariat From hannes.tschofenig@gmx.net Tue Jan 29 07:19:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EAC21F88A6 for ; Tue, 29 Jan 2013 07:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gof-2dgRHBvT for ; Tue, 29 Jan 2013 07:19:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1B17B21F886C for ; Tue, 29 Jan 2013 07:19:26 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M0NrX-1UrcX21EyL-00uVvi for ; Tue, 29 Jan 2013 16:19:25 +0100 Received: (qmail invoked by alias); 29 Jan 2013 15:19:25 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 29 Jan 2013 16:19:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19gPSxuQFRgxaF8YozeEnBqAvaRMJv+eOWquef8Ji jv0cCqYQyA2Pg/ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jan 2013 17:19:23 +0200 Message-Id: <42E40943-8449-41AE-9DBE-1C226A14F6B5@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-psap-callback-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:19:26 -0000 Hi all, I believe that this document is ready for a working group last call. Ciao Hannes From RMarshall@telecomsys.com Tue Jan 29 09:35:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644CA21F8A49 for ; Tue, 29 Jan 2013 09:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zea8+KqXpDqJ for ; Tue, 29 Jan 2013 09:35:30 -0800 (PST) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id D293221F87D1 for ; Tue, 29 Jan 2013 09:35:29 -0800 (PST) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id r0THZM8J013227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 29 Jan 2013 09:35:23 -0800 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.134]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Tue, 29 Jan 2013 09:35:22 -0800 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: WGLC announce - draft-ietf-ecrit-psap-callback Thread-Index: Ac3+RwK0ZmcbXpSHRnGyKBwb+8lv2w== Date: Tue, 29 Jan 2013 17:35:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1E4B59SEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] WGLC announce - draft-ietf-ecrit-psap-callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:35:31 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1E4B59SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This starts WGLC for draft Public Safety Answering Point (PSAP) Callback The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback Please review the draft and provide comments to the list before COB on Febr= uary 12, 2013. Thanks, Marc & Roger CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1E4B59SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This starts WGLC for draft = Public Safety Answering Point (PSAP) Callback

 

The draft can be found at:<= o:p>

https://datatracker.ietf.o= rg/doc/draft-ietf-ecrit-psap-callback

 

Please review the draft and= provide comments to the list before COB on February 12, 2013.

 

Thanks,

 

Marc & Roger=

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1E4B59SEAEXMB1telecomsy_-- From brian.rosen@neustar.biz Tue Jan 29 10:11:56 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C6B21F8AE3 for ; Tue, 29 Jan 2013 10:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=-1.392, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8Sjdpc3-n1c for ; Tue, 29 Jan 2013 10:11:56 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7621F8AC8 for ; Tue, 29 Jan 2013 10:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1359483307; x=1674824662; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=kCR8pN7+4cEXDf6+B5eBc Rb+tj2040NeznH4mK+5jro=; b=ECassMe9yvXTw74PPFNAE1LF/QDmnD6Fk/aPq u33d0JuV6zSkUNPihPA9brge0AXzjTXORWfm4+KFFkDDuinGQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.19169758; Tue, 29 Jan 2013 13:15:06 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 29 Jan 2013 13:11:51 -0500 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Tue, 29 Jan 2013 13:11:51 -0500 Thread-Topic: Whither data-only Thread-Index: Ac3+TByEYAxFPEoGQ9GhCYUI6514mQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: qrC5+nIkRXxbYi1H1skjow== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Whither data-only X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:11:57 -0000 We ran a WGLC on data-only, and got some comments. The discussion raises s= ome fundamental issues that authors have been discussing. Here is our curr= ent thinking, which we would like discussion on before we rev the draft. "Data Only" was intended, originally, for a sensor equipped automaton to se= nd an alarm to a PSAP when there was no media. It uses a CAP message in th= e body of a MESSAGE to do that. It's been observed that there are cases where you have exactly the same kin= d of thing, with the same data, but you ALSO have media. In such a case, w= e would like to have the data sent the same way (CAP message in a body) It's also been asked how updates to the alarm are sent. At one point there= was some discussion of using MSRP to send a series of messages. Authors d= on't like this mechanism because it doesn't allow the PSAP to control the r= ate of updates. We suggest that updates be handled with a SUB/NOT, with fi= ltering, and the CAP message in the body of the NOTIFY. If we were to do this, it would be major surgery to the existing draft, inc= luding a name change. Nevertheless, that seems to be the right way to go. = We would: a)Define the mechanism to carry a CAP message in the body of a SIP transact= ion, and define it for use in INVITE, MESSAGE and NOTIFY b) Specify that INVITE is appropriate for alarms with media (creates sessio= n), and MESSAGE for alarms without media (doesn't create a session), but ot= herwise are equivalent. c) Define a SUB/NOT package, with filtering, for updates to the alarm data d) Change the name to something like "Citizen to Authority Alerts". This would mean re-running WGLC. Comments? Brian From bernard_aboba@hotmail.com Tue Jan 29 11:38:18 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FE421F8613 for ; Tue, 29 Jan 2013 11:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pycUeyOOszIO for ; Tue, 29 Jan 2013 11:38:13 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48D21F8528 for ; Tue, 29 Jan 2013 11:38:13 -0800 (PST) Received: from BLU401-EAS459 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 11:38:13 -0800 X-EIP: [bew1r3nj0+wr+8rXJ6js/O06Sr4/Uh2LlP0qsCmBHcw=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Rosen, Brian'" , References: In-Reply-To: Date: Tue, 29 Jan 2013 11:38:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgMEgjq+sb7Py3qVLc9mUOFds5v6q8Pw Content-Language: en-us X-OriginalArrivalTime: 29 Jan 2013 19:38:13.0205 (UTC) FILETIME=[2D2C0850:01CDFE58] Subject: Re: [Ecrit] Whither data-only X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bernard_aboba@hotmail.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:38:18 -0000 I am somewhat reluctant to do major surgery on the existing draft. Instead, my advice would be to define the SUB/NOT package in a separate document. That would allow this document to be completed expeditiously. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Tuesday, January 29, 2013 10:12 AM To: ecrit@ietf.org Org Subject: [Ecrit] Whither data-only We ran a WGLC on data-only, and got some comments. The discussion raises some fundamental issues that authors have been discussing. Here is our current thinking, which we would like discussion on before we rev the draft. "Data Only" was intended, originally, for a sensor equipped automaton to send an alarm to a PSAP when there was no media. It uses a CAP message in the body of a MESSAGE to do that. It's been observed that there are cases where you have exactly the same kind of thing, with the same data, but you ALSO have media. In such a case, we would like to have the data sent the same way (CAP message in a body) It's also been asked how updates to the alarm are sent. At one point there was some discussion of using MSRP to send a series of messages. Authors don't like this mechanism because it doesn't allow the PSAP to control the rate of updates. We suggest that updates be handled with a SUB/NOT, with filtering, and the CAP message in the body of the NOTIFY. If we were to do this, it would be major surgery to the existing draft, including a name change. Nevertheless, that seems to be the right way to go. We would: a)Define the mechanism to carry a CAP message in the body of a SIP transaction, and define it for use in INVITE, MESSAGE and NOTIFY b) Specify that INVITE is appropriate for alarms with media (creates session), and MESSAGE for alarms without media (doesn't create a session), but otherwise are equivalent. c) Define a SUB/NOT package, with filtering, for updates to the alarm data d) Change the name to something like "Citizen to Authority Alerts". This would mean re-running WGLC. Comments? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Tue Jan 29 12:28:17 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6CE21F8820 for ; Tue, 29 Jan 2013 12:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.282 X-Spam-Level: X-Spam-Status: No, score=-107.282 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGIecH45xAPs for ; Tue, 29 Jan 2013 12:28:17 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31C5421F881E for ; Tue, 29 Jan 2013 12:28:13 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0TKSAOJ019474 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Jan 2013 21:28:10 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 29 Jan 2013 21:28:10 +0100 From: "DRAGE, Keith (Keith)" To: "Rosen, Brian" , "ecrit@ietf.org Org" Date: Tue, 29 Jan 2013 21:28:09 +0100 Thread-Topic: Whither data-only Thread-Index: Ac3+TByEYAxFPEoGQ9GhCYUI6514mQAEov6Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [Ecrit] Whither data-only X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:28:17 -0000 I've no major problem with most of this, but I thought one fairly common us= e case was that you sent a body of data, and after that there was a decisio= n that media might be appropriate.=20 So data device is in car, which is in accident - data device automatically = fires off emergency accident data, but then there is a decision from either= end that this needs to carry voice media to turn this into an emergency ca= ll with the driver. So how would you handle this case with the proposal given. One option would= be to assume from the start that the voice would be needed in this use cas= e (even if it was not used), but are there alternatives. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: 29 January 2013 18:12 > To: ecrit@ietf.org Org > Subject: [Ecrit] Whither data-only >=20 > We ran a WGLC on data-only, and got some comments. The discussion raises > some fundamental issues that authors have been discussing. Here is our > current thinking, which we would like discussion on before we rev the > draft. >=20 > "Data Only" was intended, originally, for a sensor equipped automaton to > send an alarm to a PSAP when there was no media. It uses a CAP message i= n > the body of a MESSAGE to do that. >=20 > It's been observed that there are cases where you have exactly the same > kind of thing, with the same data, but you ALSO have media. In such a > case, we would like to have the data sent the same way (CAP message in a > body) >=20 > It's also been asked how updates to the alarm are sent. At one point > there was some discussion of using MSRP to send a series of messages. > Authors don't like this mechanism because it doesn't allow the PSAP to > control the rate of updates. We suggest that updates be handled with a > SUB/NOT, with filtering, and the CAP message in the body of the NOTIFY. >=20 > If we were to do this, it would be major surgery to the existing draft, > including a name change. Nevertheless, that seems to be the right way to > go. We would: > a)Define the mechanism to carry a CAP message in the body of a SIP > transaction, and define it for use in INVITE, MESSAGE and NOTIFY > b) Specify that INVITE is appropriate for alarms with media (creates > session), and MESSAGE for alarms without media (doesn't create a session)= , > but otherwise are equivalent. > c) Define a SUB/NOT package, with filtering, for updates to the alarm dat= a > d) Change the name to something like "Citizen to Authority Alerts". >=20 > This would mean re-running WGLC. >=20 > Comments? >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Jan 29 13:32:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F06021F84E6 for ; Tue, 29 Jan 2013 13:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3wsd2bgqHAF for ; Tue, 29 Jan 2013 13:32:08 -0800 (PST) Received: from blu0-omc1-s30.blu0.hotmail.com (blu0-omc1-s30.blu0.hotmail.com [65.55.116.41]) by ietfa.amsl.com (Postfix) with ESMTP id BE10721F8457 for ; Tue, 29 Jan 2013 13:32:07 -0800 (PST) Received: from BLU002-W143 ([65.55.116.9]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 13:32:07 -0800 X-EIP: [X5YGGWG3DPoOoixSknZwxXI6IzVikw4p] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_7e3421c2-1dab-4c81-a22d-b41fddfb3418_" From: Bernard Aboba To: Roger Marshall , "ecrit@ietf.org" Date: Tue, 29 Jan 2013 13:32:06 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jan 2013 21:32:07.0286 (UTC) FILETIME=[169A0960:01CDFE68] Subject: Re: [Ecrit] WGLC announce - draft-ietf-ecrit-psap-callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:32:08 -0000 --_7e3421c2-1dab-4c81-a22d-b41fddfb3418_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This version of the document looks ok to me=2C with the exception of a sent= ence in the Abstract=2C which appears out of date: Note that this version of the document does not yet specify a=0A= solution due to the lack of the working group participants agreeing=0A= on the requirements. From: RMarshall@telecomsys.com To: ecrit@ietf.org Date: Tue=2C 29 Jan 2013 17:35:21 +0000 Subject: [Ecrit] WGLC announce - draft-ietf-ecrit-psap-callback =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= This starts WGLC for draft Public Safety Answering Point (PSAP) Callback=0A= =0A= The draft can be found at:=0A= https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback=0A= =0A= Please review the draft and provide comments to the list before COB on Febr= uary 12=2C 2013.=0A= =0A= Thanks=2C=0A= =0A= Marc & Roger=0A= =0A= =0A= CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient=2C or r= esponsible for delivering this message to the intended recipient=2C any rev= iew=2C forwarding=2C dissemination=2C distribution or copying of this commu= nication or any attachment(s) is strictly prohibited. If you have received = this message in error=2C please notify the sender immediately=2C and delete= it and all attachments from your computer and network.=0A= =0A= _______________________________________________=0A= Ecrit mailing list=0A= Ecrit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ecrit = --_7e3421c2-1dab-4c81-a22d-b41fddfb3418_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This version of the document loo= ks ok to me=2C with the exception of a sentence in the Abstract=2C which ap= pears out of date:

   Note that this version of the document do=
es not yet specify a=0A=
   solution due to the lack of the working group participants agreeing=0A=
   on the requirements.



From: RMarshall@telecomsys.com
To: = ecrit@ietf.org
Date: Tue=2C 29 Jan 2013 17:35:21 +0000
Subject: [Ecri= t] WGLC announce - draft-ietf-ecrit-psap-callback

=0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

This start= s WGLC for draft Public Safety Answering Point (PSAP) Callback

= =0A=

 =3B

=0A=

The draft = can be found at:

=0A=

https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback

=0A=

 =3B

=0A=

Please rev= iew the draft and provide comments to the list before COB on February 12=2C= 2013.

=0A=

 =3B

=0A=

Thanks=2C<= /span>

=0A=

 =3B

=0A=

Marc &= =3B Roger

=0A=

 =3B

=0A=
=0A= CONFIDENTIALITY NOTICE:= The information contained in this message may be privileged and/or confide= ntial. If you are not the intended recipient=2C or responsible for deliveri= ng this message to the intended recipient=2C any review=2C forwarding=2C di= ssemination=2C distribution or copying of this communication or any attachm= ent(s) is strictly prohibited. If you have received this message in error= =2C please notify the sender immediately=2C and delete it and all attachmen= ts from your computer and network.
=0A= =0A=
_______________________________________________=0A= Ecrit mailing list=0A= Ecrit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ecrit
= --_7e3421c2-1dab-4c81-a22d-b41fddfb3418_--