From mary.ietf.barnes@gmail.com Fri Sep 2 12:05:20 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E382521F8D1B for ; Fri, 2 Sep 2011 12:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ls2CtfxpgNdM for ; Fri, 2 Sep 2011 12:05:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB22221F8CFB for ; Fri, 2 Sep 2011 12:05:18 -0700 (PDT) Received: by vws12 with SMTP id 12so3076795vws.31 for ; Fri, 02 Sep 2011 12:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XWfXKC+8+NNJfPTqpmKaYPgLmQEuvxdACRi7bcGkD0M=; b=M5n+kv1O4Puzr/Oj7Lom/sfLb1lgq3jxaC8ftgtMC9Eb0YxE35zid7E2bOfLWyHZrC r3gWf6esj5YcGwvvXnHUx4wehRDjfWexgLmrlAxpigd1snEiO1+HkTtg7Lqo/SVm8Ncg 9nOQzn4Kj6h6inojqV676XLrp8/2d1o61cZHo= MIME-Version: 1.0 Received: by 10.52.27.3 with SMTP id p3mr1403112vdg.224.1314990414822; Fri, 02 Sep 2011 12:06:54 -0700 (PDT) Received: by 10.52.35.2 with HTTP; Fri, 2 Sep 2011 12:06:54 -0700 (PDT) Date: Fri, 2 Sep 2011 14:06:54 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=20cf307d05a88efda004abfa1031 Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: DISPATCH WG 1st deadline for IETF-82 is Monday, Sept. 5th X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 19:05:21 -0000 --20cf307d05a88efda004abfa1031 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At this point, we've only received one email indicating that an individual will be putting forth a topic for discussion for the IETF-82 timeframe. Please let the chairs know by Monday, Sept. 5th if you plan to submit a problem statement/proposed work item for the IETF-82 timeframe. Thanks, Mary DISPATCH WG co-chair On Mon, Aug 22, 2011 at 3:44 PM, Mary Barnes wr= ote: > FYI... the DISPATCH specific deadlines are as follows and are also on the > WG wiki. Please note that the initial deadline is just two weeks away. > There has been alot of fuss about these deadlines However, folks need to > understand that the first deadline is just letting the chairs know that y= ou > want to discuss a particular work item - i.e., one sentence is all we nee= d > by that date. You have a week to refine that idea into a *rough* charter= . > > Based upon discussions over the next two weeks, the chairs (conferring wi= th > the ADs) will decide what topics are targeted for the meeting. You then > have 4 weeks to work on a draft related to the topic. > > However, you don't necessarily need a draft since the focus is on the > charter (with that term used very loosely). We need a problem statement > along with a guess at deliverables. The objective of the discussions on = the > mailing list and at the f2f meeting is to determine if the problem/work i= tem > is scoped tightly enough that it's solvable/doable, as well as to guage W= G > interest in the topic and willingness to contribute. If it's agreed, the= n > we can use the mailing list to refine the charter. > > We have been flexible about the dates as long as folks can give us an ide= a > of when they will be able to meet the deadlines. We need a rough idea of > the topics in order to request an appropriate length agenda slot. The > length tends to be far more variable than other WGs. Note, that the > deadline for the topic announcements aligns with the deadline for request= ing > a WG slot. > > Regards, > Mary. > DISPATCH WG co-chair. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of plans > to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 weeks > before -00 deadline] *2 weeks from today* > > * Sept. 12th, 2011. Cutoff for charter proposals for topics. [Three weeks > prior to BoF proposal deadline, two weeks before announcement of topics] > > * Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are > announced. [10 days before AD BoF approval and deadline to request WG slo= t, > 4 weeks before -00 deadline, deadline for requesting WG session] > > * October 24th, 2011. -00 draft deadline. > > * October 31st, 2011. Draft deadline. > > > > ---------- Forwarded message ---------- > From: IETF Agenda > Date: Mon, Aug 22, 2011 at 1:15 PM > Subject: 82nd IETF - Working Group/BOF Scheduling > To: Working Group Chairs > Cc: irsg@irtf.org > > > ----------------------------------------------------------------- > 82nd IETF =96 Taipei, Taiwan > Meeting Dates: November 13-18, 2011 > Host: Taiwan Network Information Center (TWNIC) > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting today. The milestones and deadlines for scheduling-related > activities are as follows: > > NOTE: cutoff dates are subject to change. > > - 2011-08-15 (Monday): Working Group and BOF scheduling begins. To reques= t > a Working Group session, use the IETF Meeting Session Request Tool. > - 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group > meetings at 17:00 PT (00:00 UTC). To request a Working Group session, use > the IETF Meeting Session Request Tool. > - 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area > Directors at 17:00 PT (00:00 UTC). To request a BOF, please see instructi= ons > on Requesting a BOF. > - 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs a= t > 17:00 PT (00:00 UTC). > - 2011-10-13 (Thursday): Preliminary agenda published for comment. > - 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Gro= up > and BOF meetings 17:00 PT (00:00 UTC). > - 2011-10-21 (Friday): Final agenda to be published. > - 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT > (00:00 UTC), upload using IETF Meeting Materials Management Tool. > - 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:= 00 > UTC), upload using IETF Meeting Materials Management Tool. > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting all = of > the information that the Secretariat requires to schedule your sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the messag= e, > and include all of the information specified in item (4) of "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is includ= ed > below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft Work= ing > Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. Revised > Working Group agendas are due no later than Monday, November 7, 2011 at > 17:00 PT. The proposed agenda for a BOF session should be submitted alon= g > with your request for a session. Please be sure to copy your Area Direct= or > on that message. > > Please submit the agendas for your Working Group sessions using the "IETF > Meeting Materials Management Tool," a Web-based tool for making your meet= ing > agenda, minutes, and presentation slides available to the community befor= e, > during, and after an IETF meeting. If you are a BOF chair, then you may = use > the tool to submit a revised agenda as well as other materials for your B= OF > once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the "IE= TF > Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 82 Meeting Materials" Web page is: > > https://datatracker.ietf.org/meeting/82/materials.html > > If you are a Working Group chair, then you already have accounts on the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both tools= . > If you are a BOF chair who is not also a Working Group chair, then you w= ill > be given an account on the "IETF Meeting Materials Management Tool" when > your BOF has been approved. If you require assistance in using either to= ol, > or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience, comprehensive information on requesting meeting > sessions at IETF 82 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted using > the "IETF Meeting Session Request Tool," a Web-based tool for submitting = all > of the information required by the Secretariat to schedule your sessions. > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, then > please send a message to ietf-action@ietf.org. If you are unable to use > the tool, then you may send your request via e-mail to agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved reques= t > is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S) > (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, > and the information requested in (4) below. (Please read the BOF Procedur= e > at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a > session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your Worki= ng > Group requires more than two sessions, then your request must be approved= by > an Area Director. Additional sessions will be assigned, based on > availability, after Monday, October 17, 2011 at 17:00 PT, the cut-off dat= e > for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group or B= OF > session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance: > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures= " ( > http://www.ietf.org/rfc/rfc2418.txt). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience please find here a list of the IETF Area Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Pete Resnick > Peter Saint-Andre > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Gonzalo Camarillo > Robert Sparks > > Routing Area (rtg) > Stewart Bryant > Adrian Farrel > > Security Area (sec) > Stephen Farrell > Sean Turner > > Transport Area (tsv) > Wesley Eddy > David Harrington > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 81th IETF Meeting Attendance Number - TBA > > --20cf307d05a88efda004abfa1031 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At this point, we've only received one email indicating that an individ= ual will be putting forth a topic for discussion for the IETF-82 timeframe.= =A0Please let the chairs know by Monday, Sept. 5th if you plan to submit a= problem statement/proposed work item for the IETF-82 timeframe.=A0

Thanks,
Mary
DISPATCH WG co-chair
On Mon, Aug 22, 2011 at 3:44 PM, Mary Barnes <mary.ietf= .barnes@gmail.com> wrote:
FYI... the DISPATCH specific deadlines are = as follows and are also on the WG wiki. Please note that the initial deadli= ne is just two weeks away. =A0There has been alot of fuss about these deadl= ines However, folks need to understand that the first deadline is just lett= ing the chairs know that you want to discuss a particular work item - i.e.,= one sentence is all we need by that date. =A0You have a week to refine tha= t idea into a *rough* charter. =A0

Based upon discussions over the next two weeks, the chairs (= conferring with the ADs) will decide what topics are targeted for the meeti= ng. =A0You then have 4 weeks to work on a draft related to the topic. =A0

However, you don't necessarily need a draft since t= he focus is on the charter (with that term used very loosely). =A0We need a= problem statement along with a guess at deliverables. =A0The objective of = the discussions on the mailing list and at the f2f meeting is to determine = if the problem/work item is scoped tightly enough that it's solvable/do= able, as well as to guage WG interest in the topic and willingness to contr= ibute. =A0If it's agreed, then we can use the mailing list to refine th= e charter. =A0

We have been flexible about the dates as long as folks = can give us an idea of when they will be able to meet the deadlines. =A0We = need a rough idea of the topics in order to request an appropriate length a= genda slot. =A0The length tends to be far more variable than other WGs. =A0= Note, that the deadline for the topic announcements aligns with the deadlin= e for requesting a WG slot.=A0

Regards,
Mary.
DISPATCH WG co-chair= .

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
* =A0Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of = plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 we= eks before -00 deadline] =A0 =A0 *2 weeks from today*=A0

* Sept. 12th, 2011. Cutoff for charter proposals for to= pics. [Three weeks prior to BoF proposal deadline, two weeks before announc= ement of topics]

* Sept. 26th, 2011. Topics that a= re to be the focus of IETF-82 are announced. [10 days before AD BoF approva= l and deadline to request WG slot, 4 weeks before -00 deadline, deadline fo= r requesting WG session]

* October 24th, 2011. -00 draft deadline.
* October 31st, 2011. Draft deadline.



---------- Forwarded message ----------
From: IETF Agenda <<= a href=3D"mailto:agenda@ietf.org" target=3D"_blank">agenda@ietf.org>=
Date: Mon, Aug 22, 2011 at 1:15 PM
Subject: 82nd IETF - Worki= ng Group/BOF Scheduling
To: Working Group Chairs <wgchairs@ietf.org>
Cc: irsg@irtf.org


----------------------------= -------------------------------------
82nd IETF =96 Taipei, Taiwan
Meeting Dates: November 13-18, 2011
Host: Taiwan Network Information Center (TWNIC)
-----------------------------------------------------------------
IETF meetings start Monday morning and run through Friday mid-afternoon (15= :15).

We are accepting scheduling requests for all Working Groups and BOFs starti= ng today. =A0The milestones and deadlines for scheduling-related activities= are as follows:

NOTE: cutoff dates are subject to change.

- 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool.
- 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group m= eetings at 17:00 PT (00:00 UTC). To request a Working Group session, use th= e IETF Meeting Session Request Tool.
- 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area Direc= tors at 17:00 PT (00:00 UTC). To request a BOF, please see instructions on = Requesting a BOF.
- 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (00:00 UTC).
- 2011-10-13 (Thursday): Preliminary agenda published for comment.
- 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group= and BOF meetings 17:00 PT (00:00 UTC).
- 2011-10-21 (Friday): Final agenda to be published.
- 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:0= 0 UTC), upload using IETF Meeting Materials Management Tool.
- 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00= UTC), upload using IETF Meeting Materials Management Tool.

Submitting Requests for Working Group and BOF Sessions

Please submit requests to schedule your Working Group sessions using the &q= uot;IETF Meeting Session Request Tool," a Web-based tool for submittin= g all of the information that the Secretariat requires to schedule your ses= sions.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requ= ester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_= tool_instruction.html

Please send requests to schedule your BOF sessions to agenda@ietf.org. =A0Please include the = acronym of your BOF in the subject line of the message, and include all of = the information specified in item (4) of "Requesting Meeting Sessions = at IETF Meetings" in the body. =A0(This document is included below.)
Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agenda= s for your Working Group sessions as early as possible. =A0Draft Working Gr= oup agendas are due Wednesday, November 2, 2011 by 17:00 PT. =A0Revised Wor= king Group agendas are due no later than Monday, November 7, 2011 at 17:00 = PT. =A0The proposed agenda for a BOF session should be submitted along with= your request for a session. =A0Please be sure to copy your Area Director o= n that message.

Please submit the agendas for your Working Group sessions using the "I= ETF Meeting Materials Management Tool," a Web-based tool for making yo= ur meeting agenda, minutes, and presentation slides available to the commun= ity before, during, and after an IETF meeting. =A0If you are a BOF chair, t= hen you may use the tool to submit a revised agenda as well as other materi= als for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi

Additional information about this tool is available at:

http://www.ietf.org/instructions/meeting_materials_tool.htm= l

Agendas submitted via the tool will be available to the public on the "= ;IETF Meeting Materials" Web page as soon as they are submitted.

The URL for the "IETF 82 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/82/materials.html

If you are a Working Group chair, then you already have accounts on the &qu= ot;IETF Meeting Session Request Tool" and the "IETF Meeting Mater= ials Management Tool." =A0The same User ID and password will work for = both tools. =A0If you are a BOF chair who is not also a Working Group chair= , then you will be given an account on the "IETF Meeting Materials Man= agement Tool" when your BOF has been approved. =A0If you require assis= tance in using either tool, or wish to report a bug, then please send a mes= sage to:
ietf-action@ietf.= org.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
For your convenience, comprehensive information on requesting meeting sessi= ons at IETF 82 is presented below:

1. Requests to schedule Working Group sessions should be submitted using th= e "IETF Meeting Session Request Tool," a Web-based tool for submi= tting all of the information required by the Secretariat to schedule your s= essions. =A0The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requ= ester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_= tool_instruction.html

If you require an account on this tool, or assistance in using it, then ple= ase send a message to ietf-action@ietf.org. =A0If you are unable to use the tool, then y= ou may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area D= irector(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropri= ate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please in= clude the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director(s) approved request = is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S)= (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, = and the information requested in (4) below. (Please read the BOF Procedure = at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a se= ssion for a BOF.)

3. A Working Group may request either one or two sessions. =A0If your Worki= ng Group requires more than two sessions, then your request must be approve= d by an Area Director. =A0Additional sessions will be assigned, based on av= ailability, after Monday, October 17, 2011 at 17:00 PT, the cut-off date fo= r requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF= session will be scheduled:

=A0 =A0a. Working Group or BOF full name with acronym in brackets:

=A0 =A0b. AREA under which Working Group or BOF appears:

=A0 =A0c. CONFLICTS you wish to avoid, please be as specific as possible:<= br>
=A0 =A0d. Expected Attendance:

=A0 =A0e. Special requests:

=A0 =A0f. Number of sessions:

=A0 =A0g. Length of session:
=A0 =A0 =A0 - 1 hour
=A0 =A0 =A0 - 1 1/2 hours
=A0 =A0 =A0 - 2 hours
=A0 =A0 =A0 - 2 1/2 hours

For more information on scheduling Working Group and BOF sessions, please r= efer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedur= es" (http://www.ietf.org/rfc/rfc2418.txt).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
For your convenience please find here a list of the IETF Area Directors wit= h their e-mail addresses:

IETF Chair
Russ Housley <= housley@vigilsec.com>

Applications Area (app)
Pete Resnick <presnick@qualcomm.com>
Peter Saint-Andre <stpeter@stpeter.im>

Internet Area (int)
Jari Arkko <ja= ri.arkko@piuha.net>
Ralph Droms <= rdroms.ietf@gmail.com>

Operations & Management Area (ops)
Ronald Bonica <= rbonica@juniper.net>
Dan Romascanu <d= romasca@avaya.com>

Real-time Applications and Infrastructure Area (rai)
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.com>

Routing Area (rtg)
Stewart Bryant <= stbryant@cisco.com>
Adrian Farrel <= adrian@olddog.co.uk>

Security Area (sec)
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sean Turner <turne= rs@ieca.com>

Transport Area (tsv)
Wesley Eddy <we= s@mti-systems.com>
David Harrington <ietfdbh@comcast.net>
=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
81th IETF Meeting Attendance Number - TBA


--20cf307d05a88efda004abfa1031-- From aallen@rim.com Sat Sep 3 09:32:21 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9621F85A4 for ; Sat, 3 Sep 2011 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.172 X-Spam-Level: X-Spam-Status: No, score=-5.172 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEThP3KVavfh for ; Sat, 3 Sep 2011 09:32:19 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5E21F856B for ; Sat, 3 Sep 2011 09:32:18 -0700 (PDT) X-AuditID: 0a412830-b7b8aae000002aff-cf-4e6256ebb6c3 Received: from XHT101CNC.rim.net (xht101cnc.rim.net [10.65.12.214]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 7D.4E.11007.BE6526E4; Sat, 3 Sep 2011 16:33:47 +0000 (GMT) Received: from XCT105ADS.rim.net (10.67.111.46) by XHT101CNC.rim.net (10.65.12.214) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sat, 3 Sep 2011 12:33:56 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.01.0289.001; Sat, 3 Sep 2011 11:33:53 -0500 From: Andrew Allen To: Cullen Jennings Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJg Date: Sat, 3 Sep 2011 16:33:52 +0000 Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> In-Reply-To: <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXC5chzTfd1WJKfwfNn+hZLJy1gteiYzObA 5DHl90ZWjyVLfjIFMEU1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWWJSZXKrhkFifnJGbm phYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJTtdJJDwjzvj490TjAVftzNWvJx0naWBcf9Exi5GTg4JAROJk/ePs0PYYhIX7q1n 62Lk4hAS6GWSWLzjCTOEs5RR4s7J1ewQzmZGidbpV1hAWtgElCWW/54BNkpEQE2iYcUjsFHM AqoS5091MoPYwgLpEs0LPrNC1GRItK18BVVvJDG17RFYDYuAisTKz3vBangF3CTWzbjGCLFs NaPE7J5HTF2MHBycArYSL24kg9QwAp36/dQaJohd4hK3nsxngnhBQGLJnvPMELaoxMvH/1gh bEWJJ42bWSDqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT8BqhASkJXacXMM4gVFiFpIVs5C0z0LS PgtJ+wJGllWMgrkZxQZmhsl5yXpFmbl6eaklmxjByUXDYAfjhL1ahxgFOBiVeHh7fZL8hFgT y4orcw8xSnAwK4nwPvUACvGmJFZWpRblxxeV5qQWH2K0AIbQRGYp7uR8YOLLK4k3NjBA4SiJ 84ZJG/gJCaQDE1l2ampBahFMKxMHp1QD46Q/tUsiv9mkf5epFO1Sf/O3q3TJ06UTuRPesRkm bPu5Z8nb97x5J2qXx7FmiT1+usLW/MDcNc+CZJ/LJyapOJgdtgowznd7znxOcgvP+oLnZ427 ZIVcq0T46w/uD9j67kDCsS1MHbv1L69aqrfQXj7x/5Ymjs95L55bpNkd2/3npE7buafLryqx FGckGmoxFxUnAgBWI1/hRwMAAA== Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 16:32:21 -0000 Cullen Apologies for the delay in responding. With some vacation time, a 3GPP meeti= ng to prepare for and attend and being sick for the past week this is the fi= rst chance I have had to respond. Responses included below: Andrew > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, July 26, 2011 5:23 PM > To: Andrew Allen > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- > dispatch-imei-urn-as-instanceid > > > On May 27, 2011, at 23:07 , Andrew Allen wrote: > > > Cullen > > > > Responses to your technical points below: > > > > regards > > Andrew > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Cullen Jennings > >> Sent: Wednesday, May 18, 2011 1:11 PM > >> To: DISPATCH list > >> Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- > >> dispatch-imei-urn-as-instanceid > >> > >> > >> I have said in the past, I have several concerns around the combined > >> proposal in these two drafts. In this email, I've tried to focus on > > the > >> high level problems and ignore small problems in the drafts that can > > be > >> fixed by change a bit of text in the drat. > >> > >> The biggest issues is that this is going to reduce interoperability > > with > >> systems that don't use this type of instance id yet this does not > > provide > >> features that could not be done in away that did not reduce > >> interoperability. > > > > Can you please elaborate on what your interoperability concerns are? I > > don't see any issue with end to end interoperability since with public > > GRUU the gr parameter is opaque. Devices that contain an IMEI are only > > those devices specified by 3GPP. Only 3GPP mandates that the IMEI is > > included in the instance ID, non 3GPP devices or devices not operating > > in an IMS network do not need to use an IMEI (indeed a non 3PP device > > would not even have an IMEI to use). RFC 5626 allows the possibility for > > URNs other than UUID to be used as an instance ID and RFC 5627 does not > > mandate an algorithm for the generation of GRUUs based on the instance > > ID. If the 3GPP determines that its devices that already contain an IMEI > > for their device ID need to use that as an Instance ID and defines a > > GRUU generation algorithm that satisfies its requirements when receiving > > an Instance ID that contains the IMEI URN then that seems fine to me. Is > > your concern regarding a 3GPP IMS terminal registering in a non IMS > > domain? I think that in reality a device acting as an IMS terminal > > registering in a non IMS compliant network isn't a practical scenario. > > There are so many 3GPP and IMS compliant things that would need to > > happen in the network for the device (acting as an IMS terminal) to > > register and obtain service that basically the network would need to be > > an IMS compliant network. Of course there is nothing preventing a device > > that is IMS capable being configured to either act as an IMS compliant > > device or a basic SIP compliant device (quite a few devices have such > > dual mode capabilities). The use of the IMEI as the instance ID should > > not in itself prevent the successful registration of the device in a non > > IMS network (since as Dale points out the registrar is likely to treat > > the instance ID opaquely if it doesn't understand it). > > What happens in 3GPP tends to leak out into other standard and into other > systems. [AA] I don't see how this can happen as only GSM/3GPP devices can have an IM= EI (GSMA allocates the IMEI namespace). Devices that are not compliant with= the 3GPP specifications and are not part of a 3GPP system will not have an= IMEI so I don't see how it is possible for the IMEI URN to "leak out" into= other standards. > > > > >> To be concrete, let me offer an alternative solution > >> that would be interoperable, would not have any IPR that I am aware > > of, > >> and would provide the same functionality as the goals of these drafts > > - or > >> at least the goals that have been stated at the IETF. > >> > >> To indicate the version of the software, I would suggest using the SIP > >> User Agent header. If a more structured form is required to > > specifically > >> line up with existing mobile systems, I would suggest defining an well > >> structured format to use inside the User Agent header field. The > > advantage > >> is that this is what most sip systems do today and many management > > systems > >> already can look at this header and use it. A more structured form > > would > >> be useful by systems outside the GSMA space and would also be > > backwards > >> compatible with existing systems that treat it as an unstructured > > string. > > > > I am not against the proposal of including the software version in the > > User Agent header but don't see it as an alternative to the > > representation of the IMEI-SV as part of the IMEI URN. One of the main > > objectives of the use of the IMEI and IMEI-SV in SIP signaling is to > > maintain compatibility with the IMEI and IMEI-SV use in Circuit Switched > > signaling. In some case in circuit switched signaling the device will > > return the IMEI and in other cases the device will return the IMEI-SV. > > It needs to be possible that devices registered in circuit switched > > domain and in the IMS domain can use whichever is returned IMEI or > > IMEI-SV in the same identifier. > > I understand both are used in circuit switched but I don't see that that > would require a design like this. > [AA] We are just trying to define a namespace to represent the IMEI and IMEI= -SV as already defined by GSMA. The latest version of draft-allen-dispatch-i= mei-urn-as-instanceid states: "The UAC SHOULD NOT include the optional "svn"= parameter in the GSMA IMEI URN in the "sip.instance" media feature tag, sin= ce the software version can change as a result of upgrades to the device fir= mware which would create a new instance ID.". 3GPP do not use the IMEI-SVN a= s an instance ID in their specifications. > >> > >> For the issue of identifying stolen handsets and correlating devices > >> between SIP and non SIP calls, I would propose that you use a UUID as > > the > >> URN but that the UUID be created using IMEI or a hash of the IMEI > > instead > >> of the MAC. This would involve an extension to RFC 4122 but would > > result > >> in a system that meets the needs. Even if a hash is used, the server > > side > >> can do the same hash to match. > > > > I don't fully understand the details of your proposal but a clear > > requirement is that the IMEI in the instance ID be recoverable and > > understandable by the registrar as the IMEI value of the terminal. Does > > this proposal allow the IMEI value to be obtained and understood by the > > registrar? > > The requirement was that they be matchable not recoverable which this > meets [AA] The requirement is that the IMEI be identifiable so that registration o= f barred devices (e.g stolen devices) can be prevented and also so that for= emergency calls the device used can be identified. > > > > > > If an extension to RFC 4122 is required isn't this more overhead and has > > more impact than simply defining and using a URN that represents the > > namespace that you wish to include? UUID itself is also heavier in > > computational resources and less efficient in size than the IMEI URN. > > This extension to 4122 is pretty easy and has no IPR I am aware of. > [AA] As above it seems this solution doesn't meet the above requirement that= the IMEI be recoverable. > > > >> > >> If the WG is interest in such an idea, I am glad to write up an ID for > >> each of these and submit it to the group so that it can be properly > >> considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid. > >> > >> As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am > > not > >> in favor of publishing it as is because I believe it will result in > >> interoperability failures with the many SIP devices that don't support > > it, > > > > This needs justification. 3GPP specifications also support handling > > devices that use UUID and not IMEI as many IMS compatible devices do not > > actually have an IMEI (only GSM mobile devices have an IMEI). > > I think I have provided this on more than one occasion. > [AA] As I understand from a very brief discussion with you on this in Quebec= City your concern is that GSM mobile devices may try and register using the= IMEI as an Instance ID on non IMS networks. I don't think this is a practic= al scenario. There are so many IMS specific things that 3GPP devices that co= ntain IMEIs do and expect the network to do that a device acting as a compli= ant 3GPP IMS device would not successfully register with a non 3GPP IMS comp= liant network. Firstly 3GPP IMS mobile devices that contain an IMEI either o= btain or derive their registered public user identity (which becomes the add= ress of record), the domain name to register in and their security parameter= s for authentication from the SIM card or UICC. Only GSM network operators s= upply SIM cards and UICCs that contain other GSMA allocated identities such= as mobile country code (MCC) and mobile network code (MNC) so a 3GPP IMS de= vice (with an IMEI) cannot register (according to IMS procedures) with any n= etwork that is not a network operated by a GSM operator. Additionally lower= layer security mechanisms upon which SIP signaling relies are also dependen= t on the SIM card or UICC based security mechanisms so a 3GPP IMS device (wi= th an IMEI) could not even establish the necessary security contexts. Also t= he 3GPP IMS device depends on the support and usage of certain mechanisms su= ch as Service-Route header field, P-Associated-URI header field and use of s= ecurity agreement (Security-Client, Security-Server and Security-Verify head= er fields in an IMS specific manner. Without these IMS specific procedures b= eing followed the 3GPP IMS device (with an IMEI) would not be able to succes= sfully register and establish sessions. Therefore I don't see how this is a= real issue. This concern could be addressed in draft-allen-dispatch-imei-ur= n-as-instanceid by adding a statement that an IMEI is MUST only be used as a= n Instance ID by a device registering with a 3GPP IMS network. > > > >> and it has IPR that we can easily avoid and provide the same > >> functionality. I also have issues with some of the technical details > > in it > >> but theses could all be fairly easily resolved with a few back and > > forth > >> of suggested text. RIM is offering awful licensing terms for something > >> that I believe you would have to implement to be workable in the bulk > >> mobile SIP deployments. Give this is easily avoidable, I think we > > should > >> avoid it. It's not really a topic for this WG but if this draft > > proceeded, > >> it was very late IPR disclosure. When it came to IETF LC, I would also > >> want to point out that the only teeth IETF has to enforce very late > > IPR > >> disclosures is to say no. I'm not particularly interested in talking > > about > >> this here as I don't think it will help solve the proble > >> m but I have brought this up in the past in context of this draft and > > I > >> don't want anyone to be surprised if I brought it up in an IETF LC. > >> > >> There are also significant privacy concerns around this proposal. A > > key > >> design of GRUU is being able to meet people goals of privacy while not > >> revealing private information. > > > > Privacy in GRUU is achieved through temporary GRUUs. Properties of > > temporary GRUUs are unaffected by using the IMEI as an instance ID. > > > >> The IMEI is sometimes used as a security > >> identifier between a user and SP as a shared secret. This proposal > > would > >> break theses systems. > > > > The IMEI is easily readable from the UI of mobile phones and is quite > > often printed on the case under the battery. Mobile phone stores > > sometimes keep lists (sometimes on paper) of IMEIs and the customers who > > have been allocated them (warranty reasons etc). > > agree with what you are saying but you do agree it is used as a secret > often used to show proof of possession of the phone? [AA] This is handled with the design and usage of the IMEI. The IMEI has a s= pare digit. This digit has a spare digit. This digit is always set to zero w= hen transmitted but one the mobile device has a non zero value. Thus interce= pting the transmitted IMEI value does not provide you the entire IMEI. > > > It is hardly a super > > secret security identifier. I am not aware of the security usage you > > describe and if it does exist it seems pretty flawed. > > > >> The privacy and security aspects of this would need to be addressed. > > > > 3GPP has addressed aspects of revealing the IMEI when generating GRUUs > > in their specifications. > > right, send them on over [AA] Here is the link: http://www.3gpp.org/ftp/Specs/latest/Rel-8/24_series/24229-8g0.zip > > > > >> It's conceivable that in many cases IMEI is Personal > >> Identifiable Information. > > > > IMEI is not really anymore personal information than IP address > > <..snip..> > > I'll note I think you are just wrong on this. First of all, IMEI are more > revealing than IP because they tend to be tighter bound to a single suer > instead of multiple and exist over longer time and second of all many > people, myself included, consider IP as PII in many cases. > [AA] Whether one is worse than the other is debatable but as indicated above= there isn't a issue with revealing this information since 3GPP specificatio= ns address this issue and having 3GPP IMS devices with IMEIs register on non= IMS networks isn't a practical scenario. > > > > >> The idea that every call would have to have PII > >> information in it or my call would be blocked as coming form a stolen > >> phone seems like a pretty serious flaw in this proposal. > > > > In general the IMEI is not placed in an IMS call. The blocking would be > > achieved via the registration. Blocked mobiles simply would be unable to > > register in IMS (which in IMS means they are unable to make calls). If > > an IMEI check is needed during a call the mobile can be requested by the > > network to re-register. The only use in 3GPP of the IMEI during an IMS > > call is for emergency calls. > > again, I think there are much better designs for this without IPR issues [AA] I don't think there has been such a proposal and in any case this was t= he proposal that was agreed in 3GPP. This proposal is informational not stan= dards track and is 3GPP informing the internet community of its usage. This= is applicable for 3GPP IMS deployments only so what is the basis for these= concerns? > > > > >> I'll note I brought up the privacy issues in 2007 and have yet to get > > a reply on it. > > > > > > I don't recall your previous comment (but it was 4 years ago). If we > > have failed to respond adequately to a previous comment then please > > restate it if the above responses do not cover it. > >> > >> On the topic of draft-montemurro-gsma-imei-urn, I of course think it > > is > >> fine for the GSMA to be able to allocate a namespace where they need > > it. > >> However, there are bunch of changes that would be needed to make this > >> draft fit all the URN rules. They are all small actionable things like > >> defining how comparison of things such as svn is defined and how > >> allocation of new things works. > > > > Of course all technical issues and concerns can be fixed. Please supply > > details on those so they can be addressed. > > > >> As I have also brought up many times in > >> the past, what the relationship between GSMA and 3GPP on this is very > >> weird and I would want clarity on that before proceeding. In the time > > we > >> have been discussing this draft, people constantly tell me that GSMA > > is > >> the group that will handle the namespace allocation for the 3GPP > >> deployments yet at the same time we have approved RFC 5279 which oddly > >> looks like a better namespace for this than the GSMA one. I would want > > to > >> have a clear understanding of how these different spaces interact. The > >> more we splinter this namespace, the less interoperability we have. > > > > My understanding is that in order to be allocated a URN namespace the > > registrant of the namespace has to guarantee uniqueness of the > > namespace. GSMA provides for the allocation of IMEIs and ensures > > adherence to the guidelines for IMEI allocation "GSMA Association, "IMEI > > Allocation and Approval Guidelines", PRD DG.06". Thus for the IMEI the > > GSMA is the appropriate registrant for that namespace. 3GPP has no > > responsibility for allocation of IMEIs so should not be the responsible > > registrant. 3GPP namespace would seem appropriate for items which are > > completely specified (including all their values) in 3GPP > > specifications. It should be noted that 3GPP is not a legal entity and > > might not exist for the entire period of time that IMEIs are being > > allocated and used. > >> > >> On the topic of including the software version as part of the device > >> identifier, given the software is upgraded, I think this is a mistake > > and > >> it is better to consider the software version as a separate thing from > > the > >> unique device identifier. It does not seem consistent with the goals > > and > >> requirements of a device id URN. > > > > As stated above the software version is included for backward > > compatibility with the IMEI-SV usage in circuit switched signaling. The > > SVN is a parameter and so the original IMEI which does not change can be > > easily obtained. Registrars and other devices that understand the IMEI > > URN with the SVN parameter can ignore the parameter when generating > > GRUUs for instance. If a book has a 2nd edition with different content > > doesn't that warrant being assigned a new value within the ISBN URN > > namespace? Similarly if the software is upgraded the nature and > > capabilities of the device may change so doesn't this warrant a new > > value? Note that RFC 5626 and RFC 5627 do not require that the instance > > IDs or GRUUs be forever persistent (RFC 5626 only requires that it MUST > > be persistent through a power cycle). I doubt very much that most > > embedded SIP endpoints will after a complete software upgrade (such as > > involving completely rewriting flash memory) still use the same UUID as > > previously used either. > >> > >> I will also note that as far as process is concerned, I would prefer > > the > >> problem, not the solution was brought to dispatch and we could figure > > out > >> how to solve it. I do think the problem here is well worth solving, I > > just > >> think there are solutions that will work better that this when > > considering > >> the whole eco systems of SIP endpoints and not just the GSM ones. > > > > When this was first proposed in 2006 all that was being done was > > registering a namespace. > > I doubt that is true. Please look at the drafts from 2006. I have never > objected to the idea that some other SDO might want a URN namespace. If > that was all that was requested, this would have been done long ago and > the current draft would not be requesting anything more than that. > [AA] There is nothing in the early versions (around 2006) about using the IM= EI URN as an instance ID although this was added in later versions but then= removed and then specified separately in draft-allen-dispatch-imei-urn-as-i= nstanceid > > I don't think that 3GPP needs to bring > > requirements to the dispatch WG, propose a charter etc for every problem > > that can be solved by registering a namespace or a parameter. In fact > > the SIP change process has moved away from that with only specification > > required and expert review needed for defining "proprietary" SIP header > > fields. As stated above the IMEI only applies to the GSM family of > > technology mobiles not all SIP endpoints and I fail to see the impact of > > the use of the IMEI URN by the GSM family of technology mobiles when > > registering with IMS on any other SIP endpoints. This proposal does not > > mandate the use of the IMEI URN as an Instance ID by non 3GPP terminals > > and is not being proposed to become part of an IETF standard. This is > > just trying to follow the process whereby external users of IETF > > protocols register their identifiers with IANA and provide informational > > documentation to the internet community about such usage. It seems to me > > that some of the issues of principle being raised are those > > considerations that more appropriately apply to standards track > > submissions and not to these informational submissions. > > > If the same > > level of consideration and debate about different solutions takes place > > for informational submissions as would take place for standards track > > submissions then I fear this will become a big deterrent to outside > > users of IETF protocol submitting their proprietary usages as > > informational RFCs for the benefit of the internet community and in > > ensuring that are no conflicts with the IANA registry. > > > You are asking for something that can not be approved as an information > draft by the ISE because it impacts interoperability of SIP devices. The > bar here is somewhat higher than some information drafts. If what you > needed to be approved could be done by the ISE, I would suggest you take > it there but it can't. > [AA] As above I do not agree that there are any interoperability concerns wi= th this proposal and this is only proposed for 3GPP IMS usage of SIP not for= general internet usage. > > >> > >> Cullen in my individual contributor role > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From sunilkumarsinha9@rediffmail.com Sun Sep 4 05:56:36 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E7221F8515 for ; Sun, 4 Sep 2011 05:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[AWL=1.281, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsIPC7mrqBbp for ; Sun, 4 Sep 2011 05:56:35 -0700 (PDT) Received: from rediffmail.com (f5mail-224-152.rediffmail.com [114.31.224.152]) by ietfa.amsl.com (Postfix) with SMTP id 4B75421F8505 for ; Sun, 4 Sep 2011 05:56:32 -0700 (PDT) Received: (qmail 27597 invoked by uid 510); 4 Sep 2011 12:58:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=tFzDWLKOFBHj/2TfGfLfHekcDCS8eHSMuFwtR1wkQtx8ayQcM6IR/EKPs28YGY4KdXlkN7Sho6bjBZOCNz+cfiMdBl+Mod/do8sXiIK1b65fmAI799r/AzocK9tEBsMu4YIa0OguzEOOKaf4MhFrTcEnbb2b+vkuWEca1yqNc3Q= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150204.4E6375DE.002E,ss=1,re=-2.300,fgs=0 Date: 4 Sep 2011 12:58:04 -0000 MIME-Version: 1.0 To: Received: from unknown 78.147.249.192 by rediffmail.com via HTTP; 04 Sep 2011 12:58:03 -0000 Message-ID: <1314990424.S.54625.2987.F.H.WU1hcnkgQmFybmVzAFtkaXNwYXRjaF0gUmVtaW5kZXI6IERJU1BBVENIIFdHIDFzdCBkZWFkbGluZSBmb3I_.f5-224-164.old.forward.1315141083.14272@webmail.rediffmail.com> in-reply-to: From: "sunil kumar sinha" Content-Type: multipart/alternative; boundary="=_977cfd01be52a07f4205a734d4f707dc" Cc: dispatch@ietf.org Subject: Re: [dispatch] =?utf-8?q?Reminder=3A_DISPATCH_WG_1st_deadline_for_IET?= =?utf-8?q?F-82_is_Monday=2C_Sept=2E_5th?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 12:56:36 -0000 --=_977cfd01be52a07f4205a734d4f707dc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Mary, Apologies for the delay in responding. We need some more few days to submit a problem statement/proposed work item for the IETF 82 timeframe. We are engaged in drafting the answer to all comments raised via email in the next draft version. Thanks & Regards sunil kumar sinha On Sat, 03 Sep 2011 00:37:04 +0530 wrote >At this point, we've only received one email indicating that an individual will be putting forth a topic for discussion for the IETF-82 timeframe. �Please let the chairs know by Monday, Sept. 5th if you plan to submit a problem statement/proposed work item for the IETF-82 timeframe.� Thanks,MaryDISPATCH WG co-chair On Mon, Aug 22, 2011 at 3:44 PM, Mary Barnes wrote: FYI... the DISPATCH specific deadlines are as follows and are also on the WG wiki. Please note that the initial deadline is just two weeks away. �There has been alot of fuss about these deadlines However, folks need to understand that the first deadline is just letting the chairs know that you want to discuss a particular work item - i.e., one sentence is all we need by that date. �You have a week to refine that idea into a *rough* charter. � Based upon discussions over the next two weeks, the chairs (conferring with the ADs) will decide what topics are targeted for the meeting. �You then have 4 weeks to work on a draft related to the topic. � However, you don't necessarily need a draft since the focus is on the charter (with that term used very loosely). �We need a problem statement along with a guess at deliverables. �The objective of the discussions on the mailing list and at the f2f meeting is to determine if the problem/work item is scoped tightly enough that it's solvable/doable, as well as to guage WG interest in the topic and willingness to contribute. �If it's agreed, then we can use the mailing list to refine the charter. � We have been flexible about the dates as long as folks can give us an idea of when they will be able to meet the deadlines. �We need a rough idea of the topics in order to request an appropriate length agenda slot. �The length tends to be far more variable than other WGs. �Note, that the deadline for the topic announcements aligns with the deadline for requesting a WG slot.� Regards,Mary.DISPATCH WG co-chair. ========================================================== * �Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 weeks before -00 deadline] � � *2 weeks from today*� * Sept. 12th, 2011. Cutoff for charter proposals for topics. [Three weeks prior to BoF proposal deadline, two weeks before announcement of topics] * Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are announced. [10 days before AD BoF approval and deadline to request WG slot, 4 weeks before -00 deadline, deadline for requesting WG session] * October 24th, 2011. -00 draft deadline. * October 31st, 2011. Draft deadline. ---------- Forwarded message ---------- From: IETF Agenda Date: Mon, Aug 22, 2011 at 1:15 PM Subject: 82nd IETF - Working Group/BOF Scheduling To: Working Group Chairs Cc: irsg@irtf.org ----------------------------------------------------------------- 82nd IETF � Taipei, Taiwan Meeting Dates: November 13-18, 2011 Host: Taiwan Network Information Center (TWNIC) ----------------------------------------------------------------- IETF meetings start Monday morning and run through Friday mid-afternoon (15:15). We are accepting scheduling requests for all Working Groups and BOFs starting today. �The milestones and deadlines for scheduling-related activities are as follows: NOTE: cutoff dates are subject to change. - 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. - 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (00:00 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool. - 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (00:00 UTC). To request a BOF, please see instructions on Requesting a BOF. - 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (00:00 UTC). - 2011-10-13 (Thursday): Preliminary agenda published for comment. - 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (00:00 UTC). - 2011-10-21 (Friday): Final agenda to be published. - 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. - 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. Submitting Requests for Working Group and BOF Sessions Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions. The URL for the tool is: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi Instructions for using the tool are available at: http://www.ietf.org/instructions/session_request_tool_instruction.html Please send requests to schedule your BOF sessions to agenda@ietf.org. �Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. �(This document is included below.) Submitting Session Agendas For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible. �Draft Working Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. �Revised Working Group agendas are due no later than Monday, November 7, 2011 at 17:00 PT. �The proposed agenda for a BOF session should be submitted along with your request for a session. �Please be sure to copy your Area Director on that message. Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. �If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved. The URL for the tool is: https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi Additional information about this tool is available at: http://www.ietf.org/instructions/meeting_materials_tool.html Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" Web page as soon as they are submitted. The URL for the "IETF 82 Meeting Materials" Web page is: https://datatracker.ietf.org/meeting/82/materials.html If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." �The same User ID and password will work for both tools. �If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. �If you require assistance in using either tool, or wish to report a bug, then please send a message to: ietf-action@ietf.org. =============================================================== For your convenience, comprehensive information on requesting meeting sessions at IETF 82 is presented below: 1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. �The URL for the tool is: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi Instructions for using the tool are available at: http://www.ietf.org/instructions/session_request_tool_instruction.html If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. �If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s). Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s). When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line. 2. BOFs will NOT be scheduled unless the Area Director(s) approved request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, and the information requested in (4) below. (Please read the BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a session for a BOF.) 3. A Working Group may request either one or two sessions. �If your Working Group requires more than two sessions, then your request must be approved by an Area Director. �Additional sessions will be assigned, based on availability, after Monday, October 17, 2011 at 17:00 PT, the cut-off date for requests to reschedule a session. 4. You MUST provide the following information before a Working Group or BOF session will be scheduled: � �a. Working Group or BOF full name with acronym in brackets: � �b. AREA under which Working Group or BOF appears: � �c. CONFLICTS you wish to avoid, please be as specific as possible: � �d. Expected Attendance: � �e. Special requests: � �f. Number of sessions: � �g. Length of session: � � � - 1 hour � � � - 1 1/2 hours � � � - 2 hours � � � - 2 1/2 hours For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt). =============================================================== For your convenience please find here a list of the IETF Area Directors with their e-mail addresses: IETF Chair Russ Housley Applications Area (app) Pete Resnick Peter Saint-Andre Internet Area (int) Jari Arkko Ralph Droms Operations & Management Area (ops) Ronald Bonica Dan Romascanu Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo Robert Sparks Routing Area (rtg) Stewart Bryant Adrian Farrel Security Area (sec) Stephen Farrell Sean Turner Transport Area (tsv) Wesley Eddy David Harrington �=========================================================== 81th IETF Meeting Attendance Number - TBA _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --=_977cfd01be52a07f4205a734d4f707dc Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Mary,

Apologies for the delay in responding. We need some more few days to submit= a problem statement/proposed work item for the IETF 82 timeframe. We are e= ngaged in drafting the answer to all comments raised via email in the next = draft version.

Thanks & Regards
sunil kumar sinha


On Sat, 03 Sep 2011 00:37:04 +0530 wrote
>At this point, we've only received one email indicating that an individual= will be putting forth a topic for discussion for the IETF-82 timeframe. = =EF=BF=BDPlease let the chairs know by Monday, Sept. 5th if you plan to sub= mit a problem statement/proposed work item for the IETF-82 timeframe.=EF=BF= =BD

Thanks,MaryDISPATCH WG co-chair

On Mon, Aug 22, 2011 at 3:44 PM, Mary Barnes w= rote:

FYI... the DISPATCH specific deadlines are as follows and are also on the W= G wiki. Please note that the initial deadline is just two weeks away. =EF= =BF=BDThere has been alot of fuss about these deadlines However, folks need= to understand that the first deadline is just letting the chairs know that= you want to discuss a particular work item - i.e., one sentence is all we = need by that date. =EF=BF=BDYou have a week to refine that idea into a *rou= gh* charter. =EF=BF=BD


Based upon discussions over the next two weeks, the chairs (conferring with= the ADs) will decide what topics are targeted for the meeting. =EF=BF=BDYo= u then have 4 weeks to work on a draft related to the topic. =EF=BF=BD


However, you don't necessarily need a draft since the focus is on the chart= er (with that term used very loosely). =EF=BF=BDWe need a problem statement= along with a guess at deliverables. =EF=BF=BDThe objective of the discussi= ons on the mailing list and at the f2f meeting is to determine if the probl= em/work item is scoped tightly enough that it's solvable/doable, as well as= to guage WG interest in the topic and willingness to contribute. =EF=BF=BD= If it's agreed, then we can use the mailing list to refine the charter. =EF= =BF=BD


We have been flexible about the dates as long as folks can give us an idea = of when they will be able to meet the deadlines. =EF=BF=BDWe need a rough i= dea of the topics in order to request an appropriate length agenda slot. = =EF=BF=BDThe length tends to be far more variable than other WGs. =EF=BF=BD= Note, that the deadline for the topic announcements aligns with the deadlin= e for requesting a WG slot.=EF=BF=BD



Regards,Mary.DISPATCH WG co-chair.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

* =EF=BF=BDSept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of= plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 w= eeks before -00 deadline] =EF=BF=BD =EF=BF=BD *2 weeks from today*=EF=BF=BD=


* Sept. 12th, 2011. Cutoff for charter proposals for topics. [Three weeks p= rior to BoF proposal deadline, two weeks before announcement of topics]
* Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are announce= d. [10 days before AD BoF approval and deadline to request WG slot, 4 weeks= before -00 deadline, deadline for requesting WG session]


* October 24th, 2011. -00 draft deadline.
* October 31st, 2011. Draft deadline.



---------- Forwarded message ----------

From: IETF Agenda
Date: Mon, Aug 22, 2011 at 1:15 PM
Subject: 82nd IETF - Working Group/BOF Scheduling


To: Working Group Chairs
Cc: irsg@irtf.org


-----------------------------------------------------------------



82nd IETF =EF=BF=BD Taipei, Taiwan

Meeting Dates: November 13-18, 2011

Host: Taiwan Network Information Center (TWNIC)

-----------------------------------------------------------------

IETF meetings start Monday morning and run through Friday mid-afternoon (15= :15).



We are accepting scheduling requests for all Working Groups and BOFs starti= ng today. =EF=BF=BDThe milestones and deadlines for scheduling-related acti= vities are as follows:



NOTE: cutoff dates are subject to change.



- 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool.

- 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group m= eetings at 17:00 PT (00:00 UTC). To request a Working Group session, use th= e IETF Meeting Session Request Tool.

- 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area Direc= tors at 17:00 PT (00:00 UTC). To request a BOF, please see instructions on = Requesting a BOF.

- 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (00:00 UTC).

- 2011-10-13 (Thursday): Preliminary agenda published for comment.

- 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group= and BOF meetings 17:00 PT (00:00 UTC).

- 2011-10-21 (Friday): Final agenda to be published.

- 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:0= 0 UTC), upload using IETF Meeting Materials Management Tool.

- 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00= UTC), upload using IETF Meeting Materials Management Tool.



Submitting Requests for Working Group and BOF Sessions



Please submit requests to schedule your Working Group sessions using the "I= ETF Meeting Session Request Tool," a Web-based tool for submitting all of t= he information that the Secretariat requires to schedule your sessions.





The URL for the tool is:



https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi



Instructions for using the tool are available at:



http://www.ietf.org/instructions/session_request_tool_instruction.html



Please send requests to schedule your BOF sessions to agenda@ietf.org. =EF= =BF=BDPlease include the acronym of your BOF in the subject line of the mes= sage, and include all of the information specified in item (4) of "Requesti= ng Meeting Sessions at IETF Meetings" in the body. =EF=BF=BD(This document = is included below.)





Submitting Session Agendas



For the convenience of meeting attendees, we ask that you submit the agenda= s for your Working Group sessions as early as possible. =EF=BF=BDDraft Work= ing Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. =EF=BF= =BDRevised Working Group agendas are due no later than Monday, November 7, = 2011 at 17:00 PT. =EF=BF=BDThe proposed agenda for a BOF session should be = submitted along with your request for a session. =EF=BF=BDPlease be sure to= copy your Area Director on that message.





Please submit the agendas for your Working Group sessions using the "IETF M= eeting Materials Management Tool," a Web-based tool for making your meeting= agenda, minutes, and presentation slides available to the community before= , during, and after an IETF meeting. =EF=BF=BDIf you are a BOF chair, then = you may use the tool to submit a revised agenda as well as other materials = for your BOF once the BOF has been approved.





The URL for the tool is:



https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi



Additional information about this tool is available at:



http://www.ietf.org/instructions/meeting_materials_tool.html



Agendas submitted via the tool will be available to the public on the "IETF= Meeting Materials" Web page as soon as they are submitted.



The URL for the "IETF 82 Meeting Materials" Web page is:



https://datatracker.ietf.org/meeting/82/materials.html



If you are a Working Group chair, then you already have accounts on the "IE= TF Meeting Session Request Tool" and the "IETF Meeting Materials Management= Tool." =EF=BF=BDThe same User ID and password will work for both tools. = =EF=BF=BDIf you are a BOF chair who is not also a Working Group chair, then= you will be given an account on the "IETF Meeting Materials Management Too= l" when your BOF has been approved. =EF=BF=BDIf you require assistance in u= sing either tool, or wish to report a bug, then please send a message to:


ietf-action@ietf.org.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For your convenience, comprehensive information on requesting meeting sessi= ons at IETF 82 is presented below:



1. Requests to schedule Working Group sessions should be submitted using th= e "IETF Meeting Session Request Tool," a Web-based tool for submitting all = of the information required by the Secretariat to schedule your sessions. = =EF=BF=BDThe URL for the tool is:





https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi



Instructions for using the tool are available at:



http://www.ietf.org/instructions/session_request_tool_instruction.html



If you require an account on this tool, or assistance in using it, then ple= ase send a message to ietf-action@ietf.org. =EF=BF=BDIf you are unable to u= se the tool, then you may send your request via e-mail to agenda@ietf.org, = with a copy to the appropriate Area Director(s).





Requests to schedule BOF sessions must be sent to agenda@ietf.org with a co= py to the appropriate Area Director(s).



When submitting a Working Group or BOF session request by e-mail, please in= clude the Working Group or BOF acronym in the Subject line.



2. BOFs will NOT be scheduled unless the Area Director(s) approved request = is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S) (gi= ven together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, and = the information requested in (4) below. (Please read the BOF Procedure at: = http://www.ietf.org/ietf/1bof-procedures.txt before requesting a session fo= r a BOF.)





3. A Working Group may request either one or two sessions. =EF=BF=BDIf your= Working Group requires more than two sessions, then your request must be a= pproved by an Area Director. =EF=BF=BDAdditional sessions will be assigned,= based on availability, after Monday, October 17, 2011 at 17:00 PT, the cut= -off date for requests to reschedule a session.





4. You MUST provide the following information before a Working Group or BOF= session will be scheduled:



=EF=BF=BD =EF=BF=BDa. Working Group or BOF full name with acronym in brack= ets:



=EF=BF=BD =EF=BF=BDb. AREA under which Working Group or BOF appears:



=EF=BF=BD =EF=BF=BDc. CONFLICTS you wish to avoid, please be as specific a= s possible:



=EF=BF=BD =EF=BF=BDd. Expected Attendance:



=EF=BF=BD =EF=BF=BDe. Special requests:



=EF=BF=BD =EF=BF=BDf. Number of sessions:



=EF=BF=BD =EF=BF=BDg. Length of session:

=EF=BF=BD =EF=BF=BD =EF=BF=BD - 1 hour

=EF=BF=BD =EF=BF=BD =EF=BF=BD - 1 1/2 hours

=EF=BF=BD =EF=BF=BD =EF=BF=BD - 2 hours

=EF=BF=BD =EF=BF=BD =EF=BF=BD - 2 1/2 hours



For more information on scheduling Working Group and BOF sessions, please r= efer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (= http://www.ietf.org/rfc/rfc2418.txt).



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For your convenience please find here a list of the IETF Area Directors wit= h their e-mail addresses:



IETF Chair

Russ Housley



Applications Area (app)

Pete Resnick

Peter Saint-Andre



Internet Area (int)

Jari Arkko

Ralph Droms



Operations & Management Area (ops)

Ronald Bonica

Dan Romascanu



Real-time Applications and Infrastructure Area (rai)

Gonzalo Camarillo

Robert Sparks



Routing Area (rtg)

Stewart Bryant

Adrian Farrel



Security Area (sec)

Stephen Farrell

Sean Turner



Transport Area (tsv)

Wesley Eddy

David Harrington

=EF=BF=BD=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

81th IETF Meeting Attendance Number - TBA





_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch



=

Treat yourself at a restaur= ant, spa, resort and much more with Re= diff Deal ho jaye! --=_977cfd01be52a07f4205a734d4f707dc-- From dworley@avaya.com Tue Sep 6 12:14:00 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3621F8DB0 for ; Tue, 6 Sep 2011 12:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v+pTT5z2uav for ; Tue, 6 Sep 2011 12:13:59 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7821F8DA4 for ; Tue, 6 Sep 2011 12:13:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOZwZk7GmAcF/2dsb2JhbABDqAB4gUYBAQEBAxIoPxACAQgNASgQMiUCBAENDRqkXAKcTYYKYASYW4t8 X-IronPort-AV: E=Sophos;i="4.68,340,1312171200"; d="scan'208";a="205972815" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Sep 2011 15:15:38 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Sep 2011 15:10:54 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 6 Sep 2011 15:15:38 -0400 From: "Worley, Dale R (Dale)" To: Andrew Allen , Cullen Jennings Date: Tue, 6 Sep 2011 15:15:37 -0400 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqk= Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, 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 Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 19:14:00 -0000 I hope I'm not the only person who feels that this "debate" is a tempest in a teapot. I can't see any serious reason not to define a URN namespace for IMEIs. These names have various deficiencies from various points of view, but none that are substantially worse than the currently popular system of constructing URNs from UUIDs which are constructed from MAC addresses (which are printed on a label on the back of the phone). There can only be interoperability problems if a proxy is unable to accept instance-ids that are in namespaces that it does not understand. But such a proxy is clearly deficient, and indeed, one would have to go out of one's way to build a proxy that had this deficiency, since the simplest and most natural implementation is to treat the instance-id as an opaque string. There may be IPR attached to this, but as the only vendors who would care about using it are manufacturers who have licensed the entire 3GPP IPR bundle, that causes nobody any problems that they do not already have. I regard to privacy, any user of a 3GPP phone has submitted to having their privacy protected and violated to exactly the degree designed into 3G= PP, and the transmission of an IMEI-based instance-id between the 3GPP phone through a 3GPP network to a 3GPP registrar is not going to decrease (or increase) their privacy. Can we just approve this and stop spending time on it? Dale From spromano@unina.it Wed Sep 7 10:54:10 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AE21F8CDD for ; Wed, 7 Sep 2011 10:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.564 X-Spam-Level: X-Spam-Status: No, score=-100.564 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8qWOKVUCymQ for ; Wed, 7 Sep 2011 10:54:08 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id C5E6C21F8C86 for ; Wed, 7 Sep 2011 10:53:51 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p87HtWXT006082 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 19:55:32 +0200 Message-ID: <4E67B00F.50706@unina.it> Date: Wed, 07 Sep 2011 19:55:27 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.21) Gecko/20110830 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Mary Barnes , Cullen Jennings References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000202030703080308040007" Cc: DISPATCH , rai-ads@tools.ietf.org Subject: Re: [dispatch] Reminder: DISPATCH WG 1st deadline for IETF-82 is Monday, Sept. 5th X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 17:54:10 -0000 This is a multi-part message in MIME format. --------------000202030703080308040007 Content-Type: multipart/alternative; boundary="------------020003000808040402060507" --------------020003000808040402060507 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear all, please find attached a revised proposal submission related to "Distributed Conferencing". I am sending a first draft of a potential charter for this WG, just to give you some initial material to discuss. Let me thank you all for your attention. I'm looking forward to receiving your feedback. Cheers, Simon Il 02/09/2011 21:06, Mary Barnes ha scritto: > At this point, we've only received one email indicating that an > individual will be putting forth a topic for discussion for the > IETF-82 timeframe. Please let the chairs know by Monday, Sept. 5th if > you plan to submit a problem statement/proposed work item for the > IETF-82 timeframe. > > Thanks, > Mary > DISPATCH WG co-chair > > On Mon, Aug 22, 2011 at 3:44 PM, Mary Barnes > > wrote: > > FYI... the DISPATCH specific deadlines are as follows and are also > on the WG wiki. Please note that the initial deadline is just two > weeks away. There has been alot of fuss about these deadlines > However, folks need to understand that the first deadline is just > letting the chairs know that you want to discuss a particular work > item - i.e., one sentence is all we need by that date. You have a > week to refine that idea into a *rough* charter. > > Based upon discussions over the next two weeks, the chairs > (conferring with the ADs) will decide what topics are targeted for > the meeting. You then have 4 weeks to work on a draft related to > the topic. > > However, you don't necessarily need a draft since the focus is on > the charter (with that term used very loosely). We need a problem > statement along with a guess at deliverables. The objective of > the discussions on the mailing list and at the f2f meeting is to > determine if the problem/work item is scoped tightly enough that > it's solvable/doable, as well as to guage WG interest in the topic > and willingness to contribute. If it's agreed, then we can use > the mailing list to refine the charter. > > We have been flexible about the dates as long as folks can give us > an idea of when they will be able to meet the deadlines. We need > a rough idea of the topics in order to request an appropriate > length agenda slot. The length tends to be far more variable than > other WGs. Note, that the deadline for the topic announcements > aligns with the deadline for requesting a WG slot. > > Regards, > Mary. > DISPATCH WG co-chair. > > ========================================================== > > * Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG > of plans to submit a proposal. [Two weeks prior to BoF proposal > deadline, 7 weeks before -00 deadline] *2 weeks from today* > > * Sept. 12th, 2011. Cutoff for charter proposals for topics. > [Three weeks prior to BoF proposal deadline, two weeks before > announcement of topics] > > * Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are > announced. [10 days before AD BoF approval and deadline to request > WG slot, 4 weeks before -00 deadline, deadline for requesting WG > session] > > * October 24th, 2011. -00 draft deadline. > > * October 31st, 2011. Draft deadline. > > > > ---------- Forwarded message ---------- > From: *IETF Agenda* > > Date: Mon, Aug 22, 2011 at 1:15 PM > Subject: 82nd IETF - Working Group/BOF Scheduling > To: Working Group Chairs > > Cc: irsg@irtf.org > > > ----------------------------------------------------------------- > 82nd IETF Taipei, Taiwan > Meeting Dates: November 13-18, 2011 > Host: Taiwan Network Information Center (TWNIC) > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday > mid-afternoon (15:15). > > We are accepting scheduling requests for all Working Groups and > BOFs starting today. The milestones and deadlines for > scheduling-related activities are as follows: > > NOTE: cutoff dates are subject to change. > > - 2011-08-15 (Monday): Working Group and BOF scheduling begins. To > request a Working Group session, use the IETF Meeting Session > Request Tool. > - 2011-09-26 (Monday): Cutoff date for requests to schedule > Working Group meetings at 17:00 PT (00:00 UTC). To request a > Working Group session, use the IETF Meeting Session Request Tool. > - 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to > Area Directors at 17:00 PT (00:00 UTC). To request a BOF, please > see instructions on Requesting a BOF. > - 2011-10-06 (Thursday): Cutoff date for Area Directors to approve > BOFs at 17:00 PT (00:00 UTC). > - 2011-10-13 (Thursday): Preliminary agenda published for comment. > - 2011-10-17 (Monday): Cutoff date for requests to reschedule > Working Group and BOF meetings 17:00 PT (00:00 UTC). > - 2011-10-21 (Friday): Final agenda to be published. > - 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 > PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. > - 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 > PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions > using the "IETF Meeting Session Request Tool," a Web-based tool > for submitting all of the information that the Secretariat > requires to schedule your sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to > agenda@ietf.org . Please include the > acronym of your BOF in the subject line of the message, and > include all of the information specified in item (4) of > "Requesting Meeting Sessions at IETF Meetings" in the body. (This > document is included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit > the agendas for your Working Group sessions as early as possible. > Draft Working Group agendas are due Wednesday, November 2, 2011 > by 17:00 PT. Revised Working Group agendas are due no later than > Monday, November 7, 2011 at 17:00 PT. The proposed agenda for a > BOF session should be submitted along with your request for a > session. Please be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using > the "IETF Meeting Materials Management Tool," a Web-based tool for > making your meeting agenda, minutes, and presentation slides > available to the community before, during, and after an IETF > meeting. If you are a BOF chair, then you may use the tool to > submit a revised agenda as well as other materials for your BOF > once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on > the "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 82 Meeting Materials" Web page is: > > https://datatracker.ietf.org/meeting/82/materials.html > > If you are a Working Group chair, then you already have accounts > on the "IETF Meeting Session Request Tool" and the "IETF Meeting > Materials Management Tool." The same User ID and password will > work for both tools. If you are a BOF chair who is not also a > Working Group chair, then you will be given an account on the > "IETF Meeting Materials Management Tool" when your BOF has been > approved. If you require assistance in using either tool, or wish > to report a bug, then please send a message to: > ietf-action@ietf.org . > =============================================================== > For your convenience, comprehensive information on requesting > meeting sessions at IETF 82 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted > using the "IETF Meeting Session Request Tool," a Web-based tool > for submitting all of the information required by the Secretariat > to schedule your sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, > then please send a message to ietf-action@ietf.org > . If you are unable to use the tool, > then you may send your request via e-mail to agenda@ietf.org > , with a copy to the appropriate Area > Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org > with a copy to the appropriate Area > Director(s). > > When submitting a Working Group or BOF session request by e-mail, > please include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, > CHAIR(S) NAME(S) (given together with e-mail address(es)), AN > AGENDA AND FULL DESCRIPTION, and the information requested in (4) > below. (Please read the BOF Procedure at: > http://www.ietf.org/ietf/1bof-procedures.txt before requesting a > session for a BOF.) > > 3. A Working Group may request either one or two sessions. If > your Working Group requires more than two sessions, then your > request must be approved by an Area Director. Additional sessions > will be assigned, based on availability, after Monday, October 17, > 2011 at 17:00 PT, the cut-off date for requests to reschedule a > session. > > 4. You MUST provide the following information before a Working > Group or BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance: > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, > please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines > and Procedures" (http://www.ietf.org/rfc/rfc2418.txt). > =============================================================== > For your convenience please find here a list of the IETF Area > Directors with their e-mail addresses: > > IETF Chair > Russ Housley > > > Applications Area (app) > Pete Resnick > > Peter Saint-Andre > > > Internet Area (int) > Jari Arkko > > Ralph Droms > > > Operations & Management Area (ops) > Ronald Bonica > > Dan Romascanu > > > Real-time Applications and Infrastructure Area (rai) > Gonzalo Camarillo > > Robert Sparks > > > Routing Area (rtg) > Stewart Bryant > > Adrian Farrel > > > Security Area (sec) > Stephen Farrell > > Sean Turner > > > Transport Area (tsv) > Wesley Eddy > > David Harrington > > =========================================================== > 81th IETF Meeting Attendance Number - TBA > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------020003000808040402060507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear all,

please find attached a revised proposal submission related to "Distributed Conferencing". I am sending a first draft of a potential charter for this WG, just to give you some initial material to discuss. Let me thank you all for your attention. I'm looking forward to receiving your feedback.

Cheers,

Simon

Il 02/09/2011 21:06, Mary Barnes ha scritto:
At this point, we've only received one email indicating that an individual will be putting forth a topic for discussion for the IETF-82 timeframe. Please let the chairs know by Monday, Sept. 5th if you plan to submit a problem statement/proposed work item for the IETF-82 timeframe.

Thanks,
Mary
DISPATCH WG co-chair

On Mon, Aug 22, 2011 at 3:44 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
FYI... the DISPATCH specific deadlines are as follows and are also on the WG wiki. Please note that the initial deadline is just two weeks away. There has been alot of fuss about these deadlines However, folks need to understand that the first deadline is just letting the chairs know that you want to discuss a particular work item - i.e., one sentence is all we need by that date. You have a week to refine that idea into a *rough* charter.

Based upon discussions over the next two weeks, the chairs (conferring with the ADs) will decide what topics are targeted for the meeting. You then have 4 weeks to work on a draft related to the topic.

However, you don't necessarily need a draft since the focus is on the charter (with that term used very loosely). We need a problem statement along with a guess at deliverables. The objective of the discussions on the mailing list and at the f2f meeting is to determine if the problem/work item is scoped tightly enough that it's solvable/doable, as well as to guage WG interest in the topic and willingness to contribute. If it's agreed, then we can use the mailing list to refine the charter.

We have been flexible about the dates as long as folks can give us an idea of when they will be able to meet the deadlines. We need a rough idea of the topics in order to request an appropriate length agenda slot. The length tends to be far more variable than other WGs. Note, that the deadline for the topic announcements aligns with the deadline for requesting a WG slot.

Regards,
Mary.
DISPATCH WG co-chair.

==========================================================

* Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 weeks before -00 deadline] *2 weeks from today*

* Sept. 12th, 2011. Cutoff for charter proposals for topics. [Three weeks prior to BoF proposal deadline, two weeks before announcement of topics]

* Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are announced. [10 days before AD BoF approval and deadline to request WG slot, 4 weeks before -00 deadline, deadline for requesting WG session]

* October 24th, 2011. -00 draft deadline.

* October 31st, 2011. Draft deadline.



---------- Forwarded message ----------
From: IETF Agenda <agenda@ietf.org>
Date: Mon, Aug 22, 2011 at 1:15 PM
Subject: 82nd IETF - Working Group/BOF Scheduling
To: Working Group Chairs <wgchairs@ietf.org>
Cc: irsg@irtf.org


-----------------------------------------------------------------
82nd IETF Taipei, Taiwan
Meeting Dates: November 13-18, 2011
Host: Taiwan Network Information Center (TWNIC)
-----------------------------------------------------------------
IETF meetings start Monday morning and run through Friday mid-afternoon (15:15).

We are accepting scheduling requests for all Working Groups and BOFs starting today. The milestones and deadlines for scheduling-related activities are as follows:

NOTE: cutoff dates are subject to change.

- 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool.
- 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (00:00 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool.
- 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (00:00 UTC). To request a BOF, please see instructions on Requesting a BOF.
- 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (00:00 UTC).
- 2011-10-13 (Thursday): Preliminary agenda published for comment.
- 2011-10-17 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (00:00 UTC).
- 2011-10-21 (Friday): Final agenda to be published.
- 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool.
- 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool.

Submitting Requests for Working Group and BOF Sessions

Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_tool_instruction.html

Please send requests to schedule your BOF sessions to agenda@ietf.org. Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. (This document is included below.)

Submitting Session Agendas

For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible. Draft Working Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. Revised Working Group agendas are due no later than Monday, November 7, 2011 at 17:00 PT. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message.

Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved.

The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi

Additional information about this tool is available at:

http://www.ietf.org/instructions/meeting_materials_tool.html

Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" Web page as soon as they are submitted.

The URL for the "IETF 82 Meeting Materials" Web page is:

https://datatracker.ietf.org/meeting/82/materials.html

If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to:
ietf-action@ietf.org.
===============================================================
For your convenience, comprehensive information on requesting meeting sessions at IETF 82 is presented below:

1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is:

https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi

Instructions for using the tool are available at:

http://www.ietf.org/instructions/session_request_tool_instruction.html

If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s).

Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s).

When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line.

2. BOFs will NOT be scheduled unless the Area Director(s) approved request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, CHAIR(S) NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL DESCRIPTION, and the information requested in (4) below. (Please read the BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before requesting a session for a BOF.)

3. A Working Group may request either one or two sessions. If your Working Group requires more than two sessions, then your request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Monday, October 17, 2011 at 17:00 PT, the cut-off date for requests to reschedule a session.

4. You MUST provide the following information before a Working Group or BOF session will be scheduled:

a. Working Group or BOF full name with acronym in brackets:

b. AREA under which Working Group or BOF appears:

c. CONFLICTS you wish to avoid, please be as specific as possible:

d. Expected Attendance:

e. Special requests:

f. Number of sessions:

g. Length of session:
- 1 hour
- 1 1/2 hours
- 2 hours
- 2 1/2 hours

For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt).
===============================================================
For your convenience please find here a list of the IETF Area Directors with their e-mail addresses:

IETF Chair
Russ Housley <housley@vigilsec.com>

Applications Area (app)
Pete Resnick <presnick@qualcomm.com>
Peter Saint-Andre <stpeter@stpeter.im>

Internet Area (int)
Jari Arkko <jari.arkko@piuha.net>
Ralph Droms <rdroms.ietf@gmail.com>

Operations & Management Area (ops)
Ronald Bonica <rbonica@juniper.net>
Dan Romascanu <dromasca@avaya.com>

Real-time Applications and Infrastructure Area (rai)
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.com>

Routing Area (rtg)
Stewart Bryant <stbryant@cisco.com>
Adrian Farrel <adrian@olddog.co.uk>

Security Area (sec)
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sean Turner <turners@ieca.com>

Transport Area (tsv)
Wesley Eddy <wes@mti-systems.com>
David Harrington <ietfdbh@comcast.net>
===========================================================
81th IETF Meeting Attendance Number - TBA



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento  l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------020003000808040402060507-- --------------000202030703080308040007 Content-Type: text/plain; name="DCON-CharterProposal.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DCON-CharterProposal.txt" - Decription of Working Group The focus of this Working Group is to develop a standard solution for sca= lable conferencing over the Internet. The WG will define a standard suite= of protocols for distributed conferencing and will draw inspiration from= the work carried out in the XCON working group, which has defined a comp= lete architecture for centralized conferencing. DCON is based on the ide= a that a distributed conference can be setup by appropriately orchestrating the op= eration of a number of XCON focus elements, each in charge of managing a = certain number of participants. Interaction between each participant and = the corresponding conference focus will be entirely based on the standard= XCON framework, whereas inter-focus interaction will be defined by this = WG. In the DCON architecture a number of entities are used to manage conferen= ce setup in the presence of clients which are distributed across a geogra= phical network. Each managing entity plays the role of a conference focus as de= fined in the XCON working group documents. Indeed, each XCON focus will b= e in charge of managing a certain number of clients falling under its own= "realm". In order to move the XCON scope towards a distributed environm= ent, we will introduce inter-focus coordination, which is needed to effec= tively setup and manage conference instantiation and coordination. As in= the centralized case, we will define logical entities and naming conv= entions. An appropriate data model for distributed conferencing will be = potentially defined and will extend, when needed, the XCON data model. F= urthermore, we will propose the adoption of a suitable set of protocols w= hich are complementary to the call signaling protocols and are needed to = support advanced conferencing applications. The WG will basically need to introduce two major functions: (i) a coordi= nation level among conference focus entities; (ii) a way to effectively d= istribute conference state information. As to the first point above, the= coordination level is needed in order to manage a distributed conference= along its entire life-cycle. For instance, once a user decides to create= a new conference, the corresponding conference focus has to distribute c= onference information to all other foci, in such a way as to enable other= potential participants to retrieve the needed data and possibly subscrib= e to the event. The WG will make the assumption that all the operations n= eeded inside a single conference cloud are managed via the protocols an= d interfaces defined inside the XCON working group. Hence, each single c= loud will keep on being based on a star-topology graph for all what conce= rns the call signaling part. The various available stars will then be con= nected through an upper-layer topology providing inter-focus communicatio= n. The overall topology of the distributed conferencing scenario will lo= ok like an overlay network of focus entities, each managing an underlying= "centralized" conferencing island. The WG will envisage the possibility = to exploit extended Instant Messaging (IM) protocols (e.g. XMPP) for inte= r-focus communication. As to the second point mentioned above, it looks clear that a way to prop= agate information about conferences is needed when switching the view fro= m a centralized to a distributed perspective. Indeed, whenever a new con= ference is created (or an active conference changes its state) such an ev= ent has to be communicated to all interested (or active) participants. G= iven the intrinsic nature of the distributed framework (which actually ex= pands the centralized one through the introduction of an overlay network = of focus entities), the actual flow of information will always foresee = the interaction among conference focus entities for both conference infor= mation exchanging and state changes notifications. The same obviously ap= plies also to the involved natively centralized protocols defined in the = XCON framework. A suitable mechanism will be defined by the WG, allowing= for the dispatching of such centralized messages across the DCON network= =2E The mechanism in question must be fully compliant with the existing o= peration of XCON clouds, which must keep their local participants total= ly unaware of the potential distributed nature of conferences. Conference= state propagation will take place in a number of alternative ways. For = instance, each focus might flood the received information across an inter= -focus communication mesh, thus guaranteeing that potential participants = belonging to heterogeneous islands can be reached. In such case, focus e= ntities are "stateful", i.e. each of them stores information about curren= t sessions and forwards such information to all peering entities in order= to get them up-to-date with respect to available conference sessions.=20 On the other hand, a distributed repository might be employed for the sak= e of storing conference information. Focus entities would access such re= pository, both to publish (either upon creation of a new conference, or t= o notify a change in the state of an active conference) and to retrieve i= nformation about active conferences (e.g. when a new participant wants to= access the list of ongoing/scheduled conference sessions he might be int= erested to join). In this last case, focus entities are "stateless". Fin= ally, the WG will evaluate the benefits deriving from the adoption of a p= ure peer-to-peer approach for the purpose of conference state information= spreading. The deliverables for the group will be: - A Framework for Distributed Conferencing (backward-compatible with XCON= in the single-cloud case) - A survey of potential solutions to the construction and maintainance of= a DCON conference repository (stateless, stateful, based on flooding, p2= p, etc.) - Requirements for an XCON-DCON Synchronization Protocol (XDSP) - Specification of the XDSP - DCON call-flows draft (involving the use of XDSP) - Goals and Milestones February 2012 --> Submit Framework document for publication as PS April 2012 --> Submit XDSP Requirements document for publication as Infor= mational June 2012 --> Submit survey of solutions for the DCON conference reposito= ry for publication as Informational September 2012 --> Submit XDSP Specification document for publication as = PS January 2013 --> Submit DCON call flows draft for publication as Informat= ional --------------000202030703080308040007-- From amardeep_sinha@rediffmail.com Tue Sep 13 13:45:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8944D21F8CC7 for ; Tue, 13 Sep 2011 13:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=1.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_83=0.6, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj4DiN5NzsdW for ; Tue, 13 Sep 2011 13:45:48 -0700 (PDT) Received: from rediffmail.com (f5mail-224-142.rediffmail.com [114.31.224.142]) by ietfa.amsl.com (Postfix) with SMTP id D5B7421F8CC6 for ; Tue, 13 Sep 2011 13:45:46 -0700 (PDT) Received: (qmail 13192 invoked by uid 510); 13 Sep 2011 20:47:48 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=jGt3d0NGBplq5C1lGlCTnXErt+Fg/u/or6xI6MjJ0RBdMmmGkKoR/Tb12BIli/KIzaLFmuvo5ks0JHmn9g+fZ+VPshuuPtLLe9bs9sUzwHnjfj+RvlMMC/BToaLki6xlIm/l106FbbQdHiwmmintFl27cDldMhUiLeZsghafbHM= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150204.4E6FC176.0029,ss=1,re=-2.300,fgs=0 X-REDF-OSEN: amardeep_sinha@rediffmail.com Date: 13 Sep 2011 20:47:48 -0000 MIME-Version: 1.0 To: Received: from unknown 122.167.98.242 by rediffmail.com via HTTP; 13 Sep 2011 20:47:48 -0000 Message-ID: <1314657559.S.36087.9253.F.H.TnN1bmlsIGt1bWFyIHNpbmhhAFJlOiBbZGlzcGF0Y2hdIE5ldyBEcmFmdCAtIGRyYWZ0LXNpbmhhLWRpc3A_.f5-224-128.old.1315946868.6940@webmail.rediffmail.com> in-reply-to: <20110829223918.9191.qmail@f5mail-224-128.rediffmail.com> From: "amar deep" Content-Type: multipart/alternative; boundary="=_92ab96c882548452cbc05b15185b4847" Cc: dispatch@ietf.org Subject: Re: [dispatch] =?utf-8?q?New_Draft_-_draft-sinha-dispatch-sip-continu?= =?utf-8?q?ation-option?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 20:45:49 -0000 --=_92ab96c882548452cbc05b15185b4847 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hello Everybody, We have submitted a revised draft “https://datatracker.ietf.org/doc/draft-sinha-dispatch-sip-continuation-option/?include_text=1”. Let me thank you all for your attention. I'm looking forward to receiving your feedback Thanks & Regards Amardeep Sinha On Tue, 30 Aug 2011 04:09:19 +0530 wrote >Dear All > Please find my answers inline wrt Paul Question. I am keeping everyone in loop for discussion so that most of the common queries I think has been addressed. In case there is any other question / clarification needed, please let us know. We will incorporate your valuable feedbacks based on the agreed items in our next document version. > Once again many thanks for your valuable feedbacks, much appreciate your valuable inputs and time. > Regards > Sunil kumar sinha > > > Sunil, > >I'm having trouble understanding the assumptions and intended use of this mechanism. I also think there are probably other ways of >accomplishing something similar. > [Sunil] Intended use: Applications as mentioned in Section 4, this is used as Called Party Voice feature service when Callee is not in a favorable state to receive calls, Callee is NOT in DND and can accept calls, Callee can set a parameter called NDDND (Non Dedicated Do Not Disturb) in Handsets / IP Devices or with NSP which initiates the mentioned 182 response on receiving INVITE instead of 180 Ringing from Handset or VFS as the case may be based on the configuration, finally its upto the sole discretion of Caller to make progress with placing the call or disconnect. Detailed Call Flow given in the proposal. We have studied all the methodologies and SIP parameters and found it difficult to incorporate this feature, so proposed this new SIP Header “Continue” with the designed call flows and behavior at UEs and Proxies. > >Some comments and questions on the draft: > >Figure 2: > >You don't show the F1 message. Does it contain 'Supported:continue'? If not, then putting Require:continue in the response is very questionable, since it can't be refused in a response. > [Sunil] INVITE contains “Supported: continue”, we will make the needful addition of INVITE (F1) in call flow as suggested by you in the next version. Thanks for your valuable suggestion. > >Is it intended that the 182 + Require: continue is to be interpreted by the UAC as indicating that the call hasn't yet alerted, and won't unless Continue:yes is sent? > [Sunil] Correct > >(That is an improper use of Require. It is supposed to mean "I require that you *support* this option", not that I require you to use it.) > [Sunil] Latter meaning holds good for the usage of “Require: continue” header, we have also portrayed in the same way. If there’s anything else you would like to know or want us to incorporate anything else,pls let us know > >Also, what is the intended behavior when the UAC does not support this mechanism? If it receives a 182 response, it will probably treat it just like a 180 and wait, assuming the call is alerting and will eventually be answered. Or does the UAS note there is no Supported:continue and return 486 rather than 182? > [Sunil] Agreed, accept your point fully, this is the case when caller doesn’t support this mechanism but callee does, so NDDND will not work for callee as the concept behind the usage of NDDND as a called party voice feature is to give option to the supported caller to display an option whether to finally place a call or not, the call will be placed based on the sole discretion of Caller. If Caller doesn’t support this functionality whether a DND will be flagged or Normal Call Treatment to be done I feel need to be again a configuration dependent on the Device/NSP or Device manufacturer / Service Provider implementation specific. I will incorporate the outcome behavior of this scenario in the next version after discussing with co-authors. Many thanks for your valuable feedbacks. In this case 182 won’t be responded by Callee, either 180 or 486 would be responded > >Section 4: > >IIUC this lists a number of cases where this feature might be used, yet to the UAC these are all indicated in the same way. So the user of the UAC has no idea why he is being asked to confirm or deny the importance of his call. > [Sunil] This is described above. Pls let me know if you have any questions. > > >General comments: > >This seems to be yet another spin on presence. Have you investigated how you might explicitly use presence for this? For instance, the UAS that wants this behavior could refuse (perhaps with 486) any call that doesn't have a Priority header with a sufficiently high value. In the response it could include a PIDF in the body (or content indirection to one). Then the UAC could interpret that, interact with its user, and perhaps generate another INVITE with a Priority header. > [Sunil] I agree to most of your points on the usage of Priority header, except one scenario which cannot be implemented. If Called Party supports the feature and Caller doesn’t support Priority, then this feature will be just DND. Our purpose is not to have DND by any means. In our case decision to treat this feature or not at the Callee although it is set at Callee based on Supported: continue present in initial INVITE from Caller. If Caller is not up-to-date with this feature, then he doesn’t send Supported: continue in initial INVITE and this call is treated as Normal Call with 180 Ringing sent by Called Party suppressing the feature set at Called Party. My apologies we haven’t put all the combination of scenarios in the first version of draft, we will send all position combination in our next version. Once again many thanks for your valuable feedbacks. > >Or, UACs that support this mechanism could simply subscribe to presence of the callee before sending the invite, and make a decision how to make the call based on what is received. > >[Sunil] Not all Handsets supports this. > >Or, if you really feel its essential to do this with one invite, an existing mechanism to defer alerting is through use of preconditions. >You could conceivably create a new precondition type to get the desired effect. (But this direction isn't appealing to me.) > >Most, I suggest you spend more time refining the requirements before getting involved in the mechanism. > >Thanks, >Paul Treat yourself at a restaurant, spa, resort and much more with Rediff Deal ho jaye! Amar --=_92ab96c882548452cbc05b15185b4847 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hello Everybody,

We have submitted a revised draft =E2=80=9Chttps://datatracker.ietf.org/doc= /draft-sinha-dispatch-sip-continuation-option/?include_text=3D1=E2=80=9D.
Let me thank you all for your attention. I'm looking forward to receiving y= our feedback


Thanks & Regards
Amardeep Sinha



On Tue, 30 Aug 2011 04:09:19 +0530 wrote
>Dear All
>
Please find my answers inline wrt Paul Question. I am keeping everyone in l= oop for discussion so that most of the common queries I think has been addr= essed. In case there is any other question / clarification needed, please l= et us know. We will incorporate your valuable feedbacks based on the agreed= items in our next document version.
>
Once again many thanks for your valuable feedbacks, much appreciate your va= luable inputs and time.
>
Regards
>
Sunil kumar sinha
>

>

>
Sunil,
>
>I'm having trouble understanding the assumptions and intended use of this = mechanism. I also think there are probably other ways of
>accomplishing something similar.
>
[Sunil] Intended use: Applications as mentioned in Section 4, this is used = as Called Party Voice feature service when Callee is not in a favorable sta= te to receive calls, Callee is NOT in DND and can accept calls, Callee can = set a parameter called NDDND (Non Dedicated Do Not Disturb) in Handsets / I= P Devices or with NSP which initiates the mentioned 182 response on receivi= ng INVITE instead of 180 Ringing from Handset or VFS as the case may be bas= ed on the configuration, finally its upto the sole discretion of Caller to = make progress with placing the call or disconnect. Detailed Call Flow given= in the proposal. We have studied all the methodologies and SIP parameters = and found it difficult to incorporate this feature, so proposed this new SI= P Header =E2=80=9CContinue=E2=80=9D with the designed call flows and behavi= or at UEs and Proxies.
>
>Some comments and questions on the draft:
>
>Figure 2:
>
>You don't show the F1 message. Does it contain 'Supported:continue'? If no= t, then putting Require:continue in the response is very questionable, sinc= e it can't be refused in a response.
>
[Sunil] INVITE contains =E2=80=9CSupported: continue=E2=80=9D, we will make= the needful addition of INVITE (F1) in call flow as suggested by you in th= e next version. Thanks for your valuable suggestion.
>
>Is it intended that the 182 + Require: continue is to be interpreted by th= e UAC as indicating that the call hasn't yet alerted, and won't unless Cont= inue:yes is sent?
>
[Sunil] Correct
>
>(That is an improper use of Require. It is supposed to mean "I require tha= t you *support* this option", not that I require you to use it.)
>
[Sunil] Latter meaning holds good for the usage of =E2=80=9CRequire: contin= ue=E2=80=9D header, we have also portrayed in the same way. If there=E2=80= =99s anything else you would like to know or want us to incorporate anythin= g else,pls let us know
>

>Also, what is the intended behavior when the UAC does not support this mec= hanism? If it receives a 182 response, it will probably treat it just like = a 180 and wait, assuming the call is alerting and will eventually be answer= ed. Or does the UAS note there is no Supported:continue and return 486 rath= er than 182?
>
[Sunil] Agreed, accept your point fully, this is the case when caller doesn= =E2=80=99t support this mechanism but callee does, so NDDND will not work f= or callee as the concept behind the usage of NDDND as a called party voice = feature is to give option to the supported caller to display an option whet= her to finally place a call or not, the call will be placed based on the so= le discretion of Caller. If Caller doesn=E2=80=99t support this functionali= ty whether a DND will be flagged or Normal Call Treatment to be done I feel= need to be again a configuration dependent on the Device/NSP or Device man= ufacturer / Service Provider implementation specific. I will incorporate th= e outcome behavior of this scenario in the next version after discussing wi= th co-authors. Many thanks for your valuable feedbacks. In this case 182 wo= n=E2=80=99t be responded by Callee, either 180 or 486 would be responded >
>Section 4:
>
>IIUC this lists a number of cases where this feature might be used, yet to= the UAC these are all indicated in the same way. So the user of the UAC ha= s no idea why he is being asked to confirm or deny the importance of his ca= ll.
>
[Sunil] This is described above. Pls let me know if you have any questions.=
>

>
>General comments:
>
>This seems to be yet another spin on presence. Have you investigated how y= ou might explicitly use presence for this? For instance, the UAS that wants= this behavior could refuse (perhaps with 486) any call that doesn't have a= Priority header with a sufficiently high value. In the response it could i= nclude a PIDF in the body (or content indirection to one). Then the UAC cou= ld interpret that, interact with its user, and perhaps generate another INV= ITE with a Priority header.
>
[Sunil] I agree to most of your points on the usage of Priority header, exc= ept one scenario which cannot be implemented. If Called Party supports the = feature and Caller doesn=E2=80=99t support Priority, then this feature will= be just DND. Our purpose is not to have DND by any means. In our case deci= sion to treat this feature or not at the Callee although it is set at Calle= e based on Supported: continue present in initial INVITE from Caller. If Ca= ller is not up-to-date with this feature, then he doesn=E2=80=99t send Supp= orted: continue in initial INVITE and this call is treated as Normal Call w= ith 180 Ringing sent by Called Party suppressing the feature set at Called = Party. My apologies we haven=E2=80=99t put all the combination of scenarios= in the first version of draft, we will send all position combination in ou= r next version. Once again many thanks for your valuable feedbacks.
>
>Or, UACs that support this mechanism could simply subscribe to presence of= the callee before sending the invite, and make a decision how to make the = call based on what is received.
>

>[Sunil] Not all Handsets supports this.
>

>Or, if you really feel its essential to do this with one invite, an existi= ng mechanism to defer alerting is through use of preconditions.
>You could conceivably create a new precondition type to get the desired ef= fect. (But this direction isn't appealing to me.)
>
>Most, I suggest you spend more time refining the requirements before getti= ng involved in the mechanism.
>
>Thanks,
>Paul



Treat yourself at a restaurant, spa, resort and much more with Rediff Deal = ho jaye!

Amar


Treat yourself at a restaurant, sp= a, resort and much more with Rediff De= al ho jaye! --=_92ab96c882548452cbc05b15185b4847-- From md3135@att.com Wed Sep 14 14:10:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA3721F8D3D for ; Wed, 14 Sep 2011 14:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZvvBSfJYk4U for ; Wed, 14 Sep 2011 14:10:21 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1321F8D31 for ; Wed, 14 Sep 2011 14:10:20 -0700 (PDT) X-Env-Sender: md3135@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1316034749!25710936!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29226 invoked from network); 14 Sep 2011 21:12:30 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 21:12:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8ELCuCU004046; Wed, 14 Sep 2011 17:12:56 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8ELCnYd003979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Sep 2011 17:12:49 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.142]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0289.001; Wed, 14 Sep 2011 17:12:23 -0400 From: "DOLLY, MARTIN C" To: "Worley, Dale R (Dale)" , Andrew Allen , Cullen Jennings Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADLXcIA== Date: Wed, 14 Sep 2011 21:12:22 +0000 Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.174.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 21:10:23 -0000 AT&T supports this draft moving forward :)=20 -----Original Message----- From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 Sent: Tuesday, September 06, 2011 3:16 PM To: Andrew Allen; Cullen Jennings Cc: DISPATCH list Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa= tch-imei-urn-as-instanceid I hope I'm not the only person who feels that this "debate" is a tempest in a teapot. I can't see any serious reason not to define a URN namespace for IMEIs. These names have various deficiencies from various points of view, but none that are substantially worse than the currently popular system of constructing URNs from UUIDs which are constructed from MAC addresses (which are printed on a label on the back of the phone). There can only be interoperability problems if a proxy is unable to accept instance-ids that are in namespaces that it does not understand. But such a proxy is clearly deficient, and indeed, one would have to go out of one's way to build a proxy that had this deficiency, since the simplest and most natural implementation is to treat the instance-id as an opaque string. There may be IPR attached to this, but as the only vendors who would care about using it are manufacturers who have licensed the entire 3GPP IPR bundle, that causes nobody any problems that they do not already have. I regard to privacy, any user of a 3GPP phone has submitted to having their privacy protected and violated to exactly the degree designed into 3G= PP, and the transmission of an IMEI-based instance-id between the 3GPP phone through a 3GPP network to a 3GPP registrar is not going to decrease (or increase) their privacy. Can we just approve this and stop spending time on it? Dale From tanakai@nttdocomo.co.jp Wed Sep 14 16:48:25 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EE121F8C4F for ; Wed, 14 Sep 2011 16:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze5frCAr1Jd3 for ; Wed, 14 Sep 2011 16:48:25 -0700 (PDT) Received: from zcsg-mailro12.is.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4C621F8C4E for ; Wed, 14 Sep 2011 16:48:24 -0700 (PDT) Received: from zcsg-mailmt12.is.nttdocomo.co.jp (zcsg-mailmt10.is.nttdocomo.co.jp [10.160.86.41]) by zcsg-mailro12.is.nttdocomo.co.jp (Postfix) with ESMTP id 20C383400E for ; Thu, 15 Sep 2011 08:50:34 +0900 (JST) Received: from zcsg-mailmi13.is.nttdocomo.co.jp (zcsg-mailmi10.is.nttdocomo.co.jp [10.160.86.49]) by zcsg-mailmt12.is.nttdocomo.co.jp (NTT DoCoMo Mail System) with SMTP id <0LRJ00CH4E8A3O60@NTTDoCoMo.co.jp> for dispatch@ietf.org; Thu, 15 Sep 2011 08:50:34 +0900 (JST) Received: from unknown (HELO zcsg-mailvs12.is.nttdocomo.co.jp) (10.160.86.48) by 0 with SMTP; Thu, 15 Sep 2011 08:50:34 +0900 Received: from zcsg-mailvs12.is.nttdocomo.co.jp (localhost [127.0.0.1]) by localhost.is.nttdocomo.co.jp (Postfix) with ESMTP id DA36B8003; Thu, 15 Sep 2011 08:50:33 +0900 (JST) Received: from zcsg-mailsa12.is.nttdocomo.co.jp (zcsg-mailsa10.is.nttdocomo.co.jp [10.160.86.46]) by zcsg-mailvs12.is.nttdocomo.co.jp (Postfix) with ESMTP id CE92F8002; Thu, 15 Sep 2011 08:50:33 +0900 (JST) Received: from AKTANAKAI223 ([10.18.210.35]) by zcsg-mailsa12.is.nttdocomo.co.jp (NTT DoCoMo Mail System) with ESMTPA id <0LRJ00BSME85SIA0@NTTDoCoMo.co.jp>; Thu, 15 Sep 2011 08:50:33 +0900 (JST) Date: Thu, 15 Sep 2011 08:50:43 +0900 From: Itsuma TANAKA In-reply-to: To: "'DOLLY, MARTIN C'" , "'Worley, Dale R (Dale)'" , 'Andrew Allen' , 'Cullen Jennings' Message-id: <92EF9F2691D0496AAA0B17734206D213@docomo.docomogr.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADLXcIIAAK/zw X-DoCoMo: ZCSG References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> Cc: 'DISPATCH list' Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 23:48:25 -0000 Dear All, Just to echo what other supporters of this draft say - NTT DOCOMO also supports this draft moving forward. Thank you, Itsuma Tanaka NTT DOCOMO -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Thursday, September 15, 2011 6:12 AM To: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid AT&T supports this draft moving forward :) -----Original Message----- From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] Sent: Tuesday, September 06, 2011 3:16 PM To: Andrew Allen; Cullen Jennings Cc: DISPATCH list Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid I hope I'm not the only person who feels that this "debate" is a tempest in a teapot. I can't see any serious reason not to define a URN namespace for IMEIs. These names have various deficiencies from various points of view, but none that are substantially worse than the currently popular system of constructing URNs from UUIDs which are constructed from MAC addresses (which are printed on a label on the back of the phone). There can only be interoperability problems if a proxy is unable to accept instance-ids that are in namespaces that it does not understand. But such a proxy is clearly deficient, and indeed, one would have to go out of one's way to build a proxy that had this deficiency, since the simplest and most natural implementation is to treat the instance-id as an opaque string. There may be IPR attached to this, but as the only vendors who would care about using it are manufacturers who have licensed the entire 3GPP IPR bundle, that causes nobody any problems that they do not already have. I regard to privacy, any user of a 3GPP phone has submitted to having their privacy protected and violated to exactly the degree designed into 3GPP, and the transmission of an IMEI-based instance-id between the 3GPP phone through a 3GPP network to a 3GPP registrar is not going to decrease (or increase) their privacy. Can we just approve this and stop spending time on it? Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From shida@ntt-at.com Wed Sep 14 16:58:41 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE74F21F8ABE for ; Wed, 14 Sep 2011 16:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fI1M9tYkF6f for ; Wed, 14 Sep 2011 16:58:37 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D978721F8AB9 for ; Wed, 14 Sep 2011 16:58:37 -0700 (PDT) Received: from [122.135.86.64] (port=55805 helo=[192.168.1.139]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R3zNk-0007ht-Py; Wed, 14 Sep 2011 19:00:45 -0500 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <92EF9F2691D0496AAA0B17734206D213@docomo.docomogr.net> Date: Thu, 15 Sep 2011 09:00:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9E09F6DD-BCF3-429F-ACDB-2F59713858F8@ntt-at.com> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> <92EF9F2691D0496AAA0B17734206D213@docomo.docomogr.net> To: DISPATCH list X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-122-135-86-64.tky.mesh.ad.jp ([192.168.1.139]) [122.135.86.64]:55805 X-Source-Auth: shida@agnada.com X-Email-Count: 6 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 23:58:41 -0000 We support the draft as well.=20 Regards Shida On Sep 15, 2011, at 8:50 AM, Itsuma TANAKA wrote: > Dear All, =20 >=20 > Just to echo what other supporters of this draft say - NTT DOCOMO also > supports this draft moving forward. >=20 > Thank you, > Itsuma Tanaka > NTT DOCOMO >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf > Of DOLLY, MARTIN C > Sent: Thursday, September 15, 2011 6:12 AM > To: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn > anddraft-allen-dispatch-imei-urn-as-instanceid >=20 > AT&T supports this draft moving forward :)=20 >=20 > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Sent: Tuesday, September 06, 2011 3:16 PM > To: Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn > anddraft-allen-dispatch-imei-urn-as-instanceid >=20 > I hope I'm not the only person who feels that this "debate" is a = tempest > in a teapot. >=20 > I can't see any serious reason not to define a URN namespace for > IMEIs. These names have various deficiencies from various points > of view, but none that are substantially worse than the currently = popular > system of constructing URNs from UUIDs which are constructed from > MAC addresses (which are printed on a label on the back of the phone). >=20 > There can only be interoperability problems if a proxy is unable to = accept > instance-ids that are in namespaces that it does not understand. But > such a proxy is clearly deficient, and indeed, one would have to go = out > of one's way to build a proxy that had this deficiency, since the = simplest > and most natural implementation is to treat the instance-id as an = opaque > string. >=20 > There may be IPR attached to this, but as the only vendors who would > care about using it are manufacturers who have licensed the entire = 3GPP > IPR bundle, that causes nobody any problems that they do not already = have. >=20 > I regard to privacy, any user of a 3GPP phone has submitted to having > their privacy protected and violated to exactly the degree designed = into > 3GPP, > and the transmission of an IMEI-based instance-id between the 3GPP = phone > through a 3GPP network to a 3GPP registrar is not going to decrease = (or > increase) their privacy. >=20 > Can we just approve this and stop spending time on it? >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From lili.yang@huawei.com Wed Sep 14 18:08:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86F321F8B03 for ; Wed, 14 Sep 2011 18:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJyhWIQJxd8G for ; Wed, 14 Sep 2011 18:08:47 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4221F8AFE for ; Wed, 14 Sep 2011 18:08:47 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ001XIHY9N1@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 15 Sep 2011 09:10:57 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00FRCHY9WF@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 15 Sep 2011 09:10:57 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADZ05053; Thu, 15 Sep 2011 09:10:56 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 09:10:47 +0800 Received: from SZXEML521-MBX.china.huawei.com ([169.254.1.146]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 15 Sep 2011 09:10:53 +0800 Date: Thu, 15 Sep 2011 01:10:52 +0000 From: Lili Yang_lili In-reply-to: <9E09F6DD-BCF3-429F-ACDB-2F59713858F8@ntt-at.com> X-Originating-IP: [10.85.29.168] To: Shida Schubert , DISPATCH list Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-index: AQHMczq6fD69vMxt4UiI7ryuewebVJVNoi3w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> <92EF9F2691D0496AAA0B17734206D213@docomo.docomogr.net> <9E09F6DD-BCF3-429F-ACDB-2F59713858F8@ntt-at.com> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 01:08:51 -0000 SGVsbG8sDQoNCisxIHN1cHBvcnQuIA0KDQpCZXN0IHJlZ2FyZHMsDQpMaWxpIA0Ku6rOqry8yvXT 0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KDQoNClBob25lOiArODYtNzU1 LTI4NDIyNTUzDQpGYXg6ICs4Ni03NTUtMjg0MjA0MTMNCk1vYmlsZTorODYtMTM2MzI2MzIwNjUN CkVtYWlsOiBMaWxpLnlhbmdAaHVhd2VpLmNvbQ0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7 +bXYINPKseCjujUxODEyOQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4s IExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3 Lmh1YXdlaS5jb20gDQoNCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP 3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjOus7G5Mv7yMvS1MjO us7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mx vtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o 1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBj b250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggDQppcyBp bnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxp c3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0 aWFsIA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJz b25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkgDQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGlkYSBT Y2h1YmVydA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxNSwgMjAxMSA4OjAxIEFNDQpUbzog RElTUEFUQ0ggbGlzdA0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gZHJhZnQtbW9udGVtdXJyby1n c21hLWltZWktdXJuIGFuZGRyYWZ0LWFsbGVuLWRpc3BhdGNoLWltZWktdXJuLWFzLWluc3RhbmNl aWQNCg0KDQpXZSBzdXBwb3J0IHRoZSBkcmFmdCBhcyB3ZWxsLiANCg0KIFJlZ2FyZHMNCiAgU2hp ZGENCg0KT24gU2VwIDE1LCAyMDExLCBhdCA4OjUwIEFNLCBJdHN1bWEgVEFOQUtBIHdyb3RlOg0K DQo+IERlYXIgQWxsLCAgDQo+IA0KPiBKdXN0IHRvIGVjaG8gd2hhdCBvdGhlciBzdXBwb3J0ZXJz IG9mIHRoaXMgZHJhZnQgc2F5IC0gTlRUIERPQ09NTyBhbHNvDQo+IHN1cHBvcnRzIHRoaXMgZHJh ZnQgbW92aW5nIGZvcndhcmQuDQo+IA0KPiBUaGFuayB5b3UsDQo+IEl0c3VtYSBUYW5ha2ENCj4g TlRUIERPQ09NTw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGlz cGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZiBET0xMWSwgTUFSVElOIEMNCj4gU2VudDogVGh1cnNkYXksIFNlcHRl bWJlciAxNSwgMjAxMSA2OjEyIEFNDQo+IFRvOiBXb3JsZXksIERhbGUgUiAoRGFsZSk7IEFuZHJl dyBBbGxlbjsgQ3VsbGVuIEplbm5pbmdzDQo+IENjOiBESVNQQVRDSCBsaXN0DQo+IFN1YmplY3Q6 IFJlOiBbZGlzcGF0Y2hdIGRyYWZ0LW1vbnRlbXVycm8tZ3NtYS1pbWVpLXVybg0KPiBhbmRkcmFm dC1hbGxlbi1kaXNwYXRjaC1pbWVpLXVybi1hcy1pbnN0YW5jZWlkDQo+IA0KPiBBVCZUIHN1cHBv cnRzIHRoaXMgZHJhZnQgbW92aW5nIGZvcndhcmQgOikgDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb3JsZXksIERhbGUgUiAoRGFsZSkgW21haWx0bzpkd29ybGV5 QGF2YXlhLmNvbV0gDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNiwgMjAxMSAzOjE2IFBN DQo+IFRvOiBBbmRyZXcgQWxsZW47IEN1bGxlbiBKZW5uaW5ncw0KPiBDYzogRElTUEFUQ0ggbGlz dA0KPiBTdWJqZWN0OiBSRTogW2Rpc3BhdGNoXSBkcmFmdC1tb250ZW11cnJvLWdzbWEtaW1laS11 cm4NCj4gYW5kZHJhZnQtYWxsZW4tZGlzcGF0Y2gtaW1laS11cm4tYXMtaW5zdGFuY2VpZA0KPiAN Cj4gSSBob3BlIEknbSBub3QgdGhlIG9ubHkgcGVyc29uIHdobyBmZWVscyB0aGF0IHRoaXMgImRl YmF0ZSIgaXMgYSB0ZW1wZXN0DQo+IGluIGEgdGVhcG90Lg0KPiANCj4gSSBjYW4ndCBzZWUgYW55 IHNlcmlvdXMgcmVhc29uIG5vdCB0byBkZWZpbmUgYSBVUk4gbmFtZXNwYWNlIGZvcg0KPiBJTUVJ cy4gIFRoZXNlIG5hbWVzIGhhdmUgdmFyaW91cyBkZWZpY2llbmNpZXMgZnJvbSB2YXJpb3VzIHBv aW50cw0KPiBvZiB2aWV3LCBidXQgbm9uZSB0aGF0IGFyZSBzdWJzdGFudGlhbGx5IHdvcnNlIHRo YW4gdGhlIGN1cnJlbnRseSBwb3B1bGFyDQo+IHN5c3RlbSBvZiBjb25zdHJ1Y3RpbmcgVVJOcyBm cm9tIFVVSURzIHdoaWNoIGFyZSBjb25zdHJ1Y3RlZCBmcm9tDQo+IE1BQyBhZGRyZXNzZXMgKHdo aWNoIGFyZSBwcmludGVkIG9uIGEgbGFiZWwgb24gdGhlIGJhY2sgb2YgdGhlIHBob25lKS4NCj4g DQo+IFRoZXJlIGNhbiBvbmx5IGJlIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgaWYgYSBwcm94 eSBpcyB1bmFibGUgdG8gYWNjZXB0DQo+IGluc3RhbmNlLWlkcyB0aGF0IGFyZSBpbiBuYW1lc3Bh Y2VzIHRoYXQgaXQgZG9lcyBub3QgdW5kZXJzdGFuZC4gIEJ1dA0KPiBzdWNoIGEgcHJveHkgaXMg Y2xlYXJseSBkZWZpY2llbnQsIGFuZCBpbmRlZWQsIG9uZSB3b3VsZCBoYXZlIHRvIGdvIG91dA0K PiBvZiBvbmUncyB3YXkgdG8gYnVpbGQgYSBwcm94eSB0aGF0IGhhZCB0aGlzIGRlZmljaWVuY3ks IHNpbmNlIHRoZSBzaW1wbGVzdA0KPiBhbmQgbW9zdCBuYXR1cmFsIGltcGxlbWVudGF0aW9uIGlz IHRvIHRyZWF0IHRoZSBpbnN0YW5jZS1pZCBhcyBhbiBvcGFxdWUNCj4gc3RyaW5nLg0KPiANCj4g VGhlcmUgbWF5IGJlIElQUiBhdHRhY2hlZCB0byB0aGlzLCBidXQgYXMgdGhlIG9ubHkgdmVuZG9y cyB3aG8gd291bGQNCj4gY2FyZSBhYm91dCB1c2luZyBpdCBhcmUgbWFudWZhY3R1cmVycyB3aG8g aGF2ZSBsaWNlbnNlZCB0aGUgZW50aXJlIDNHUFANCj4gSVBSIGJ1bmRsZSwgdGhhdCBjYXVzZXMg bm9ib2R5IGFueSBwcm9ibGVtcyB0aGF0IHRoZXkgZG8gbm90IGFscmVhZHkgaGF2ZS4NCj4gDQo+ IEkgcmVnYXJkIHRvIHByaXZhY3ksIGFueSB1c2VyIG9mIGEgM0dQUCBwaG9uZSBoYXMgc3VibWl0 dGVkIHRvIGhhdmluZw0KPiB0aGVpciBwcml2YWN5IHByb3RlY3RlZCBhbmQgdmlvbGF0ZWQgdG8g ZXhhY3RseSB0aGUgZGVncmVlIGRlc2lnbmVkIGludG8NCj4gM0dQUCwNCj4gYW5kIHRoZSB0cmFu c21pc3Npb24gb2YgYW4gSU1FSS1iYXNlZCBpbnN0YW5jZS1pZCBiZXR3ZWVuIHRoZSAzR1BQIHBo b25lDQo+IHRocm91Z2ggYSAzR1BQIG5ldHdvcmsgdG8gYSAzR1BQIHJlZ2lzdHJhciBpcyBub3Qg Z29pbmcgdG8gZGVjcmVhc2UgKG9yDQo+IGluY3JlYXNlKSB0aGVpciBwcml2YWN5Lg0KPiANCj4g Q2FuIHdlIGp1c3QgYXBwcm92ZSB0aGlzIGFuZCBzdG9wIHNwZW5kaW5nIHRpbWUgb24gaXQ/DQo+ IA0KPiBEYWxlDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0Y2gg bWFpbGluZyBsaXN0DQo+IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg== From ricky.kaura@samsung.com Wed Sep 14 19:26:20 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BCA21F8A70 for ; Wed, 14 Sep 2011 19:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtC5s70OzJeP for ; Wed, 14 Sep 2011 19:26:19 -0700 (PDT) Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by ietfa.amsl.com (Postfix) with ESMTP id 14F7C21F8A6C for ; Wed, 14 Sep 2011 19:26:18 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Q8K54vqWTS2t32yQcO814w)" Received: from euspt1 ([210.118.77.13]) by mailout3.w1.samsung.com (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTP id <0LRJ00ESVLJDK380@mailout3.w1.samsung.com> for dispatch@ietf.org; Thu, 15 Sep 2011 03:28:26 +0100 (BST) Received: from dc2.seri.co.uk ([106.1.8.33]) by spt1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0LRJ00D96LJDPU@spt1.w1.samsung.com> for dispatch@ietf.org; Thu, 15 Sep 2011 03:28:25 +0100 (BST) Date: Thu, 15 Sep 2011 03:28:18 +0100 From: Ricky Kaura In-reply-to: To: "Worley, Dale R (Dale)" , Andrew Allen , Cullen Jennings Message-id: <454CFC84C5CDDD46AC9CF438F0CFDC7D0328F3D7@dc2.seri.co.uk> X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADQvHQA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 02:26:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Q8K54vqWTS2t32yQcO814w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hello, I would like to repeat my support for the progressing of this work in = IETF. Please see my attached email I sent earlier on in the year in which I = expressed the reasons for why this work is important for 3GPP and GSMA. Regards, =A0 Ricky Kaura. Principal Standards Engineer Standands and Industry Affairs (SIA) Samsung Electronics Research Institute Tel:=A0=A0 +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: = +44 (0) 1784 428 610 Email: ricky.kaura@samsung.com; Skype: rickykaura; Yahoo: rkaura1969 Samsung Electronics (UK) Limited Registered number: 03086621 Registered address: Communications house, South Street, Staines, = Middlesex TW18 4QE. -----Original Message----- From: Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 Sent: 06 September 2011 20:16 To: Andrew Allen; Cullen Jennings Cc: DISPATCH list Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn = anddraft-allen-dispatch-imei-urn-as-instanceid I hope I'm not the only person who feels that this "debate" is a tempest in a teapot. I can't see any serious reason not to define a URN namespace for IMEIs. These names have various deficiencies from various points of view, but none that are substantially worse than the currently = popular system of constructing URNs from UUIDs which are constructed from MAC addresses (which are printed on a label on the back of the phone). There can only be interoperability problems if a proxy is unable to = accept instance-ids that are in namespaces that it does not understand. But such a proxy is clearly deficient, and indeed, one would have to go out of one's way to build a proxy that had this deficiency, since the = simplest and most natural implementation is to treat the instance-id as an opaque string. There may be IPR attached to this, but as the only vendors who would care about using it are manufacturers who have licensed the entire 3GPP IPR bundle, that causes nobody any problems that they do not already = have. I regard to privacy, any user of a 3GPP phone has submitted to having their privacy protected and violated to exactly the degree designed into = 3GPP, and the transmission of an IMEI-based instance-id between the 3GPP phone through a 3GPP network to a 3GPP registrar is not going to decrease (or increase) their privacy. Can we just approve this and stop spending time on it? Dale --Boundary_(ID_Q8K54vqWTS2t32yQcO814w) Content-type: message/rfc822 Date: Wed, 02 Feb 2011 20:40:18 +0100 From: Ricky Kaura Subject: Re: [dispatch] Revision ofdraft-allen-dispatch-imei-urn-as-instanceid To: dispatch@ietf.org Message-id: <8972E662C0942A4E89214083CDA4F5E601F3BF23@dc2.seri.co.uk> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message Thread-topic: Re: [dispatch] Revision ofdraft-allen-dispatch-imei-urn-as-instanceid Thread-index: AcvDEQVMaNmKnHSTS5SkPTmpKwo+6w== X-MS-Has-Attach: X-MS-TNEF-Correlator: Dear all, I work for Samsung and attend 3GPP CT1/CT meetings and GSM Association (GSMA) Interworking, Roaming Expert Group (IREG), Roaming in LTE (RiLTE) subgroup meetings. I would like to express my support of draft-montemurro-gsma-imei-urn and the associated draft-allen-dispatch-imei-urn-as-instanceid for the following reasons: * 3GPP has specified IMS emergency calls over LTE and GPRS in 3GPP Release 9. When originating an emergency call over these access technologies, it is required to include the IMEI-URN as the instance ID in the "+sip.instance" header field parameter in the Contact header of the SIP INVITE (see 3GPP TS 23.237 and 3GPP TS 24.237). This is required in order to support access transfer of emergency calls from the PS domain to the CS domain. The IMEI is used at the Emergency Access Transfer Function (EATF) to correlate the original IMS emergency session with the session transfer request that was initiated from the MSC (Mobile services Switching Centre) upon handover to the CS domain. Specifically, in the case of limited service mode, where an IMS registration does not necessarily occur, the IMEI is the only available identifier that can be used to allow the EATF to correlate the source and target access legs. * Recently in 3GPP TS 24.229, a CR was approved which states that if a UE has an IMEI available, it shall always include the IMEI in the "+sip.instance" header field parameter in the Contact header of the SIP Register. The requirement for the inclusion of the IMEI came from GSMA and is included in PRD IR.92. IR.92 is a user-to-network (UNI) profile of the key 3GPP IMS specifications for voice and SMS over LTE and has been developed in GSMA IREG RiLTE by a number of operators, network vendors and device manufacturers. The requirement to include the IMEI (if available) in the SIP Register is to support operator requirements for the IMS network to perform an IMEI check when the UE is IMS registered, as stated in the Stage 1 requirements in 3GPP TS 22.016 (section 5). * 3GPP developed a feature in Release 8 called "IMS Centralised Services" (ICS) (see TS 23.292 and TS 24.292) which allows a user to have a consistent set of features independent of whether the UE is on PS access or CS access. 3GPP have defined the MSC server enhanced for ICS to control voice sessions set up using circuit bearers. To enabled this feature, the MSC server performs a SIP registration on behalf of the UE when the UE is in the circuit domain. However, a registration for the user may also exist in the PS domain. The IMEI included as the Instance Id is used as a way of allowing the IMS network to identify that the SIP registrations below to the same UE and to allow correct handling of session establishment requests using GRUU. * The ICS feature in 3GPP also allows the use of specialised functionality on the UE (i.e. an ICS client). Such a UE is called an ICS UE. When the ICS UE performs a SIP registration, it identifies itself by using the IMEI and includes this as the Instance Id in the SIP REGISTER. When used in conjunction with an MSC server enhanced for ICS, the application server in IMS can use the GRUU to correlate the SIP signalling that comes directly from the UE with the SIP signalling that comes via the MSC server when the ICE UE initiates an ICS session. In summary, these drafts are very important for the support of key features in 3GPP. I request that this work is progressed as quickly as possible in IETF. Regards, Ricky Kaura. Principal Standards Engineer Standands and Industry Affairs (SIA) Samsung Electronics Research Institute Tel: +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: +44 (0) 1784 428 610 Email: ricky.kaura@samsung.com; Skype: rickykaura; Yahoo: rkaura1969 Samsung Electronics (UK) Limited Registered number: 03086621 Registered address: Communications house, South Street, Staines, Middlesex TW18 4QE. --Boundary_(ID_Q8K54vqWTS2t32yQcO814w)-- From R.Jesske@telekom.de Wed Sep 14 21:26:55 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFA721F85CE for ; Wed, 14 Sep 2011 21:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn4qt87aTVLe for ; Wed, 14 Sep 2011 21:26:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 369A821F84D9 for ; Wed, 14 Sep 2011 21:26:53 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 15 Sep 2011 06:29:01 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.121]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 15 Sep 2011 06:29:01 +0200 From: To: , , , Date: Thu, 15 Sep 2011 06:29:00 +0200 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADLXcIIAAehlA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D093C9DD491@HE111648.emea1.cds.t-internal.com> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 04:26:55 -0000 +1 Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58 12766 (Tel.) +49 391 580 133 831 (Fax) +49 171 8618-445 (Mobil) E-Mail: mailto:r.jesske@telekom.de http://www.telekom.de Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: N.N. (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken. > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C > Gesendet: Mittwoch, 14. September 2011 23:12 > An: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Betreff: Re: [dispatch] draft-montemurro-gsma-imei-urn > anddraft-allen-dispatch-imei-urn-as-instanceid > > AT&T supports this draft moving forward :) > > -----Original Message----- > From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] > Sent: Tuesday, September 06, 2011 3:16 PM > To: Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Subject: RE: [dispatch] draft-montemurro-gsma-imei-urn > anddraft-allen-dispatch-imei-urn-as-instanceid > > I hope I'm not the only person who feels that this "debate" > is a tempest > in a teapot. > > I can't see any serious reason not to define a URN namespace for > IMEIs. These names have various deficiencies from various points > of view, but none that are substantially worse than the > currently popular > system of constructing URNs from UUIDs which are constructed from > MAC addresses (which are printed on a label on the back of the phone). > > There can only be interoperability problems if a proxy is > unable to accept > instance-ids that are in namespaces that it does not understand. But > such a proxy is clearly deficient, and indeed, one would have > to go out > of one's way to build a proxy that had this deficiency, since > the simplest > and most natural implementation is to treat the instance-id > as an opaque > string. > > There may be IPR attached to this, but as the only vendors who would > care about using it are manufacturers who have licensed the > entire 3GPP > IPR bundle, that causes nobody any problems that they do not > already have. > > I regard to privacy, any user of a 3GPP phone has submitted to having > their privacy protected and violated to exactly the degree > designed into 3GPP, > and the transmission of an IMEI-based instance-id between the > 3GPP phone > through a 3GPP network to a 3GPP registrar is not going to > decrease (or > increase) their privacy. > > Can we just approve this and stop spending time on it? > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From christer.holmberg@ericsson.com Wed Sep 14 22:32:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE63E21F8713 for ; Wed, 14 Sep 2011 22:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cI-PzsGNKVC for ; Wed, 14 Sep 2011 22:32:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 16DF321F86FF for ; Wed, 14 Sep 2011 22:32:50 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-83-4e718e847cf8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.9A.20773.48E817E4; Thu, 15 Sep 2011 07:35:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 15 Sep 2011 07:35:00 +0200 From: Christer Holmberg To: "Worley, Dale R (Dale)" , Andrew Allen , Cullen Jennings Date: Thu, 15 Sep 2011 07:34:59 +0200 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADUJjIA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, 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-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 05:32:52 -0000 +1 Regards, Christer=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) > Sent: 6. syyskuuta 2011 22:16 > To: Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn=20 > anddraft-allen-dispatch-imei-urn-as-instanceid >=20 > I hope I'm not the only person who feels that this "debate"=20 > is a tempest in a teapot. >=20 > I can't see any serious reason not to define a URN namespace=20 > for IMEIs. These names have various deficiencies from=20 > various points of view, but none that are substantially worse=20 > than the currently popular system of constructing URNs from=20 > UUIDs which are constructed from MAC addresses (which are=20 > printed on a label on the back of the phone). >=20 > There can only be interoperability problems if a proxy is=20 > unable to accept instance-ids that are in namespaces that it=20 > does not understand. But such a proxy is clearly deficient,=20 > and indeed, one would have to go out of one's way to build a=20 > proxy that had this deficiency, since the simplest and most=20 > natural implementation is to treat the instance-id as an=20 > opaque string. >=20 > There may be IPR attached to this, but as the only vendors=20 > who would care about using it are manufacturers who have=20 > licensed the entire 3GPP IPR bundle, that causes nobody any=20 > problems that they do not already have. >=20 > I regard to privacy, any user of a 3GPP phone has submitted=20 > to having their privacy protected and violated to exactly the=20 > degree designed into 3GPP, and the transmission of an=20 > IMEI-based instance-id between the 3GPP phone through a 3GPP=20 > network to a 3GPP registrar is not going to decrease (or > increase) their privacy. >=20 > Can we just approve this and stop spending time on it? >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From laura.liess.dt@googlemail.com Wed Sep 14 22:45:35 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43621F85A4 for ; Wed, 14 Sep 2011 22:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1twizxWSUni for ; Wed, 14 Sep 2011 22:45:34 -0700 (PDT) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0065221F856B for ; Wed, 14 Sep 2011 22:45:33 -0700 (PDT) Received: by vws14 with SMTP id 14so3673172vws.37 for ; Wed, 14 Sep 2011 22:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4G4LABw5jC8TrDs3uS9WU5GACy6BHNt5tdM/BGB/gp8=; b=Uxp/nH4rPiQSwcD/8SIjVP5YSUV6qcDtle/Vo+PdyKiSUyq9apte7QEWAjdlQ8Gg2c 4egl8woiGwc98j4IAQizT2dAgL09I4NHWa2t3G6HUZrtEvAd/ZD+KMIqqc/LZWVEQPDf AYDi29DX4Y9QWmGcghXn5RwnqCRq6KUiMFAOo= MIME-Version: 1.0 Received: by 10.52.71.49 with SMTP id r17mr621802vdu.188.1316065664346; Wed, 14 Sep 2011 22:47:44 -0700 (PDT) Received: by 10.52.182.137 with HTTP; Wed, 14 Sep 2011 22:47:44 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 15 Sep 2011 07:47:44 +0200 Message-ID: From: Laura Liess To: DISPATCH list , Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 05:45:35 -0000 +1 Thanks, Laura 2011/9/15 Christer Holmberg : > > +1 > > Regards, > > Christer > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) >> Sent: 6. syyskuuta 2011 22:16 >> To: Andrew Allen; Cullen Jennings >> Cc: DISPATCH list >> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn >> anddraft-allen-dispatch-imei-urn-as-instanceid >> >> I hope I'm not the only person who feels that this "debate" >> is a tempest in a teapot. >> >> I can't see any serious reason not to define a URN namespace >> for IMEIs. =A0These names have various deficiencies from >> various points of view, but none that are substantially worse >> than the currently popular system of constructing URNs from >> UUIDs which are constructed from MAC addresses (which are >> printed on a label on the back of the phone). >> >> There can only be interoperability problems if a proxy is >> unable to accept instance-ids that are in namespaces that it >> does not understand. =A0But such a proxy is clearly deficient, >> and indeed, one would have to go out of one's way to build a >> proxy that had this deficiency, since the simplest and most >> natural implementation is to treat the instance-id as an >> opaque string. >> >> There may be IPR attached to this, but as the only vendors >> who would care about using it are manufacturers who have >> licensed the entire 3GPP IPR bundle, that causes nobody any >> problems that they do not already have. >> >> I regard to privacy, any user of a 3GPP phone has submitted >> to having their privacy protected and violated to exactly the >> degree designed into 3GPP, and the transmission of an >> IMEI-based instance-id between the 3GPP phone through a 3GPP >> network to a 3GPP registrar is not going to decrease (or >> increase) their privacy. >> >> Can we just approve this and stop spending time on it? >> >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From oej@edvina.net Thu Sep 15 00:48:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26AC21F8520 for ; Thu, 15 Sep 2011 00:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeVx4HnZetK3 for ; Thu, 15 Sep 2011 00:48:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35D21F851A for ; Thu, 15 Sep 2011 00:48:22 -0700 (PDT) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 3A12B754BCE5; Thu, 15 Sep 2011 07:50:31 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 15 Sep 2011 09:50:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <33AFBA20-8C73-4C79-9B4F-07ED54D4807F@edvina.net> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 07:48:23 -0000 +1 /O 15 sep 2011 kl. 07:34 skrev Christer Holmberg: > > +1 > > Regards, > > Christer > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) >> Sent: 6. syyskuuta 2011 22:16 >> To: Andrew Allen; Cullen Jennings >> Cc: DISPATCH list >> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn >> anddraft-allen-dispatch-imei-urn-as-instanceid >> >> I hope I'm not the only person who feels that this "debate" >> is a tempest in a teapot. >> >> I can't see any serious reason not to define a URN namespace >> for IMEIs. These names have various deficiencies from >> various points of view, but none that are substantially worse >> than the currently popular system of constructing URNs from >> UUIDs which are constructed from MAC addresses (which are >> printed on a label on the back of the phone). >> >> There can only be interoperability problems if a proxy is >> unable to accept instance-ids that are in namespaces that it >> does not understand. But such a proxy is clearly deficient, >> and indeed, one would have to go out of one's way to build a >> proxy that had this deficiency, since the simplest and most >> natural implementation is to treat the instance-id as an >> opaque string. >> >> There may be IPR attached to this, but as the only vendors >> who would care about using it are manufacturers who have >> licensed the entire 3GPP IPR bundle, that causes nobody any >> problems that they do not already have. >> >> I regard to privacy, any user of a 3GPP phone has submitted >> to having their privacy protected and violated to exactly the >> degree designed into 3GPP, and the transmission of an >> IMEI-based instance-id between the 3GPP phone through a 3GPP >> network to a 3GPP registrar is not going to decrease (or >> increase) their privacy. >> >> Can we just approve this and stop spending time on it? >> >> Dale From dworley@avaya.com Thu Sep 15 08:44:40 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7321F8B46 for ; Thu, 15 Sep 2011 08:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35CleWwPnlU3 for ; Thu, 15 Sep 2011 08:44:40 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5380921F8B31 for ; Thu, 15 Sep 2011 08:44:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFYdck6HCzI1/2dsb2JhbABDp1d4gVMBAQEBAxIoPxACAQgNKRAyJQIEAQ0NGqJgApsqhhRgBJkCjAs X-IronPort-AV: E=Sophos;i="4.68,387,1312171200"; d="scan'208";a="303746840" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Sep 2011 11:46:46 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Sep 2011 11:37:21 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 15 Sep 2011 11:46:36 -0400 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" , Mary Barnes , Cullen Jennings Date: Thu, 15 Sep 2011 11:46:35 -0400 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADes0ow== Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, , 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 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:44:41 -0000 Based on responses that have been sent to my original rant, (1) I formally request the chairs to recognize that rough consensus has been reached that the work described in draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid should progress, and those proposals be dispatched to an appropriate working group. (2) I ask any person who believes that the current methods of constructing SIP instance ids can be significantly improved upon (along any dimension), and who wishes to work on improving them, present proposals for research and/or implementation to Dispatch or another working group, so that the state of SIP can be improved. Dale From peter.leis@nsn.com Thu Sep 15 22:17:29 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8752F21F8B89 for ; Thu, 15 Sep 2011 22:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=1.991, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH-+1jeEC+Es for ; Thu, 15 Sep 2011 22:17:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C821F8B5C for ; Thu, 15 Sep 2011 22:17:28 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8G5JaIw003084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 07:19:36 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8G5Jagr006904; Fri, 16 Sep 2011 07:19:36 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 07:19:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Sep 2011 07:19:33 +0200 Message-ID: <79C4240C13B4C84B910850B96B1B431203165E16@DEMUEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADtA8oA== References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, From: "Leis, Peter (NSN - DE/Munich)" To: "ext Worley, Dale R (Dale)" , "Andrew Allen" , "Cullen Jennings" X-OriginalArrivalTime: 16 Sep 2011 05:19:34.0952 (UTC) FILETIME=[38F1BA80:01CC7430] Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 05:17:29 -0000 +1 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Worley, Dale R (Dale) Sent: Tuesday, September 06, 2011 9:16 PM To: Andrew Allen; Cullen Jennings Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid I hope I'm not the only person who feels that this "debate" is a tempest in a teapot. I can't see any serious reason not to define a URN namespace for IMEIs. These names have various deficiencies from various points of view, but none that are substantially worse than the currently popular system of constructing URNs from UUIDs which are constructed from MAC addresses (which are printed on a label on the back of the phone). There can only be interoperability problems if a proxy is unable to accept instance-ids that are in namespaces that it does not understand. But such a proxy is clearly deficient, and indeed, one would have to go out of one's way to build a proxy that had this deficiency, since the simplest and most natural implementation is to treat the instance-id as an opaque string. There may be IPR attached to this, but as the only vendors who would care about using it are manufacturers who have licensed the entire 3GPP IPR bundle, that causes nobody any problems that they do not already have. I regard to privacy, any user of a 3GPP phone has submitted to having their privacy protected and violated to exactly the degree designed into 3GPP, and the transmission of an IMEI-based instance-id between the 3GPP phone through a 3GPP network to a 3GPP registrar is not going to decrease (or increase) their privacy. Can we just approve this and stop spending time on it? Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Fri Sep 16 05:19:14 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462F121F8AF3 for ; Fri, 16 Sep 2011 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVsCOf3BAmAl for ; Fri, 16 Sep 2011 05:19:12 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6A08821F87FA for ; Fri, 16 Sep 2011 05:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=980; q=dns/txt; s=iport; t=1316175687; x=1317385287; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UHI71ZGTT7LDaIqBoa3mdBh2HVOLAawjceERADZTzvA=; b=FWJnaE9TcunnLB7o0SOEZhgeRSFldFr9Sscu7griFibA3LCcDCCvM2LJ jTYiawncpMXVEIAOqi7PxfAa/L8QT4hvHLY6bCixHYdlWn8PMbi8Km4Hw +JdfXOvoQ0s7WvfIY74adP8l15uliwrk5ENfC+DJpRde252UNdG2OtgJT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMk+c06rRDoJ/2dsb2JhbABBp2N3gVMBAQEBAgESASc/BQsLRlcGNYdVllMBnhyGGGAEh2+LWoUdjC4 X-IronPort-AV: E=Sophos;i="4.68,393,1312156800"; d="scan'208";a="2529327" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 16 Sep 2011 12:21:26 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8GCLPwO013765; Fri, 16 Sep 2011 12:21:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 16 Sep 2011 06:21:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8A82641A-7BD5-4B2E-9504-B66D41086194@cisco.com> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, , To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1084) Cc: Mary Barnes , dispatch@ietf.org Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 12:19:14 -0000 On Sep 15, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote: > Based on responses that have been sent to my original rant, >=20 > (1) I formally request the chairs to recognize that rough consensus > has been reached that the work described in > draft-montemurro-gsma-imei-urn and > draft-allen-dispatch-imei-urn-as-instanceid should progress, and those > proposals be dispatched to an appropriate working group. Did any the emails sent since your rant discuss any of the issues = raised? Of course no one has ever objected some organization such ad GSM = having a URN they can use. >=20 > (2) I ask any person who believes that the current methods of > constructing SIP instance ids can be significantly improved upon > (along any dimension), and who wishes to work on improving them, > present proposals for research and/or implementation to Dispatch or > another working group, so that the state of SIP can be improved. I have. >=20 > Dale >=20 From aallen@rim.com Fri Sep 16 05:36:03 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71B21F8BA6 for ; Fri, 16 Sep 2011 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.173 X-Spam-Level: X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpdondE6yNzq for ; Fri, 16 Sep 2011 05:36:02 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 965F921F8A67 for ; Fri, 16 Sep 2011 05:36:01 -0700 (PDT) X-AuditID: 0a41282f-b7b33ae000006667-62-4e73431dfe8f Received: from XHT109CNC.rim.net (xht109cnc.rim.net [10.65.12.218]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 48.AE.26215.D13437E4; Fri, 16 Sep 2011 12:37:49 +0000 (GMT) Received: from XCT102ADS.rim.net (10.67.111.43) by XHT109CNC.rim.net (10.65.12.218) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 16 Sep 2011 08:38:15 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.01.0289.001; Fri, 16 Sep 2011 07:38:11 -0500 From: Andrew Allen To: "fluffy@cisco.com" , "dworley@avaya.com" Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMdGssbZceBMmjD0yI7xBT9wvw85VP8iJY Date: Fri, 16 Sep 2011 12:38:11 +0000 Message-ID: In-Reply-To: <8A82641A-7BD5-4B2E-9504-B66D41086194@cisco.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.252] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsXC5chzS1fWudjPYNovE4ulkxawWrTtmsNs 0TGZzWL245csDiweB1fOYfeY8nsjq8eSJT+ZPF48UApgiWpgtEnMy8svSSxJVUhJLU62VfJJ TU/MUQgoyixLTK5UcMksTs5JzMxNLVJSyEyxVTJRUijISUxOzU3NK7FVSiwoSM1LUbLjUsAA NkBlmXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZKdrpIIOEfd8biO1+ZCvbyVLzetoepgXEhVxcj J4eEgInEz89TmCFsMYkL99azgdhCAr1MEusvO3QxcgHZyxglXkx+xAzhbGGUWDN9HVgVm4Cy xPLfMxhBbBGBEIlVk5ayg9jMAkkSt99PBIsLC6RL3GxqYYOoyZB433mEGcI2kji37CEriM0i oCrx49gOsDivgJvEtCWXgXo5ODgFbCX6ntaChBkFZCV2n73OBDFeXOLWk/lMEEcLSCzZcx7q AVGJl4//sYK0SggoSizfLgVRridxY+oUNghbW2LZwtdQmwQlTs58wgLxr7TEjpNrGCcwis9C smEWkvZZSNpnIWlfwMiyilEwN6PYwMwgOS9ZrygzVy8vtWQTIzjBaOjvYOzbq3WIUYCDUYmH t0K92E+INbGsuDL3EKMEB7OSCK+BPVCINyWxsiq1KD++qDQntfgQowUwTCYyS3En5wOTX15J vLGBAQpHSZyX91KGn5BAOjBNZaemFqQWwbQycXBKNTCaFtoULrt/w93st8EhW9//HBmBJ2f2 1+4LyN9kzuU959uUkIWCuVY7bkkdaVj9ReWjpKzVsXiFq0ePNV2fLD9h/7tVd5hTZLdefG73 2i9P1jvO0nKKnNCib/5GDtuitp7rthIvv7fxg+O++dpZkVZ/t385apm4MCbtp3hxqtr17emc MYwnq/2VWIozEg21mIuKEwHqSfdiSQMAAA== Cc: "mary.barnes@polycom.com" , "dispatch@ietf.org" Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 12:36:03 -0000 Cullen I think my email prior to Dale's that Dale replied to responded to all your= points Andrew ----- Original Message ----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, September 16, 2011 07:21 AM=0A= To: Worley, Dale R (Dale) Cc: Mary Barnes ; dispatch@ietf.org Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispat= ch-imei-urn-as-instanceid On Sep 15, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote: > Based on responses that have been sent to my original rant, > > (1) I formally request the chairs to recognize that rough consensus > has been reached that the work described in > draft-montemurro-gsma-imei-urn and > draft-allen-dispatch-imei-urn-as-instanceid should progress, and those > proposals be dispatched to an appropriate working group. Did any the emails sent since your rant discuss any of the issues raised? Of= course no one has ever objected some organization such ad GSM having a URN= they can use. > > (2) I ask any person who believes that the current methods of > constructing SIP instance ids can be significantly improved upon > (along any dimension), and who wishes to work on improving them, > present proposals for research and/or implementation to Dispatch or > another working group, so that the state of SIP can be improved. I have. > > Dale > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From krisztian.kiss@nokia.com Fri Sep 16 14:07:51 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C65C21F8B80 for ; Fri, 16 Sep 2011 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mPEcU4aHsZu for ; Fri, 16 Sep 2011 14:07:50 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEE221F888A for ; Fri, 16 Sep 2011 14:07:41 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8GL9o5O027114; Sat, 17 Sep 2011 00:09:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Sep 2011 00:09:50 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Sep 2011 23:09:49 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.188]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Fri, 16 Sep 2011 23:09:48 +0200 From: To: , , , Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMaldNj2uxc5UdzEOmTtann14q1JVAnIGAgA0/s4CAAjsMAA== Date: Fri, 16 Sep 2011 21:09:48 +0000 Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [99.92.93.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2011 21:09:50.0205 (UTC) FILETIME=[F8AEEAD0:01CC74B4] X-Nokia-AV: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 21:07:51 -0000 +1 Cheers, Krisztian -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Christer Holmberg Sent: Wednesday, September 14, 2011 22:35 To: Worley, Dale R (Dale); Andrew Allen; Cullen Jennings Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispa= tch-imei-urn-as-instanceid +1 Regards, Christer=20 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) > Sent: 6. syyskuuta 2011 22:16 > To: Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn=20 > anddraft-allen-dispatch-imei-urn-as-instanceid >=20 > I hope I'm not the only person who feels that this "debate"=20 > is a tempest in a teapot. >=20 > I can't see any serious reason not to define a URN namespace for=20 > IMEIs. These names have various deficiencies from various points of=20 > view, but none that are substantially worse than the currently popular=20 > system of constructing URNs from UUIDs which are constructed from MAC=20 > addresses (which are printed on a label on the back of the phone). >=20 > There can only be interoperability problems if a proxy is unable to=20 > accept instance-ids that are in namespaces that it does not=20 > understand. But such a proxy is clearly deficient, and indeed, one=20 > would have to go out of one's way to build a proxy that had this=20 > deficiency, since the simplest and most natural implementation is to=20 > treat the instance-id as an opaque string. >=20 > There may be IPR attached to this, but as the only vendors who would=20 > care about using it are manufacturers who have licensed the entire=20 > 3GPP IPR bundle, that causes nobody any problems that they do not=20 > already have. >=20 > I regard to privacy, any user of a 3GPP phone has submitted to having=20 > their privacy protected and violated to exactly the degree designed=20 > into 3GPP, and the transmission of an IMEI-based instance-id between=20 > the 3GPP phone through a 3GPP network to a 3GPP registrar is not going=20 > to decrease (or > increase) their privacy. >=20 > Can we just approve this and stop spending time on it? >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From atle.monrad@ericsson.com Fri Sep 16 15:57:18 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B46521F8B3F for ; Fri, 16 Sep 2011 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os6mFf9GcwFh for ; Fri, 16 Sep 2011 15:57:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B22EF21F8B3E for ; Fri, 16 Sep 2011 15:57:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-84-4e73d4d178d6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A8.EA.02839.2D4D37E4; Sat, 17 Sep 2011 00:59:30 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.187]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 17 Sep 2011 00:59:29 +0200 From: Atle Monrad To: Christer Holmberg , "Worley, Dale R (Dale)" , Andrew Allen , Cullen Jennings Date: Sat, 17 Sep 2011 00:59:26 +0200 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADUJjIIACsfbg Message-ID: <7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 22:57:18 -0000 All +1 I'd like to echo Dales request. To me it seems that there are quite some support for progressing and comple= ting draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-in= stanceid.=20 3GPP needs a solution to this. thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) > Sent: 6. syyskuuta 2011 22:16 > To: Andrew Allen; Cullen Jennings > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn=20 > anddraft-allen-dispatch-imei-urn-as-instanceid >=20 > I hope I'm not the only person who feels that this "debate"=20 > is a tempest in a teapot. >=20 > I can't see any serious reason not to define a URN namespace for=20 > IMEIs. These names have various deficiencies from various points of=20 > view, but none that are substantially worse than the currently popular=20 > system of constructing URNs from UUIDs which are constructed from MAC=20 > addresses (which are printed on a label on the back of the phone). >=20 > There can only be interoperability problems if a proxy is unable to=20 > accept instance-ids that are in namespaces that it does not=20 > understand. But such a proxy is clearly deficient, and indeed, one=20 > would have to go out of one's way to build a proxy that had this=20 > deficiency, since the simplest and most natural implementation is to=20 > treat the instance-id as an opaque string. >=20 > There may be IPR attached to this, but as the only vendors who would=20 > care about using it are manufacturers who have licensed the entire=20 > 3GPP IPR bundle, that causes nobody any problems that they do not=20 > already have. >=20 > I regard to privacy, any user of a 3GPP phone has submitted to having=20 > their privacy protected and violated to exactly the degree designed=20 > into 3GPP, and the transmission of an IMEI-based instance-id between=20 > the 3GPP phone through a 3GPP network to a 3GPP registrar is not going=20 > to decrease (or > increase) their privacy. >=20 > Can we just approve this and stop spending time on it? >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Sun Sep 18 19:55:31 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACEB21F8B29 for ; Sun, 18 Sep 2011 19:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bVBRQcGd-+b for ; Sun, 18 Sep 2011 19:55:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC1721F8B1A for ; Sun, 18 Sep 2011 19:55:30 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 18 Sep 2011 22:57:49 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 18 Sep 2011 22:57:48 -0400 From: Hadriel Kaplan To: "dispatch-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMdnfph1Tw5h+P50+E88g5ElDGWg== Date: Mon, 19 Sep 2011 02:57:48 +0000 Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <00B9A2198AC62D4086C45B5D622AAE0B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 02:55:31 -0000 I have read through all the emails since the one that started this thread b= ack on May 18, and I agree with Dale. Every issue raised has actually been= responded to as far as I can tell, and clearly there is demand/interest. In particular, since we actually need to DISPATCH these somewhere, I sugges= t that they both go the A-D sponsored path and not require a new mini-WG (a= nd no existing group is appropriate afaict). -hadriel On Sep 6, 2011, at 3:15 PM, Worley, Dale R (Dale) wrote: > I hope I'm not the only person who feels that this "debate" is a tempest > in a teapot. >=20 > I can't see any serious reason not to define a URN namespace for > IMEIs. These names have various deficiencies from various points > of view, but none that are substantially worse than the currently popular > system of constructing URNs from UUIDs which are constructed from > MAC addresses (which are printed on a label on the back of the phone). >=20 > There can only be interoperability problems if a proxy is unable to accep= t > instance-ids that are in namespaces that it does not understand. But > such a proxy is clearly deficient, and indeed, one would have to go out > of one's way to build a proxy that had this deficiency, since the simples= t > and most natural implementation is to treat the instance-id as an opaque > string. >=20 > There may be IPR attached to this, but as the only vendors who would > care about using it are manufacturers who have licensed the entire 3GPP > IPR bundle, that causes nobody any problems that they do not already have= . >=20 > I regard to privacy, any user of a 3GPP phone has submitted to having > their privacy protected and violated to exactly the degree designed into = 3GPP, > and the transmission of an IMEI-based instance-id between the 3GPP phone > through a 3GPP network to a 3GPP registrar is not going to decrease (or > increase) their privacy. >=20 > Can we just approve this and stop spending time on it? >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From aallen@rim.com Sun Sep 18 19:58:30 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1643821F8B06 for ; Sun, 18 Sep 2011 19:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRntEE+d55k7 for ; Sun, 18 Sep 2011 19:58:29 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 44E8521F8AF5 for ; Sun, 18 Sep 2011 19:58:29 -0700 (PDT) X-AuditID: 0a412830-b7c9cae000003349-c4-4e76b062e8ae Received: from XHT103CNC.rim.net (xht103cnc.rim.net [10.65.22.51]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 14.23.13129.260B67E4; Mon, 19 Sep 2011 03:00:50 +0000 (GMT) Received: from XCT101ADS.rim.net (10.67.111.42) by XHT103CNC.rim.net (10.65.22.51) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sun, 18 Sep 2011 23:00:50 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.01.0289.001; Sun, 18 Sep 2011 22:00:48 -0500 From: Andrew Allen To: "HKaplan@acmepacket.com" , "dispatch-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmAE7OnAP//rQN7 Date: Mon, 19 Sep 2011 03:00:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.252] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5ShmrJu0oczPYO5VSYutL1azWCydtIDV Yu7l5+wWe7fPY3Rg8dg0eTObx5IlP5k8vlz+zBbAHNXAaJOYl5dfkliSqpCSWpxsq+STmp6Y oxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDK MvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HSRQMI/7oz1x6awFFwWrfjVdpC1gfGKYBcjJ4eE gIlEy+92FghbTOLCvfVsXYxcHEICPUwScw/vZoRwljJKtG65yQ7hbGGUOH5rEztIC5uAssTy 3zPAqkQE1jNKvJw1jwkkwSygLfH/+jpGEFtYIF1i18VmMFtEIEOibeUrKNtN4szSB2wgNouA qsTjBw1gd/ACxXffP8zaxcjBwSngJDFtvxtImFFAVmL32etQ48Ulbj2ZzwRxtoDEkj3nmSFs UYmXj/+BtUoIKEos3y4FUa4ncWPqFDaYy5YtfM0MsUlQ4uTMJ2BbhQSkJXacXMM4gVF8FpIN s5C0z0LSPgtJ+wJGllWMgrkZxQZmhsl5yXpFmbl6eaklmxjB6UXDYAfjhL1ahxgFOBiVeHiZ V5X5CbEmlhVX5h5ilOBgVhLhjWoECvGmJFZWpRblxxeV5qQWH2K0AIbJRGYp7uR8YOrLK4k3 NjBA4SiJ88pcyvATEkgHpqrs1NSC1CKYViYOTqkGxuy5WxJ8hXmmrdriOz2ro7fM+Nf2O+tc pFKtTnivlF36o+fYnuOb9+3Y4xn60/l3gsWLCMXYhDL7KSxr2udftWA+EHBaI83pW3XLHb+n 4XN9mW4cSswJziha3K7dHHTWK0jmvePGqdNu6jNyMOQsEDph4aNQY1Ial/la9BNbwtes37d2 dyrVKrEUZyQaajEXFScCAOXJW9xIAwAA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 02:58:30 -0000 +1 AD sponsored is my preferred approach. Andrew ----- Original Message ----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Sunday, September 18, 2011 09:57 PM=0A= To: dispatch-chairs@tools.ietf.org ; rai-ads= @tools.ietf.org Cc: DISPATCH list Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispat= ch-imei-urn-as-instanceid I have read through all the emails since the one that started this thread ba= ck on May 18, and I agree with Dale. Every issue raised has actually been r= esponded to as far as I can tell, and clearly there is demand/interest. In particular, since we actually need to DISPATCH these somewhere, I suggest= that they both go the A-D sponsored path and not require a new mini-WG (and= no existing group is appropriate afaict). -hadriel On Sep 6, 2011, at 3:15 PM, Worley, Dale R (Dale) wrote: > I hope I'm not the only person who feels that this "debate" is a tempest > in a teapot. > > I can't see any serious reason not to define a URN namespace for > IMEIs. These names have various deficiencies from various points > of view, but none that are substantially worse than the currently popular > system of constructing URNs from UUIDs which are constructed from > MAC addresses (which are printed on a label on the back of the phone). > > There can only be interoperability problems if a proxy is unable to accept > instance-ids that are in namespaces that it does not understand. But > such a proxy is clearly deficient, and indeed, one would have to go out > of one's way to build a proxy that had this deficiency, since the simplest > and most natural implementation is to treat the instance-id as an opaque > string. > > There may be IPR attached to this, but as the only vendors who would > care about using it are manufacturers who have licensed the entire 3GPP > IPR bundle, that causes nobody any problems that they do not already have. > > I regard to privacy, any user of a 3GPP phone has submitted to having > their privacy protected and violated to exactly the degree designed into 3= GPP, > and the transmission of an IMEI-based instance-id between the 3GPP phone > through a 3GPP network to a 3GPP registrar is not going to decrease (or > increase) their privacy. > > Can we just approve this and stop spending time on it? > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jan.van.geel@belgacom.be Sun Sep 18 23:41:50 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEB121F8A7A for ; Sun, 18 Sep 2011 23:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH5R3rpNiAx5 for ; Sun, 18 Sep 2011 23:41:49 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id 60BF021F8677 for ; Sun, 18 Sep 2011 23:41:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,403,1312149600"; d="scan'208";a="7063615" Received: from a03007.bgc.net ([10.120.129.162]) by mx13.belgacom.be with ESMTP; 19 Sep 2011 08:44:10 +0200 X-TM-IMSS-Message-ID: <21775cdf00050874@belgacom.be> Received: from AE7111.BGC.NET ([45.219.2.50]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 21775cdf00050874 ; Mon, 19 Sep 2011 08:44:09 +0200 Received: from CMS03.BGC.NET ([169.254.1.110]) by AE7111.BGC.NET ([45.219.2.50]) with mapi; Mon, 19 Sep 2011 08:44:09 +0200 From: "VAN GEEL Jan (SDV/PSE)" To: DISPATCH list Date: Mon, 19 Sep 2011 08:44:08 +0200 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADUJjIIACsfbggAOqeFA= Message-ID: <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET> References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net> <1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18394.005 x-tm-as-result: No--54.332800-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 06:41:50 -0000 Also=20Belgacom=20would=20like=20to=20see=20this=20draft=20progressed Jan=20Van=20Geel=20 IT=20and=20Network=20Specialist=20 Belgacom=20SDE/SDV/PSE/FVC=20 Tel:=20+32=202=20202=201035=20 Tel:=20+32=202=20207=209032=20 Email=20:=20jan.van.geel@belgacom.be=20 -----Original=20Message----- From:=20dispatch-bounces@ietf.org=20[mailto:dispatch-bounces@ietf.org]=20= On=20Behalf=20Of=20Atle=20Monrad Sent:=2017=20September=202011=2000:59 To:=20Christer=20Holmberg;=20Worley,=20Dale=20R=20(Dale);=20Andrew=20Alle= n;=20Cullen=20Jennings Cc:=20DISPATCH=20list Subject:=20Re:=20[dispatch]=20draft-montemurro-gsma-imei-urn=20anddraft-a= llen-dispatch-imei-urn-as-instanceid All +1 I'd=20like=20to=20echo=20Dales=20request. To=20me=20it=20seems=20that=20there=20are=20quite=20some=20support=20for= =20progressing=20and=20completing=20draft-montemurro-gsma-imei-urn=20and= =20draft-allen-dispatch-imei-urn-as-instanceid.=20 3GPP=20needs=20a=20solution=20to=20this. thanks /atle ________________________________=20 Atle=20Monrad 3GPP=20CT=20Chairman Standardization=20and=20Regulation, Group=20Function=20Technology=20and=20Portfolio=20Management=20 Ericsson >=20-----Original=20Message----- >=20From:=20dispatch-bounces@ietf.org >=20[mailto:dispatch-bounces@ietf.org]=20On=20Behalf=20Of=20Worley,=20Dal= e=20R=20(Dale) >=20Sent:=206.=20syyskuuta=202011=2022:16 >=20To:=20Andrew=20Allen;=20Cullen=20Jennings >=20Cc:=20DISPATCH=20list >=20Subject:=20Re:=20[dispatch]=20draft-montemurro-gsma-imei-urn=20 >=20anddraft-allen-dispatch-imei-urn-as-instanceid >=20 >=20I=20hope=20I'm=20not=20the=20only=20person=20who=20feels=20that=20thi= s=20"debate"=20 >=20is=20a=20tempest=20in=20a=20teapot. >=20 >=20I=20can't=20see=20any=20serious=20reason=20not=20to=20define=20a=20UR= N=20namespace=20for=20 >=20IMEIs.=20=20These=20names=20have=20various=20deficiencies=20from=20va= rious=20points=20of=20 >=20view,=20but=20none=20that=20are=20substantially=20worse=20than=20the= =20currently=20popular=20 >=20system=20of=20constructing=20URNs=20from=20UUIDs=20which=20are=20cons= tructed=20from=20MAC=20 >=20addresses=20(which=20are=20printed=20on=20a=20label=20on=20the=20back= =20of=20the=20phone). >=20 >=20There=20can=20only=20be=20interoperability=20problems=20if=20a=20prox= y=20is=20unable=20to=20 >=20accept=20instance-ids=20that=20are=20in=20namespaces=20that=20it=20do= es=20not=20 >=20understand.=20=20But=20such=20a=20proxy=20is=20clearly=20deficient,= =20and=20indeed,=20one=20 >=20would=20have=20to=20go=20out=20of=20one's=20way=20to=20build=20a=20pr= oxy=20that=20had=20this=20 >=20deficiency,=20since=20the=20simplest=20and=20most=20natural=20impleme= ntation=20is=20to=20 >=20treat=20the=20instance-id=20as=20an=20opaque=20string. >=20 >=20There=20may=20be=20IPR=20attached=20to=20this,=20but=20as=20the=20onl= y=20vendors=20who=20would=20 >=20care=20about=20using=20it=20are=20manufacturers=20who=20have=20licens= ed=20the=20entire=20 >=203GPP=20IPR=20bundle,=20that=20causes=20nobody=20any=20problems=20that= =20they=20do=20not=20 >=20already=20have. >=20 >=20I=20regard=20to=20privacy,=20any=20user=20of=20a=203GPP=20phone=20has= =20submitted=20to=20having=20 >=20their=20privacy=20protected=20and=20violated=20to=20exactly=20the=20d= egree=20designed=20 >=20into=203GPP,=20and=20the=20transmission=20of=20an=20IMEI-based=20inst= ance-id=20between=20 >=20the=203GPP=20phone=20through=20a=203GPP=20network=20to=20a=203GPP=20r= egistrar=20is=20not=20going=20 >=20to=20decrease=20(or >=20increase)=20their=20privacy. >=20 >=20Can=20we=20just=20approve=20this=20and=20stop=20spending=20time=20on= =20it? >=20 >=20Dale >=20_______________________________________________ >=20dispatch=20mailing=20list >=20dispatch@ietf.org >=20https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch=20mailing=20list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch=20mailing=20list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ****=20DISCLAIMER=20**** http://www.belgacom.be/maildisclaimer From bruno.chatras@orange.com Mon Sep 19 06:03:17 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7321F8BF3 for ; Mon, 19 Sep 2011 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfuQmWaL3Ivz for ; Mon, 19 Sep 2011 06:03:16 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2D41621F8BE4 for ; Mon, 19 Sep 2011 06:03:16 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 31F088B8007; Mon, 19 Sep 2011 15:06:34 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2773E8B8001; Mon, 19 Sep 2011 15:06:34 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 15:05:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Sep 2011 15:05:36 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADUJjIIACsfbggAOqeFCAAGrAsA== References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET> From: To: , X-OriginalArrivalTime: 19 Sep 2011 13:05:38.0131 (UTC) FILETIME=[D3897A30:01CC76CC] X-Mailman-Approved-At: Mon, 19 Sep 2011 06:46:36 -0700 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 13:04:39 -0000 +1 > -----Message d'origine----- > De=A0: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De = la > part de VAN GEEL Jan (SDV/PSE) > Envoy=E9=A0: lundi 19 septembre 2011 08:44 > =C0=A0: DISPATCH list > Objet=A0: Re: [dispatch] draft-montemurro-gsma-imei-urn = anddraft-allen- > dispatch-imei-urn-as-instanceid >=20 > Also Belgacom would like to see this draft progressed >=20 > Jan Van Geel > IT and Network Specialist > Belgacom SDE/SDV/PSE/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Atle Monrad > Sent: 17 September 2011 00:59 > To: Christer Holmberg; Worley, Dale R (Dale); Andrew Allen; Cullen > Jennings > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- > dispatch-imei-urn-as-instanceid >=20 > All >=20 > +1 >=20 > I'd like to echo Dales request. >=20 > To me it seems that there are quite some support for progressing and > completing draft-montemurro-gsma-imei-urn and = draft-allen-dispatch-imei- > urn-as-instanceid. >=20 > 3GPP needs a solution to this. >=20 > thanks > /atle >=20 > ________________________________ >=20 >=20 > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management > Ericsson >=20 >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale R = (Dale) > > Sent: 6. syyskuuta 2011 22:16 > > To: Andrew Allen; Cullen Jennings > > Cc: DISPATCH list > > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn > > anddraft-allen-dispatch-imei-urn-as-instanceid > > > > I hope I'm not the only person who feels that this "debate" > > is a tempest in a teapot. > > > > I can't see any serious reason not to define a URN namespace for > > IMEIs. These names have various deficiencies from various points of > > view, but none that are substantially worse than the currently = popular > > system of constructing URNs from UUIDs which are constructed from = MAC > > addresses (which are printed on a label on the back of the phone). > > > > There can only be interoperability problems if a proxy is unable to > > accept instance-ids that are in namespaces that it does not > > understand. But such a proxy is clearly deficient, and indeed, one > > would have to go out of one's way to build a proxy that had this > > deficiency, since the simplest and most natural implementation is to > > treat the instance-id as an opaque string. > > > > There may be IPR attached to this, but as the only vendors who would > > care about using it are manufacturers who have licensed the entire > > 3GPP IPR bundle, that causes nobody any problems that they do not > > already have. > > > > I regard to privacy, any user of a 3GPP phone has submitted to = having > > their privacy protected and violated to exactly the degree designed > > into 3GPP, and the transmission of an IMEI-based instance-id between > > the 3GPP phone through a 3GPP network to a 3GPP registrar is not = going > > to decrease (or > > increase) their privacy. > > > > Can we just approve this and stop spending time on it? > > > > Dale > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > **** DISCLAIMER **** > http://www.belgacom.be/maildisclaimer > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From rifatyu@avaya.com Tue Sep 20 11:34:28 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2521D1F0C69 for ; Tue, 20 Sep 2011 11:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKikSQ8V+bqo for ; Tue, 20 Sep 2011 11:34:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 407D41F0C68 for ; Tue, 20 Sep 2011 11:34:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANjbeE7GmAcF/2dsb2JhbABCgk2kK2l4gVoSG14BFWsmAQQbGpsThAwCm02GHWAEmQiMDg X-IronPort-AV: E=Sophos;i="4.68,412,1312171200"; d="scan'208,217";a="268830282" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Sep 2011 14:36:50 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Sep 2011 14:36:09 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 20 Sep 2011 14:36:44 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "dispatch@ietf.org" Date: Tue, 20 Sep 2011 14:36:43 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx3xD58K/QCxy77RU+NJxPPpra6SQ== Message-ID: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822D1B91606DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 18:34:28 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822D1B91606DCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The following is a charter proposal for a Remote Call/Device Control WG. We would appreciate it if you review it and provide us with your feedback. Thanks, Rifaat ------- Remote Call/Device Control WG The Session Initiation Protocol (SIP) [RFC3261] provides users with the abi= lity to initiate, manage, and terminate multimedia sessions. A SIP application is a program running on a SIP network element that provid= es some value-added function to a user. Many deployments have SIP applications in the SIP signaling path that get i= nvolved in the setup and management of these multimedia sessions. Third-Party Application might also be interested in interacting with User A= gents and the setup of multimedia sessions. Some of these applications need a mechanism to remotely invoke some actions= or/and monitor the invocation of actions on a SIP User Agent. SIP allows for the invocation of actions on a remote User Agent using the R= EFER method. The actions that can be invoked by the REFER method are limited, and there = is a need for more actions by some SIP applications. The purpose of this WG is to evaluate the various available mechanisms or p= roposed mechanism and recommend one or more of them, or define a new mechanism if none of the available are good enough to addre= ss this need. The work group will need to address the following: * Clearly answer the following questions: a. What is "call control"? b. What is "device control"? * Will the new mechanism address "call control", "device control" or both? * Will the new mechanism be a SIP or a non-SIP based mechanism? * If a non-SIP mechanism is used, how to deal with the fact that some of th= ese actions already covered by the SIP REFER method and widely used in the in= dustry * Define a model for the actions * Define a scope for the actions * Define a set of initial actions that can be later extended, if needed. * Others? --_000_6369CB70BFD88942B9705AC1E639A33822D1B91606DCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

T= he following is a charter proposal for a Remote Call/Device Control WG.

We would appreciate it if you review it = and provide us with your feedback.

 

Thanks,

Rifaat

 

-------

 

Remote Call/Device Control = WG

 

The Session Initiation Protocol (SIP) [RFC3261] provides users w= ith the ability to initiate, manage, and terminate multimedia sessions.

A SIP application is a program running o= n a SIP network element that provides some value-added function to a user.<= o:p>

Many deployments have SIP application= s in the SIP signaling path that get involved in the setup and management o= f these multimedia sessions.

Third-P= arty Application might also be interested in interacting with User Agents a= nd the setup of multimedia sessions.

= Some of these applications need a mechanism to remotely invoke some actions= or/and monitor the invocation of actions on a SIP User Agent. <= /p>

SIP allows for the invocation of actions on a re= mote User Agent using the REFER method.

The actions that can be invoked by the REFER method are limited, and th= ere is a need for more actions by some SIP applications.

The purpose of this WG is to evaluate the various avail= able mechanisms or proposed mechanism and recommend one or more of them,

or define a new mechanism if none of t= he available are good enough to address this need.

 

The work group= will need to address the following:

= * Clearly answer the following questions:

   a. What is "call control"?

   b. What is "device control"?<= /o:p>

* Will the new mechanism address "cal= l control", "device control" or both?

* Will the new mechanism be a SIP or a non-SIP based mechan= ism?

* If a non-SIP mechanism is used= , how to deal with the fact that some of these

  actions already covered by the SIP REFER method and widely= used in the industry

* Define a mode= l for the actions

* Define a scope fo= r the actions

* Define a set of initi= al actions that can be later extended, if needed.

* Others?

 

= --_000_6369CB70BFD88942B9705AC1E639A33822D1B91606DCUS1MBEX4glo_-- From dworley@avaya.com Tue Sep 20 12:49:37 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F371B1F0C6E for ; Tue, 20 Sep 2011 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMXrmkfLbis5 for ; Tue, 20 Sep 2011 12:49:36 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id E154A1F0C40 for ; Tue, 20 Sep 2011 12:49:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJrueE6HCzI1/2dsb2JhbABCp2J4gVMBAQEBAxIoTwIBCA0pEDIlAgQbGp89AptIhh1gBJkIjA4 X-IronPort-AV: E=Sophos;i="4.68,413,1312171200"; d="scan'208";a="268842994" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Sep 2011 15:52:01 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Sep 2011 15:42:35 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 20 Sep 2011 15:52:00 -0400 From: "Worley, Dale R (Dale)" To: "dispatch@ietf.org" Date: Tue, 20 Sep 2011 15:51:30 -0400 Thread-Topic: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid Thread-Index: AQHMS+KRk28SBYZz406Llwoh5NDtuZU73uJggAUZVqmADUJjIIACsfbggAOqeFCAAGrAsIACA9P+ Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> 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 Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 19:49:37 -0000 Given that the decision to be made in this working group is whether to assign these I-Ds for further work to be done on them, there are a small number of questions in play (with assorted other issues to be addressed during the technical refinement of the proposal): 1. Does this proposal introduce any interoperability problems? 2. Does this proposal present any privacy concerns? 3. Does this proposal allow anyone to extract an unconscionable "tax" (through the use of IPR)? Here are my assessments of these issues: 1. Does this proposal introduce any interoperability problems? I don't see what interoperability problems can result from the introduction of an additional format of URN, as long as the format adheres to the generic URN syntax. RFC 5626 section 4.1 makes it clear that a SIP element may receive a +sip.instance value which is in a URN namespace that it does not recognize, so any properly constructed SIP element should be able to handle +sip.instance values in namespaces that it does not have prior knowledge of. (Certainly, the one product/project that I have detailed knowledge of has always treated +sip.instance as a string. Thereon hangs a tale: If the +sip.instance is a UUID-based URN, and if the UUID is based on a MAC address, the registrar extracts the MAC address so that the UA can be addressed through a special URI that encodes its MAC address. But it turns out that a popular make of UA formats its UUIDs incorrectly, so that it was not recognized as a MAC-based UUID. We've had to add special code to the registrar to recognize this defective URN format!) 2. Does this proposal present any privacy concerns? There would be general privacy concerns if this or any other +sip.instance value was present in dialog-forming requests or responses, and so could be seen by the other end of phone calls. But as far as I can tell, no UA uses +sip.instance in INVITEs; +sip.instance values are presented only in REGISTER messages. On the other hand, generated GRUU values are given in INVITEs, and the GRUU can give information about the UA's +sip.instance and the AOR, even if the GRUU is generated using a secret key. However, the problems resulting from this seem to be essentially the same when the +sip.instance is derived from an IMEI as when it is derived from a MAC address. In regard to registrations, given that the intended scope of application of the proposal is entirely within paid wireless networks, there can be no privacy between the UA and its registrar. 3. Does this proposal allow anyone to extract an unconscionable "tax" (through the use of IPR)? Though this proposal may be encumbered by IPR claims, the only users who would be *required* to use this URN format are products within the GSM/3GPP/IMS universe, and even then, only if GSM/3GPP/IMS adopts this as mandatory-to-implement. Those users might be subjected to an unconscionable tax, but the GSM/3GPP/IMS universe has its own political/economic structure for deciding what licensed technology is mandatory to implement and what licensing terms are considered acceptable. It seems to me that we can justly leave these questions to GSM/3GPP/IMS. There is some concern that the IPR disclosures were filed "late". However, as the latest IPR disclosure was filed in January 2011, the working group is now even later, and the objection has expired. In summary, I don't see any of these issues as being particularly problematic. If I've overlooked an important aspect of this, I would like to see some detailed information about it. Dale From fluffy@cisco.com Wed Sep 21 08:34:40 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267D15E800A; Wed, 21 Sep 2011 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.124 X-Spam-Level: X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMnSkqcfQHwW; Wed, 21 Sep 2011 08:34:39 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 56A235E8004; Wed, 21 Sep 2011 08:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=7595; q=dns/txt; s=iport; t=1316619428; x=1317829028; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=YMqgkdSoZ6nL37y2qodbqQ+B6RNml3GdvKHkRuWaOdE=; b=Gcbihi8xLY5dVPKofnwjTeQPJc9IYOsTAwS7Pafg9DPfJsvl7aURsPYe Ee3J+oFABmcJ9GN1kr9ONCxaQcNYcgwDmRAwx+xdFSW2WX6+CgBvKmX/B sX2NLNVn7NzXXfvNcufPHpnIbDB3cxBdIK/qNF0xCalYZIlh1Y3Te+zm8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE8Eek6rRDoH/2dsb2JhbABCp2Z4gWwBBQ8TLQEGCy0SaxQBKwIHnhUBniKGHWAEh3CLXYUfjC8 X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="3429663" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 Sep 2011 15:37:02 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8LFb10m014169; Wed, 21 Sep 2011 15:37:01 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Sep 2011 09:37:01 -0600 Message-Id: <38F7F113-95F4-4187-A02A-C9B1C9094BF7@cisco.com> To: DISPATCH list , rai@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dispatch] Distributed Conferencing BOF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 15:34:40 -0000 Simon has proposed a Distributed Conferencing WG in the charter below. = This work was discussed long ago in XCON and the decision was to wait = till the XCON work was further along. Now that the XCON works is = wrapping up, we should consider taking on this new work.=20 The ADs and chairs discussed using dispatch agenda time for this and our = initial take was that this was a pretty big chunk of work that could = involve input from people outside the usual Dispatch participants. = Because of that, we think this would probably best be done as a full = BOF. If people don't think this is the right path forward for this work, = we welcome feedback and reconsider what to do. The current plan is to = propose this a normal IETF BOF at the upcoming IETF. Of course we would = want to encourage discussion of this charter ahead of time. Given the = tentative plan to run this as a BOF, I have added the RAI mailing list = to this thread.=20 Thanks, Cullen - Description of Working Group The focus of this Working Group is to develop a standard solution for = scalable conferencing over the Internet. The WG will define a standard = suite of protocols for distributed conferencing and will draw = inspiration from the work carried out in the XCON working group, which = has defined a complete architecture for centralized conferencing. DCON = is based on the idea that a distributed conference can be setup by appropriately orchestrating the = operation of a number of XCON focus elements, each in charge of managing = a certain number of participants. Interaction between each participant = and the corresponding conference focus will be entirely based on the = standard XCON framework, whereas inter-focus interaction will be defined = by this WG. In the DCON architecture a number of entities are used to manage = conference setup in the presence of clients which are distributed across = a geographical network. Each managing entity plays the role of a conference focus as = defined in the XCON working group documents. Indeed, each XCON focus = will be in charge of managing a certain number of clients falling under = its own "realm". In order to move the XCON scope towards a distributed = environment, we will introduce inter-focus coordination, which is needed = to effectively setup and manage conference instantiation and = coordination. As in the centralized case, we will define logical = entities and naming conventions. An appropriate data model for = distributed conferencing will be potentially defined and will extend, = when needed, the XCON data model. Furthermore, we will propose the = adoption of a suitable set of protocols which are complementary to the = call signaling protocols and are needed to support advanced conferencing = applications. The WG will basically need to introduce two major functions: (i) a = coordination level among conference focus entities; (ii) a way to = effectively distribute conference state information. As to the first = point above, the coordination level is needed in order to manage a = distributed conference along its entire life-cycle. For instance, once a = user decides to create a new conference, the corresponding conference = focus has to distribute conference information to all other foci, in = such a way as to enable other potential participants to retrieve the = needed data and possibly subscribe to the event. The WG will make the = assumption that all the operations needed inside a single conference = cloud are managed via the protocols and interfaces defined inside the = XCON working group. Hence, each single cloud will keep on being based = on a star-topology graph for all what concerns the call signaling part. = The various available stars will then be connected through an = upper-layer topology providing inter-focus communication. The overall = topology of the distributed conferencing scenario will look like an = overlay network of focus entities, each managing an underlying = "centralized" conferencing island. The WG will envisage the possibility = to exploit extended Instant Messaging (IM) protocols (e.g. XMPP) for = inter-focus communication. As to the second point mentioned above, it looks clear that a way to = propagate information about conferences is needed when switching the = view from a centralized to a distributed perspective. Indeed, whenever = a new conference is created (or an active conference changes its state) = such an event has to be communicated to all interested (or active) = participants. Given the intrinsic nature of the distributed framework = (which actually expands the centralized one through the introduction of = an overlay network of focus entities), the actual flow of information = will always foresee the interaction among conference focus entities for = both conference information exchanging and state changes notifications. = The same obviously applies also to the involved natively centralized = protocols defined in the XCON framework. A suitable mechanism will be = defined by the WG, allowing for the dispatching of such centralized = messages across the DCON network. The mechanism in question must be = fully compliant with the existing operation of XCON clouds, which must = keep their local participants totally unaware of the potential = distributed nature of conferences. Conference state propagation will = take place in a number of alternative ways. For instance, each focus = might flood the received information across an inter-focus communication = mesh, thus guaranteeing that potential participants belonging to = heterogeneous islands can be reached. In such case, focus entities are = "stateful", i.e. each of them stores information about current sessions = and forwards such information to all peering entities in order to get = them up-to-date with respect to available conference sessions.=20 On the other hand, a distributed repository might be employed for the = sake of storing conference information. Focus entities would access = such repository, both to publish (either upon creation of a new = conference, or to notify a change in the state of an active conference) = and to retrieve information about active conferences (e.g. when a new = participant wants to access the list of ongoing/scheduled conference = sessions he might be interested to join). In this last case, focus = entities are "stateless". Finally, the WG will evaluate the benefits = deriving from the adoption of a pure peer-to-peer approach for the = purpose of conference state information spreading. The deliverables for the group will be: - A Framework for Distributed Conferencing (backward-compatible with = XCON in the single-cloud case) - A survey of potential solutions to the construction and maintenance of = a DCON conference repository (stateless, stateful, based on flooding, = p2p, etc.) - Requirements for an XCON-DCON Synchronization Protocol (XDSP) - Specification of the XDSP - DCON call-flows draft (involving the use of XDSP) - Goals and Milestones February 2012 --> Submit Framework document for publication as PS April 2012 --> Submit XDSP Requirements document for publication as = Informational June 2012 --> Submit survey of solutions for the DCON conference = repository for publication as Informational September 2012 --> Submit XDSP Specification document for publication as = PS January 2013 --> Submit DCON call flows draft for publication as = Informational From fluffy@cisco.com Wed Sep 21 08:35:11 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212F1F0C82 for ; Wed, 21 Sep 2011 08:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.119 X-Spam-Level: X-Spam-Status: No, score=-103.119 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg-aMjqsIPy6 for ; Wed, 21 Sep 2011 08:35:06 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CFC841F0C70 for ; Wed, 21 Sep 2011 08:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2127; q=dns/txt; s=iport; t=1316619456; x=1317829056; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5DSpiKaPRfQyOoGtkBT48c00yOutV5hixdTdUj1Xrbs=; b=mxPvBTGtyv5kYtwovwLiMmQ0fvagZrHPN7qfs4medYPqdkz372IMKY3g oiVigHo2OP0DJIWS+271O6Z3vQWhPn3d+ZScgCxb9ZWZ7v8MoKw/5QPtq TXQrk/Lu1hRHwPYu69rScdqgtLoROO0mno/KDZR9+LM5lXXVo7BhEuGmC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC0Eek6rRDoH/2dsb2JhbABCp2Z4gVQBAQQSASc/EFFXBjWeEQGeIoYdYASHcItdhR+MLw X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="3429662" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 21 Sep 2011 15:37:35 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8LFb10n014169; Wed, 21 Sep 2011 15:37:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 21 Sep 2011 09:37:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3A795A86-23FE-4CC5-8052-AA790E23EEC2@cisco.com> References: <20110822181534.B109121F850B@ietfa.amsl.com> To: DISPATCH list X-Mailer: Apple Mail (2.1084) Cc: rai-ads@tools.ietf.org Subject: [dispatch] 82nd IETF - Draft Agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 15:35:11 -0000 There will be adjustments and changes to this agenda but here are the = current straw man agenda. Things that don't have drafts will get bumped = off the agenda and things where the list discussion is not happening = might get bumped too.=20 Description of problem and requirements in SIP Continuation - 20 min=20 draft-sinha-dispatch-sip-continuation-option Requirement for 3GPP transport service interaction information - 20 min = (Christer) Proposal for Remote Call/Device Control WG - 40 min (Rifaat) A mechanism for referencing and verifying user attributes in SIP and = email - 20 min (Kumiko) Thanks, Cullen On Aug 22, 2011, at 2:44 PM, Mary Barnes wrote: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > * Sept. 5th, 2011. Cutoff date to notify the chairs/DISPATCH WG of = plans to submit a proposal. [Two weeks prior to BoF proposal deadline, 7 = weeks before -00 deadline] *2 weeks from today*=20 >=20 > * Sept. 12th, 2011. Cutoff for charter proposals for topics. [Three = weeks prior to BoF proposal deadline, two weeks before announcement of = topics] >=20 > * Sept. 26th, 2011. Topics that are to be the focus of IETF-82 are = announced. [10 days before AD BoF approval and deadline to request WG = slot, 4 weeks before -00 deadline, deadline for requesting WG session] >=20 > * October 24th, 2011. -00 draft deadline. >=20 > * October 31st, 2011. Draft deadline. >=20 >=20 >=20 > Submitting Session Agendas >=20 > For the convenience of meeting attendees, we ask that you submit the = agendas for your Working Group sessions as early as possible. Draft = Working Group agendas are due Wednesday, November 2, 2011 by 17:00 PT. = Revised Working Group agendas are due no later than Monday, November 7, = 2011 at 17:00 PT. The proposed agenda for a BOF session should be = submitted along with your request for a session. Please be sure to copy = your Area Director on that message. From spromano@unina.it Wed Sep 21 10:22:14 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C889211E8087 for ; Wed, 21 Sep 2011 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.615 X-Spam-Level: X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+s-mp6H5gFj for ; Wed, 21 Sep 2011 10:22:13 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 65DC321F85B1 for ; Wed, 21 Sep 2011 10:22:13 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p8LHObfk026906 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 21 Sep 2011 19:24:38 +0200 Message-ID: <4E7A1DD1.9080000@unina.it> Date: Wed, 21 Sep 2011 19:24:33 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> Content-Type: multipart/alternative; boundary="------------030704000705010405090205" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 17:22:15 -0000 This is a multi-part message in MIME format. --------------030704000705010405090205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Rifaat and all, as one of the main supporters of the SPLICES attempts at addressing these issues, I cannot refrain myself from strongly supporting your initiative. Reading through the charter, I see that you have clear in your mind the main issues that came out from our past discussions in the IETF (with special regard to the meeting we had in Quebec City). With respect to this, I would suggest not to mix call control with device control, unless we want to open a never-ending discussion. Cheers, Simon Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto: > > Hi, > > The following is a charter proposal for a Remote Call/Device Control WG. > > We would appreciate it if you review it and provide us with your feedback. > > Thanks, > > Rifaat > > ------- > > Remote Call/Device Control WG > > The Session Initiation Protocol (SIP) [RFC3261] provides users with > the ability to initiate, manage, and terminate multimedia sessions. > > A SIP application is a program running on a SIP network element that > provides some value-added function to a user. > > Many deployments have SIP applications in the SIP signaling path that > get involved in the setup and management of these multimedia sessions. > > Third-Party Application might also be interested in interacting with > User Agents and the setup of multimedia sessions. > > Some of these applications need a mechanism to remotely invoke some > actions or/and monitor the invocation of actions on a SIP User Agent. > > SIP allows for the invocation of actions on a remote User Agent using > the REFER method. > > The actions that can be invoked by the REFER method are limited, and > there is a need for more actions by some SIP applications. > > The purpose of this WG is to evaluate the various available mechanisms > or proposed mechanism and recommend one or more of them, > > or define a new mechanism if none of the available are good enough to > address this need. > > The work group will need to address the following: > > * Clearly answer the following questions: > > a. What is "call control"? > > b. What is "device control"? > > * Will the new mechanism address "call control", "device control" or both? > > * Will the new mechanism be a SIP or a non-SIP based mechanism? > > * If a non-SIP mechanism is used, how to deal with the fact that some > of these > > actions already covered by the SIP REFER method and widely used in > the industry > > * Define a model for the actions > > * Define a scope for the actions > > * Define a set of initial actions that can be later extended, if needed. > > * Others? > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------030704000705010405090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Rifaat and all,

as one of the main supporters of the SPLICES attempts at addressing these issues, I cannot refrain myself from strongly supporting your initiative. Reading through the charter, I see that you have clear in your mind the main issues that came out from our past discussions in the IETF (with special regard to the meeting we had in Quebec City). With respect to this, I would suggest not to mix call control with device control, unless we want to open a never-ending discussion.

Cheers,

Simon

Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto:

Hi,

 

The following is a charter proposal for a Remote Call/Device Control WG.

We would appreciate it if you review it and provide us with your feedback.

 

Thanks,

Rifaat

 

-------

 

Remote Call/Device Control WG

 

The Session Initiation Protocol (SIP) [RFC3261] provides users with the ability to initiate, manage, and terminate multimedia sessions.

A SIP application is a program running on a SIP network element that provides some value-added function to a user.

Many deployments have SIP applications in the SIP signaling path that get involved in the setup and management of these multimedia sessions.

Third-Party Application might also be interested in interacting with User Agents and the setup of multimedia sessions.

Some of these applications need a mechanism to remotely invoke some actions or/and monitor the invocation of actions on a SIP User Agent.

SIP allows for the invocation of actions on a remote User Agent using the REFER method.

The actions that can be invoked by the REFER method are limited, and there is a need for more actions by some SIP applications.

The purpose of this WG is to evaluate the various available mechanisms or proposed mechanism and recommend one or more of them,

or define a new mechanism if none of the available are good enough to address this need.

 

The work group will need to address the following:

* Clearly answer the following questions:

   a. What is "call control"?

   b. What is "device control"?

* Will the new mechanism address "call control", "device control" or both?

* Will the new mechanism be a SIP or a non-SIP based mechanism?

* If a non-SIP mechanism is used, how to deal with the fact that some of these

  actions already covered by the SIP REFER method and widely used in the industry

* Define a model for the actions

* Define a scope for the actions

* Define a set of initial actions that can be later extended, if needed.

* Others?

 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------030704000705010405090205-- From pkyzivat@alum.mit.edu Wed Sep 21 10:30:17 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C216C1F0C45 for ; Wed, 21 Sep 2011 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVPA98Yzx0fP for ; Wed, 21 Sep 2011 10:30:16 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id BF7081F0C55 for ; Wed, 21 Sep 2011 10:30:16 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id bPA31h0041ZXKqc5EVYlST; Wed, 21 Sep 2011 17:32:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id bVYk1h01f0tdiYw3hVYlHs; Wed, 21 Sep 2011 17:32:45 +0000 Message-ID: <4E7A1FBB.6010406@alum.mit.edu> Date: Wed, 21 Sep 2011 13:32:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 17:30:17 -0000 On 9/20/11 3:51 PM, Worley, Dale R (Dale) wrote: > I don't see what interoperability problems can result from the > introduction of an additional format of URN, as long as the format > adheres to the generic URN syntax. RFC 5626 section 4.1 makes it > clear that a SIP element may receive a +sip.instance value which is in > a URN namespace that it does not recognize, so any properly > constructed SIP element should be able to handle +sip.instance values > in namespaces that it does not have prior knowledge of. > > (Certainly, the one product/project that I have detailed knowledge of > has always treated +sip.instance as a string. Thereon hangs a tale: > If the +sip.instance is a UUID-based URN, and if the UUID is based on > a MAC address, the registrar extracts the MAC address so that the UA > can be addressed through a special URI that encodes its MAC address. > But it turns out that a popular make of UA formats its UUIDs > incorrectly, so that it was not recognized as a MAC-based UUID. We've > had to add special code to the registrar to recognize this defective > URN format!) Can you say more? (Or is this all proprietary?) This usage sounds bizarre. The REGISTER contains the Contact URI at which the UA wishes to be reached. What is the point of forming a different URI from the MAC? How can you know that it will work? Thanks, Paul From Hannes.Tschofenig@gmx.net Wed Sep 21 10:41:50 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0F21F854F for ; Wed, 21 Sep 2011 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXfDblMB3M8d for ; Wed, 21 Sep 2011 10:41:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2059B1F0C84 for ; Wed, 21 Sep 2011 10:41:48 -0700 (PDT) Received: (qmail 30196 invoked by uid 0); 21 Sep 2011 17:44:15 -0000 Received: from 88.115.210.23 by rms-de006.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary8851316627054690461" Date: Wed, 21 Sep 2011 19:44:14 +0200 From: "Hannes Tschofenig" Message-ID: <20110921174414.8850@gmx.net> MIME-Version: 1.0 To: "Paul Kyzivat" ,dispatch@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: D04RJjxWTlI8UJsGtWlrQphOU2poZVkl Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 17:41:50 -0000 --========GMXBoundary8851316627054690461 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hope I understand the proposal correctly but putting a MAC address in a URI is from a privacy point of view a bad idea. We got a lot of feedback when a MAC address was put into the IPv6 interface identifier. The result was the work on RFC 3041, which was later obsoleted by RFC 4941. ----- Ursprüngliche Nachricht ----- Von: Paul Kyzivat Gesendet: 21.09.11 20:32 Uhr An: dispatch@ietf.org Betreff: [dispatch] Deriving URI from MAC-based URN ??? On 9/20/11 3:51 PM, Worley, Dale R (Dale) wrote: > I don't see what interoperability problems can result from the > introduction of an additional format of URN, as long as the format > adheres to the generic URN syntax. RFC 5626 section 4.1 makes it > clear that a SIP element may receive a +sip.instance value which is in > a URN namespace that it does not recognize, so any properly > constructed SIP element should be able to handle +sip.instance values > in namespaces that it does not have prior knowledge of. > > (Certainly, the one product/project that I have detailed knowledge of > has always treated +sip.instance as a string. Thereon hangs a tale: > If the +sip.instance is a UUID-based URN, and if the UUID is based on > a MAC address, the registrar extracts the MAC address so that the UA > can be addressed through a special URI that encodes its MAC address. > But it turns out that a popular make of UA formats its UUIDs > incorrectly, so that it was not recognized as a MAC -based UUID. We've > had to add special code to the registrar to recognize this defective > URN format!) Can you say more? (Or is this all proprietary?) This usage sounds bizarre. The REGISTER contains the Contact URI at which the UA wishes to be reached. What is the point of forming a different URI from the MAC? How can you know that it will work? Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --========GMXBoundary8851316627054690461 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hope I u= nderstand the proposal correctly but putting a MAC address in a URI is from= a privacy point of view a bad idea. We got a lot of feedback when a MAC ad= dress was put into the IPv6 interface identifier. The result was the work o= n RFC 3041, which was later obsoleted by RFC 4941.
=20

=20 =C2=A0

=20
=20

=20 ----- = Urspr=C3=BCngliche Nachricht -----

=20

=20 Von: P= aul Kyzivat

=20

=20 Gesend= et: 21.09.11 20:32 Uhr

=20

=20 An: di= spatch@ietf.org

=20

=20 Betref= f: [dispatch] Deriving URI from MAC-based URN ???

=20
=20
=20
=20 
=20
On 9/20/11 3:51 PM, Worley, Dale R (Dale) wrote:=20

> I don't see what interoperability problems can result from the=20
> introduction of an additional format of URN, as long as the format=20
> adheres to the generic URN syntax.  RFC 5626 section 4.1 makes it=20
> clear that a SIP element may receive a +sip.instance value which is in=
=20
> a URN namespace that it does not recognize, so any properly=20
> constructed SIP element should be able to handle +sip.instance values=
=20
> in namespaces that it does not have prior knowledge of.=20
>=20
> (Certainly, the one product/project that I have detailed knowledge of=
=20
> has always treated +sip.instance as a string.  Thereon hangs a tale:=
=20
> If the +sip.instance is a UUID-based URN, and if the UUID is based on=
=20
> a MAC address, the registrar extracts the MAC address so that the UA=
=20
> can be addressed through a special URI that encodes its MAC address.=
=20
> But it turns out that a popular make of UA formats its UUIDs=20
> incorrectly, so that it was not recognized as a MAC-based UUID.  We've=
=20
> had to add special code to the registrar to recognize this defective=
=20
> URN format!)=20

Can you say more? (Or is this all proprietary?)=20
This usage sounds bizarre. The REGISTER contains the Contact URI at=20
which the UA wishes to be reached. What is the point of forming a=20
different URI from the MAC? How can you know that it will work?=20

	Thanks,=20
	Paul=20
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch
=20
=20
=20
=20

=20 =C2=A0

=20 --========GMXBoundary8851316627054690461-- From dworley@avaya.com Wed Sep 21 11:21:03 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBF21F0C4D for ; Wed, 21 Sep 2011 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Kgzp3ltYyRf for ; Wed, 21 Sep 2011 11:21:02 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 47A981F0C45 for ; Wed, 21 Sep 2011 11:20:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPgqek6HCzI1/2dsb2JhbAA4Cg6nW3iBUwEBAQECARIdC0QJAgIBCA0BBxkCBhAbFyUBAQQBEggTB4dVBpkwAps9AoNTGwUHgiFgBJkLizpT X-IronPort-AV: E=Sophos;i="4.68,418,1312171200"; d="scan'208";a="208848444" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Sep 2011 14:23:24 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Sep 2011 14:13:58 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 21 Sep 2011 14:23:24 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "dispatch@ietf.org" Date: Wed, 21 Sep 2011 14:23:24 -0400 Thread-Topic: [dispatch] Deriving URI from MAC-based URN ??? Thread-Index: Acx4hH2ODffkKnBRQUeZvOF+wX5mqwAAj85E Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> In-Reply-To: <4E7A1FBB.6010406@alum.mit.edu> 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 Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 18:21:03 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > Can you say more? (Or is this all proprietary?) > This usage sounds bizarre. The REGISTER contains the Contact URI at > which the UA wishes to be reached. What is the point of forming a > different URI from the MAC? How can you know that it will work? All of this is in open-source versions of sipX, so it's not proprietary. Remember, sipX is a PBX, so it is in environment that is not particularly sensitive for privacy and security, but conversely, it has to service various needs that do not arise in wider-scale communications. In this case, we discovered that we want to be able to address "all the line appearances on a phone" and also "a particular line appearance on a particular phone". Situations where these are useful include: - Ordering a particular phone to reboot when the provisioning system has revised the configuration files that it should load. - Being able to drive a BLF light with "Is the boss's phone busy?" (In the common case where the assistant's phone also has an appearance of the boss's extension (AOR), a BLF light on the assistant's phone that reports whether the boss's AOR is busy is not particularly useful, since most of the times when the assistant needs to know if the boss is on the phone are when the assistant is talking to a caller on the boss's AOR.) Of course, the registered contacts for the phone can be used for these purposes, but the contact URIs are dynamic, which makes them hard to, e.g., insert in a BLF "resource list". The solution is to define a series of special URIs that are mapped through the registration database *in different ways* than AORs are mapped. In our implementation (see http://sipxecs.sipfoundry.org/rep/sipXecs/main/meta/system-sip-identities): - sip:~~in~[MAC address]@[domain] is mapped to all contacts registered by the phone with the specified MAC address. - sip:~~in~[user name]&[MAC address]@[domain] is mapped to all contacts registered for the specified SIP user name by the phone with the specified MAC address. As a mathematician, I want to add for completeness: - sip:[user name]@[domain] is mapped to all contacts registered for the specified SIP user name. During registration, the registrar extracts from the REGISTER request the MAC address of the phone, via: - If +sip.instance is given, and its value is a URN derived from a UUID, and the UUID is based on a MAC address, that MAC address is used. - If that fails, the "authentication user" from the Authorization header is examined to see if it has the form [user name]/[MAC address]. If so, the MAC address is used (and the user name part is used to look up the password). (This form is useful if the phone does not provide +sip.instance, as all phones allow the arbitrary configuration of the authentication user.) Thus, for instance, if the provisioning system has generated new configuration files for the phone with MAC address 0123456789ab, it can send a NOTIFY for "Event: check-sync" to URI sip:~~in~0123456789ab@[domain]. Previously, the provisioning system sent the NOTIFY to the AOR of the first line appearance on the phone, which often rebooted more phones than needed to be rebooted. If an assistant wants a BLF for "Is the boss's phone busy?", the BLF URI can be sip:~~in~[boss's MAC address]@[domain]. Conveniently, that monitors *all* of the boss's line appearances, even if he has more than one AOR on his phone. More narrowly, each line appearance on the boss's phone can be monitored separately with URIs of the form sip:~~in~[user name]&[boss's MAC address]@[domain]. I suppose that in abstract the same functionality can be implemented by the various subsystems examining the registration database themselves, e.g., the provisioning system could look up the current contact of phone 0123456789ab itself. But sipX is not a monolithic system, it is a set of processes that communicate via SIP, and the registration lookups are done entirely by the redirection facility of the proxy/registrar. So the provisioning system would rather not have to dig through the registration database itself. Instead, we give it a set of URIs it can use to request that the redirector does the desired lookup. In no case does a phone use these URIs to identify itself, so there isn't much of a privacy problem. They do allow a caller to more finely control routing of his call, but a caller can often obtain the same effect by placing a call to a Contact saved from a previous dialog. Dale From pkyzivat@alum.mit.edu Wed Sep 21 16:15:14 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71B621F8CCC for ; Wed, 21 Sep 2011 16:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qog1jhkex8nv for ; Wed, 21 Sep 2011 16:15:13 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8806E21F8CCB for ; Wed, 21 Sep 2011 16:15:13 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id bXwX1h0031ei1Bg57bHk2u; Wed, 21 Sep 2011 23:17:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id bbHj1h0080tdiYw3kbHjCC; Wed, 21 Sep 2011 23:17:43 +0000 Message-ID: <4E7A7095.2090203@alum.mit.edu> Date: Wed, 21 Sep 2011 19:17:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:15:14 -0000 OK, what you describe isn't as disturbing to me as what I thought at first. What you are saying is that the registrar/proxy is *deriving* some added AORs, and location db for them, from from properties of the registered contacts. The names of these added AORs are defined by convention. The only thing I find wrong with that is that the anyone wanting to use those AORs must know the convention. Given the unfriendliness of the names, I presume that they aren't typically entered by humans - but rather are derived by software that understands the convention. Any such software is of course then dependent on the registrar following these conventions. For instance, if I had a softphone with a BLF light that I wanted to use as the secretary's phone in the case you describe below, it would need to be customized for this convention before it would work right. While this is a potential interoperability problem, its not likely to be much of a problem in practice, at least as things are typically deployed. Thanks, Paul On 9/21/11 2:23 PM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> Can you say more? (Or is this all proprietary?) >> This usage sounds bizarre. The REGISTER contains the Contact URI at >> which the UA wishes to be reached. What is the point of forming a >> different URI from the MAC? How can you know that it will work? > > All of this is in open-source versions of sipX, so it's not > proprietary. > > Remember, sipX is a PBX, so it is in environment that is not > particularly sensitive for privacy and security, but conversely, it > has to service various needs that do not arise in wider-scale > communications. > > In this case, we discovered that we want to be able to address "all > the line appearances on a phone" and also "a particular line > appearance on a particular phone". Situations where these are useful > include: > > - Ordering a particular phone to reboot when the provisioning system > has revised the configuration files that it should load. > > - Being able to drive a BLF light with "Is the boss's phone busy?" > (In the common case where the assistant's phone also has an > appearance of the boss's extension (AOR), a BLF light on the > assistant's phone that reports whether the boss's AOR is busy is not > particularly useful, since most of the times when the assistant > needs to know if the boss is on the phone are when the assistant is > talking to a caller on the boss's AOR.) > > Of course, the registered contacts for the phone can be used for these > purposes, but the contact URIs are dynamic, which makes them hard to, > e.g., insert in a BLF "resource list". > > The solution is to define a series of special URIs that are mapped > through the registration database *in different ways* than AORs are > mapped. In our implementation (see > http://sipxecs.sipfoundry.org/rep/sipXecs/main/meta/system-sip-identities): > > - sip:~~in~[MAC address]@[domain] is mapped to all contacts registered > by the phone with the specified MAC address. > > - sip:~~in~[user name]&[MAC address]@[domain] is mapped to all contacts > registered for the specified SIP user name by the phone with the > specified MAC address. > > As a mathematician, I want to add for completeness: > > - sip:[user name]@[domain] is mapped to all contacts registered for > the specified SIP user name. > > During registration, the registrar extracts from the REGISTER request > the MAC address of the phone, via: > > - If +sip.instance is given, and its value is a URN derived from a > UUID, and the UUID is based on a MAC address, that MAC address is > used. > > - If that fails, the "authentication user" from the Authorization > header is examined to see if it has the form [user name]/[MAC > address]. If so, the MAC address is used (and the user name part is > used to look up the password). (This form is useful if the phone > does not provide +sip.instance, as all phones allow the > arbitrary configuration of the authentication user.) > > Thus, for instance, if the provisioning system has generated new > configuration files for the phone with MAC address 0123456789ab, it > can send a NOTIFY for "Event: check-sync" to URI > sip:~~in~0123456789ab@[domain]. Previously, the provisioning system > sent the NOTIFY to the AOR of the first line appearance on the phone, > which often rebooted more phones than needed to be rebooted. > > If an assistant wants a BLF for "Is the boss's phone busy?", the BLF > URI can be sip:~~in~[boss's MAC address]@[domain]. Conveniently, that > monitors *all* of the boss's line appearances, even if he has more > than one AOR on his phone. > > More narrowly, each line appearance on the boss's phone can be > monitored separately with URIs of the form sip:~~in~[user > name]&[boss's MAC address]@[domain]. > > I suppose that in abstract the same functionality can be implemented > by the various subsystems examining the registration database themselves, > e.g., the provisioning system could look up the current contact of phone > 0123456789ab itself. But sipX is not a monolithic system, it is a set of > processes that communicate via SIP, and the registration lookups are > done entirely by the redirection facility of the proxy/registrar. So the > provisioning system would rather not have to dig through the registration > database itself. Instead, we give it a set of URIs it can use to request > that the redirector does the desired lookup. > > In no case does a phone use these URIs to identify itself, so there > isn't much of a privacy problem. They do allow a caller to more > finely control routing of his call, but a caller can often obtain the > same effect by placing a call to a Contact saved from a previous > dialog. > > Dale > From dworley@avaya.com Thu Sep 22 08:24:24 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935D021F8C8C for ; Thu, 22 Sep 2011 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.459 X-Spam-Level: X-Spam-Status: No, score=-104.459 tagged_above=-999 required=5 tests=[AWL=1.140, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcpSGStV+9BV for ; Thu, 22 Sep 2011 08:24:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9F21F8C8B for ; Thu, 22 Sep 2011 08:24:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADtTe06HCzI1/2dsb2JhbAA5CQ6lVIIeeIFTAQEBAQIBEig/BQsCAQgNAQchEDIlAQEEDgUIGodWmUcCm0KDVoJHYASZDos6Uw X-IronPort-AV: E=Sophos;i="4.68,424,1312171200"; d="scan'208";a="305151816" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Sep 2011 11:26:55 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Sep 2011 11:17:27 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 22 Sep 2011 11:26:55 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Thu, 22 Sep 2011 11:26:54 -0400 Thread-Topic: [dispatch] Deriving URI from MAC-based URN ??? Thread-Index: Acx4tKqacFsdl08QT4WCRLVdcWMAxwAhmPua Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> In-Reply-To: <4E7A7095.2090203@alum.mit.edu> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 15:24:24 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > The only thing I find wrong with that is that the anyone wanting to use > those AORs must know the convention.=20 Yes... If you want to call Joe, you have to know his name, phone number, or some such. If you want status information on a particular line appearance, you have to know how to specify it. > Given the unfriendliness of the names, I presume that they aren't > typically entered by humans - but rather are derived by software that > understands the convention. In general, we do expect most uses of special URIs to be software-generated, although one can use them manually, too. The biggest constraint is that we needed to define a syntax that would allow the creation of many series of special URIs (there are 10 now in use) and minimize the risk of collision with "legitimate" user names/phone numbers. So the syntax "~~[letter][letter]~[arbitrary]" was reserved for special purpose user names, and the provisioning system prevents administrators from creating names that start with "~~". The prefix "~~in~" is thus used for "instrument identity user names". > While this is a potential interoperability problem, its not likely > to be much of a problem in practice, at least as things are > typically deployed. It's not clear to me how this could lead to an interoperability problem, as the PBX is the authority for the use of user names within its own domain. Dale From rifatyu@avaya.com Thu Sep 22 09:17:10 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE3A21F84FA for ; Thu, 22 Sep 2011 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwtjZX65qZHw for ; Thu, 22 Sep 2011 09:17:09 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF2121F85F1 for ; Thu, 22 Sep 2011 09:17:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAACdfe06HCzI1/2dsb2JhbABCgk2WPY53eIFTAQEBAQMBAQEPG0ELDgICAQgNBAQBASgHGwwLFAkIAQEEDgUIGodcmUUCmz0ChhtgBIdBkU2MDQ X-IronPort-AV: E=Sophos;i="4.68,424,1312171200"; d="scan'208,217";a="209046835" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Sep 2011 12:19:39 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Sep 2011 12:10:10 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 22 Sep 2011 12:19:38 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Simon Pietro Romano Date: Thu, 22 Sep 2011 12:19:37 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx4g1p7KX0EV8YFRzK44b/lgQ94UQAv2MmA Message-ID: <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> In-Reply-To: <4E7A1DD1.9080000@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822D1D2C895DCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 16:17:11 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822D1D2C895DCUS1MBEX4glo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Simon, >With respect to this, I would suggest not to mix call control with device = control, unless we want to open a never-ending discussion. I was not trying to suggest that the same protocol would be used for call &= device control, quite the opposite. Is that your concern? Or you are saying that the WG should deal with only either call control OR = device control, but not both? Regards, Rifaat From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: Wednesday, September 21, 2011 1:25 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG Hi Rifaat and all, as one of the main supporters of the SPLICES attempts at addressing these i= ssues, I cannot refrain myself from strongly supporting your initiative. Re= ading through the charter, I see that you have clear in your mind the main = issues that came out from our past discussions in the IETF (with special re= gard to the meeting we had in Quebec City). With respect to this, I would s= uggest not to mix call control with device control, unless we want to open = a never-ending discussion. Cheers, Simon Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto: Hi, The following is a charter proposal for a Remote Call/Device Control WG. We would appreciate it if you review it and provide us with your feedback. Thanks, Rifaat ------- Remote Call/Device Control WG The Session Initiation Protocol (SIP) [RFC3261] provides users with the abi= lity to initiate, manage, and terminate multimedia sessions. A SIP application is a program running on a SIP network element that provid= es some value-added function to a user. Many deployments have SIP applications in the SIP signaling path that get i= nvolved in the setup and management of these multimedia sessions. Third-Party Application might also be interested in interacting with User A= gents and the setup of multimedia sessions. Some of these applications need a mechanism to remotely invoke some actions= or/and monitor the invocation of actions on a SIP User Agent. SIP allows for the invocation of actions on a remote User Agent using the R= EFER method. The actions that can be invoked by the REFER method are limited, and there = is a need for more actions by some SIP applications. The purpose of this WG is to evaluate the various available mechanisms or p= roposed mechanism and recommend one or more of them, or define a new mechanism if none of the available are good enough to addre= ss this need. The work group will need to address the following: * Clearly answer the following questions: a. What is "call control"? b. What is "device control"? * Will the new mechanism address "call control", "device control" or both? * Will the new mechanism be a SIP or a non-SIP based mechanism? * If a non-SIP mechanism is used, how to deal with the fact that some of th= ese actions already covered by the SIP REFER method and widely used in the in= dustry * Define a model for the actions * Define a scope for the actions * Define a set of initial actions that can be later extended, if needed. * Others? _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --_000_6369CB70BFD88942B9705AC1E639A33822D1D2C895DCUS1MBEX4glo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Hi Simon,

 

>With respect to this, I would suggest not to mix call cont= rol with device control, unless we want to open a never-ending discussion.<= br>I was not trying to suggest that the same = protocol would be used for call & device control, quite the opposite. I= s that your concern?

Or you are saying that the WG should deal with only eith= er call control OR device control, but not both?

 

<= p class=3DMsoNormal>Regards,

Rifaat<= /span>

 

 = ;

Fr= om: Simon Pietro Romano [mailto:spromano@unina.it]
= Sent: Wednesday, September 21, 2011 1:25 PM
To: Shekh-Yuse= f, Rifaat (Rifaat)
Cc: dispatch@ietf.org
Subject: Re: [= dispatch] Charter Proposal - Remote Call/Device Control WG

 

Hi Rifaat and all,

as one of the main supporters of the SPLICES= attempts at addressing these issues, I cannot refrain myself from strongly= supporting your initiative. Reading through the charter, I see that you ha= ve clear in your mind the main issues that came out from our past discussio= ns in the IETF (with special regard to the meeting we had in Quebec City). = With respect to this, I would suggest not to mix call control with device c= ontrol, unless we want to open a never-ending discussion.

Cheers,
Simon

Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scri= tto:

Hi,

 

The following is a = charter proposal for a Remote Call/Device Control WG.

We would appreciate it if you review it and provide us wit= h your feedback.

 

Thanks,

Rifa= at

 

-------

 <= /p>

Remote Call/Device Control WG

 

The Sessio= n Initiation Protocol (SIP) [RFC3261] provides users with the ability to in= itiate, manage, and terminate multimedia sessions.

A SIP application is a program running on a SIP network ele= ment that provides some value-added function to a user.

Many deployments have SIP applications in the SIP signal= ing path that get involved in the setup and management of these multimedia = sessions.

Third-Party Application mi= ght also be interested in interacting with User Agents and the setup of mul= timedia sessions.

Some of these appli= cations need a mechanism to remotely invoke some actions or/and monitor the= invocation of actions on a SIP User Agent.

SIP allows for the invocation of actions on a remote User Agent usi= ng the REFER method.

The actions tha= t can be invoked by the REFER method are limited, and there is a need for m= ore actions by some SIP applications.

The purpose of this WG is to evaluate the various available mechanisms or = proposed mechanism and recommend one or more of them,

or define a new mechanism if none of the available are go= od enough to address this need.

 = ;

The work group will need to address= the following:

* Clearly answer the = following questions:

   a. = What is "call control"?

&nb= sp;  b. What is "device control"?

* Will the new mechanism address "call control", &quo= t;device control" or both?

* Wil= l the new mechanism be a SIP or a non-SIP based mechanism?

* If a non-SIP mechanism is used, how to deal with th= e fact that some of these

  acti= ons already covered by the SIP REFER method and widely used in the industry=

* Define a model for the actions

* Define a scope for the actions

* Define a set of initial actions that can b= e later extended, if needed.

* Others= ?

 

&nbs=
p;
 
____________________________=
___________________
dispatch mailing list
dispatch@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/dispatch


-- 
=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0_\\|//_
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ( O-O )
=A0=A0=
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Simon Piet=
ro Romano
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Univ=
ersita' di Napoli Federico II
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 Computer Science Department 
=
=A0=A0=A0=A0=A0=A0=A0=A0Phone: +39 081 7683823 -- Fax: +39 081 7684219=

 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0e-mail: spromano@unina.it
=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.comics.unina.it/simonpietro.romano
 
=A0=A0=A0 <<Molti mi dicono che l=
o scoraggiamento =E8 l'alibi degli 
=A0=A0=A0idioti. C=
i rifletto un istante; e mi scoraggio>>. Magritte.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 oooO
=A0=A0 ~~~~~~~~~~~~~~~~~~~~~~(=A0=A0 )~~ Oooo~~~=
~~~~~~~~~~~~~~~~~~~~~~
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \ (=A0=A0=A0 (=A0=A0 )
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 \_)=A0=A0=A0 ) /
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0(_/
 
= --_000_6369CB70BFD88942B9705AC1E639A33822D1D2C895DCUS1MBEX4glo_-- From pkyzivat@alum.mit.edu Thu Sep 22 10:22:53 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F7F21F8B94 for ; Thu, 22 Sep 2011 10:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAxA7MLFWGW6 for ; Thu, 22 Sep 2011 10:22:52 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 220EE21F8B64 for ; Thu, 22 Sep 2011 10:22:51 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id bmMG1h0011vXlb851tRQ60; Thu, 22 Sep 2011 17:25:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id btRP1h01i0tdiYw3dtRQ8W; Thu, 22 Sep 2011 17:25:24 +0000 Message-ID: <4E7B6F81.20305@alum.mit.edu> Date: Thu, 22 Sep 2011 13:25:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 17:22:53 -0000 On 9/22/11 11:26 AM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> The only thing I find wrong with that is that the anyone wanting to use >> those AORs must know the convention. > > Yes... If you want to call Joe, you have to know his name, phone > number, or some such. If you want status information on a particular > line appearance, you have to know how to specify it. My general philosophy is that URIs are determined by the recipient, and conveyed to those that will use them. While its possible to "guess" URIs, there are in general no guarantees that doing so will get the result you intend. In some realms there are conventions about how URIs are constructed, making it possible to guess with higher confidence, *if* you know the convention for that realm. That's what I see here - a realm with a convention that facilitates guessing, to those that are clued in to it. >> Given the unfriendliness of the names, I presume that they aren't >> typically entered by humans - but rather are derived by software that >> understands the convention. > > In general, we do expect most uses of special URIs to be > software-generated, although one can use them manually, too. The > biggest constraint is that we needed to define a syntax that would > allow the creation of many series of special URIs (there are 10 now in > use) and minimize the risk of collision with "legitimate" user > names/phone numbers. > > So the syntax "~~[letter][letter]~[arbitrary]" was reserved for > special purpose user names, and the provisioning system prevents > administrators from creating names that start with "~~". > > The prefix "~~in~" is thus used for "instrument identity user names". > >> While this is a potential interoperability problem, its not likely >> to be much of a problem in practice, at least as things are >> typically deployed. > > It's not clear to me how this could lead to an interoperability > problem, as the PBX is the authority for the use of user names within > its own domain. An example of when the interop problem would arise is if I introduce a new phone into a system that has this convention. I then may have to modify it to take advantage of this convention (to get its lights to work in the proper cases.) Then later, if the phone system gets swapped out for one that doesn't support the same convention, the phone's feature will no longer work. Its an interop problem because it is non-standard behavior. Its not an issue as long as you stick to standardized behavior. Thanks, Paul From adam@nostrum.com Thu Sep 22 10:32:33 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024FE21F8AE6 for ; Thu, 22 Sep 2011 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2UQbhAAcYVk for ; Thu, 22 Sep 2011 10:32:32 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D71F21F8AB8 for ; Thu, 22 Sep 2011 10:32:31 -0700 (PDT) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8MHZ1t2053645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 12:35:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E7B71C5.9010905@nostrum.com> Date: Thu, 22 Sep 2011 12:35:01 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> Content-Type: multipart/alternative; boundary="------------020001090709080508040205" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 17:32:33 -0000 This is a multi-part message in MIME format. --------------020001090709080508040205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi Simon, > > >With respect to this, I would suggest not to mix call control with > device control, unless we want to open a never-ending discussion. > I was not trying to suggest that the same protocol would be used for > call & device control, quite the opposite. Is that your concern? > > Or you are saying that the WG should deal with only either call > control OR device control, but not both? > > I think you need to work through use cases first, and then determine whether they can all be accomplished through call control alone. Or through just device control. Or if you need a combination of both to satisfy the use cases that people interested in this work have in mind. In other words, I think it would be foolish to charter a working group with an answer, and then work towards finding questions that fit the answer. /a --------------020001090709080508040205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hi Simon,

 

>With respect to this, I would suggest not to mix call control with device control, unless we want to open a never-ending discussion.
I was not trying to suggest that the same protocol would be used for call & device control, quite the opposite. Is that your concern?

Or you are saying that the WG should deal with only either call control OR device control, but not both?

 


I think you need to work through use cases first, and then determine whether they can all be accomplished through call control alone. Or through just device control. Or if you need a combination of both to satisfy the use cases that people interested in this work have in mind.

In other words, I think it would be foolish to charter a working group with an answer, and then work towards finding questions that fit the answer.

/a
--------------020001090709080508040205-- From dworley@avaya.com Thu Sep 22 11:35:02 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF64C1F0C3C for ; Thu, 22 Sep 2011 11:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92+YFek+vPGM for ; Thu, 22 Sep 2011 11:35:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 27C861F0C5D for ; Thu, 22 Sep 2011 11:35:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAO5/e06HCzI1/2dsb2JhbABCqAJ4gVMBAQEBAgESKEQLAgEIDQghEDIlAQEEARIIGodWmX0CmzuGHWAEmQ6MDQ X-IronPort-AV: E=Sophos;i="4.68,424,1312171200"; d="scan'208";a="305199082" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Sep 2011 14:37:33 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Sep 2011 14:28:04 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 22 Sep 2011 14:37:33 -0400 From: "Worley, Dale R (Dale)" To: "Shekh-Yusef, Rifaat (Rifaat)" , "dispatch@ietf.org" Date: Thu, 22 Sep 2011 14:33:24 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx3xD58K/QCxy77RU+NJxPPpra6SQBkd2P0 Message-ID: References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> 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 Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:35:02 -0000 > From: Shekh-Yusef, Rifaat (Rifaat) [rifatyu@avaya.com] >=20 > The following is a charter proposal for a Remote Call/Device Control WG. > We would appreciate it if you review it and provide us with your feedback= . I think this is a valuable effort to proceed with. I'm not deeply concerned with the details of the charter, because we can (and probably will) adjust them later. But I think that we now know, at the highest level, the critical questions that must be investigated. What is needed next is an environment where we can explore use cases, functionality, proposed mechanisms, and implementation consequences -- that is, a working group. Dale From dworley@avaya.com Thu Sep 22 11:40:45 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264521F0C5D for ; Thu, 22 Sep 2011 11:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXZEY7+twqXM for ; Thu, 22 Sep 2011 11:40:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A219D1F0C3C for ; Thu, 22 Sep 2011 11:40:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABmBe07GmAcF/2dsb2JhbABCDqd0eIFTAQEBAQIBEig/BQsCAQgNAQchEDIlAQEEDgUIGodWmgACmzuGHWAEmQ6LOlM X-IronPort-AV: E=Sophos;i="4.68,424,1312171200"; d="scan'208";a="305200376" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Sep 2011 14:43:16 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Sep 2011 14:42:33 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 22 Sep 2011 14:43:15 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Thu, 22 Sep 2011 14:40:42 -0400 Thread-Topic: [dispatch] Deriving URI from MAC-based URN ??? Thread-Index: Acx5TJ2cLmpTjGhtTiyeAqk12bff8wACoOd/ Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> In-Reply-To: <4E7B6F81.20305@alum.mit.edu> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:40:45 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > An example of when the interop problem would arise is if I introduce a > new phone into a system that has this convention. I then may have to > modify it to take advantage of this convention (to get its lights to > work in the proper cases.) Then later, if the phone system gets swapped > out for one that doesn't support the same convention, the phone's > feature will no longer work. You don't have to modify the phone to use this convention, you just have to give the phone the proper URIs for each BLF light, matching what status you want the BLF light to report. These URIs are, after all, syntactically correct. Dale From pkyzivat@alum.mit.edu Thu Sep 22 12:17:27 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9802E21F8C16 for ; Thu, 22 Sep 2011 12:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBn+Mf-wMNqd for ; Thu, 22 Sep 2011 12:17:27 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id DCB0821F8C11 for ; Thu, 22 Sep 2011 12:17:26 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id bmVR1h0071ZXKqc51vKzG4; Thu, 22 Sep 2011 19:19:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id bvKy1h01Z0tdiYw3hvKzCt; Thu, 22 Sep 2011 19:19:59 +0000 Message-ID: <4E7B8A5C.4080307@alum.mit.edu> Date: Thu, 22 Sep 2011 15:19:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 19:17:27 -0000 On 9/22/11 2:40 PM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> An example of when the interop problem would arise is if I introduce a >> new phone into a system that has this convention. I then may have to >> modify it to take advantage of this convention (to get its lights to >> work in the proper cases.) Then later, if the phone system gets swapped >> out for one that doesn't support the same convention, the phone's >> feature will no longer work. > > You don't have to modify the phone to use this convention, you just > have to give the phone the proper URIs for each BLF light, matching > what status you want the BLF light to report. These URIs are, after > all, syntactically correct. You can just configure the phone as you say, IF: - the phone has a configurable light - the light can be configured with a URI - the phone determines the light status by using the URI in the way intended by the target of that URI AFAIK all of those are unusual properties, except for the specific equipment that currently supports it. If I have some "other" phone I am out of luck unless I am in a position to modify it in that way. I'm not saying that any of this is a bad thing to do. I'm just saying that it is still in the realm of proprietary systems. Conceivably it could be expanded into a standard, but nobody seems to be working on that. Thanks, Paul From rifatyu@avaya.com Thu Sep 22 13:34:14 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0A1F0C68 for ; Thu, 22 Sep 2011 13:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.029 X-Spam-Level: X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAu2y3Kdomgr for ; Thu, 22 Sep 2011 13:34:13 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1A22F1F0C63 for ; Thu, 22 Sep 2011 13:34:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAABace06HCzI1/2dsb2JhbABCgk2WPo53eIFTAQEBAQMSG0wQAgEIDQQEAQEoBzIUCQgBAQQOBQgaoVgCmz2GHWAEmQ6MDQ X-IronPort-AV: E=Sophos;i="4.68,425,1312171200"; d="scan'208,217";a="209101839" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Sep 2011 16:36:31 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Sep 2011 16:27:02 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 22 Sep 2011 16:36:30 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Adam Roach Date: Thu, 22 Sep 2011 16:36:29 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx5TfbfU46gWIdyT0SARxxIjRCBsgAGMwCA Message-ID: <6369CB70BFD88942B9705AC1E639A33822D1D2CC4E@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> <4E7B71C5.9010905@nostrum.com> In-Reply-To: <4E7B71C5.9010905@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822D1D2CC4EDCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 20:34:14 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822D1D2CC4EDCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >In other words, I think it would be foolish to charter a working group wit= h an answer, and then work towards finding questions that fit the answer. The current charter is mainly a list of open questions; I do not see any an= swers in there. Do you? Rifaat From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, September 22, 2011 1:35 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: Simon Pietro Romano; dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote: Hi Simon, >With respect to this, I would suggest not to mix call control with device = control, unless we want to open a never-ending discussion. I was not trying to suggest that the same protocol would be used for call &= device control, quite the opposite. Is that your concern? Or you are saying that the WG should deal with only either call control OR = device control, but not both? I think you need to work through use cases first, and then determine whethe= r they can all be accomplished through call control alone. Or through just = device control. Or if you need a combination of both to satisfy the use cas= es that people interested in this work have in mind. In other words, I think it would be foolish to charter a working group with= an answer, and then work towards finding questions that fit the answer. /a --_000_6369CB70BFD88942B9705AC1E639A33822D1D2CC4EDCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= >= In other words, I think it would be foolish to charter a working group with= an answer, and then work towards finding questions that fit the answer.The current charter is mainly a list = of open questions; I do not see any answers in there. Do you?

 

Rifaat<= /o:p>

&nb= sp;

 

From: Adam Roach [mailto:adam@nostrum.com]
Se= nt: Thursday, September 22, 2011 1:35 PM
To: Shekh-Yusef, Rif= aat (Rifaat)
Cc: Simon Pietro Romano; dispatch@ietf.org
Sub= ject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG

 

<= p class=3DMsoNormal>On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) = wrote:

Hi Simon,

 

>With respect to = this, I would suggest not to mix call control with device control, unless w= e want to open a never-ending discussion.
= I was not trying to suggest that the same protocol would be used for call &= amp; device control, quite the opposite. Is that your concern? =

Or you are say= ing that the WG should deal with only either call control OR device control= , but not both?

 


I think you= need to work through use cases first, and then determine whether they can = all be accomplished through call control alone. Or through just device cont= rol. Or if you need a combination of both to satisfy the use cases that peo= ple interested in this work have in mind.

In other words, I think it= would be foolish to charter a working group with an answer, and then work = towards finding questions that fit the answer.

/a<= /p>

= --_000_6369CB70BFD88942B9705AC1E639A33822D1D2CC4EDCUS1MBEX4glo_-- From adam@nostrum.com Thu Sep 22 13:39:07 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ECC11E80A6 for ; Thu, 22 Sep 2011 13:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y44fKh9WFWk for ; Thu, 22 Sep 2011 13:39:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F14B11E808F for ; Thu, 22 Sep 2011 13:39:06 -0700 (PDT) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8MKfanF077523 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 15:41:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E7B9D80.6040601@nostrum.com> Date: Thu, 22 Sep 2011 15:41:36 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> <4E7B71C5.9010905@nostrum.com> <6369CB70BFD88942B9705AC1E639A33822D1D2CC4E@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1D2CC4E@DC-US1MBEX4.global.avaya.com> Content-Type: multipart/alternative; boundary="------------020602060203000003070706" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 20:39:07 -0000 This is a multi-part message in MIME format. --------------020602060203000003070706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/22/11 15:36, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >In other words, I think it would be foolish to charter a working group > with an answer, and then work towards finding questions that fit the > answer. > The current charter is mainly a list of open questions; I do not see > any answers in there. Do you? > I was responding to your query regarding pursuing "call control OR device control, but not both." Basically, my statement was: "If you're considering such a change to the charter text, stop." /a > Rifaat > > *From:*Adam Roach [mailto:adam@nostrum.com] > *Sent:* Thursday, September 22, 2011 1:35 PM > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* Simon Pietro Romano; dispatch@ietf.org > *Subject:* Re: [dispatch] Charter Proposal - Remote Call/Device Control WG > > On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Hi Simon, > > >With respect to this, I would suggest not to mix call control with > device control, unless we want to open a never-ending discussion. > I was not trying to suggest that the same protocol would be used for > call & device control, quite the opposite. Is that your concern? > > Or you are saying that the WG should deal with only either call > control OR device control, but not both? > > > I think you need to work through use cases first, and then determine > whether they can all be accomplished through call control alone. Or > through just device control. Or if you need a combination of both to > satisfy the use cases that people interested in this work have in mind. > > In other words, I think it would be foolish to charter a working group > with an answer, and then work towards finding questions that fit the > answer. > > /a > --------------020602060203000003070706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/22/11 15:36, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote:

>In other words, I think it would be foolish to charter a working group with an answer, and then work towards finding questions that fit the answer.
The current charter is mainly a list of open questions; I do not see any answers in there. Do you?


I was responding to your query regarding pursuing "call control OR device control, but not both."

Basically, my statement was: "If you're considering such a change to the charter text, stop."

/a


 

Rifaat

 

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Thursday, September 22, 2011 1:35 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Simon Pietro Romano; dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG

 

On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hi Simon,

 

>With respect to this, I would suggest not to mix call control with device control, unless we want to open a never-ending discussion.
I was not trying to suggest that the same protocol would be used for call & device control, quite the opposite. Is that your concern?

Or you are saying that the WG should deal with only either call control OR device control, but not both?

 


I think you need to work through use cases first, and then determine whether they can all be accomplished through call control alone. Or through just device control. Or if you need a combination of both to satisfy the use cases that people interested in this work have in mind.

In other words, I think it would be foolish to charter a working group with an answer, and then work towards finding questions that fit the answer.

/a


--------------020602060203000003070706-- From spromano@unina.it Thu Sep 22 13:55:28 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9901F0C72 for ; Thu, 22 Sep 2011 13:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK2yxXsC1Ir4 for ; Thu, 22 Sep 2011 13:55:27 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6DC1F0C38 for ; Thu, 22 Sep 2011 13:55:26 -0700 (PDT) Received: from [192.168.43.82] ([94.167.164.229]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p8MKvqF4020736 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 22:57:54 +0200 Message-ID: <4E7BA149.2020203@unina.it> Date: Thu, 22 Sep 2011 22:57:45 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> Content-Type: multipart/alternative; boundary="------------020009000407020602090108" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 20:55:29 -0000 This is a multi-part message in MIME format. --------------020009000407020602090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Rifaat, > >With respect to this, I would suggest not to mix call control with > device control, unless we want to open a never-ending discussion. > I was not trying to suggest that the same protocol would be used for > call & device control, quite the opposite. Is that your concern? > No. > > Or you are saying that the WG should deal with only either call > control OR device control, but not both? > Yes. My impression is that call control would be feasible, while device control is a can of worms. Simon > > Regards, > > Rifaat > > *From:*Simon Pietro Romano [mailto:spromano@unina.it] > *Sent:* Wednesday, September 21, 2011 1:25 PM > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] Charter Proposal - Remote Call/Device Control WG > > Hi Rifaat and all, > > as one of the main supporters of the SPLICES attempts at addressing > these issues, I cannot refrain myself from strongly supporting your > initiative. Reading through the charter, I see that you have clear in > your mind the main issues that came out from our past discussions in > the IETF (with special regard to the meeting we had in Quebec City). > With respect to this, I would suggest not to mix call control with > device control, unless we want to open a never-ending discussion. > > Cheers, > > Simon > > Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto: > > Hi, > > The following is a charter proposal for a Remote Call/Device Control WG. > > We would appreciate it if you review it and provide us with your feedback. > > Thanks, > > Rifaat > > ------- > > Remote Call/Device Control WG > > The Session Initiation Protocol (SIP) [RFC3261] provides users with > the ability to initiate, manage, and terminate multimedia sessions. > > A SIP application is a program running on a SIP network element that > provides some value-added function to a user. > > Many deployments have SIP applications in the SIP signaling path that > get involved in the setup and management of these multimedia sessions. > > Third-Party Application might also be interested in interacting with > User Agents and the setup of multimedia sessions. > > Some of these applications need a mechanism to remotely invoke some > actions or/and monitor the invocation of actions on a SIP User Agent. > > SIP allows for the invocation of actions on a remote User Agent using > the REFER method. > > The actions that can be invoked by the REFER method are limited, and > there is a need for more actions by some SIP applications. > > The purpose of this WG is to evaluate the various available mechanisms > or proposed mechanism and recommend one or more of them, > > or define a new mechanism if none of the available are good enough to > address this need. > > The work group will need to address the following: > > * Clearly answer the following questions: > > a. What is "call control"? > > b. What is "device control"? > > * Will the new mechanism address "call control", "device control" or both? > > * Will the new mechanism be a SIP or a non-SIP based mechanism? > > * If a non-SIP mechanism is used, how to deal with the fact that some > of these > > actions already covered by the SIP REFER method and widely used in > the industry > > * Define a model for the actions > > * Define a scope for the actions > > * Define a set of initial actions that can be later extended, if needed. > > * Others? > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail:spromano@unina.it > http://www.comics.unina.it/simonpietro.romano > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------020009000407020602090108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Rifaat,

 

>With respect to this, I would suggest not to mix call control with device control, unless we want to open a never-ending discussion.
I was not trying to suggest that the same protocol would be used for call & device control, quite the opposite. Is that your concern?

No.

Or you are saying that the WG should deal with only either call control OR device control, but not both?

Yes. My impression is that call control would be feasible, while device control is a can of worms.

Simon

 

Regards,

Rifaat

 

 

From: Simon Pietro Romano [mailto:spromano@unina.it]
Sent: Wednesday, September 21, 2011 1:25 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG

 

Hi Rifaat and all,

as one of the main supporters of the SPLICES attempts at addressing these issues, I cannot refrain myself from strongly supporting your initiative. Reading through the charter, I see that you have clear in your mind the main issues that came out from our past discussions in the IETF (with special regard to the meeting we had in Quebec City). With respect to this, I would suggest not to mix call control with device control, unless we want to open a never-ending discussion.

Cheers,

Simon

Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto:

Hi,

 

The following is a charter proposal for a Remote Call/Device Control WG.

We would appreciate it if you review it and provide us with your feedback.

 

Thanks,

Rifaat

 

-------

 

Remote Call/Device Control WG

 

The Session Initiation Protocol (SIP) [RFC3261] provides users with the ability to initiate, manage, and terminate multimedia sessions.

A SIP application is a program running on a SIP network element that provides some value-added function to a user.

Many deployments have SIP applications in the SIP signaling path that get involved in the setup and management of these multimedia sessions.

Third-Party Application might also be interested in interacting with User Agents and the setup of multimedia sessions.

Some of these applications need a mechanism to remotely invoke some actions or/and monitor the invocation of actions on a SIP User Agent.

SIP allows for the invocation of actions on a remote User Agent using the REFER method.

The actions that can be invoked by the REFER method are limited, and there is a need for more actions by some SIP applications.

The purpose of this WG is to evaluate the various available mechanisms or proposed mechanism and recommend one or more of them,

or define a new mechanism if none of the available are good enough to address this need.

 

The work group will need to address the following:

* Clearly answer the following questions:

   a. What is "call control"?

   b. What is "device control"?

* Will the new mechanism address "call control", "device control" or both?

* Will the new mechanism be a SIP or a non-SIP based mechanism?

* If a non-SIP mechanism is used, how to deal with the fact that some of these

  actions already covered by the SIP REFER method and widely used in the industry

* Define a model for the actions

* Define a scope for the actions

* Define a set of initial actions that can be later extended, if needed.

* Others?

 

 
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano
 
    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
 

-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------020009000407020602090108-- From pkyzivat@alum.mit.edu Thu Sep 22 14:09:25 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8A21F8B38 for ; Thu, 22 Sep 2011 14:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMft0rQ18INc for ; Thu, 22 Sep 2011 14:09:24 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4E821F8B34 for ; Thu, 22 Sep 2011 14:09:24 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id bth11h0041ap0As5AxBxsx; Thu, 22 Sep 2011 21:11:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta22.westchester.pa.mail.comcast.net with comcast id bxBw1h02F0tdiYw3ixBxYh; Thu, 22 Sep 2011 21:11:57 +0000 Message-ID: <4E7BA49B.7090209@alum.mit.edu> Date: Thu, 22 Sep 2011 17:11:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> <4E7BA149.2020203@unina.it> In-Reply-To: <4E7BA149.2020203@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:09:25 -0000 On 9/22/11 4:57 PM, Simon Pietro Romano wrote: > Hi Rifaat, > >> >With respect to this, I would suggest not to mix call control with >> device control, unless we want to open a never-ending discussion. >> I was not trying to suggest that the same protocol would be used for >> call & device control, quite the opposite. Is that your concern? >> > No. >> >> Or you are saying that the WG should deal with only either call >> control OR device control, but not both? >> > Yes. My impression is that call control would be feasible, while device > control is a can of worms. And yet, call control is at least in part a solved problem, while many of the scenarios of interest seem to require some degree of device control. Thanks, Paul From rifatyu@avaya.com Thu Sep 22 16:19:12 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C440221F8BB7 for ; Thu, 22 Sep 2011 16:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfOSCcIvexyf for ; Thu, 22 Sep 2011 16:19:12 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2971B21F8B91 for ; Thu, 22 Sep 2011 16:19:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAALnCe06HCzI1/2dsb2JhbABCgk2WQI54eIFTAQEBAQMSZxACAQgNBAQBAQEnBzIUCQgBAQQOBQgaoW4CmzuGHWAEh0GRTYwN X-IronPort-AV: E=Sophos;i="4.68,426,1312171200"; d="scan'208,217";a="305249322" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Sep 2011 19:21:37 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Sep 2011 19:12:08 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 22 Sep 2011 19:21:36 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Adam Roach Date: Thu, 22 Sep 2011 19:16:53 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx5aAxpYSi8/GtcR8yEDScDB0tedQAFaqQl Message-ID: <6369CB70BFD88942B9705AC1E639A33822CE7CF889@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com> <4E7B71C5.9010905@nostrum.com> <6369CB70BFD88942B9705AC1E639A33822D1D2CC4E@DC-US1MBEX4.global.avaya.com>, <4E7B9D80.6040601@nostrum.com> In-Reply-To: <4E7B9D80.6040601@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CE7CF889DCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 23:19:12 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CE7CF889DCUS1MBEX4glo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My query was to try to understand Simon's question; that does not necessari= ly mean that I agree with that statement or that I will change the charter = proposal because of that. Rifaat ________________________________ From: Adam Roach [adam@nostrum.com] Sent: Thursday, September 22, 2011 4:41 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: Simon Pietro Romano; dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG On 9/22/11 15:36, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote: >In other words, I think it would be foolish to charter a working group wit= h an answer, and then work towards finding questions that fit the answer. The current charter is mainly a list of open questions; I do not see any an= swers in there. Do you? I was responding to your query regarding pursuing "call control OR device c= ontrol, but not both." Basically, my statement was: "If you're considering such a change to the ch= arter text, stop." /a Rifaat From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, September 22, 2011 1:35 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: Simon Pietro Romano; dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote: Hi Simon, >With respect to this, I would suggest not to mix call control with device = control, unless we want to open a never-ending discussion. I was not trying to suggest that the same protocol would be used for call &= device control, quite the opposite. Is that your concern? Or you are saying that the WG should deal with only either call control OR = device control, but not both? I think you need to work through use cases first, and then determine whethe= r they can all be accomplished through call control alone. Or through just = device control. Or if you need a combination of both to satisfy the use cas= es that people interested in this work have in mind. In other words, I think it would be foolish to charter a working group with= an answer, and then work towards finding questions that fit the answer. /a --_000_6369CB70BFD88942B9705AC1E639A33822CE7CF889DCUS1MBEX4glo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My query was to try to understand Simon's question; that does not nece= ssarily mean that I agree with that statement or that I will change the cha= rter proposal because of that.
=  
Rifaat
 
From: Adam Roach = [adam@nostrum.com]
Sent: Thursday, September 22, 2011 4:41 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Simon Pietro Romano; dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Contro= l WG

On 9/22/11 15:36, Sep 22, Shekh-Yusef, Rifaat (Rifaat) wrote:

>In other words, I think it would be foolis= h to charter a working group with an answer, and then work towards finding = questions that fit the answer.
The current charter is mainly = a list of open questions; I do not see any answers in there. Do you?=


I was responding to your query regarding pursuing "call control OR dev= ice control, but not both."

Basically, my statement was: "If you're considering such a change to t= he charter text, stop."

/a


 

Rifaat

 

 

From: Adam Roa= ch [mai= lto:adam@nostrum.com]
Sent: Thursday, September 22, 2011 1:35 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Simon Pietro Romano; dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Contro= l WG

 

On 9/22/11 11:19, Sep 22, Shekh-Yusef, Rifaat (Rifaa= t) wrote:

Hi Simon,

 

>With respect to this, I would suggest not to mix= call control with device control, unless we want to open a never-ending di= scussion.
I was not trying to suggest that the same pr= otocol would be used for call & device control, quite the opposite. Is = that your concern?

Or you are saying tha= t the WG should deal with only either call control OR device control, but n= ot both?

 


I think you need to work through use cases first, and then determine whethe= r they can all be accomplished through call control alone. Or through just = device control. Or if you need a combination of both to satisfy the use cas= es that people interested in this work have in mind.

In other words, I think it would be foolish to charter a working group with= an answer, and then work towards finding questions that fit the answer.
/a


--_000_6369CB70BFD88942B9705AC1E639A33822CE7CF889DCUS1MBEX4glo_-- From rifatyu@avaya.com Thu Sep 22 16:27:22 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A621F0C43 for ; Thu, 22 Sep 2011 16:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHxxtNLCs+EN for ; Thu, 22 Sep 2011 16:27:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BA5911F0C40 for ; Thu, 22 Sep 2011 16:27:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAAfEe06HCzI1/2dsb2JhbABCgk2WQI54eIFTAQEBAQMBAQEPXAsOAgIBCA0EBAEBKAcbDAsUCQgBAQQOBQgah1yaDgKbOwKGG2AEh0GRTYwN X-IronPort-AV: E=Sophos;i="4.68,426,1312171200"; d="scan'208,217";a="269294544" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Sep 2011 19:29:51 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Sep 2011 19:20:21 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 22 Sep 2011 19:29:50 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Simon Pietro Romano Date: Thu, 22 Sep 2011 19:29:49 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx5ak/1Kn/E+M8iRm2sfheDj/TPaAAFBPoF Message-ID: <6369CB70BFD88942B9705AC1E639A33822CE7CF88A@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <4E7A1DD1.9080000@unina.it> <6369CB70BFD88942B9705AC1E639A33822D1D2C895@DC-US1MBEX4.global.avaya.com>, <4E7BA149.2020203@unina.it> In-Reply-To: <4E7BA149.2020203@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CE7CF88ADCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 23:27:23 -0000 --_000_6369CB70BFD88942B9705AC1E639A33822CE7CF88ADCUS1MBEX4glo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Simon, There are different ideas out there on how to best address the remote call/= device control, and the charter was put like this to allow the WG to discus= s all these ideas and then decide on the best way going forward. Regards, Rifaat ________________________________ From: Simon Pietro Romano [spromano@unina.it] Sent: Thursday, September 22, 2011 4:57 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG Hi Rifaat, >With respect to this, I would suggest not to mix call control with device = control, unless we want to open a never-ending discussion. I was not trying to suggest that the same protocol would be used for call &= device control, quite the opposite. Is that your concern? No. Or you are saying that the WG should deal with only either call control OR = device control, but not both? Yes. My impression is that call control would be feasible, while device con= trol is a can of worms. Simon Regards, Rifaat From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: Wednesday, September 21, 2011 1:25 PM To: Shekh-Yusef, Rifaat (Rifaat) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG Hi Rifaat and all, as one of the main supporters of the SPLICES attempts at addressing these i= ssues, I cannot refrain myself from strongly supporting your initiative. Re= ading through the charter, I see that you have clear in your mind the main = issues that came out from our past discussions in the IETF (with special re= gard to the meeting we had in Quebec City). With respect to this, I would s= uggest not to mix call control with device control, unless we want to open = a never-ending discussion. Cheers, Simon Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto: Hi, The following is a charter proposal for a Remote Call/Device Control WG. We would appreciate it if you review it and provide us with your feedback. Thanks, Rifaat ------- Remote Call/Device Control WG The Session Initiation Protocol (SIP) [RFC3261] provides users with the abi= lity to initiate, manage, and terminate multimedia sessions. A SIP application is a program running on a SIP network element that provid= es some value-added function to a user. Many deployments have SIP applications in the SIP signaling path that get i= nvolved in the setup and management of these multimedia sessions. Third-Party Application might also be interested in interacting with User A= gents and the setup of multimedia sessions. Some of these applications need a mechanism to remotely invoke some actions= or/and monitor the invocation of actions on a SIP User Agent. SIP allows for the invocation of actions on a remote User Agent using the R= EFER method. The actions that can be invoked by the REFER method are limited, and there = is a need for more actions by some SIP applications. The purpose of this WG is to evaluate the various available mechanisms or p= roposed mechanism and recommend one or more of them, or define a new mechanism if none of the available are good enough to addre= ss this need. The work group will need to address the following: * Clearly answer the following questions: a. What is "call control"? b. What is "device control"? * Will the new mechanism address "call control", "device control" or both? * Will the new mechanism be a SIP or a non-SIP based mechanism? * If a non-SIP mechanism is used, how to deal with the fact that some of th= ese actions already covered by the SIP REFER method and widely used in the in= dustry * Define a model for the actions * Define a scope for the actions * Define a set of initial actions that can be later extended, if needed. * Others? _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --_000_6369CB70BFD88942B9705AC1E639A33822CE7CF88ADCUS1MBEX4glo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Simon,
 
There are different ideas out there on how to best ad= dress the remote call/device control, and the charter was put like this to allow the WG to discuss all these i= deas and then decide on the best way going forward.
 
Regards,
 Rifaat
 
 
=  
From: Simon Pietr= o Romano [spromano@unina.it]
Sent: Thursday, September 22, 2011 4:57 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Contro= l WG

Hi Rifaat,

 

>With respect to this, I would suggest not to mix= call control with device control, unless we want to open a never-ending di= scussion.
I was not trying to suggest that the = same protocol would be used for call & device control, quite the opposi= te. Is that your concern?

No.

Or you are say= ing that the WG should deal with only either call control OR device control= , but not both?

Yes. My impression is that call control would be feasible, while device con= trol is a can of worms.

Simon

 <= /p>

Regards,

Rifaat<= /p>

 <= /p>

 <= /p>

From: Simon Pi= etro Romano [mailto:spromano@unina.it]
Sent: Wednesday, September 21, 2011 1:25 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Contro= l WG

 

Hi Rifaat and all,

as one of the main supporters of the SPLICES attempts at addressing these i= ssues, I cannot refrain myself from strongly supporting your initiative. Re= ading through the charter, I see that you have clear in your mind the main = issues that came out from our past discussions in the IETF (with special regard to the meeting we had in Queb= ec City). With respect to this, I would suggest not to mix call control wit= h device control, unless we want to open a never-ending discussion.

Cheers,

Simon

Il 20/09/2011 20:36, Shekh-Yusef, Rifaat (Rifaat) ha scritto:

Hi,

 

The following is a charter proposal for a Remote = Call/Device Control WG.

We would appreciate it if you review it and provi= de us with your feedback.

 

Thanks,

Rifaat

 

-------

 

Remote Call/Device Control WG

 

The Session Initiation Protocol (SIP) [RFC3261] p= rovides users with the ability to initiate, manage, and terminate multimedi= a sessions.

A SIP application is a program running on a SIP n= etwork element that provides some value-added function to a user.

Many deployments have SIP applications in the SIP= signaling path that get involved in the setup and management of these mult= imedia sessions.

Third-Party Application might also be interested = in interacting with User Agents and the setup of multimedia sessions.

Some of these applications need a mechanism to re= motely invoke some actions or/and monitor the invocation of actions on a SI= P User Agent.

SIP allows for the invocation of actions on a rem= ote User Agent using the REFER method.

The actions that can be invoked by the REFER meth= od are limited, and there is a need for more actions by some SIP applicatio= ns.

The purpose of this WG is to evaluate the various= available mechanisms or proposed mechanism and recommend one or more of th= em,

or define a new mechanism if none of the availabl= e are good enough to address this need.

 

The work group will need to address the following= :

* Clearly answer the following questions:

   a. What is "call control"?=

   b. What is "device control"= ;?

* Will the new mechanism address "call contr= ol", "device control" or both?

* Will the new mechanism be a SIP or a non-SIP ba= sed mechanism?

* If a non-SIP mechanism is used, how to deal wit= h the fact that some of these

  actions already covered by the SIP REFER m= ethod and widely used in the industry

* Define a model for the actions

* Define a scope for the actions

* Define a set of initial actions that can be lat= er extended, if needed.

* Others?

 

 
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



-- 
           &nbs=
p;            &=
nbsp;   _\\|//_
           &nbs=
p;            &=
nbsp;   ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~=
~~
           &nbs=
p;        Simon Pietro Romano
           &nbs=
p;  Universita' di Napoli Federico II
           &nbs=
p;     Computer Science Department 
        Phone: +39 081 768=
3823 -- Fax: +39 081 7684219
            &nb=
sp;   e-mail: spromano@=
unina.it
          http://www.com=
ics.unina.it/simonpietro.romano
 
    <<Molti mi dicono che lo scoraggiamento =E8 l=
'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>&g=
t;. Magritte.
           &nbs=
p;             =
oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~=
~~~~~~~~~~~~
           &nbs=
p;            &=
nbsp; \ (    (   )
           &nbs=
p;            &=
nbsp;  \_)    ) /
           &nbs=
p;             =
        (_/
 

--=20
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department=20
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simon=
pietro.romano

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--_000_6369CB70BFD88942B9705AC1E639A33822CE7CF88ADCUS1MBEX4glo_-- From dworley@avaya.com Fri Sep 23 08:45:43 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B3421F8C72 for ; Fri, 23 Sep 2011 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxK7l6Ike45p for ; Fri, 23 Sep 2011 08:45:42 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 887D121F8AF8 for ; Fri, 23 Sep 2011 08:45:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ2pfE6HCzI1/2dsb2JhbAA8Bg6oBXiBUwEBAQECARIoPwULAgEIDQEHIRAyJQEBBA4FCBqHVpsxAptKg2KCP2AEmRGLO1M X-IronPort-AV: E=Sophos;i="4.68,430,1312171200"; d="scan'208";a="209262912" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Sep 2011 11:48:16 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Sep 2011 11:38:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 23 Sep 2011 11:48:15 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Fri, 23 Sep 2011 11:46:16 -0400 Thread-Topic: [dispatch] Deriving URI from MAC-based URN ??? Thread-Index: Acx5XJ+yufoSDmQAQoSEA5Gfd3p6IAAq024M Message-ID: References: <56DC300C52125F46BA19D2D5CCEC4D70C54E0A@XCH04ADS.rim.net><1E0C1A28-B2EC-4714-8BE6-B008352E002A@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu> In-Reply-To: <4E7B8A5C.4080307@alum.mit.edu> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:45:43 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > You can just configure the phone as you say, IF: >=20 > - the phone has a configurable light > - the light can be configured with a URI > - the phone determines the light status by using the URI > in the way intended by the target of that URI >=20 > AFAIK all of those are unusual properties, except for the specific > equipment that currently supports it. If I have some "other" phone I am > out of luck unless I am in a position to modify it in that way. I may be completely misunderstanding you, but I know of no SIP phone which is claimed to "have BLF lights" that does *not* implement the points you've listed. Dale From kpfleming@digium.com Fri Sep 23 09:19:36 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EA421F8CC2 for ; Fri, 23 Sep 2011 09:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLPUxel4VJQI for ; Fri, 23 Sep 2011 09:19:35 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2B21F8CAD for ; Fri, 23 Sep 2011 09:19:35 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1R78Vm-0007kO-RL for dispatch@ietf.org; Fri, 23 Sep 2011 11:22:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C25281A2013 for ; Fri, 23 Sep 2011 11:22:02 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+qPeLOtEK7D for ; Fri, 23 Sep 2011 11:22:02 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 52FCE1A200A for ; Fri, 23 Sep 2011 11:22:02 -0500 (CDT) Message-ID: <4E7CB229.2050207@digium.com> Date: Fri, 23 Sep 2011 11:22:01 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: dispatch@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233F1DD99@ESESSCMS0356.eemea.ericsson.se><7A051DFAA46D0246A82293C7CEF621E9056D47BCBC@ESESSCMS0352.eemea.ericsson.se> <208EAE1DFA28FC419529619ABB8622441B6275FD83@CMS03.BGC.NET>, <9ECCF01B52E7AB408A7EB8535264214103443215@ftrdmel0.rd.francetelecom.fr> , <4E7A1FBB.6010406@alum.mit.edu> , <4E7A7095.2090203@alum.mit.edu> , <4E7B6F81.20305@alum.mit.edu> , <4E7B8A5C.4080307@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Deriving URI from MAC-based URN ??? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 16:19:36 -0000 On 09/23/2011 10:46 AM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> You can just configure the phone as you say, IF: >> >> - the phone has a configurable light >> - the light can be configured with a URI >> - the phone determines the light status by using the URI >> in the way intended by the target of that URI >> >> AFAIK all of those are unusual properties, except for the specific >> equipment that currently supports it. If I have some "other" phone I am >> out of luck unless I am in a position to modify it in that way. > > I may be completely misunderstanding you, but I know of no SIP phone > which is claimed to "have BLF lights" that does *not* implement the > points you've listed. Yeah... I was going to post the same thing, but wasn't quite sure if I was missing something obvious :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From HKaplan@acmepacket.com Fri Sep 23 16:38:04 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285A521F8C48 for ; Fri, 23 Sep 2011 16:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCXgl+0F7gMR for ; Fri, 23 Sep 2011 16:38:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB321F8C22 for ; Fri, 23 Sep 2011 16:37:27 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Sep 2011 19:40:02 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 19:40:02 -0400 From: Hadriel Kaplan To: "Shekh-Yusef, Rifaat (Rifaat)" Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: AQHMekoc1VJFr3SpnkmhwqAcrekfxw== Date: Fri, 23 Sep 2011 23:39:54 +0000 Message-ID: <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <60B6017C3C50E14A983796D4B70E5F12@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 23:38:04 -0000 I don't mean to argue for or against this work in any way, but the charter = seems very odd to me. I could be totally wrong, but I don't think WG charters usually have goals = like the first two you have listed: > * Clearly answer the following questions: > a. What is "call control"? > b. What is "device control"? > * Will the new mechanism address "call control", "device control" or both= ? =20 Those types of questions are usually answered *before* a WG is chartered, a= s far as I can recall. Otherwise it's like saying one of the goals of the = Working Group is to define it's own scope. Well... usually the IETF wants = to know the scope before creating a WG. Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face IETF me= eting, with a presentation(s) on the problem and possible solutions, and th= e chairs ask for hands on who's interested in the work and would be willing= to contribute and such. Are you planning on doing that for the Taipei mee= ting?=20 -hadriel On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > =20 > The following is a charter proposal for a Remote Call/Device Control WG. > We would appreciate it if you review it and provide us with your feedback= . > =20 > Thanks, > Rifaat > =20 > ------- > =20 > Remote Call/Device Control WG > =20 > The Session Initiation Protocol (SIP) [RFC3261] provides users with the a= bility to initiate, manage, and terminate multimedia sessions. > A SIP application is a program running on a SIP network element that prov= ides some value-added function to a user. > Many deployments have SIP applications in the SIP signaling path that get= involved in the setup and management of these multimedia sessions. > Third-Party Application might also be interested in interacting with User= Agents and the setup of multimedia sessions. > Some of these applications need a mechanism to remotely invoke some actio= ns or/and monitor the invocation of actions on a SIP User Agent. > SIP allows for the invocation of actions on a remote User Agent using the= REFER method. > The actions that can be invoked by the REFER method are limited, and ther= e is a need for more actions by some SIP applications. > The purpose of this WG is to evaluate the various available mechanisms or= proposed mechanism and recommend one or more of them, > or define a new mechanism if none of the available are good enough to add= ress this need. > =20 > The work group will need to address the following: > * Clearly answer the following questions: > a. What is "call control"? > b. What is "device control"? > * Will the new mechanism address "call control", "device control" or both= ? > * Will the new mechanism be a SIP or a non-SIP based mechanism? > * If a non-SIP mechanism is used, how to deal with the fact that some of = these > actions already covered by the SIP REFER method and widely used in the = industry > * Define a model for the actions > * Define a scope for the actions > * Define a set of initial actions that can be later extended, if needed. > * Others? > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Mon Sep 26 07:37:26 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101D021F8D5D for ; Mon, 26 Sep 2011 07:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GMA9GG4T3us for ; Mon, 26 Sep 2011 07:37:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7BA221F8D59 for ; Mon, 26 Sep 2011 07:37:24 -0700 (PDT) Received: by vws5 with SMTP id 5so6917928vws.31 for ; Mon, 26 Sep 2011 07:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=liwfgDijYOzFzfwW2ylYGrpaKGMmIOMzZrje/BOLItY=; b=pMlYPuKbhuiiy6eEcx21tzbYSbzIYN/uy/mevhbVhlWcdhXLWWx4pDUJssAasr/bla dTYfcZQii91Gz4JxrhhuirkVZRCzpfqCczUUqqZa0zfoJ61MuoBaWMTLTuHKjNPGYotr QoLdP9kGw2sIXV14AmsG1d6vqLSFOl7krOuDE= MIME-Version: 1.0 Received: by 10.52.22.74 with SMTP id b10mr6252595vdf.90.1317048006124; Mon, 26 Sep 2011 07:40:06 -0700 (PDT) Received: by 10.52.157.134 with HTTP; Mon, 26 Sep 2011 07:40:06 -0700 (PDT) In-Reply-To: <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> Date: Mon, 26 Sep 2011 09:40:06 -0500 Message-ID: From: Mary Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=20cf3077639f8ea57404add922e4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:37:26 -0000 --20cf3077639f8ea57404add922e4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 23, 2011 at 6:39 PM, Hadriel Kaplan wrote: > > I don't mean to argue for or against this work in any way, but the charter > seems very odd to me. > I could be totally wrong, but I don't think WG charters usually have goals > like the first two you have listed: > > * Clearly answer the following questions: > > a. What is "call control"? > > b. What is "device control"? > > * Will the new mechanism address "call control", "device control" or > both? > > Those types of questions are usually answered *before* a WG is chartered, > as far as I can recall. Otherwise it's like saying one of the goals of the > Working Group is to define it's own scope. Well... usually the IETF wants > to know the scope before creating a WG. > > Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face IETF > meeting, with a presentation(s) on the problem and possible solutions, and > the chairs ask for hands on who's interested in the work and would be > willing to contribute and such. Are you planning on doing that for the > Taipei meeting? > > -hadriel > [MB] Yes, that is the intent of the agenda time for this topic in DISPATCH. [/MB] > > > > On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi, > > > > The following is a charter proposal for a Remote Call/Device Control WG. > > We would appreciate it if you review it and provide us with your > feedback. > > > > Thanks, > > Rifaat > > > > ------- > > > > Remote Call/Device Control WG > > > > The Session Initiation Protocol (SIP) [RFC3261] provides users with the > ability to initiate, manage, and terminate multimedia sessions. > > A SIP application is a program running on a SIP network element that > provides some value-added function to a user. > > Many deployments have SIP applications in the SIP signaling path that get > involved in the setup and management of these multimedia sessions. > > Third-Party Application might also be interested in interacting with User > Agents and the setup of multimedia sessions. > > Some of these applications need a mechanism to remotely invoke some > actions or/and monitor the invocation of actions on a SIP User Agent. > > SIP allows for the invocation of actions on a remote User Agent using the > REFER method. > > The actions that can be invoked by the REFER method are limited, and > there is a need for more actions by some SIP applications. > > The purpose of this WG is to evaluate the various available mechanisms or > proposed mechanism and recommend one or more of them, > > or define a new mechanism if none of the available are good enough to > address this need. > > > > The work group will need to address the following: > > * Clearly answer the following questions: > > a. What is "call control"? > > b. What is "device control"? > > * Will the new mechanism address "call control", "device control" or > both? > > * Will the new mechanism be a SIP or a non-SIP based mechanism? > > * If a non-SIP mechanism is used, how to deal with the fact that some of > these > > actions already covered by the SIP REFER method and widely used in the > industry > > * Define a model for the actions > > * Define a scope for the actions > > * Define a set of initial actions that can be later extended, if needed. > > * Others? > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --20cf3077639f8ea57404add922e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 23, 2011 at 6:39 PM, Hadriel Kap= lan <HKaplan= @acmepacket.com> wrote:

I don't mean to argue for or against this work in any way, but the char= ter seems very odd to me.
I could be totally wrong, but I don't think WG charters usually have go= als like the first two you have listed:
> * Clearly answer the following questions:
> =A0 =A0a. What is "call control"?
> =A0 =A0b. What is "device control"?
> * Will the new mechanism address "call control", "devic= e control" or both?

Those types of questions are usually answered *before* a WG is charte= red, as far as I can recall. =A0Otherwise it's like saying one of the g= oals of the Working Group is to define it's own scope. =A0Well... usual= ly the IETF wants to know the scope before creating a WG.

Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-fa= ce IETF meeting, with a presentation(s) on the problem and possible solutio= ns, and the chairs ask for hands on who's interested in the work and wo= uld be willing to contribute and such. =A0Are you planning on doing that fo= r the Taipei meeting?

-hadriel

[MB] Yes, that is the i= ntent of the agenda time for this topic in DISPATCH. =A0[/MB]



On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:

> Hi,
>
> The following is a charter proposal for a Remote Call/Device Control W= G.
> We would appreciate it if you review it and provide us with your feedb= ack.
>
> Thanks,
> Rifaat
>
> -------
>
> Remote Call/Device Control WG
>
> The Session Initiation Protocol (SIP) [RFC3261] provides users with th= e ability to initiate, manage, and terminate multimedia sessions.
> A SIP application is a program running on a SIP network element that p= rovides some value-added function to a user.
> Many deployments have SIP applications in the SIP signaling path that = get involved in the setup and management of these multimedia sessions.
> Third-Party Application might also be interested in interacting with U= ser Agents and the setup of multimedia sessions.
> Some of these applications need a mechanism to remotely invoke some ac= tions or/and monitor the invocation of actions on a SIP User Agent.
> SIP allows for the invocation of actions on a remote User Agent using = the REFER method.
> The actions that can be invoked by the REFER method are limited, and t= here is a need for more actions by some SIP applications.
> The purpose of this WG is to evaluate the various available mechanisms= or proposed mechanism and recommend one or more of them,
> or define a new mechanism if none of the available are good enough to = address this need.
>
> The work group will need to address the following:
> * Clearly answer the following questions:
> =A0 =A0a. What is "call control"?
> =A0 =A0b. What is "device control"?
> * Will the new mechanism address "call control", "devic= e control" or both?
> * Will the new mechanism be a SIP or a non-SIP based mechanism?
> * If a non-SIP mechanism is used, how to deal with the fact that some = of these
> =A0 actions already covered by the SIP REFER method and widely used in= the industry
> * Define a model for the actions
> * Define a scope for the actions
> * Define a set of initial actions that can be later extended, if neede= d.
> * Others?
>
> ________________________= _______________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--20cf3077639f8ea57404add922e4-- From rifatyu@avaya.com Tue Sep 27 05:31:49 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8B21F8512 for ; Tue, 27 Sep 2011 05:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uyrdeTLS4eB for ; Tue, 27 Sep 2011 05:31:48 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5120E21F846D for ; Tue, 27 Sep 2011 05:31:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAAAPvBgU7GmAcF/2dsb2JhbABBmHGPBniBUwEBAQEDAQEBDyg0CwwEAgEIDQEDBAEBAR4JBycLFAkIAgQOBQgTB4dcnQUCm1QDhitgBJkTjA8 X-IronPort-AV: E=Sophos;i="4.68,449,1312171200"; d="scan'208";a="269945284" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Sep 2011 08:34:30 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Sep 2011 08:33:31 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 27 Sep 2011 08:34:29 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Hadriel Kaplan Date: Tue, 27 Sep 2011 08:34:28 -0400 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: AQHMekoc1VJFr3SpnkmhwqAcrekfx5VhKCnQ Message-ID: <6369CB70BFD88942B9705AC1E639A33822D1EBF8C6@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> In-Reply-To: <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> 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 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 12:31:49 -0000 Our intention with the original SIP Action Referral proposal and later on w= ith the INVOKE method proposal was to extend the Remote *Call* Control mech= anism defined by the REFER method. During the discussion of these proposals some people showed interest in a R= emote *Device* Control, but it was clear that the line between Remote Call = Control and Remote Device Control is blurry. Different people have different ideas on how to address these needs: * One mechanism over SIP should address both Call and Device control * SIP should be used for Call control and a non-SIP mechanism for Device = control * non-SIP mechanism should be used for both Call and Device control That is the reason for the questions stated below. In any case, I would welcome any suggestions on how to improve the text of = this charter proposal. Regards, Rifaat > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, September 23, 2011 7:40 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG >=20 >=20 > I don't mean to argue for or against this work in any way, but the charte= r > seems very odd to me. > I could be totally wrong, but I don't think WG charters usually have goal= s > like the first two you have listed: > > * Clearly answer the following questions: > > a. What is "call control"? > > b. What is "device control"? > > * Will the new mechanism address "call control", "device control" or bo= th? >=20 > Those types of questions are usually answered *before* a WG is chartered,= as > far as I can recall. Otherwise it's like saying one of the goals of the > Working Group is to define it's own scope. Well... usually the IETF want= s to > know the scope before creating a WG. >=20 > Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face IETF > meeting, with a presentation(s) on the problem and possible solutions, an= d the > chairs ask for hands on who's interested in the work and would be willing= to > contribute and such. Are you planning on doing that for the Taipei meeti= ng? >=20 > -hadriel >=20 >=20 >=20 > On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >=20 > > Hi, > > > > The following is a charter proposal for a Remote Call/Device Control WG= . > > We would appreciate it if you review it and provide us with your feedba= ck. > > > > Thanks, > > Rifaat > > > > ------- > > > > Remote Call/Device Control WG > > > > The Session Initiation Protocol (SIP) [RFC3261] provides users with the > ability to initiate, manage, and terminate multimedia sessions. > > A SIP application is a program running on a SIP network element that > provides some value-added function to a user. > > Many deployments have SIP applications in the SIP signaling path that g= et > involved in the setup and management of these multimedia sessions. > > Third-Party Application might also be interested in interacting with Us= er > Agents and the setup of multimedia sessions. > > Some of these applications need a mechanism to remotely invoke some act= ions > or/and monitor the invocation of actions on a SIP User Agent. > > SIP allows for the invocation of actions on a remote User Agent using t= he > REFER method. > > The actions that can be invoked by the REFER method are limited, and th= ere > is a need for more actions by some SIP applications. > > The purpose of this WG is to evaluate the various available mechanisms = or > proposed mechanism and recommend one or more of them, > > or define a new mechanism if none of the available are good enough to > address this need. > > > > The work group will need to address the following: > > * Clearly answer the following questions: > > a. What is "call control"? > > b. What is "device control"? > > * Will the new mechanism address "call control", "device control" or bo= th? > > * Will the new mechanism be a SIP or a non-SIP based mechanism? > > * If a non-SIP mechanism is used, how to deal with the fact that some o= f > these > > actions already covered by the SIP REFER method and widely used in th= e > industry > > * Define a model for the actions > > * Define a scope for the actions > > * Define a set of initial actions that can be later extended, if needed= . > > * Others? > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Tue Sep 27 09:20:52 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4921F8EBF for ; Tue, 27 Sep 2011 09:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.075 X-Spam-Level: X-Spam-Status: No, score=-100.075 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v95VX6NnTi0f for ; Tue, 27 Sep 2011 09:20:51 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 4979721F8EBE for ; Tue, 27 Sep 2011 09:20:51 -0700 (PDT) Received: (qmail 24445 invoked by uid 0); 27 Sep 2011 16:23:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 27 Sep 2011 16:23:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=FMK5/YeQ39fjQCh9cIyRWlPP39i4oZsfc/NB9hm1oXA=; b=jara5ERKvNftJkI+Jmu5u9kAJ0ucwPiv6qcVrSUlqf251kVAvIjh+pPLdjPhtRyt7s+erkLQs4QDQhIyU1QSjm2H3yHzkZ9lS8faRcZdnZXEYdYzUvQahpyKf4E5FA34; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8aRT-0001L3-El; Tue, 27 Sep 2011 10:23:35 -0600 From: "Richard Shockey" To: "'Mary Barnes'" , References: <6369CB70BFD88942B9705AC1E639A33822D1B91606@DC-US1MBEX4.global.avaya.com> <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> In-Reply-To: Date: Tue, 27 Sep 2011 12:23:33 -0400 Message-ID: <00ac01cc7d31$ce093080$6a1b9180$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CC7D10.46F79080" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx8WjLq5HuOV62HQMGQPKXHEO7NqQA1zSdg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 16:20:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01CC7D10.46F79080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WOW cool ! The CIA- National Security Agency MI5/MI6 Russian FSB working group. Is this going to be coordinated with RTC-WEB where there are no privacy security controls on the browser UA? Third-Party Application might also be interested in interacting with User Agents and the setup of multimedia sessions. Some of these applications need a mechanism to remotely invoke some actions or/and monitor the invocation of actions on a SIP User Agent. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Monday, September 26, 2011 10:40 AM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG On Fri, Sep 23, 2011 at 6:39 PM, Hadriel Kaplan wrote: I don't mean to argue for or against this work in any way, but the charter seems very odd to me. I could be totally wrong, but I don't think WG charters usually have goals like the first two you have listed: > * Clearly answer the following questions: > a. What is "call control"? > b. What is "device control"? > * Will the new mechanism address "call control", "device control" or both? Those types of questions are usually answered *before* a WG is chartered, as far as I can recall. Otherwise it's like saying one of the goals of the Working Group is to define it's own scope. Well... usually the IETF wants to know the scope before creating a WG. Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face IETF meeting, with a presentation(s) on the problem and possible solutions, and the chairs ask for hands on who's interested in the work and would be willing to contribute and such. Are you planning on doing that for the Taipei meeting? -hadriel [MB] Yes, that is the intent of the agenda time for this topic in DISPATCH. [/MB] On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Hi, > > The following is a charter proposal for a Remote Call/Device Control WG. > We would appreciate it if you review it and provide us with your feedback. > > Thanks, > Rifaat > > ------- > > Remote Call/Device Control WG > > The Session Initiation Protocol (SIP) [RFC3261] provides users with the ability to initiate, manage, and terminate multimedia sessions. > A SIP application is a program running on a SIP network element that provides some value-added function to a user. > Many deployments have SIP applications in the SIP signaling path that get involved in the setup and management of these multimedia sessions. > Third-Party Application might also be interested in interacting with User Agents and the setup of multimedia sessions. > Some of these applications need a mechanism to remotely invoke some actions or/and monitor the invocation of actions on a SIP User Agent. > SIP allows for the invocation of actions on a remote User Agent using the REFER method. > The actions that can be invoked by the REFER method are limited, and there is a need for more actions by some SIP applications. > The purpose of this WG is to evaluate the various available mechanisms or proposed mechanism and recommend one or more of them, > or define a new mechanism if none of the available are good enough to address this need. > > The work group will need to address the following: > * Clearly answer the following questions: > a. What is "call control"? > b. What is "device control"? > * Will the new mechanism address "call control", "device control" or both? > * Will the new mechanism be a SIP or a non-SIP based mechanism? > * If a non-SIP mechanism is used, how to deal with the fact that some of these > actions already covered by the SIP REFER method and widely used in the industry > * Define a model for the actions > * Define a scope for the actions > * Define a set of initial actions that can be later extended, if needed. > * Others? > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_00AD_01CC7D10.46F79080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WOW cool ! =

 

The CIA-  National Security Agency  MI5/MI6 =  Russian FSB working group.  Is this going to be coordinated = with RTC-WEB where there are no privacy security controls on the browser = UA?

 

 

Third-Party = Application might also be interested in interacting with User Agents and = the setup of multimedia sessions.


Some of these applications need a mechanism to = remotely invoke some actions or/and monitor the invocation of actions on = a SIP User Agent.

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Mary Barnes
Sent: Monday, September 26, 2011 = 10:40 AM
To: Hadriel Kaplan
Cc: = dispatch@ietf.org
Subject: Re: [dispatch] Charter Proposal - = Remote Call/Device Control WG

 

 

On Fri, = Sep 23, 2011 at 6:39 PM, Hadriel Kaplan <HKaplan@acmepacket.com> = wrote:


I don't mean to argue for = or against this work in any way, but the charter seems very odd to = me.
I could be totally wrong, but I don't think WG charters usually = have goals like the first two you have listed:

> * Clearly answer = the following questions:
>    a. What is "call = control"?
>    b. What is "device = control"?
> * Will the new mechanism address "call = control", "device control" or = both?

Those types of questions = are usually answered *before* a WG is chartered, as far as I can recall. =  Otherwise it's like saying one of the goals of the Working Group = is to define it's own scope.  Well... usually the IETF wants to = know the scope before creating a WG.

Also, for some topics = DISPATCH needs a "mini-BOF" at a face-to-face IETF meeting, = with a presentation(s) on the problem and possible solutions, and the = chairs ask for hands on who's interested in the work and would be = willing to contribute and such.  Are you planning on doing that for = the Taipei meeting?

-hadriel

 

[MB] Yes, that is the intent of the agenda time for = this topic in DISPATCH.  [/MB]




On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, = Rifaat (Rifaat) wrote:

> Hi,
>
> The following is = a charter proposal for a Remote Call/Device Control WG.
> We would = appreciate it if you review it and provide us with your = feedback.
>
> Thanks,
> Rifaat
>
> = -------
>
> Remote Call/Device Control WG
>
> = The Session Initiation Protocol (SIP) [RFC3261] provides users with the = ability to initiate, manage, and terminate multimedia sessions.
> = A SIP application is a program running on a SIP network element that = provides some value-added function to a user.
> Many deployments = have SIP applications in the SIP signaling path that get involved in the = setup and management of these multimedia sessions.
> Third-Party = Application might also be interested in interacting with User Agents and = the setup of multimedia sessions.
> Some of these applications = need a mechanism to remotely invoke some actions or/and monitor the = invocation of actions on a SIP User Agent.
> SIP allows for the = invocation of actions on a remote User Agent using the REFER = method.
> The actions that can be invoked by the REFER method are = limited, and there is a need for more actions by some SIP = applications.
> The purpose of this WG is to evaluate the various = available mechanisms or proposed mechanism and recommend one or more of = them,
> or define a new mechanism if none of the available are = good enough to address this need.
>
> The work group will = need to address the following:
> * Clearly answer the following = questions:
>    a. What is "call = control"?
>    b. What is "device = control"?
> * Will the new mechanism address "call = control", "device control" or both?
> * Will the = new mechanism be a SIP or a non-SIP based mechanism?
> * If a = non-SIP mechanism is used, how to deal with the fact that some of = these
>   actions already covered by the SIP REFER method and = widely used in the industry
> * Define a model for the = actions
> * Define a scope for the actions
> * Define a set = of initial actions that can be later extended, if needed.
> * = Others?
>

> = _______________________________________________
> dispatch mailing = list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
<= br>_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 

------=_NextPart_000_00AD_01CC7D10.46F79080-- From D.Malas@cablelabs.com Tue Sep 27 15:21:34 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2E21F9073 for ; Tue, 27 Sep 2011 15:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.385 X-Spam-Level: X-Spam-Status: No, score=-100.385 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iksMbE62eB1w for ; Tue, 27 Sep 2011 15:21:33 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C90A621F9071 for ; Tue, 27 Sep 2011 15:21:33 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p8RMO8mL009546; Tue, 27 Sep 2011 16:24:08 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 27 Sep 2011 16:24:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 27 Sep 2011 16:22:15 -0600 From: Daryl Malas To: Hadriel Kaplan , "Shekh-Yusef, Rifaat (Rifaat)" Date: Tue, 27 Sep 2011 16:22:23 -0600 Thread-Topic: [dispatch] Charter Proposal - Remote Call/Device Control WG Thread-Index: Acx9Y+iGh5XC1dHRQpCr5aBb8cpS1A== Message-ID: In-Reply-To: <5651F13D-6AC9-49D8-B493-BEF0FF08B22F@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal - Remote Call/Device Control WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 22:21:34 -0000 I agree with Hadriel's comments/questions. --Daryl On 9/23/11 5:39 PM, "Hadriel Kaplan" wrote: > >I don't mean to argue for or against this work in any way, but the >charter seems very odd to me. >I could be totally wrong, but I don't think WG charters usually have >goals like the first two you have listed: >> * Clearly answer the following questions: >> a. What is "call control"? >> b. What is "device control"? >> * Will the new mechanism address "call control", "device control" or >>both? =20 > >Those types of questions are usually answered *before* a WG is chartered, >as far as I can recall. Otherwise it's like saying one of the goals of >the Working Group is to define it's own scope. Well... usually the IETF >wants to know the scope before creating a WG. > >Also, for some topics DISPATCH needs a "mini-BOF" at a face-to-face IETF >meeting, with a presentation(s) on the problem and possible solutions, >and the chairs ask for hands on who's interested in the work and would be >willing to contribute and such. Are you planning on doing that for the >Taipei meeting?=20 > >-hadriel > > > >On Sep 20, 2011, at 2:36 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> Hi, >> =20 >> The following is a charter proposal for a Remote Call/Device Control WG. >> We would appreciate it if you review it and provide us with your >>feedback. >> =20 >> Thanks, >> Rifaat >> =20 >> ------- >> =20 >> Remote Call/Device Control WG >> =20 >> The Session Initiation Protocol (SIP) [RFC3261] provides users with the >>ability to initiate, manage, and terminate multimedia sessions. >> A SIP application is a program running on a SIP network element that >>provides some value-added function to a user. >> Many deployments have SIP applications in the SIP signaling path that >>get involved in the setup and management of these multimedia sessions. >> Third-Party Application might also be interested in interacting with >>User Agents and the setup of multimedia sessions. >> Some of these applications need a mechanism to remotely invoke some >>actions or/and monitor the invocation of actions on a SIP User Agent. >> SIP allows for the invocation of actions on a remote User Agent using >>the REFER method. >> The actions that can be invoked by the REFER method are limited, and >>there is a need for more actions by some SIP applications. >> The purpose of this WG is to evaluate the various available mechanisms >>or proposed mechanism and recommend one or more of them, >> or define a new mechanism if none of the available are good enough to >>address this need. >> =20 >> The work group will need to address the following: >> * Clearly answer the following questions: >> a. What is "call control"? >> b. What is "device control"? >> * Will the new mechanism address "call control", "device control" or >>both? >> * Will the new mechanism be a SIP or a non-SIP based mechanism? >> * If a non-SIP mechanism is used, how to deal with the fact that some >>of these >> actions already covered by the SIP REFER method and widely used in >>the industry >> * Define a model for the actions >> * Define a scope for the actions >> * Define a set of initial actions that can be later extended, if needed. >> * Others? >> =20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From petithug@acm.org Wed Sep 28 14:38:11 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2811E80D0; Wed, 28 Sep 2011 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoKvABzHIEmI; Wed, 28 Sep 2011 14:38:10 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9E11E80A1; Wed, 28 Sep 2011 14:38:10 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C2DF2208BA; Wed, 28 Sep 2011 21:34:25 +0000 (UTC) Message-ID: <4E839468.8000500@acm.org> Date: Wed, 28 Sep 2011 14:40:56 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13 MIME-Version: 1.0 To: DISPATCH list X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: [dispatch] Fwd: I-D Action: draft-petithuguenin-dispatch-unique-overlay-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: DISPATCH list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 21:38:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just published a short I-D describing a special kind of peer-to-peer overlay, and listing some of the requirements for a mechanism to find the bootstrap servers for these overlays. The goal is to start a discussion on how to best solve this. Please follow-up in the dispatch mailing-list. Thanks. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-dispatch-unique-overlay-00.txt Date: Wed, 28 Sep 2011 14:33:59 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Infrastructure Overlay Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-dispatch-unique-overlay-00.txt Pages : 5 Date : 2011-09-28 This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6DlGAACgkQ9RoMZyVa61dsmQCfeoHjJURinb7fQTqNcAqbSQJh kTkAn0RexWNjy9Dc2a/6XA1EauwfwhL2 =/D29 -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Thu Sep 29 16:23:08 2011 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4D21F8B22 for ; Thu, 29 Sep 2011 16:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic9BTZJeg6mk for ; Thu, 29 Sep 2011 16:23:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D37D121F8B1A for ; Thu, 29 Sep 2011 16:23:07 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1348251vcb.31 for ; Thu, 29 Sep 2011 16:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nU2V9giLmu20oLsDEodcAPaADc+wfe3OJm3OX/wAZ20=; b=iqyoO5rBU5mrFfHXb16dETTUft6n3Z/QR2bg8PiApw9tNffpnSGAMdsYlcU9V1yDXt 6Opav7iF9sVuFVVg6CqTLzy9+4xOwt9Y27oT6j5yDtEcKRQ5uWo/l6bDVsEyl1s/E23C KzcOE1ndIgGpZ7n8md7hUuVGXbkcIZW9spDuY= MIME-Version: 1.0 Received: by 10.52.34.129 with SMTP id z1mr1150776vdi.157.1317338758777; Thu, 29 Sep 2011 16:25:58 -0700 (PDT) Received: by 10.52.160.136 with HTTP; Thu, 29 Sep 2011 16:25:58 -0700 (PDT) In-Reply-To: <20110929211207.7B31E21F8C22@ietfa.amsl.com> References: <20110929211207.7B31E21F8C22@ietfa.amsl.com> Date: Thu, 29 Sep 2011 18:25:58 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=20cf30780e6ac40c7004ae1cd456 Subject: [dispatch] Fwd: New Non-WG Mailing List: dcon -- Distributed Conferencing BOF discussion list X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 23:23:08 -0000 --20cf30780e6ac40c7004ae1cd456 Content-Type: text/plain; charset=ISO-8859-1 FYI... ---------- Forwarded message ---------- From: IETF Secretariat Date: Thu, Sep 29, 2011 at 4:12 PM Subject: New Non-WG Mailing List: dcon -- Distributed Conferencing BOF discussion list To: IETF Announcement list A new IETF non-working group email list has been created. List address: dcon@ietf.org Archive: http://www.ietf.org/mail-archive/web/dcon/ To subscribe: https://www.ietf.org/mailman/listinfo/dcon Purpose: This list is for discussions relating to the potential setup of a new IETF working group devoted to Distributed Conferencing. For additional information, please contact the list administrators. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --20cf30780e6ac40c7004ae1cd456 Content-Type: text/html; charset=ISO-8859-1 FYI...

---------- Forwarded message ----------
From: IETF Secretariat <ietf-secretariat@ietf.org>
Date: Thu, Sep 29, 2011 at 4:12 PM
Subject: New Non-WG Mailing List: dcon -- Distributed Conferencing BOF discussion list
To: IETF Announcement list <ietf-announce@ietf.org>



A new IETF non-working group email list has been created.

List address: dcon@ietf.org
Archive: http://www.ietf.org/mail-archive/web/dcon/
To subscribe: https://www.ietf.org/mailman/listinfo/dcon

Purpose: This list is for discussions relating to the potential setup of a new IETF working group devoted to Distributed Conferencing.

For additional information, please contact the list administrators.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--20cf30780e6ac40c7004ae1cd456--