From mary.ietf.barnes@gmail.com  Fri Aug  2 06:29:59 2013
Return-Path: <mary.ietf.barnes@gmail.com>
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 7C3E911E82B9 for <dispatch@ietfa.amsl.com>; Fri,  2 Aug 2013 06:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.328
X-Spam-Level: 
X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WjwlleGTqArU for <dispatch@ietfa.amsl.com>; Fri,  2 Aug 2013 06:29:58 -0700 (PDT)
Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 73DC321F9A30 for <dispatch@ietf.org>; Fri,  2 Aug 2013 06:29:40 -0700 (PDT)
Received: by mail-qe0-f53.google.com with SMTP id f6so325424qej.12 for <dispatch@ietf.org>; Fri, 02 Aug 2013 06:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=qeCyJBa25hILFwaZspTVegcxSTLB1LkASTF83BhSIq8=; b=YJHfJYZX+w+mCVOGoA8Pt630DOrzqJIBhk8TX88+oT6MvwJwovK0KwPU7uEnCXePPz LSW+gkDUlgJ86X3e/gf4AUQ97HJLg5TOTLPrG5szEoZZBGC3BvxzvC4fmMm23Gp4+S0x wP4XHQbmIOAvABz8AyH146gDOhvcLCcK77APu4gM3lmM8rMsdoDoUFdk46CvT+R6jGMU tNWSWOjh1ujpAHYkqwBLzXt1Wj7mRgnfRtHapMYmfwrWNoaWbX+saAVXWQIrnr4cYQz4 vBAr/jLqz/X2S0tpV+Gjkb0l/u2SFWOyMhuIoPr6FZEZCZftHOWnT2m/PMzZSZDkaBKN WIKw==
MIME-Version: 1.0
X-Received: by 10.224.126.129 with SMTP id c1mr11010626qas.93.1375450177124; Fri, 02 Aug 2013 06:29:37 -0700 (PDT)
Received: by 10.49.48.36 with HTTP; Fri, 2 Aug 2013 06:29:37 -0700 (PDT)
Date: Fri, 2 Aug 2013 08:29:37 -0500
Message-ID: <CAHBDyN6qbAH++EfytFakCA2XG1_74K8z11rDEZ+Xiw_f2Pbywg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2e32836bdaf04e2f6f31f
Cc: "rai-ads@tools.ietf.org" <rai-ads@tools.ietf.org>
Subject: [dispatch] DISPATCH WG Deadlines for IETF-88
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2013 13:30:00 -0000

--001a11c2e32836bdaf04e2f6f31f
Content-Type: text/plain; charset=ISO-8859-1

As mentioned in other WGs this week, the IETF-88 meeting will approach very
quickly.  Here are the complete deadlines:
http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88

I have updated the DISPATCH WG wiki based on those dates:
http://trac.tools.ietf.org/wg/dispatch/trac/wiki/WikiStart

I will also update the IETF-87 section to reflect some of the documents
that we dispatched after the IETF-87 deadlines.


Mary.

--001a11c2e32836bdaf04e2f6f31f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As mentioned in other WGs this week, the IETF-88 meeting w=
ill approach very quickly. =A0Here are the complete deadlines: =A0<a href=
=3D"http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88">http://www.i=
etf.org/meeting/cutoff-dates-2013.html#IETF88</a><div>
<br><div><div>I have updated the DISPATCH WG wiki based on those dates:=A0<=
/div><div><a href=3D"http://trac.tools.ietf.org/wg/dispatch/trac/wiki/WikiS=
tart">http://trac.tools.ietf.org/wg/dispatch/trac/wiki/WikiStart</a><br></d=
iv>
<div><br></div><div>I will also update the IETF-87 section to reflect some =
of the documents that we dispatched after the IETF-87 deadlines.</div><div>=
<br></div><div><br></div><div>Mary.</div><div><br></div><div><br></div>
</div></div></div>

--001a11c2e32836bdaf04e2f6f31f--

From worley@shell01.TheWorld.com  Fri Aug  2 14:14:31 2013
Return-Path: <worley@shell01.TheWorld.com>
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 8689411E8109 for <dispatch@ietfa.amsl.com>; Fri,  2 Aug 2013 14:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.402,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 KydWctVlkE+l for <dispatch@ietfa.amsl.com>; Fri,  2 Aug 2013 14:14:25 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3321E8050 for <dispatch@ietf.org>; Fri,  2 Aug 2013 14:14:22 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r72LEGJU019138 for <dispatch@ietf.org>; Fri, 2 Aug 2013 17:14:19 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r72LEGTa408277 for <dispatch@ietf.org>; Fri, 2 Aug 2013 17:14:16 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r72LEDpk405539; Fri, 2 Aug 2013 17:14:13 -0400 (EDT)
Date: Fri, 2 Aug 2013 17:14:13 -0400 (EDT)
Message-Id: <201308022114.r72LEDpk405539@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: dispatch@ietf.org
Subject: [dispatch] draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2013 21:14:31 -0000

This discusses a number of things that I think could be improved in
the current draft:

As has been mentioned before, the current draft doesn't really conform
to the SIP event model.  One way to fix that is to consider that the
"state" is really the (potentially unlimited) list of diversion
events.  Thus, when a *new* diversion happens, the state changes and a
notification should be generated.

This means that the length of notifications could grow without limit,
which is not desirable.

One fix would be to define "full" and "partial" notifications such
that a "partial" notification contains only the additional elements
added to the list since the last full or partial notification.  These
notifications will usually contain exactly exactly one diversion.

This also solves a problem regarding rate-limiting of notifications:
The draft says that notifications should be sent at most every 5
seconds, but it doesn't specify what is to be done if notifiable
diversions happen more often than once every 5 seconds.  In principle,
the notifier could get arbitrarily far behind in sending
notifications.  In the new method, very frequehnt diversions would not
cause more frequent notifications, but many notifications would list
more than one diversion.

But full notifications would still grow without limit.  That could be
limited by prescribing that every time the subscriber re-subscribes,
it must update the selection criteria start-time to be the latest time
of any diversion it's seen.  That would ensure that most re-subscribes
would receive a NOTIFY that contains no diversions; after that, full
notifications would grow from zero.

You would also want to allow the notifier to forget history that was
sufficiently far in the past, so that even a subscriber that asks for
diversion history since 1970 can receive only a limited amount of
data.  Perhaps that can be just written into the text, but in a
perfect world, part of the state would be the current date/time before
which the notifier no longer has history (regarding the directory
number that is being watched).  (You'd want to specify that changes in
the cutoff date/time alone would not trigger notification.)  The
notifier would gradully time-out diversion information that was too
old to be practically significant, that is, which you don't need a
subscriber to be able to access.

I notice that if two calls *from* the same directory number, *to* the
same directory number are diverted for the same reason, at the same
second, for the same reason, they produce identical
<comm-div-ntfy-info> elements.  That would make it difficult for the
subscriber to distinguish that it has received two notifications
rather than one.  I would suggest adding an "id" element as is used in
the "reg" and "dialog" event packages.  Since the "id" value is an
arbitrary string, the notifier can generate it as an encoding of
whatever internal identifier it uses to identify diversion events,
which should be efficient to implement.

I'm not sure what the <previous-cdivn-state> element is intended to
do.  It appears that there are two levels of filtering, "selection"
and "notification".  As written, the previous-cdivn-state tells
whether there was a selected-but-non-notifiable diversion between the
previous selected-and-notifiable diversion and the current
selected-and-notifiable diversion.  It's not clear to me why this is
useful to the subscriber, or whether the subscriber wants to know when
the previous-cdivn-state value changes due to a non-notifiable
diversion.  I think it would help if you explained what its ultimate
purpose is; it's possible that the design could be made more useful
relative to that purpose.

Dale

From fas_vm@surguttel.ru  Mon Aug 26 06:54:07 2013
Return-Path: <fas_vm@surguttel.ru>
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 32AC321F9CDA for <dispatch@ietfa.amsl.com>; Mon, 26 Aug 2013 06:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.135
X-Spam-Level: **
X-Spam-Status: No, score=2.135 tagged_above=-999 required=5 tests=[AWL=-0.329,  BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=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 IuE6aZOMIMCW for <dispatch@ietfa.amsl.com>; Mon, 26 Aug 2013 06:54:01 -0700 (PDT)
Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0C321F99CD for <dispatch@ietf.org>; Mon, 26 Aug 2013 06:53:52 -0700 (PDT)
Received: by mail.s86.ru (Postfix, from userid 1116) id A362A5149FE; Mon, 26 Aug 2013 19:53:49 +0600 (YEKT)
Received: from Gateway (unknown [151.252.73.84]) by mail.s86.ru (Postfix) with ESMTPA id 7CDD95149D9 for <dispatch@ietf.org>; Mon, 26 Aug 2013 19:53:46 +0600 (YEKT)
Message-ID: <1C8D7B8DC8A24FCAB8F79E9BCB22BF0D@Gateway>
From: "Anton Tveretin" <fas_vm@surguttel.ru>
To: <dispatch@ietf.org>
Date: Mon, 26 Aug 2013 00:07:02 +0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Antivirus: avast! (VPS 130826-0, 26.08.2013), Outbound message
X-Antivirus-Status: Clean
Subject: [dispatch] SIP Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2013 13:54:08 -0000

Hello All,
Maybe this is wrong WG (sipcore would be better). But I have some notes on 
SIP (and VoIP in general) future development. At least I want that.
I dare even to say that telephone wasn't invented by Bell; it is uninvented 
yet. ;)

1. Support for call pick-up, and other remote call control (remote call 
rejection, remote answering).
 Note: I am working on an I-D for this (over 25 years...). I suggest a new 
method, PICKUP.
One more note: call pick-up is specified for H.323 (H.450.5), and DPNSS1 
defines all remote call control.
2. Easy conferences without any supporting infrastructure, similar to H.323, 
as opposed to RFC 4575etc.
No way to join a SIP conference in the same way as H.323.
Note: may require to normatively update existing RFCs.
3. Standard call management codes, as GSM USSD.
4. Tons of headers, with arbitrary grouping of parameters (see my earlier 
post on From: and To:), and redundancy.
Example: transaction-id in Via: header and a pair of dialog-id, CSeq, which 
also uniquely indentifies a transaction.
5. Overload of INVITE with much potentially unused data (e.g. Caller-name 
when it is not displayed).
The same is true for SS7 and H.323.
Proposed solution: inquire some data only when needed; specify an 
Info-package for this.
6. D-channel bearer equivalent. I guess it is really undesired. Or, specify 
an Info-package.
7. True P2P (no infrastructure). Based on IP multicast.This is out of scope 
of current P2PSIP WG.

Any comments? Clearly, 4 is for next versions of SIP (if ever), maybe 6G 
(tm).

Sincerely yours,
Anton


From mary.ietf.barnes@gmail.com  Mon Aug 26 14:14:39 2013
Return-Path: <mary.ietf.barnes@gmail.com>
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 24EA321F9DB8 for <dispatch@ietfa.amsl.com>; Mon, 26 Aug 2013 14:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.579
X-Spam-Level: 
X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 Pab8ToiF90-m for <dispatch@ietfa.amsl.com>; Mon, 26 Aug 2013 14:14:38 -0700 (PDT)
Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 34EF321F9E88 for <dispatch@ietf.org>; Mon, 26 Aug 2013 14:14:38 -0700 (PDT)
Received: by mail-qe0-f54.google.com with SMTP id i11so2134149qej.27 for <dispatch@ietf.org>; Mon, 26 Aug 2013 14:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lJebWBY3OtqMjAVydfmY2wLVOb6kowFo4DHf74XH8tw=; b=o3h+Im2aCMuoA5a0dAc6JKRxJ1FzR7d/XqXvJtyVrwHa1sirnB8ePCiDihc+Xg7YS1 jbgceCBP9bCY7nehMHe1PAc6dvzPX043TMeSbsWn63Rg2kXpw6TSlAsvNx2LRolXpkuv Hp+wSBeRcc8iKXCuxyd/8eXcyR0laGIktQTQsLywIZtxq0PsFFhbpuA9NhOWa5PgjvOE qnerW9tu92jSegoPIQpDtfphYMCg2HWP6WJIqi0FFRjMv5Hnb4KMp8e3ZbGIF0QIhsK5 tRXKpmcb3/CGAg5VF44Fq/ARMhbDiSM6O2FeWbPibqxr4hi/PTsUPgcTXU8ctICWAJcm HRNg==
MIME-Version: 1.0
X-Received: by 10.224.126.129 with SMTP id c1mr3817535qas.93.1377551677648; Mon, 26 Aug 2013 14:14:37 -0700 (PDT)
Received: by 10.49.71.243 with HTTP; Mon, 26 Aug 2013 14:14:37 -0700 (PDT)
In-Reply-To: <1C8D7B8DC8A24FCAB8F79E9BCB22BF0D@Gateway>
References: <1C8D7B8DC8A24FCAB8F79E9BCB22BF0D@Gateway>
Date: Mon, 26 Aug 2013 16:14:37 -0500
Message-ID: <CAHBDyN5eTg1SagkT-4q+e9nMbwP-2aX4wTdWke8RnA3zE9EbKQ@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Anton Tveretin <fas_vm@surguttel.ru>
Content-Type: multipart/alternative; boundary=001a11c2e32867fff204e4e03eae
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] SIP Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2013 21:14:39 -0000

--001a11c2e32867fff204e4e03eae
Content-Type: text/plain; charset=ISO-8859-1

Generally, new works should be run through the DISPATCH WG.  I have a few
comments about some of your suggestions below [MB].

While we don't explicitly require drafts for topics, we do REQUIRE a clear
problem state and motivation for doing any new work.  Some of your
suggestions jump right into solutions, so it's not possible to discern the
real problem you are intending to solve with each of your suggestions.
You might consider writing some drafts.

Also, you should do a bit of homework - googling ietf and sip along with
some of your desired features will lead you to past work.  It's really
important you look at that to understand why you are unlikely to get some
of your proposals accepted or why there just won't be enough momentum for
IETF to take on the work.

Regards,
Mary
DISPATCH WG co-chair


On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin <fas_vm@surguttel.ru> wrote:

> Hello All,
> Maybe this is wrong WG (sipcore would be better). But I have some notes on
> SIP (and VoIP in general) future development. At least I want that.
> I dare even to say that telephone wasn't invented by Bell; it is
> uninvented yet. ;)
>
> 1. Support for call pick-up, and other remote call control (remote call
> rejection, remote answering).
> Note: I am working on an I-D for this (over 25 years...). I suggest a new
> method, PICKUP.
> One more note: call pick-up is specified for H.323 (H.450.5), and DPNSS1
> defines all remote call control.
>
[MB]  There have been proposals for call park and call pickup. You can see
here why the work was not progressed:
http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html
Also, Google ietf sip remote call control.  There are a number of proposal
in the past for remote call control.  We've never had success in getting
the proposals agreed for a variety of reasons.  It's also important to note
that equivalency with H.323 was never a core requirement for SIP protocol
development.  You might want to look at the work in IMTC where they have a
profile for SIP that supports some of the h.323 functionality.  They sent a
liaison statement in the past.

2. Easy conferences without any supporting infrastructure, similar to
> H.323, as opposed to RFC 4575etc.
> No way to join a SIP conference in the same way as H.323.
> Note: may require to normatively update existing RFCs.
>
[MB] It's not at all clear to me what functionality you are asking for.
[/MB]


> 3. Standard call management codes, as GSM USSD.
>
[MB] I have no idea what you mean here.  [/MB]


> 4. Tons of headers, with arbitrary grouping of parameters (see my earlier
> post on From: and To:), and redundancy.
> Example: transaction-id in Via: header and a pair of dialog-id, CSeq,
> which also uniquely indentifies a transaction



> 5. Overload of INVITE with much potentially unused data (e.g. Caller-name
> when it is not displayed).
> The same is true for SS7 and H.323.
> Proposed solution: inquire some data only when needed; specify an
> Info-package for this.
>
[MB] Again, we would need more details.  I think you are suggested we
should make some mandatory headers optional.  If that's what you're looking
for, then you need to provide ALOT of motivation. [/MB]

6. D-channel bearer equivalent. I guess it is really undesired. Or, specify
> an Info-package.
>


> 7. True P2P (no infrastructure). Based on IP multicast.This is out of
> scope of current P2PSIP WG.


> Any comments? Clearly, 4 is for next versions of SIP (if ever), maybe 6G
> (tm).
>
> Sincerely yours,
> Anton
>
> ______________________________**_________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>

--001a11c2e32867fff204e4e03eae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Generally, new works should be run through the DISPATCH WG=
. =A0I have a few comments about some of your suggestions below [MB].=A0<di=
v><br><div>While we don&#39;t explicitly require drafts for topics, we do R=
EQUIRE a clear problem state and motivation for doing any new work. =A0Some=
 of your suggestions jump right into solutions, so it&#39;s not possible to=
 discern the real problem you are intending to solve with each of your sugg=
estions. =A0 You might consider writing some drafts.=A0</div>
<div><br></div><div>Also, you should do a bit of homework - googling ietf a=
nd sip along with some of your desired features will lead you to past work.=
 =A0It&#39;s really important you look at that to understand why you are un=
likely to get some of your proposals accepted or why there just won&#39;t b=
e enough momentum for IETF to take on the work.=A0</div>
<div>=A0</div><div>Regards,</div><div>Mary=A0</div><div>DISPATCH WG co-chai=
r</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun=
, Aug 25, 2013 at 1:07 PM, Anton Tveretin <span dir=3D"ltr">&lt;<a href=3D"=
mailto:fas_vm@surguttel.ru" target=3D"_blank">fas_vm@surguttel.ru</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;=
margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello All,<br>
Maybe this is wrong WG (sipcore would be better). But I have some notes on =
SIP (and VoIP in general) future development. At least I want that.<br>
I dare even to say that telephone wasn&#39;t invented by Bell; it is uninve=
nted yet. ;)<br>
<br>
1. Support for call pick-up, and other remote call control (remote call rej=
ection, remote answering).<br>
Note: I am working on an I-D for this (over 25 years...). I suggest a new m=
ethod, PICKUP.<br>
One more note: call pick-up is specified for H.323 (H.450.5), and DPNSS1 de=
fines all remote call control.<br></blockquote><div>[MB] =A0There have been=
 proposals for call park and call pickup. You can see here why the work was=
 not progressed:</div>
<div><a href=3D"http://www.ietf.org/mail-archive/web/bliss/current/msg01107=
.html">http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html</a>=
<br></div><div>Also,=A0Google ietf sip remote call control. =A0There are a =
number of proposal in the past for remote call control. =A0We&#39;ve never =
had success in getting the proposals agreed for a variety of reasons. =A0It=
&#39;s also important to note that equivalency with H.323 was never a core =
requirement for SIP protocol development. =A0You might want to look at the =
work in IMTC where they have a profile for SIP that supports some of the h.=
323 functionality. =A0They sent a liaison statement in the past.=A0<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin-top:=
0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex">

2. Easy conferences without any supporting infrastructure, similar to H.323=
, as opposed to RFC 4575etc.<br>
No way to join a SIP conference in the same way as H.323.<br>
Note: may require to normatively update existing RFCs.<br></blockquote><div=
>[MB] It&#39;s not at all clear to me what functionality you are asking for=
. [/MB]</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

3. Standard call management codes, as GSM USSD.<br></blockquote><div>[MB] I=
 have no idea what you mean here. =A0[/MB]</div><div>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom=
:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">

4. Tons of headers, with arbitrary grouping of parameters (see my earlier p=
ost on From: and To:), and redundancy.<br>
Example: transaction-id in Via: header and a pair of dialog-id, CSeq, which=
 also uniquely indentifies a transaction</blockquote><div>=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-b=
ottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204=
,204,204);border-left-style:solid;padding-left:1ex">

5. Overload of INVITE with much potentially unused data (e.g. Caller-name w=
hen it is not displayed).<br>
The same is true for SS7 and H.323.<br>
Proposed solution: inquire some data only when needed; specify an Info-pack=
age for this.<br></blockquote><div>[MB] Again, we would need more details. =
=A0I think you are suggested we should make some mandatory headers optional=
. =A0If that&#39;s what you&#39;re looking for, then you need to provide AL=
OT of motivation. [/MB]=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;ma=
rgin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

6. D-channel bearer equivalent. I guess it is really undesired. Or, specify=
 an Info-package.<br></blockquote><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-le=
ft:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">

7. True P2P (no infrastructure). Based on IP multicast.This is out of scope=
 of current P2PSIP WG.=A0</blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex">

<br>
Any comments? Clearly, 4 is for next versions of SIP (if ever), maybe 6G (t=
m).<br>
<br>
Sincerely yours,<br>
Anton<br>
<br>
______________________________<u></u>_________________<br>
dispatch mailing list<br>
<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a=
><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank=
">https://www.ietf.org/mailman/<u></u>listinfo/dispatch</a><br>
</blockquote></div><br></div></div></div>

--001a11c2e32867fff204e4e03eae--

From pkyzivat@alum.mit.edu  Tue Aug 27 09:32:19 2013
Return-Path: <pkyzivat@alum.mit.edu>
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 677E711E8348 for <dispatch@ietfa.amsl.com>; Tue, 27 Aug 2013 09:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.311
X-Spam-Level: 
X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.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 nRejLCXVV72u for <dispatch@ietfa.amsl.com>; Tue, 27 Aug 2013 09:32:13 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F09B11E8261 for <dispatch@ietf.org>; Tue, 27 Aug 2013 09:32:08 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id Hnou1m0031c6gX858sY7bM; Tue, 27 Aug 2013 16:32:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id HsY71m00N3ZTu2S3jsY78R; Tue, 27 Aug 2013 16:32:07 +0000
Message-ID: <521CD486.3050105@alum.mit.edu>
Date: Tue, 27 Aug 2013 12:32:06 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: dispatch@ietf.org
References: <1C8D7B8DC8A24FCAB8F79E9BCB22BF0D@Gateway> <CAHBDyN5eTg1SagkT-4q+e9nMbwP-2aX4wTdWke8RnA3zE9EbKQ@mail.gmail.com>
In-Reply-To: <CAHBDyN5eTg1SagkT-4q+e9nMbwP-2aX4wTdWke8RnA3zE9EbKQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377621127; bh=cr7nsbh1vmnbUy1qiUY/YHgSbC8rDqjhZOfwTYIcKbo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ngChs95PP+51DsCXXXsMM3e0qzFFvtWbi6KA0ytGBH5GnwqlnSXoKKKYKyE+3sqao Quju5KI056uReWH8GOiBeFsT/QPrOaSewENkgIewhloekGZr9CfihUiaDT1xcT+3rA fIji+7uwrt5S04Fq2AfUpT/RLsbJLPa1ZwSwBP7oHpZDRWG1hS/E0AUlsK1xu6+C/+ 3s/c/jsth1oz/qYjIcd6vYew1vmCKh4uusikDK13vG1ppycHsFLHfQwFoMvC9jqiMO CoEloZnzpmaKBIjtsRecc+OQ/+n94pSFckmBRebzgeNniLH0eGGqkvMqOlowbtjoWY JhmwmOAhHDvXw==
Subject: Re: [dispatch] SIP Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 16:32:19 -0000

Where was this originally posted? (I don't think I got the original 
post, only this reply.)

Anton, I'm one of the chairs of SIPCORE. I agree that something like 
this should be first discussed on dispatch.

I won't go into the details of your message at this time, because there 
are meta-questions to address first.

I'd like to understand in general why you are posting this, and what 
sort of outcome you are expecting. What you seem to be suggesting sounds 
like a replacement, or a totally new version, of sip. People from time 
to time have expressed a wish to do a sip 3.0 that could fix many 
problems that are known with sip. But nobody talks about it very long, 
because pretty much everybody involved recognizes that there is no way 
to justify the work, or for such a think to be deployed if it were done.

If you want to consider something new and different, then I suggest you 
look into WebRTC/RTCWEB.

OTOH, if you have in mind incremental, backward compatible, changes to 
SIP, then I suggest you take out the stuff that doesn't fit that model.

	Thanks,
	Paul


On 8/26/13 5:14 PM, Mary Barnes wrote:
> Generally, new works should be run through the DISPATCH WG.  I have a
> few comments about some of your suggestions below [MB].
>
> While we don't explicitly require drafts for topics, we do REQUIRE a
> clear problem state and motivation for doing any new work.  Some of your
> suggestions jump right into solutions, so it's not possible to discern
> the real problem you are intending to solve with each of your
> suggestions.   You might consider writing some drafts.
>
> Also, you should do a bit of homework - googling ietf and sip along with
> some of your desired features will lead you to past work.  It's really
> important you look at that to understand why you are unlikely to get
> some of your proposals accepted or why there just won't be enough
> momentum for IETF to take on the work.
> Regards,
> Mary
> DISPATCH WG co-chair
>
>
> On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin <fas_vm@surguttel.ru
> <mailto:fas_vm@surguttel.ru>> wrote:
>
>     Hello All,
>     Maybe this is wrong WG (sipcore would be better). But I have some
>     notes on SIP (and VoIP in general) future development. At least I
>     want that.
>     I dare even to say that telephone wasn't invented by Bell; it is
>     uninvented yet. ;)
>
>     1. Support for call pick-up, and other remote call control (remote
>     call rejection, remote answering).
>     Note: I am working on an I-D for this (over 25 years...). I suggest
>     a new method, PICKUP.
>     One more note: call pick-up is specified for H.323 (H.450.5), and
>     DPNSS1 defines all remote call control.
>
> [MB]  There have been proposals for call park and call pickup. You can
> see here why the work was not progressed:
> http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html
> Also, Google ietf sip remote call control.  There are a number of
> proposal in the past for remote call control.  We've never had success
> in getting the proposals agreed for a variety of reasons.  It's also
> important to note that equivalency with H.323 was never a core
> requirement for SIP protocol development.  You might want to look at the
> work in IMTC where they have a profile for SIP that supports some of the
> h.323 functionality.  They sent a liaison statement in the past.
>
>     2. Easy conferences without any supporting infrastructure, similar
>     to H.323, as opposed to RFC 4575etc.
>     No way to join a SIP conference in the same way as H.323.
>     Note: may require to normatively update existing RFCs.
>
> [MB] It's not at all clear to me what functionality you are asking for.
> [/MB]
>
>     3. Standard call management codes, as GSM USSD.
>
> [MB] I have no idea what you mean here.  [/MB]
>
>     4. Tons of headers, with arbitrary grouping of parameters (see my
>     earlier post on From: and To:), and redundancy.
>     Example: transaction-id in Via: header and a pair of dialog-id,
>     CSeq, which also uniquely indentifies a transaction
>
>     5. Overload of INVITE with much potentially unused data (e.g.
>     Caller-name when it is not displayed).
>     The same is true for SS7 and H.323.
>     Proposed solution: inquire some data only when needed; specify an
>     Info-package for this.
>
> [MB] Again, we would need more details.  I think you are suggested we
> should make some mandatory headers optional.  If that's what you're
> looking for, then you need to provide ALOT of motivation. [/MB]
>
>     6. D-channel bearer equivalent. I guess it is really undesired. Or,
>     specify an Info-package.
>
>     7. True P2P (no infrastructure). Based on IP multicast.This is out
>     of scope of current P2PSIP WG.
>
>
>     Any comments? Clearly, 4 is for next versions of SIP (if ever),
>     maybe 6G (tm).
>
>     Sincerely yours,
>     Anton
>
>     _________________________________________________
>     dispatch mailing list
>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/dispatch
>     <https://www.ietf.org/mailman/listinfo/dispatch>
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>


From mary.ietf.barnes@gmail.com  Tue Aug 27 09:38:05 2013
Return-Path: <mary.ietf.barnes@gmail.com>
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 8B26111E8261 for <dispatch@ietfa.amsl.com>; Tue, 27 Aug 2013 09:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.569
X-Spam-Level: 
X-Spam-Status: No, score=-101.569 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 aqsIt8M+GqFD for <dispatch@ietfa.amsl.com>; Tue, 27 Aug 2013 09:37:55 -0700 (PDT)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5825511E83B8 for <dispatch@ietf.org>; Tue, 27 Aug 2013 09:37:10 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id a1so2740422qcx.31 for <dispatch@ietf.org>; Tue, 27 Aug 2013 09:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sqo9oRyy06a4D+oAtnmXTo60E8Yy3euN4x78DfnT7EU=; b=TSaDBfU0m28LKHWWp1XnwHAgSV/jZrkp3gkN3LiPRvXBtfNNEEbMRRvVWzM7Gnuy/f /kYuaJn1Qkh5WFv8bLicjosN/auV9sU+/n6BJZRhEh7ZEXsatRioBwTJmjNIK/dhLHck +HexOy1kvPiucQfJDG0LdK86ScysXflZyKEJAHf42/8Bk1gz4SOJtaz7KAPxvNK4yEbW Un3+rPk3w0zPryPwsK25ByqO4T305hmdQuukvQvQTW96RETGFeg37DXwLdPROU4RgCbG FoP2Y7wq3vCcJRe+2zcF7a2/RNmprzRIgcQPTMGFrptlu+PaWX7y0N/UnDbVwDK0hKj8 fd/w==
MIME-Version: 1.0
X-Received: by 10.224.114.11 with SMTP id c11mr23945730qaq.37.1377621430413; Tue, 27 Aug 2013 09:37:10 -0700 (PDT)
Received: by 10.49.71.243 with HTTP; Tue, 27 Aug 2013 09:37:10 -0700 (PDT)
In-Reply-To: <521CD486.3050105@alum.mit.edu>
References: <1C8D7B8DC8A24FCAB8F79E9BCB22BF0D@Gateway> <CAHBDyN5eTg1SagkT-4q+e9nMbwP-2aX4wTdWke8RnA3zE9EbKQ@mail.gmail.com> <521CD486.3050105@alum.mit.edu>
Date: Tue, 27 Aug 2013 11:37:10 -0500
Message-ID: <CAHBDyN7_6ut2S9EyQDTvkbA9GcaRviYTOK6Na7RLu_AReJGwsw@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=047d7bdc939cfeb93704e4f07b7e
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] SIP Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 16:38:09 -0000

--047d7bdc939cfeb93704e4f07b7e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Aug 27, 2013 at 11:32 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>wrote:

> Where was this originally posted? (I don't think I got the original post,
> only this reply.)
>
[MB] It was posted to the DISPATCH WG mailing list two days ago (you may
need to check your spam filters on your mit account as this doesn't seem
the first time you've missed some email ;)
http://www.ietf.org/mail-archive/web/dispatch/current/msg05017.html
[/MB]

>
> Anton, I'm one of the chairs of SIPCORE. I agree that something like this
> should be first discussed on dispatch.
>
> I won't go into the details of your message at this time, because there
> are meta-questions to address first.
>
> I'd like to understand in general why you are posting this, and what sort
> of outcome you are expecting. What you seem to be suggesting sounds like a
> replacement, or a totally new version, of sip. People from time to time
> have expressed a wish to do a sip 3.0 that could fix many problems that are
> known with sip. But nobody talks about it very long, because pretty much
> everybody involved recognizes that there is no way to justify the work, or
> for such a think to be deployed if it were done.
>
> If you want to consider something new and different, then I suggest you
> look into WebRTC/RTCWEB.
>
> OTOH, if you have in mind incremental, backward compatible, changes to
> SIP, then I suggest you take out the stuff that doesn't fit that model.
>
>         Thanks,
>         Paul
>
>
>
> On 8/26/13 5:14 PM, Mary Barnes wrote:
>
>> Generally, new works should be run through the DISPATCH WG.  I have a
>> few comments about some of your suggestions below [MB].
>>
>> While we don't explicitly require drafts for topics, we do REQUIRE a
>> clear problem state and motivation for doing any new work.  Some of your
>> suggestions jump right into solutions, so it's not possible to discern
>> the real problem you are intending to solve with each of your
>> suggestions.   You might consider writing some drafts.
>>
>> Also, you should do a bit of homework - googling ietf and sip along with
>> some of your desired features will lead you to past work.  It's really
>> important you look at that to understand why you are unlikely to get
>> some of your proposals accepted or why there just won't be enough
>> momentum for IETF to take on the work.
>> Regards,
>> Mary
>> DISPATCH WG co-chair
>>
>>
>> On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin <fas_vm@surguttel.ru
>> <mailto:fas_vm@surguttel.ru>> wrote:
>>
>>     Hello All,
>>     Maybe this is wrong WG (sipcore would be better). But I have some
>>     notes on SIP (and VoIP in general) future development. At least I
>>     want that.
>>     I dare even to say that telephone wasn't invented by Bell; it is
>>     uninvented yet. ;)
>>
>>     1. Support for call pick-up, and other remote call control (remote
>>     call rejection, remote answering).
>>     Note: I am working on an I-D for this (over 25 years...). I suggest
>>     a new method, PICKUP.
>>     One more note: call pick-up is specified for H.323 (H.450.5), and
>>     DPNSS1 defines all remote call control.
>>
>> [MB]  There have been proposals for call park and call pickup. You can
>> see here why the work was not progressed:
>> http://www.ietf.org/mail-**archive/web/bliss/current/**msg01107.html<http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html>
>> Also, Google ietf sip remote call control.  There are a number of
>> proposal in the past for remote call control.  We've never had success
>> in getting the proposals agreed for a variety of reasons.  It's also
>> important to note that equivalency with H.323 was never a core
>> requirement for SIP protocol development.  You might want to look at the
>> work in IMTC where they have a profile for SIP that supports some of the
>> h.323 functionality.  They sent a liaison statement in the past.
>>
>>     2. Easy conferences without any supporting infrastructure, similar
>>     to H.323, as opposed to RFC 4575etc.
>>     No way to join a SIP conference in the same way as H.323.
>>     Note: may require to normatively update existing RFCs.
>>
>> [MB] It's not at all clear to me what functionality you are asking for.
>> [/MB]
>>
>>     3. Standard call management codes, as GSM USSD.
>>
>> [MB] I have no idea what you mean here.  [/MB]
>>
>>     4. Tons of headers, with arbitrary grouping of parameters (see my
>>     earlier post on From: and To:), and redundancy.
>>     Example: transaction-id in Via: header and a pair of dialog-id,
>>     CSeq, which also uniquely indentifies a transaction
>>
>>     5. Overload of INVITE with much potentially unused data (e.g.
>>     Caller-name when it is not displayed).
>>     The same is true for SS7 and H.323.
>>     Proposed solution: inquire some data only when needed; specify an
>>     Info-package for this.
>>
>> [MB] Again, we would need more details.  I think you are suggested we
>> should make some mandatory headers optional.  If that's what you're
>> looking for, then you need to provide ALOT of motivation. [/MB]
>>
>>     6. D-channel bearer equivalent. I guess it is really undesired. Or,
>>     specify an Info-package.
>>
>>     7. True P2P (no infrastructure). Based on IP multicast.This is out
>>     of scope of current P2PSIP WG.
>>
>>
>>     Any comments? Clearly, 4 is for next versions of SIP (if ever),
>>     maybe 6G (tm).
>>
>>     Sincerely yours,
>>     Anton
>>
>>     ______________________________**___________________
>>     dispatch mailing list
>>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>>     https://www.ietf.org/mailman/_**_listinfo/dispatch<https://www.ietf.org/mailman/__listinfo/dispatch>
>>     <https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>> >
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>>
>>
> ______________________________**_________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>

--047d7bdc939cfeb93704e4f07b7e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra">On Tue, Aug 27, 2013 at 11:=
32 AM, Paul Kyzivat <span dir=3D"ltr">&lt;<a href=3D"mailto:pkyzivat@alum.m=
it.edu" target=3D"_blank">pkyzivat@alum.mit.edu</a>&gt;</span> wrote:<br><d=
iv class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;=
margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Where was this =
originally posted? (I don&#39;t think I got the original post, only this re=
ply.)<br>
</blockquote><div>[MB] It was posted to the DISPATCH WG mailing list two da=
ys ago (you may need to check your spam filters on your mit account as this=
 doesn&#39;t seem the first time you&#39;ve missed some email ;)</div><div>
<a href=3D"http://www.ietf.org/mail-archive/web/dispatch/current/msg05017.h=
tml">http://www.ietf.org/mail-archive/web/dispatch/current/msg05017.html</a=
></div><div>[/MB]<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

<br>
Anton, I&#39;m one of the chairs of SIPCORE. I agree that something like th=
is should be first discussed on dispatch.<br>
<br>
I won&#39;t go into the details of your message at this time, because there=
 are meta-questions to address first.<br>
<br>
I&#39;d like to understand in general why you are posting this, and what so=
rt of outcome you are expecting. What you seem to be suggesting sounds like=
 a replacement, or a totally new version, of sip. People from time to time =
have expressed a wish to do a sip 3.0 that could fix many problems that are=
 known with sip. But nobody talks about it very long, because pretty much e=
verybody involved recognizes that there is no way to justify the work, or f=
or such a think to be deployed if it were done.<br>

<br>
If you want to consider something new and different, then I suggest you loo=
k into WebRTC/RTCWEB.<br>
<br>
OTOH, if you have in mind incremental, backward compatible, changes to SIP,=
 then I suggest you take out the stuff that doesn&#39;t fit that model.<br>
<br>
=A0 =A0 =A0 =A0 Thanks,<br>
=A0 =A0 =A0 =A0 Paul<div class=3D"im"><br>
<br>
<br>
On 8/26/13 5:14 PM, Mary Barnes wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-righ=
t:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div clas=
s=3D"im">

Generally, new works should be run through the DISPATCH WG. =A0I have a<br>
few comments about some of your suggestions below [MB].<br>
<br>
While we don&#39;t explicitly require drafts for topics, we do REQUIRE a<br=
>
clear problem state and motivation for doing any new work. =A0Some of your<=
br>
suggestions jump right into solutions, so it&#39;s not possible to discern<=
br>
the real problem you are intending to solve with each of your<br>
suggestions. =A0 You might consider writing some drafts.<br>
<br>
Also, you should do a bit of homework - googling ietf and sip along with<br=
>
some of your desired features will lead you to past work. =A0It&#39;s reall=
y<br>
important you look at that to understand why you are unlikely to get<br>
some of your proposals accepted or why there just won&#39;t be enough<br>
momentum for IETF to take on the work.<br>
Regards,<br>
Mary<br>
DISPATCH WG co-chair<br>
<br>
<br>
On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin &lt;<a href=3D"mailto:fas_v=
m@surguttel.ru" target=3D"_blank">fas_vm@surguttel.ru</a><br></div><div><di=
v class=3D"h5">
&lt;mailto:<a href=3D"mailto:fas_vm@surguttel.ru" target=3D"_blank">fas_vm@=
surguttel.ru</a>&gt;&gt; wrote:<br>
<br>
=A0 =A0 Hello All,<br>
=A0 =A0 Maybe this is wrong WG (sipcore would be better). But I have some<b=
r>
=A0 =A0 notes on SIP (and VoIP in general) future development. At least I<b=
r>
=A0 =A0 want that.<br>
=A0 =A0 I dare even to say that telephone wasn&#39;t invented by Bell; it i=
s<br>
=A0 =A0 uninvented yet. ;)<br>
<br>
=A0 =A0 1. Support for call pick-up, and other remote call control (remote<=
br>
=A0 =A0 call rejection, remote answering).<br>
=A0 =A0 Note: I am working on an I-D for this (over 25 years...). I suggest=
<br>
=A0 =A0 a new method, PICKUP.<br>
=A0 =A0 One more note: call pick-up is specified for H.323 (H.450.5), and<b=
r>
=A0 =A0 DPNSS1 defines all remote call control.<br>
<br>
[MB] =A0There have been proposals for call park and call pickup. You can<br=
>
see here why the work was not progressed:<br>
<a href=3D"http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html=
" target=3D"_blank">http://www.ietf.org/mail-<u></u>archive/web/bliss/curre=
nt/<u></u>msg01107.html</a><br>
Also, Google ietf sip remote call control. =A0There are a number of<br>
proposal in the past for remote call control. =A0We&#39;ve never had succes=
s<br>
in getting the proposals agreed for a variety of reasons. =A0It&#39;s also<=
br>
important to note that equivalency with H.323 was never a core<br>
requirement for SIP protocol development. =A0You might want to look at the<=
br>
work in IMTC where they have a profile for SIP that supports some of the<br=
>
h.323 functionality. =A0They sent a liaison statement in the past.<br>
<br>
=A0 =A0 2. Easy conferences without any supporting infrastructure, similar<=
br>
=A0 =A0 to H.323, as opposed to RFC 4575etc.<br>
=A0 =A0 No way to join a SIP conference in the same way as H.323.<br>
=A0 =A0 Note: may require to normatively update existing RFCs.<br>
<br>
[MB] It&#39;s not at all clear to me what functionality you are asking for.=
<br>
[/MB]<br>
<br>
=A0 =A0 3. Standard call management codes, as GSM USSD.<br>
<br>
[MB] I have no idea what you mean here. =A0[/MB]<br>
<br>
=A0 =A0 4. Tons of headers, with arbitrary grouping of parameters (see my<b=
r>
=A0 =A0 earlier post on From: and To:), and redundancy.<br>
=A0 =A0 Example: transaction-id in Via: header and a pair of dialog-id,<br>
=A0 =A0 CSeq, which also uniquely indentifies a transaction<br>
<br>
=A0 =A0 5. Overload of INVITE with much potentially unused data (e.g.<br>
=A0 =A0 Caller-name when it is not displayed).<br>
=A0 =A0 The same is true for SS7 and H.323.<br>
=A0 =A0 Proposed solution: inquire some data only when needed; specify an<b=
r>
=A0 =A0 Info-package for this.<br>
<br>
[MB] Again, we would need more details. =A0I think you are suggested we<br>
should make some mandatory headers optional. =A0If that&#39;s what you&#39;=
re<br>
looking for, then you need to provide ALOT of motivation. [/MB]<br>
<br>
=A0 =A0 6. D-channel bearer equivalent. I guess it is really undesired. Or,=
<br>
=A0 =A0 specify an Info-package.<br>
<br>
=A0 =A0 7. True P2P (no infrastructure). Based on IP multicast.This is out<=
br>
=A0 =A0 of scope of current P2PSIP WG.<br>
<br>
<br>
=A0 =A0 Any comments? Clearly, 4 is for next versions of SIP (if ever),<br>
=A0 =A0 maybe 6G (tm).<br>
<br>
=A0 =A0 Sincerely yours,<br>
=A0 =A0 Anton<br>
<br></div></div>
=A0 =A0 ______________________________<u></u>___________________<br>
=A0 =A0 dispatch mailing list<br>
=A0 =A0 <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@iet=
f.org</a> &lt;mailto:<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank"=
>dispatch@ietf.org</a>&gt;<br>
=A0 =A0 <a href=3D"https://www.ietf.org/mailman/__listinfo/dispatch" target=
=3D"_blank">https://www.ietf.org/mailman/_<u></u>_listinfo/dispatch</a><br>
=A0 =A0 &lt;<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" targ=
et=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/dispatch</a>&gt;=
<div class=3D"im"><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
dispatch mailing list<br>
<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a=
><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank=
">https://www.ietf.org/mailman/<u></u>listinfo/dispatch</a><br>
<br>
</div></blockquote><div class=3D""><div class=3D"h5">
<br>
______________________________<u></u>_________________<br>
dispatch mailing list<br>
<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@ietf.org</a=
><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank=
">https://www.ietf.org/mailman/<u></u>listinfo/dispatch</a><br>
</div></div></blockquote></div><br></div></div>

--047d7bdc939cfeb93704e4f07b7e--

From keith.drage@alcatel-lucent.com  Tue Aug 27 10:22:46 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 C3D1421E809F for <dispatch@ietfa.amsl.com>; Tue, 27 Aug 2013 10:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.619
X-Spam-Level: 
X-Spam-Status: No, score=-110.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 93oxcA3hDqsz for <dispatch@ietfa.amsl.com>; Tue, 27 Aug 2013 10:22:41 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C921E80C6 for <dispatch@ietf.org>; Tue, 27 Aug 2013 10:22:37 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r7RHMXwu029374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Aug 2013 12:22:35 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r7RHMXYB025996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 19:22:33 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 27 Aug 2013 19:22:33 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] SIP Problem Statement
Thread-Index: AQHOomPJw4FaIw0lPEiK9yAeOEev8Jmn3DuAgAFDZQCAACfTMA==
Date: Tue, 27 Aug 2013 17:22:32 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B08976D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <1C8D7B8DC8A24FCAB8F79E9BCB22BF0D@Gateway> <CAHBDyN5eTg1SagkT-4q+e9nMbwP-2aX4wTdWke8RnA3zE9EbKQ@mail.gmail.com> <521CD486.3050105@alum.mit.edu>
In-Reply-To: <521CD486.3050105@alum.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [dispatch] SIP Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 17:22:47 -0000

I'd like to endorse the comments from Paul and Mary.

Some of these issues would need an entirely new protocol. I do concur with =
those issues, and anyone involved in telephony protocols in ITU would have =
clearly pointed out these problems - however they were not present at that =
early date. However I'm not seeing a marketplace for a one-for-one replacem=
ent for SIP at the moment.

As regards other stuff, generally do bear in mind that while SIP has forced=
 to become the carryall for pretty much everything, the IETF principle is t=
o split functionality between protocols on the basis that "small is beautif=
ul". That was the part of the basis for carving out the conference stuff as=
 a separate protocol. Identify the problem, but do not necessarily present =
it as if SIP was the only solution.

Regards

Keith





> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: 27 August 2013 17:32
> To: dispatch@ietf.org
> Subject: Re: [dispatch] SIP Problem Statement
>=20
> Where was this originally posted? (I don't think I got the original
> post, only this reply.)
>=20
> Anton, I'm one of the chairs of SIPCORE. I agree that something like
> this should be first discussed on dispatch.
>=20
> I won't go into the details of your message at this time, because there
> are meta-questions to address first.
>=20
> I'd like to understand in general why you are posting this, and what
> sort of outcome you are expecting. What you seem to be suggesting sounds
> like a replacement, or a totally new version, of sip. People from time
> to time have expressed a wish to do a sip 3.0 that could fix many
> problems that are known with sip. But nobody talks about it very long,
> because pretty much everybody involved recognizes that there is no way
> to justify the work, or for such a think to be deployed if it were done.
>=20
> If you want to consider something new and different, then I suggest you
> look into WebRTC/RTCWEB.
>=20
> OTOH, if you have in mind incremental, backward compatible, changes to
> SIP, then I suggest you take out the stuff that doesn't fit that model.
>=20
> 	Thanks,
> 	Paul
>=20
>=20
> On 8/26/13 5:14 PM, Mary Barnes wrote:
> > Generally, new works should be run through the DISPATCH WG.  I have a
> > few comments about some of your suggestions below [MB].
> >
> > While we don't explicitly require drafts for topics, we do REQUIRE a
> > clear problem state and motivation for doing any new work.  Some of you=
r
> > suggestions jump right into solutions, so it's not possible to discern
> > the real problem you are intending to solve with each of your
> > suggestions.   You might consider writing some drafts.
> >
> > Also, you should do a bit of homework - googling ietf and sip along wit=
h
> > some of your desired features will lead you to past work.  It's really
> > important you look at that to understand why you are unlikely to get
> > some of your proposals accepted or why there just won't be enough
> > momentum for IETF to take on the work.
> > Regards,
> > Mary
> > DISPATCH WG co-chair
> >
> >
> > On Sun, Aug 25, 2013 at 1:07 PM, Anton Tveretin <fas_vm@surguttel.ru
> > <mailto:fas_vm@surguttel.ru>> wrote:
> >
> >     Hello All,
> >     Maybe this is wrong WG (sipcore would be better). But I have some
> >     notes on SIP (and VoIP in general) future development. At least I
> >     want that.
> >     I dare even to say that telephone wasn't invented by Bell; it is
> >     uninvented yet. ;)
> >
> >     1. Support for call pick-up, and other remote call control (remote
> >     call rejection, remote answering).
> >     Note: I am working on an I-D for this (over 25 years...). I suggest
> >     a new method, PICKUP.
> >     One more note: call pick-up is specified for H.323 (H.450.5), and
> >     DPNSS1 defines all remote call control.
> >
> > [MB]  There have been proposals for call park and call pickup. You can
> > see here why the work was not progressed:
> > http://www.ietf.org/mail-archive/web/bliss/current/msg01107.html
> > Also, Google ietf sip remote call control.  There are a number of
> > proposal in the past for remote call control.  We've never had success
> > in getting the proposals agreed for a variety of reasons.  It's also
> > important to note that equivalency with H.323 was never a core
> > requirement for SIP protocol development.  You might want to look at th=
e
> > work in IMTC where they have a profile for SIP that supports some of th=
e
> > h.323 functionality.  They sent a liaison statement in the past.
> >
> >     2. Easy conferences without any supporting infrastructure, similar
> >     to H.323, as opposed to RFC 4575etc.
> >     No way to join a SIP conference in the same way as H.323.
> >     Note: may require to normatively update existing RFCs.
> >
> > [MB] It's not at all clear to me what functionality you are asking for.
> > [/MB]
> >
> >     3. Standard call management codes, as GSM USSD.
> >
> > [MB] I have no idea what you mean here.  [/MB]
> >
> >     4. Tons of headers, with arbitrary grouping of parameters (see my
> >     earlier post on From: and To:), and redundancy.
> >     Example: transaction-id in Via: header and a pair of dialog-id,
> >     CSeq, which also uniquely indentifies a transaction
> >
> >     5. Overload of INVITE with much potentially unused data (e.g.
> >     Caller-name when it is not displayed).
> >     The same is true for SS7 and H.323.
> >     Proposed solution: inquire some data only when needed; specify an
> >     Info-package for this.
> >
> > [MB] Again, we would need more details.  I think you are suggested we
> > should make some mandatory headers optional.  If that's what you're
> > looking for, then you need to provide ALOT of motivation. [/MB]
> >
> >     6. D-channel bearer equivalent. I guess it is really undesired. Or,
> >     specify an Info-package.
> >
> >     7. True P2P (no infrastructure). Based on IP multicast.This is out
> >     of scope of current P2PSIP WG.
> >
> >
> >     Any comments? Clearly, 4 is for next versions of SIP (if ever),
> >     maybe 6G (tm).
> >
> >     Sincerely yours,
> >     Anton
> >
> >     _________________________________________________
> >     dispatch mailing list
> >     dispatch@ietf.org <mailto:dispatch@ietf.org>
> >     https://www.ietf.org/mailman/__listinfo/dispatch
> >     <https://www.ietf.org/mailman/listinfo/dispatch>
> >
> >
> >
> >
> > _______________________________________________
> > 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 fluffy@iii.ca  Wed Aug 28 08:51:22 2013
Return-Path: <fluffy@iii.ca>
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 092E021E8064 for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 08:51:21 -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 lLbxrp0aBgFK for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 08:51:16 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCC021F9BD3 for <dispatch@ietf.org>; Wed, 28 Aug 2013 08:51:15 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 274AE50A88 for <dispatch@ietf.org>; Wed, 28 Aug 2013 11:51:08 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAHBDyN6qbAH++EfytFakCA2XG1_74K8z11rDEZ+Xiw_f2Pbywg@mail.gmail.com>
Date: Wed, 28 Aug 2013 09:51:03 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <06ECD53C-813F-4C36-A79C-624C3B431B40@iii.ca>
References: <CAHBDyN6qbAH++EfytFakCA2XG1_74K8z11rDEZ+Xiw_f2Pbywg@mail.gmail.com>
To: DISPATCH <dispatch@ietf.org>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [dispatch] DISPATCH WG Deadlines for IETF-88
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 15:51:22 -0000

Just reminding folks, deadline for dispatch is October 1.

On Aug 2, 2013, at 7:29 AM, Mary Barnes <mary.ietf.barnes@gmail.com> =
wrote:

> As mentioned in other WGs this week, the IETF-88 meeting will approach =
very quickly.  Here are the complete deadlines:  =
http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88
>=20
> I have updated the DISPATCH WG wiki based on those dates:=20
> http://trac.tools.ietf.org/wg/dispatch/trac/wiki/WikiStart
>=20
> I will also update the IETF-87 section to reflect some of the =
documents that we dispatched after the IETF-87 deadlines.
>=20
>=20
> Mary.
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From fluffy@cisco.com  Wed Aug 28 09:46:22 2013
Return-Path: <fluffy@cisco.com>
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 E218D11E81F7 for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 09:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.522
X-Spam-Level: 
X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LQBS3VVcnVTf for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 09:46:07 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A511E8239 for <dispatch@ietf.org>; Wed, 28 Aug 2013 09:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=415; q=dns/txt; s=iport; t=1377708360; x=1378917960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Qz+AimpGC9a9H6vGNXYWt0mcFfIc7Z7g2k4Xv7mFrI=; b=YeqV15G0C2nUjzY7fZaZB8MriYib6n7OjCaQ5aUGrPdEtKYLr7KbRiMz V5P0YkO7laB0kKBLDMN/u2n0tdJGG5FgWhyQ8TD/Yt5w+6kkUs2z6q/0i 5U58bITlWqSFr6YvmeBoRL4KZSVovPLuH68HIudAdEmCbIqODtN0XOoXl 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkcFAN0oHlKtJV2a/2dsb2JhbABbDoJ5gQaCYL1KgSAWdIIkAQEBAwE6PwULAgEIDhQUEDIlAgQOBQiHcwa5ZI8xAjEHgxx9A6lSgmE/gio
X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="252727193"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 28 Aug 2013 16:46:00 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7SGjxHw021142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 16:45:59 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 28 Aug 2013 11:45:59 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
Thread-Index: AQHOpA4S5OvbXVzIEUWmvHRSJNDyBQ==
Date: Wed, 28 Aug 2013 16:45:59 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com>
References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu>
In-Reply-To: <51F684D9.6040204@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <42587F483BABE142997AE6A986CB9921@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 16:46:23 -0000

On Jul 29, 2013, at 9:06 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> As sipcore co-chair, I also think sipcore will ultimately be the right pl=
ace for this.

Given it's been a month with no objections to this. I think we should consi=
der this successfully dispatched to sip core. If folks feel this was the wr=
ong decision, let the chairs know and we can fix/change/justify this decisi=
on.=20



From keith.drage@alcatel-lucent.com  Wed Aug 28 10:06:35 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 10D8D11E824A for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 10:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.613
X-Spam-Level: 
X-Spam-Status: No, score=-110.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 D8+kX+XVTZNg for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 10:06:29 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5842311E8286 for <dispatch@ietf.org>; Wed, 28 Aug 2013 10:06:18 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7SH6FhC020846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Aug 2013 12:06:16 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r7SH6CN7023164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 19:06:12 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 28 Aug 2013 19:06:12 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
Thread-Index: AQHOpA4S5OvbXVzIEUWmvHRSJNDyBZmq2TrA
Date: Wed, 28 Aug 2013 17:06:11 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B08A50B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 17:06:35 -0000

I assume that "dispatch" means the DISPATCH working group considers that SI=
PCORE is the appropriate place to study this. It is up to SIPCORE to gauge =
interest and decide if work is appropriate.

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: 28 August 2013 17:46
> To: Paul Kyzivat
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-
> response-00
>=20
>=20
> On Jul 29, 2013, at 9:06 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>=20
> > As sipcore co-chair, I also think sipcore will ultimately be the right
> place for this.
>=20
> Given it's been a month with no objections to this. I think we should
> consider this successfully dispatched to sip core. If folks feel this was
> the wrong decision, let the chairs know and we can fix/change/justify thi=
s
> decision.
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From mary.ietf.barnes@gmail.com  Wed Aug 28 10:12:35 2013
Return-Path: <mary.ietf.barnes@gmail.com>
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 3514E11E820F for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 10:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.391
X-Spam-Level: 
X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 30VGeXB7iBSe for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 10:12:34 -0700 (PDT)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 627B621F9FF3 for <dispatch@ietf.org>; Wed, 28 Aug 2013 10:12:34 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id w8so2371401qac.3 for <dispatch@ietf.org>; Wed, 28 Aug 2013 10:12:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bfG4ozKqSFKaQdX1mI4iLRfu1GuzoAdNHvw+6QbaZ7s=; b=byIlNQW81+Y1t9/LYJb2q96NIwDcFVixPq+aQ/PCQgj4MhLtA2AVipWgLkGwjexTf4 kqeQx9+YflJ+neD1at3K0MG43LOJrPhm1Sz95aTAjtBAQmW+JHCuH4GZbG3jN0eVLG+S /hhrTR9Ia/FczNz9viT3Fm0n7W/LFwY6o2lZjAZpa/qId0ChE3uCgENN/otIUPyZ14kp EwhNWRAd5eAHxhpRUTwCSqirCVET2WmYM5AbgIGsBUc0s4yr/H+gZs7L0qxwI8NDa0Y/ /DWhleY+9Tncubw96KUapHjWnYpf0szPMdY9+po9iIyMblB6SL/SXYGPCu8UISl3Wu60 lwTA==
MIME-Version: 1.0
X-Received: by 10.224.114.11 with SMTP id c11mr30978301qaq.37.1377709952828; Wed, 28 Aug 2013 10:12:32 -0700 (PDT)
Received: by 10.49.71.243 with HTTP; Wed, 28 Aug 2013 10:12:32 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B08A50B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com> <949EF20990823C4C85C18D59AA11AD8B08A50B@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Wed, 28 Aug 2013 12:12:32 -0500
Message-ID: <CAHBDyN7Md3rh4--AjVWaRpt866XiwXD7EHC52LgAbNsVBPokCA@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=047d7bdc939c578d4804e505186f
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 17:12:35 -0000

--047d7bdc939c578d4804e505186f
Content-Type: text/plain; charset=ISO-8859-1

Yes, as usual, when there is consensus in the DISPATCH WG as to an existing
WG that seems most appropriate for the work, it is then up to that WG to
make the decision as to whether the WG participants are interested in
working on that item. In which case, the WG chairs work with the ADs to get
it added to their charter. This is the exact way we handled the logging
requirements being dispatching to INSIPID.

Mary.


On Wed, Aug 28, 2013 at 12:06 PM, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

> I assume that "dispatch" means the DISPATCH working group considers that
> SIPCORE is the appropriate place to study this. It is up to SIPCORE to
> gauge interest and decide if work is appropriate.
>
> Keith
>
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> > Behalf Of Cullen Jennings (fluffy)
> > Sent: 28 August 2013 17:46
> > To: Paul Kyzivat
> > Cc: dispatch@ietf.org
> > Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-
> > response-00
> >
> >
> > On Jul 29, 2013, at 9:06 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> >
> > > As sipcore co-chair, I also think sipcore will ultimately be the right
> > place for this.
> >
> > Given it's been a month with no objections to this. I think we should
> > consider this successfully dispatched to sip core. If folks feel this was
> > the wrong decision, let the chairs know and we can fix/change/justify
> this
> > decision.
> >
> >
> > _______________________________________________
> > 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
>

--047d7bdc939c578d4804e505186f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, as usual, when there is consensus in the DISPATCH WG =
as to an existing WG that seems most appropriate for the work, it is then u=
p to that WG to make the decision as to whether the WG participants are int=
erested in working on that item. In which case, the WG chairs work with the=
 ADs to get it added to their charter. This is the exact way we handled the=
 logging requirements being dispatching to INSIPID. =A0<div>
<br></div><div>Mary.</div></div><div class=3D"gmail_extra"><br><br><div cla=
ss=3D"gmail_quote">On Wed, Aug 28, 2013 at 12:06 PM, DRAGE, Keith (Keith) <=
span dir=3D"ltr">&lt;<a href=3D"mailto:keith.drage@alcatel-lucent.com" targ=
et=3D"_blank">keith.drage@alcatel-lucent.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I assume that &quot;dispatch&quot; means the=
 DISPATCH working group considers that SIPCORE is the appropriate place to =
study this. It is up to SIPCORE to gauge interest and decide if work is app=
ropriate.<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Keith<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bounces@ie=
tf.org</a> [mailto:<a href=3D"mailto:dispatch-bounces@ietf.org">dispatch-bo=
unces@ietf.org</a>] On<br>
&gt; Behalf Of Cullen Jennings (fluffy)<br>
&gt; Sent: 28 August 2013 17:46<br>
&gt; To: Paul Kyzivat<br>
&gt; Cc: <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-20=
5-<br>
&gt; response-00<br>
&gt;<br>
&gt;<br>
&gt; On Jul 29, 2013, at 9:06 AM, Paul Kyzivat &lt;<a href=3D"mailto:pkyziv=
at@alum.mit.edu">pkyzivat@alum.mit.edu</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; As sipcore co-chair, I also think sipcore will ultimately be the =
right<br>
&gt; place for this.<br>
&gt;<br>
&gt; Given it&#39;s been a month with no objections to this. I think we sho=
uld<br>
&gt; consider this successfully dispatched to sip core. If folks feel this =
was<br>
&gt; the wrong decision, let the chairs know and we can fix/change/justify =
this<br>
&gt; decision.<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dispatch mailing list<br>
&gt; <a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br>
_______________________________________________<br>
dispatch mailing list<br>
<a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/dispatch</a><br>
</div></div></blockquote></div><br></div>

--047d7bdc939c578d4804e505186f--

From pkyzivat@alum.mit.edu  Wed Aug 28 10:28:13 2013
Return-Path: <pkyzivat@alum.mit.edu>
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 CF92311E81A9 for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 10:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.323
X-Spam-Level: 
X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.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 5uT3l7z6BV1Z for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 10:28:09 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 08BA121F9C32 for <dispatch@ietf.org>; Wed, 28 Aug 2013 10:28:08 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id JFEA1m00616LCl059HU8QP; Wed, 28 Aug 2013 17:28:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id JHU81m00R3ZTu2S3SHU8K4; Wed, 28 Aug 2013 17:28:08 +0000
Message-ID: <521E3328.2030005@alum.mit.edu>
Date: Wed, 28 Aug 2013 13:28:08 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com> <949EF20990823C4C85C18D59AA11AD8B08A50B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAHBDyN7Md3rh4--AjVWaRpt866XiwXD7EHC52LgAbNsVBPokCA@mail.gmail.com>
In-Reply-To: <CAHBDyN7Md3rh4--AjVWaRpt866XiwXD7EHC52LgAbNsVBPokCA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377710888; bh=86M5XV6EaCzQzhfxe2colRdI3QJsDOdG3JWvGiCyjuQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iHgpX4tZmSDOdil8FHBvZOJLiL/GnP5iFXfvE5M8/mDFVgWm67rEy32jNtXBoTh4G s2FJN4QVRZUDI21L5KvnQoKdTz03HzqLheBuSzN0vTiQ+heLs2juxdWfcRjNXDzMAa jCjpiDWcltN/mc0Nqv6nRnl7euVk4hFgNhkJxyUuT15om08CqKLiqHcxJhrD12/Chi w2ncP8olkT8rO/dTzSnjrUWedDaQO2WK2QZeEnOUEUI6dxNgIYFTH+YefS0FqWRkwb ke02jGC8ifXtcFsPhH+ipBBKHLtd7UpoeRHdVVARyzkW0qOQzTDqdm4E+4HVVz/Q07 +GoxbVBcjhesA==
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 17:28:14 -0000

I don't think we need a charter change to sipcore for this.

On 8/28/13 1:12 PM, Mary Barnes wrote:
> Yes, as usual, when there is consensus in the DISPATCH WG as to an
> existing WG that seems most appropriate for the work, it is then up to
> that WG to make the decision as to whether the WG participants are
> interested in working on that item. In which case, the WG chairs work
> with the ADs to get it added to their charter. This is the exact way we
> handled the logging requirements being dispatching to INSIPID.
>
> Mary.
>
>
> On Wed, Aug 28, 2013 at 12:06 PM, DRAGE, Keith (Keith)
> <keith.drage@alcatel-lucent.com <mailto:keith.drage@alcatel-lucent.com>>
> wrote:
>
>     I assume that "dispatch" means the DISPATCH working group considers
>     that SIPCORE is the appropriate place to study this. It is up to
>     SIPCORE to gauge interest and decide if work is appropriate.
>
>     Keith
>
>      > -----Original Message-----
>      > From: dispatch-bounces@ietf.org
>     <mailto:dispatch-bounces@ietf.org> [mailto:dispatch-bounces@ietf.org
>     <mailto:dispatch-bounces@ietf.org>] On
>      > Behalf Of Cullen Jennings (fluffy)
>      > Sent: 28 August 2013 17:46
>      > To: Paul Kyzivat
>      > Cc: dispatch@ietf.org <mailto:dispatch@ietf.org>
>      > Subject: Re: [dispatch] Dispatch request:
>     draft-kaplan-dispatch-sip-205-
>      > response-00
>      >
>      >
>      > On Jul 29, 2013, at 9:06 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>     <mailto:pkyzivat@alum.mit.edu>> wrote:
>      >
>      > > As sipcore co-chair, I also think sipcore will ultimately be
>     the right
>      > place for this.
>      >
>      > Given it's been a month with no objections to this. I think we should
>      > consider this successfully dispatched to sip core. If folks feel
>     this was
>      > the wrong decision, let the chairs know and we can
>     fix/change/justify this
>      > decision.
>      >
>      >
>      > _______________________________________________
>      > dispatch mailing list
>      > dispatch@ietf.org <mailto:dispatch@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/dispatch
>     _______________________________________________
>     dispatch mailing list
>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>


From jbakker@blackberry.com  Wed Aug 28 11:14:11 2013
Return-Path: <jbakker@blackberry.com>
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 4DE8B21F967F for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 11:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level: 
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[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 kq5B7KY3CNMc for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 11:14:06 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 50EA821E804D for <dispatch@ietf.org>; Wed, 28 Aug 2013 11:14:05 -0700 (PDT)
X-AuditID: 0a41282f-b7f8b6d000004656-4a-521e3de53805
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 12.AC.18006.5ED3E125; Wed, 28 Aug 2013 13:13:57 -0500 (CDT)
Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Wed, 28 Aug 2013 13:13:56 -0500
From: John-Luc Bakker <jbakker@blackberry.com>
To: "Dale R. Worley" <worley@ariadne.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: purpose <previous-cdivn-state> RE: [dispatch] draft-avasarala-dispatch-comm-div-notification
Thread-Index: Ac6jb/uAg4i1zjyQQIGYb63razl6FA==
Date: Wed, 28 Aug 2013 18:13:56 +0000
Message-ID: <155970D1DA8E174F9E46039E10E2AA35E7339B@XMB103ADS.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsXC5Zyvp/vUVi7IoPm4kMXSSQtYLV6eKHNg 8pi8/yuzx5IlP5kCmKIaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLLEpMrFVwyi5NzEjNz U4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66rZJnsL+u hYWppa6hkp0uEkj4x51xdc0uloLLNhV3en6zNzCuMOxi5OSQEDCROPXpMDOELSZx4d56NhBb SGAlo8Sx6QpdjFxA9lZGidnH94MVsQnoSayYvIoRxBYRCJH4PK0TzBYWSJf4+uERUxcjB1A8 R2LBB1+IEj2JQ3O/sIKEWQRUJfY84AcJ8wq4Sfyb0wTWyQi09vupNUwgNrOAuMStJ/OZIM4R kFiy5zzUaaISLx//Y4WwFSUet3SzQNTrSCzY/YkNwtaWWLbwNTPEfEGJkzOfsExgFJ6FZOws JC2zkLTMQtKygJFlFaNgbkaxgZlBcl6yXlFmrl5easkmRlBkO2ro72B8+97iEKMAB6MSD6+d mVyQEGtiWXFl7iFGCQ5mJRHe3yJAId6UxMqq1KL8+KLSnNTiQ4yuQM9PZJbiTs4HJp28knhj AwPcHCVxXleVD4FCAunA9JKdmlqQWgQzh4mDU6qB8bzLoWsnOe4e/L9vue2lFbtUShvPqpx+ Od3q+btVttsnOmp+KGF6+fRjTHDD41eVxduWdn9WtWVetU9jSrPk+k/d56Qe/vewfMe4sEEo cW/27yaDx27HRJouOs+502cbktsdbHpg7rHKCepzIjTcnrswMC/Y9ShMJqRM9Mzi2PcTuv9u e+N4yE2JpTgj0VCLuag4EQAnCuU2EgMAAA==
Subject: [dispatch] purpose <previous-cdivn-state> RE: draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 18:14:11 -0000

Hi Dale, 

Thanks for the response below.
You suggest various forms of state that could help conforming to the SIP eve=
nt model.
A number of e-mails have been received, many e-mails have questioned the sta=
te model used in this draft, whether it satisfies the SIP event model. There=
 are other issues too and I will come back to them separately.

The authors initially thought that the information in <previous-cdivn-state>=
 could be the state satisfying the SIP event model. 

I am not discounting the other examples of state but would like to first exp=
lain the reasoning behind the state indicated in <previous-cdivn-state>. It=
 might well be that this state indicated and maintained is not SIP event mod=
el compliant.

	<copied from Dale, below>
	I'm not sure what the <previous-cdivn-state> element is intended to do.  It=
 appears that there are two levels of filtering, 
	"selection" and "notification".  As written, the previous-cdivn-state tells=
 whether there was a selected-but-non-notifiable 
	diversion between the previous selected-and-notifiable diversion and the cu=
rrent selected-and-notifiable diversion.  It's 
	not clear to me why this is useful to the subscriber, or whether the subscr=
iber wants to know when the previous-cdivn-state 
	value changes due to a non-notifiable diversion.  I think it would help if=
 you explained what its ultimate purpose is; it's possible 
	that the design could be made more useful relative to that purpose.
	<end copy from Dale, below>

The initial motivation for CDIVN is "debugging" or analyses of communication=
 diversion rules (see "introduction" in the draft). Some state is needed in=
 the network enabling this analyses.
The proposed state is a ternary value and can take the following values IDLE=
, DIVERSION_NOTIFIED, DIVERSION_NOT_NOTIFIED:

   <copied from draft>
   The subscriber could receive, as part of the notification
   information, the state the FSM was in prior to detecting the
   diversion.

   o  [IDLE]: meaning that no diversions have occurred since setting the
      present "filter".

   o  [DIVERSION_NOTIFIED]: meaning that since receiving the last NOTIFY
      request for this event package, no additional diversions have
      occurred.

   o  [DIVERSION_NOT_NOTIFIED]: meaning that one or more diversions have
      occurred since setting the present "filter" or since receiving the
      last NOTIFY request for this event package.
   <end copy from draft>

The state has limited use to a user trying to understand communication diver=
sion rules. If a user receives an indication that diversions have happened f=
or which it did not receive a notification and the user had not expected the=
se diversions to happen, then the user can further "debug" the diversion and=
 notification filtering rules. The primary advantage of this rather limited=
 information is that the amount of state stored for a user subscribed to "co=
mmunication diversion" is limited, yet still enables "analyses". 

There is no 3GPP requirement to receive notification from all diversions tha=
t have happened in the past. That is, if a diversion wasn't notified due to=
 failing to meet conditions expressed in the notification filter, then there=
 is no requirement to be able to notify that diversion at a later stage.

Is the ternary value maintained at the NOTIFIER per CDIVN subscriber complia=
nt with the SIP event model?

Kind regards,

	JL

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf=
 Of Dale R. Worley
Sent: Friday, August 02, 2013 4:14 PM
To: dispatch@ietf.org
Subject: [dispatch] draft-avasarala-dispatch-comm-div-notification

This discusses a number of things that I think could be improved in the curr=
ent draft:

As has been mentioned before, the current draft doesn't really conform to th=
e SIP event model.  One way to fix that is to consider that the "state" is r=
eally the (potentially unlimited) list of diversion events.  Thus, when a *n=
ew* diversion happens, the state changes and a notification should be genera=
ted.

This means that the length of notifications could grow without limit, which=
 is not desirable.

One fix would be to define "full" and "partial" notifications such that a "p=
artial" notification contains only the additional elements added to the list=
 since the last full or partial notification.  These notifications will usua=
lly contain exactly exactly one diversion.

This also solves a problem regarding rate-limiting of notifications:
The draft says that notifications should be sent at most every 5 seconds, bu=
t it doesn't specify what is to be done if notifiable diversions happen more=
 often than once every 5 seconds.  In principle, the notifier could get arbi=
trarily far behind in sending notifications.  In the new method, very freque=
hnt diversions would not cause more frequent notifications, but many notific=
ations would list more than one diversion.

But full notifications would still grow without limit.  That could be limite=
d by prescribing that every time the subscriber re-subscribes, it must updat=
e the selection criteria start-time to be the latest time of any diversion i=
t's seen.  That would ensure that most re-subscribes would receive a NOTIFY=
 that contains no diversions; after that, full notifications would grow from=
 zero.

You would also want to allow the notifier to forget history that was suffici=
ently far in the past, so that even a subscriber that asks for diversion his=
tory since 1970 can receive only a limited amount of data.  Perhaps that can=
 be just written into the text, but in a perfect world, part of the state wo=
uld be the current date/time before which the notifier no longer has history=
 (regarding the directory number that is being watched).  (You'd want to spe=
cify that changes in the cutoff date/time alone would not trigger notificati=
on.)  The notifier would gradully time-out diversion information that was to=
o old to be practically significant, that is, which you don't need a subscri=
ber to be able to access.

I notice that if two calls *from* the same directory number, *to* the same d=
irectory number are diverted for the same reason, at the same second, for th=
e same reason, they produce identical <comm-div-ntfy-info> elements.  That w=
ould make it difficult for the subscriber to distinguish that it has receive=
d two notifications rather than one.  I would suggest adding an "id" element=
 as is used in the "reg" and "dialog" event packages.  Since the "id" value=
 is an arbitrary string, the notifier can generate it as an encoding of what=
ever internal identifier it uses to identify diversion events, which should=
 be efficient to implement.

I'm not sure what the <previous-cdivn-state> element is intended to do.  It=
 appears that there are two levels of filtering, "selection"
and "notification".  As written, the previous-cdivn-state tells whether ther=
e was a selected-but-non-notifiable diversion between the previous selected-=
and-notifiable diversion and the current selected-and-notifiable diversion.=
  It's not clear to me why this is useful to the subscriber, or whether the=
 subscriber wants to know when the previous-cdivn-state value changes due to=
 a non-notifiable diversion.  I think it would help if you explained what it=
s ultimate purpose is; it's possible that the design could be made more usef=
ul relative to that purpose.

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 pkyzivat@alum.mit.edu  Wed Aug 28 12:44:04 2013
Return-Path: <pkyzivat@alum.mit.edu>
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 DEB9B21E8090 for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 12:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.331
X-Spam-Level: 
X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.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 mb0hGtsmdale for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 12:43:59 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id B851921E8092 for <dispatch@ietf.org>; Wed, 28 Aug 2013 12:43:58 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id JKjA1m0011YDfWL5CKjyVd; Wed, 28 Aug 2013 19:43:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id JKjy1m0043ZTu2S3gKjyvr; Wed, 28 Aug 2013 19:43:58 +0000
Message-ID: <521E52FD.50108@alum.mit.edu>
Date: Wed, 28 Aug 2013 15:43:57 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: dispatch@ietf.org
References: <155970D1DA8E174F9E46039E10E2AA35E7339B@XMB103ADS.rim.net>
In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35E7339B@XMB103ADS.rim.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377719038; bh=RMp7cSySOIZcS/ZyZnPoEhxzJtF2Hllx4cqOpem7MWc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G/MBy3QNuthZ20zKTMg03Wz1782oF8TdHp70qB0ocapYk4aUd7XB2Gi6401YpNhzR XAuBSLMU4BQL6oTxiPOi/wXtX77nZhHLrCEhBFqRlPWi9ap95zxNmgk9IAtDWE+gwo ry2/3M1HLwPk8ze9iCiaeHT7raU82jvA6wEryHoljXCJihsrNY/dN3EuLWebyi18oG WGH6mQt5rV0dYUOekahc2hOiquUryebgfcqDoNuh1PNkfDJGvVYUl6XBtAymU1nkDZ 0k7sgsTA0I9/rN2UIUnoEAeh72SF3fhecbUq4k3AAP+H3kZqT/lQ1YTWZ22LSYiUqT YmLkm8188fccw==
Subject: Re: [dispatch] purpose <previous-cdivn-state> RE: draft-avasarala-dispatch-comm-div-notification
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 19:44:05 -0000

On 8/28/13 2:13 PM, John-Luc Bakker wrote:

> The state has limited use to a user trying to understand communication diversion rules.

The above is helpful.

> If a user receives an indication that diversions have happened for which it did not receive a notification and the user had not expected these diversions to happen, then the user can further "debug" the diversion and notification filtering rules. The primary advantage of this rather limited information is that the amount of state stored for a user subscribed to "communication diversion" is limited, yet still enables "analyses".

Sounds like you are trying to debug both the diversion rules and the 
subscription filters.

Without a filter, I would be getting a notification of every diversion, 
and then could decide if I thought my rules should have caused that one 
or not.

Does the DIVERSION_NOT_NOTIFIED mean "a diversion happened, but no 
notification was requested for it"? Or can it mean "a diversion happened 
but I haven't *yet* sent a notification for it"? (Delay can occur due to 
rate limiting, etc.)

> There is no 3GPP requirement to receive notification from all diversions that have happened in the past. That is, if a diversion wasn't notified due to failing to meet conditions expressed in the notification filter, then there is no requirement to be able to notify that diversion at a later stage.

OK.

> Is the ternary value maintained at the NOTIFIER per CDIVN subscriber compliant with the SIP event model?

IMO its not enough.

The expectation is that the state changes, and then the notification 
contains the (new) state, possibly filtered.

If the state were only this ternary value, then the notification would 
contain only that. If you want the notification to contain info about 
the diverted request, then that information ought to be part of the 
state. So at least it ought to contain "most recent diversion".

And having per-subscriber state is at least troubling to me.

	Thanks,
	Paul

From james.yu@neustar.biz  Wed Aug 28 15:00:10 2013
Return-Path: <james.yu@neustar.biz>
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 C599C21E8054 for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 15:00:08 -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 KfFyikwUHAFR for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 15:00:04 -0700 (PDT)
Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7742121F999B for <dispatch@ietf.org>; Wed, 28 Aug 2013 15:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1377727169; x=1693078478; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=46hVBPKdbKJEOyF2huGKV hzG3HDMxUySP+8DW+XJ0ac=; b=aDTX5irBmoK5UfeJkeMtTQpO9vRh8bFNxIrTr vPxFAbEcifAB9pb0lRP/14PH7SMDrNvax+/en2+8bss0VA3Jg==
Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.24612263;  Wed, 28 Aug 2013 17:59:28 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.44]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 28 Aug 2013 17:59:33 -0400
From: "Yu, James" <james.yu@neustar.biz>
To: Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp>
Thread-Topic: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
Thread-Index: AQHOmZqtFEEix6MeI0+rMB8IgXoPupmrOTCA
Date: Wed, 28 Aug 2013 21:59:32 +0000
Message-ID: <56FB15AFE08E1242B0736CBDCE6E8561080C73A3@STNTEXMB10.cis.neustar.com>
References: <51E4B4ED.4060305@ntt-at.co.jp> <7D2F7D7ADBA812449F25F4A69922881C14AA59@ESESSMB203.ericsson.se> <7D2F7D7ADBA812449F25F4A69922881C16E34A@ESESSMB203.ericsson.se>
In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C16E34A@ESESSMB203.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.130.13]
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: G3YkshQ0d/KynNawU6YdOQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 28 Aug 2013 15:01:44 -0700
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 22:00:11 -0000

Mayumi,

I have a few comments below.

Best Regards,

James

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

#1. Page 4, Section 1.1, 2nd sentence:  Remove the parentheses and either l=
eave the sentence at the same place or move it to a footnote.

#2. Page 5, Section 1.5, 1st paragraph: Change the sentence containing "net=
work element (supporting this specification) traversed" to "A private netwo=
rk indication as proposed by this document that is received in an incoming =
request indicates to the receiving network element (supporting this specifi=
cation) that this request is related to a private network traffic as oppose=
d to a public network traffic.".  Change "on behalf to" to "on behalf of" i=
n the 2nd to the last line.

#3. Page 6, Section 1.5, the last set of items 1 and 2: Change "As caller" =
to "Caller" in item 1.  Change "network" to "networks" in the 1st line and =
"is" to "are" in the 3rd line of item 2.

#4. Page 8, 1st paragraph and Figure 1 (and other places?):  It may be bett=
er to use "pre-arranged domain name" instead of "common domain".  Suggest t=
o change the 1st paragraph to "There may be circumstances where traffic bet=
ween two different enterprises are tagged as private network traffic using =
a pre-arranged domain name agreed by the two involved enterprises."

#5. Page 8, last paragraph, 6th line: Change "break out" to "break-out".

#6. Page 10, Figure 3:  Between the enterprise phone and the hosted enterpr=
ise service for enterprise 1, should it be "public network traffic" because=
 there is no need to include the P-Private-Network-Indication header field =
in the request in either direction.

#7. Page 10, Section 5, R1: Change "that indicates" to "to indicate".

#8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd line. =
 Also the 2nd line says "associated with the originating enterprise".  For =
a common domain, the PNI would be associated with both the originating and =
terminating enterprises.

#9. Page 12, 1st paragraph:  "subdomains" is mentioned when an enterprise n=
eeds more than one identifier.  But the I-D should not rule out that an ent=
erprise can use multiple domain names so long as it owns them.

#10. Page 12, Section 7.1.1: If a common domain name is used, the PNI would=
 correspond to two enterprises in the last sentence.  In case an enterprise=
 has more than one identifiers, the proxy would need to know which identifi=
er is to be used when it needs to convert public network traffic to private=
 network .  I don't know if the proxy has the knowledge to know the appropr=
iate identifier to use based on the incoming request.  If not, there should=
 be a default identifier and the procedure needs to be discussed.

#11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line and insert=
 "a" before "case" in the 2nd to the last line.  The 1st server in the publ=
ic telecom network that receives the P-Private-Network-Indication header fi=
eld in an incoming request should check if the originating enterprise can i=
nclude the indicated domain name in the header field (also see comment #15

#12. Page 12, Section 7.1.3: Change "breakout" to "break-out" in the 2nd li=
ne to be consistent.  Is there a need to include "with a value" in the last=
 line?  The text would imply that this header field is not removed if it do=
es not contain a value.  This header field should always be removed.

#13. Page 13, 1st paragraph, last sentence: "for a specific enterprise" pro=
bably does not apply to the case with a common domain name used by two ente=
rprises.

#14. Page 13, 2nd paragraph, 2nd line: Change "the following" to "described=
 below".

#15. Page 13, Section 9:  Change "physically" to "physical" in the 5th line=
.  When an enterprise includes the P-Private-Network-Indication header fiel=
d in a request, should the public telecom network check if the originating =
enterprise can use that domain name?  If an enterprise wrongly uses another=
 enterprise's domain name without any verification, the only impact is that=
 rules for another enterprise is applied to the traffic related to this req=
uest.  But for the purpose of security, the public telecom network would be=
 provisioned with the domain names that can be used in the this header fiel=
d for each served enterprise.

#16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd lin=
e.  Change "understand the" to "understand this".


-----Original Message-----
From: Atle Monrad [mailto:atle.monrad@ERICSSON.COM]=20
Sent: Thursday, August 15, 2013 5:35 AM
To: 3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG
Subject: FW: [dispatch] New version of draft-vanelburg-dispatch-private-net=
work-ind

Again

Kindly review and/or advocate support for this draft on the dispatch-list.

It seems to be close to completion!!

thanks
/a
________________________________=20


Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation Ericss=
on



-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Atle Monrad
Sent: 29. juli 2013 10:40
To: Mayumi Ohsugi; dispatch@ietf.org
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-net=
work-ind

All

Thanks to Mayumi to pick up the remaining topics on this draft.

I have reviewed the new version.

I have no comments and can confirm that 3GPP would like to get the draft co=
mpleted to finish one of our long time outstanding dependencies.

cheers
/atle
________________________________=20


Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation Ericss=
on



-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Mayumi Ohsugi
Sent: 16. juli 2013 04:50
To: dispatch@ietf.org
Subject: [dispatch] New version of draft-vanelburg-dispatch-private-network=
-ind

Hi,

I have submitted the following draft:

http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-02.txt

The draft was discussed in DISPATCH list three years ago.=20
While it has been expired for more than two years, the draft has been refer=
red in 3GPP IMS specifications and the P-Private-Network-Indication header =
field is now implemented by some vendors for enterprise customers.

We have updated the draft to solve the remaining issues from Expert Review =
(by John Elwell) of three years ago.

Any comments are welcome.

Thanks,
Mayumi

-----
Mayumi Ohsugi, NTT
_______________________________________________
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

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3211/6577 - Release Date: 08/14/13

From christer.holmberg@ericsson.com  Wed Aug 28 23:10:15 2013
Return-Path: <christer.holmberg@ericsson.com>
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 3267021F9EC4 for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 23:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.888
X-Spam-Level: 
X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.361,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 xZUXlfMUeUWn for <dispatch@ietfa.amsl.com>; Wed, 28 Aug 2013 23:10:10 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A103F21F9D9B for <dispatch@ietf.org>; Wed, 28 Aug 2013 23:10:09 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-93-521ee5bf8f58
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6C.A4.03802.FB5EE125; Thu, 29 Aug 2013 08:10:07 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 08:10:07 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Mary Barnes <mary.ietf.barnes@gmail.com>
Thread-Topic: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
Thread-Index: AQHOpBHM9lydKT/ZgUGEUAZ6KxN2r5mqvkEAgAD2SMA=
Date: Thu, 29 Aug 2013 06:10:06 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C47F803@ESESSMB209.ericsson.se>
References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com> <949EF20990823C4C85C18D59AA11AD8B08A50B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAHBDyN7Md3rh4--AjVWaRpt866XiwXD7EHC52LgAbNsVBPokCA@mail.gmail.com> <521E3328.2030005@alum.mit.edu>
In-Reply-To: <521E3328.2030005@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7+p3JBBl+e6VosnbSA1aJjMpvF 5/37mS1WbDjA6sDi8ff9ByaPKb83snrsnHWX3WPJkp9MASxRXDYpqTmZZalF+nYJXBlTb29m LzgkXrHn8SnGBsalQl2MnBwSAiYSE84dYoWwxSQu3FvP1sXIxSEkcJhRYlbHEiYIZwmjRPfG KSxdjBwcbAIWEt3/tEEaRARCJFouNbKB2MwCMRJHZm8BGyQsECrRvgEiLiIQJvHv0hlGCNtK 4s/ClSwgNouAqsSavcfYQWxeAV+J498/M0Psmsws8efydiaQBKeAjsTmrv1gNiPQdd9PrWGC WCYu8eHgdWaIqwUkluw5D2WLSrx8/A/qGyWJxiVPWCHq9SRuTJ0Cdai2xLKFr5khFgtKnJz5 hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAmPp4JbfqjsY75wTOcQozcGiJM67 We9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGqC+fvu4Nk11SK/R3wlTPMokXmZe/ThJm MLWfc0DhyfVEgVWX/wn6rb+2R63Hym+x1f6cPQ52FjZ2L++v3csxjSP6VXe6Y13U8UVKUu1S Pkna6geZNaeerPhhvFzimkKmhu8m7RiZFefdWzjm8zXtOz13Rvp5tTJlu3T/CfnrIrf57Sn6 8KBYiaU4I9FQi7moOBEAwDXVNnMCAAA=
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Dispatch request:	draft-kaplan-dispatch-sip-205-response-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 06:10:15 -0000

The world famous 199 response code didn't require a charter change either, =
so...

Regards,

Christer

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.or=
g] Puolesta Paul Kyzivat
L=E4hetetty: 28. elokuuta 2013 20:28
Vastaanottaja: Mary Barnes
Kopio: Cullen Jennings (fluffy); dispatch@ietf.org
Aihe: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-respon=
se-00

I don't think we need a charter change to sipcore for this.

On 8/28/13 1:12 PM, Mary Barnes wrote:
> Yes, as usual, when there is consensus in the DISPATCH WG as to an=20
> existing WG that seems most appropriate for the work, it is then up to=20
> that WG to make the decision as to whether the WG participants are=20
> interested in working on that item. In which case, the WG chairs work=20
> with the ADs to get it added to their charter. This is the exact way=20
> we handled the logging requirements being dispatching to INSIPID.
>
> Mary.
>
>
> On Wed, Aug 28, 2013 at 12:06 PM, DRAGE, Keith (Keith)=20
> <keith.drage@alcatel-lucent.com=20
> <mailto:keith.drage@alcatel-lucent.com>>
> wrote:
>
>     I assume that "dispatch" means the DISPATCH working group considers
>     that SIPCORE is the appropriate place to study this. It is up to
>     SIPCORE to gauge interest and decide if work is appropriate.
>
>     Keith
>
>      > -----Original Message-----
>      > From: dispatch-bounces@ietf.org
>     <mailto:dispatch-bounces@ietf.org> [mailto:dispatch-bounces@ietf.org
>     <mailto:dispatch-bounces@ietf.org>] On
>      > Behalf Of Cullen Jennings (fluffy)
>      > Sent: 28 August 2013 17:46
>      > To: Paul Kyzivat
>      > Cc: dispatch@ietf.org <mailto:dispatch@ietf.org>
>      > Subject: Re: [dispatch] Dispatch request:
>     draft-kaplan-dispatch-sip-205-
>      > response-00
>      >
>      >
>      > On Jul 29, 2013, at 9:06 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>     <mailto:pkyzivat@alum.mit.edu>> wrote:
>      >
>      > > As sipcore co-chair, I also think sipcore will ultimately be
>     the right
>      > place for this.
>      >
>      > Given it's been a month with no objections to this. I think we sho=
uld
>      > consider this successfully dispatched to sip core. If folks feel
>     this was
>      > the wrong decision, let the chairs know and we can
>     fix/change/justify this
>      > decision.
>      >
>      >
>      > _______________________________________________
>      > dispatch mailing list
>      > dispatch@ietf.org <mailto:dispatch@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/dispatch
>     _______________________________________________
>     dispatch mailing list
>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dispatch
>
>

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

From mayumi.ohsugi@ntt-at.co.jp  Thu Aug 29 01:35:54 2013
Return-Path: <mayumi.ohsugi@ntt-at.co.jp>
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 C4E5721E8090 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 01:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.51
X-Spam-Level: 
X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6]
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 dyn7fbV9pEHn for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 01:35:51 -0700 (PDT)
Received: from mgw2.ntt-at.co.jp (mgw2.ntt-at.co.jp [202.253.162.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55111E80F6 for <dispatch@ietf.org>; Thu, 29 Aug 2013 01:35:50 -0700 (PDT)
Received: from gwall1.bb.ntt-at.co.jp ([192.168.225.241]) by mgw2i.dc.ntt-at.co.jp with ESMTP; 29 Aug 2013 17:35:48 +0900
Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id r7T8Zmwl011956; Thu, 29 Aug 2013 17:35:48 +0900
Received: from vcsrv1d.dc.ntt-at.co.jp [192.168.225.46]  by gwall1.bb.ntt-at.co.jp with ESMTP id TAA11955; Thu, 29 Aug 2013 17:35:48 +0900
Received: from vcsrv1d.dc.ntt-at.co.jp (vcsrv1d.dc.ntt-at.co.jp [127.0.0.1]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r7T8ZmZ9004329; Thu, 29 Aug 2013 17:35:48 +0900
Received: from atmail27.am.ntt-at.co.jp (atmail27.am.ntt-at.co.jp [192.168.225.147]) by vcsrv1d.dc.ntt-at.co.jp (vcsrv1d) with ESMTP id r7T8ZmUx004319; Thu, 29 Aug 2013 17:35:48 +0900
Received: from [IPv6:::1] (ip21-098.tec.ntt-at.co.jp [192.168.21.98]) by atmail27.am.ntt-at.co.jp (Postfix) with ESMTP id CFF7BED005E; Thu, 29 Aug 2013 17:35:47 +0900 (JST)
Message-ID: <521F07CB.4040305@ntt-at.co.jp>
Date: Thu, 29 Aug 2013 17:35:23 +0900
From: Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Yu, James" <james.yu@neustar.biz>
References: <51E4B4ED.4060305@ntt-at.co.jp> <7D2F7D7ADBA812449F25F4A69922881C14AA59@ESESSMB203.ericsson.se> <7D2F7D7ADBA812449F25F4A69922881C16E34A@ESESSMB203.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080C73A3@STNTEXMB10.cis.neustar.com>
In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E8561080C73A3@STNTEXMB10.cis.neustar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: No
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 08:35:54 -0000

Hi James,

Thank you for the comments to the P-Private-Network-Indication draft.
See inline.

(2013/08/29 6:59), Yu, James wrote:
> Mayumi,
>
> I have a few comments below.
>
> Best Regards,
>
> James
>
> -------------------
>
> #1. Page 4, Section 1.1, 2nd sentence:  Remove the parentheses
> and either leave the sentence at the same place or move it to a footnote.

[MO] I will remove the parentheses.

>
> #2. Page 5, Section 1.5, 1st paragraph: Change the sentence
> containing "network element (supporting this specification)
> traversed" to "A private network indication as proposed by
> this document that is received in an incoming request indicates
> to the receiving network element (supporting this specification)
> that this request is related to a private network traffic as
> opposed to a public network traffic.".

[MO] I prefer a little shorter sentence. I will correct it to
"A private network indication as proposed by this document
  indicates to the receiving network element (supporting this
  specification) that this request is related to a private
  network traffic as opposed to a public network traffic."


> Change "on behalf to" to"on behalf of" in the 2nd to the last line.

[MO] Yes, I will.

>
> #3. Page 6, Section 1.5, the last set of items 1 and 2:
> Change "As caller" to "Caller" in item 1.
> Change "network" to "networks" in the 1st line and "is" to "are"
> in the 3rd line of item 2.

[MO] I will make these editorial corrections.

>
> #4. Page 8, 1st paragraph and Figure 1 (and other places?):
>  It may be better to use "pre-arranged domain name" instead of
> "common domain".  Suggest to change the 1st paragraph to
> "There may be circumstances where traffic between two different
> enterprises are tagged as private network traffic using a
> pre-arranged domain name agreed by the two involved enterprises."

[MO] I agree your suggestion is much better.
I will change the sentence as you proposed.

>
> #5. Page 8, last paragraph, 6th line: Change "break out" to "break-out".

[MO] I will correct it.

>
> #6. Page 10, Figure 3:  Between the enterprise phone and the
> hosted enterprise service for enterprise 1, should it be
> "public network traffic" because there is no need to include
> the P-Private-Network-Indication header field in the request
> in either direction.

[MO] The traffic can be either public or private.
This figure shows the example where the traffic is tagged as private.
I will correct the explanation of Figure 3 as follows;
"Traffic from the enterprise phones would not normally be
  tagged, but it can be tagged as private network traffic."

>
> #7. Page 10, Section 5, R1: Change "that indicates" to "to indicate".

[MO] I will.

>
> #8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd line.
> Also the 2nd line says "associated with the originating enterprise".
> For a common domain, the PNI would be associated with both the
> originating and terminating enterprises.

[MO] I will insert "a" before "globally" and
correct "associated with the originating enterprise" to
"associated with the originating and/or terminating enterprise(s)".

>
> #9. Page 12, 1st paragraph:  "subdomains" is mentioned when anenterprise
> needs more than one identifier.  But the I-D should notrule out that
> an enterprise can use multiple domain names so long as it owns them.

[MO] I will delete the sentence regarding subdomain
in order not to mention about subdomain in this draft.

>
> #10. Page 12, Section 7.1.1: If a common domain name is used,
> the PNI would correspond to two enterprises in the last sentence.
> In case an enterprise has more than one identifiers, the proxy would
> need to know which identifier is to be used when it needs to convert
> public network traffic to private network .  I don't know if the proxy
> has the knowledge to know the appropriate identifier to use based on
> the incoming request.  If not, there should be a default identifier
> and the procedure needs to be discussed.

[MO] I will correct "enterprise" to "enterprise(s)".
Regarding the multiple identifiers, which identity should be used will be
implementation matter, so I would like to avoid mention it in this draft.

>
> #11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line
> and insert "a" before "case" in the 2nd to the last line.
> The 1st server in the public telecom network that receives the
> P-Private-Network-Indication header field in an incoming request
> should check if the originating enterprise can include the
> indicateddomain name in the header field (also see comment #15

[MO] I will make these editorial corrections.

>
> #12. Page 12, Section 7.1.3: Change "breakout" to "break-out"
> in the 2nd line to be consistent.  Is there a need to include
> "with a value" in the last line?  The text would imply that this
> header field is not removed if it does not contain a value.
> This header field should always be removed.

[MO] I will correct "breakout" to "break-out".
I agree and will delete "with a value".

>
> #13. Page 13, 1st paragraph, last sentence: "for a specific enterprise"
> probably does not apply to the case with a common domain name used by
> two enterprises.

[MO] I will correct "for a specific enterprise" to
"for a specific enterprise(s)".

>
> #14. Page 13, 2nd paragraph, 2nd line: Change "the following" to "described below".

[MO] I will correct it as you proposed.

>
> #15. Page 13, Section 9:  Change "physically" to "physical" in the 5th line.
> When an enterprise includes the P-Private-Network-Indication header field
> in a request, should the public telecom network check if the originating
> enterprise can use that domain name?  If an enterprise wrongly uses another
> enterprise's domain name without any verification, the only impact is that
> rules for another enterprise is applied to the traffic related to this request.
> But for the purpose of security, the public telecom network would be
> provisioned with the domain names that can be used in the this header field
> for each served enterprise.

[MO] I will correct "physically" to "physical".
Regarding the verification of domain name by the public telecom network,
I will put a new subsection as follows;

   7.1.4. P-Private-Network-Indication verification
   When proxies supporting this specification receive a P-Private-Network-Indication
   header field in a SIP request from a trusted node, proxies MUST check whether
   the received domain name in the request is the same as the domain name associated
   with the provisioned domain name. If the received domain name does not match,
   proxies MUST remove the P-Private-Network-Indication header field.

>
> #16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd line.
> Change "understand the" to "understand this".

[MO] I will delete "such as the own proxy" and
correct "understands the" to "understands this".

Many Thanks,
Mayumi


>
>
> -----Original Message-----
> From: Atle Monrad [mailto:atle.monrad@ERICSSON.COM]
> Sent: Thursday, August 15, 2013 5:35 AM
> To: 3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG
> Subject: FW: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
>
> Again
>
> Kindly review and/or advocate support for this draft on the dispatch-list.
>
> It seems to be close to completion!!
>
> thanks
> /a
> ________________________________
>
>
> Atle Monrad
> 3GPP CT Chairman
>
> Group Function Technology - Standardization and Technical Regulation Ericsson
>
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Atle Monrad
> Sent: 29. juli 2013 10:40
> To: Mayumi Ohsugi; dispatch@ietf.org
> Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
>
> All
>
> Thanks to Mayumi to pick up the remaining topics on this draft.
>
> I have reviewed the new version.
>
> I have no comments and can confirm that 3GPP would like to get the draft completed to finish one of our long time outstanding dependencies.
>
> cheers
> /atle
> ________________________________
>
>
> Atle Monrad
> 3GPP CT Chairman
>
> Group Function Technology - Standardization and Technical Regulation Ericsson
>
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mayumi Ohsugi
> Sent: 16. juli 2013 04:50
> To: dispatch@ietf.org
> Subject: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
>
> Hi,
>
> I have submitted the following draft:
>
> http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-02.txt
>
> The draft was discussed in DISPATCH list three years ago.
> While it has been expired for more than two years, the draft has been referred in 3GPP IMS specifications and the P-Private-Network-Indication header field is now implemented by some vendors for enterprise customers.
>
> We have updated the draft to solve the remaining issues from Expert Review (by John Elwell) of three years ago.
>
> Any comments are welcome.
>
> Thanks,
> Mayumi
>
> -----
> Mayumi Ohsugi, NTT
> _______________________________________________
> 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
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2904 / Virus Database: 3211/6577 - Release Date: 08/14/13
>


From james.yu@neustar.biz  Thu Aug 29 05:12:29 2013
Return-Path: <james.yu@neustar.biz>
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 F0D2921F8721 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 05:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 yP4Xf-lSYdpr for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 05:12:25 -0700 (PDT)
Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id ED21721F9D2E for <dispatch@ietf.org>; Thu, 29 Aug 2013 05:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1377778904; x=1693118481; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=rkwLzv840DbwknTJpn9nS kRDYbVwCcJCzZ4GE8I3GFs=; b=khYDT4yZJsFL9WxHHX+vriQ1vBYLGxPSY5YmM HqAu6wJAeymlqp63jWTvR1LSpclLNEC77nMp3j0mBoXqIHt1g==
Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.30832483;  Thu, 29 Aug 2013 08:21:42 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.44]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 29 Aug 2013 08:12:10 -0400
From: "Yu, James" <james.yu@neustar.biz>
To: "'mayumi.ohsugi@ntt-at.co.jp'" <mayumi.ohsugi@ntt-at.co.jp>
Thread-Topic: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
Thread-Index: AQHOmZqtFEEix6MeI0+rMB8IgXoPupmrOTCAgAD8EID///mCUw==
Date: Thu, 29 Aug 2013 12:12:09 +0000
Message-ID: <56FB15AFE08E1242B0736CBDCE6E8561080C756A@STNTEXMB10.cis.neustar.com>
In-Reply-To: <521F07CB.4040305@ntt-at.co.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.31.15.64]
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: LWxNOXONMTBS2Jyyb/+IFw==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "'dispatch@ietf.org'" <dispatch@ietf.org>, "'fluffy@iii.ca'" <fluffy@iii.ca>
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 12:12:29 -0000

Mayumi,

I'm fine with your answers.

BR,

James

----- Original Message -----
From: Mayumi Ohsugi [mailto:mayumi.ohsugi@ntt-at.co.jp]
Sent: Thursday, August 29, 2013 04:35 AM=0A=
To: Yu, James
Cc: Atle Monrad <atle.monrad@ERICSSON.COM>; dispatch@ietf.org <dispatch@iet=
f.org>; Mary Barnes <mary.ietf.barnes@gmail.com>; Cullen Jennings <fluffy@i=
ii.ca>
Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-net=
work-ind

Hi James,

Thank you for the comments to the P-Private-Network-Indication draft.
See inline.

(2013/08/29 6:59), Yu, James wrote:
> Mayumi,
>
> I have a few comments below.
>
> Best Regards,
>
> James
>
> -------------------
>
> #1. Page 4, Section 1.1, 2nd sentence:  Remove the parentheses
> and either leave the sentence at the same place or move it to a footnote.

[MO] I will remove the parentheses.

>
> #2. Page 5, Section 1.5, 1st paragraph: Change the sentence
> containing "network element (supporting this specification)
> traversed" to "A private network indication as proposed by
> this document that is received in an incoming request indicates
> to the receiving network element (supporting this specification)
> that this request is related to a private network traffic as
> opposed to a public network traffic.".

[MO] I prefer a little shorter sentence. I will correct it to
"A private network indication as proposed by this document
  indicates to the receiving network element (supporting this
  specification) that this request is related to a private
  network traffic as opposed to a public network traffic."


> Change "on behalf to" to"on behalf of" in the 2nd to the last line.

[MO] Yes, I will.

>
> #3. Page 6, Section 1.5, the last set of items 1 and 2:
> Change "As caller" to "Caller" in item 1.
> Change "network" to "networks" in the 1st line and "is" to "are"
> in the 3rd line of item 2.

[MO] I will make these editorial corrections.

>
> #4. Page 8, 1st paragraph and Figure 1 (and other places?):
>  It may be better to use "pre-arranged domain name" instead of
> "common domain".  Suggest to change the 1st paragraph to
> "There may be circumstances where traffic between two different
> enterprises are tagged as private network traffic using a
> pre-arranged domain name agreed by the two involved enterprises."

[MO] I agree your suggestion is much better.
I will change the sentence as you proposed.

>
> #5. Page 8, last paragraph, 6th line: Change "break out" to "break-out".

[MO] I will correct it.

>
> #6. Page 10, Figure 3:  Between the enterprise phone and the
> hosted enterprise service for enterprise 1, should it be
> "public network traffic" because there is no need to include
> the P-Private-Network-Indication header field in the request
> in either direction.

[MO] The traffic can be either public or private.
This figure shows the example where the traffic is tagged as private.
I will correct the explanation of Figure 3 as follows;
"Traffic from the enterprise phones would not normally be
  tagged, but it can be tagged as private network traffic."

>
> #7. Page 10, Section 5, R1: Change "that indicates" to "to indicate".

[MO] I will.

>
> #8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd line=
.
> Also the 2nd line says "associated with the originating enterprise".
> For a common domain, the PNI would be associated with both the
> originating and terminating enterprises.

[MO] I will insert "a" before "globally" and
correct "associated with the originating enterprise" to
"associated with the originating and/or terminating enterprise(s)".

>
> #9. Page 12, 1st paragraph:  "subdomains" is mentioned when anenterprise
> needs more than one identifier.  But the I-D should notrule out that
> an enterprise can use multiple domain names so long as it owns them.

[MO] I will delete the sentence regarding subdomain
in order not to mention about subdomain in this draft.

>
> #10. Page 12, Section 7.1.1: If a common domain name is used,
> the PNI would correspond to two enterprises in the last sentence.
> In case an enterprise has more than one identifiers, the proxy would
> need to know which identifier is to be used when it needs to convert
> public network traffic to private network .  I don't know if the proxy
> has the knowledge to know the appropriate identifier to use based on
> the incoming request.  If not, there should be a default identifier
> and the procedure needs to be discussed.

[MO] I will correct "enterprise" to "enterprise(s)".
Regarding the multiple identifiers, which identity should be used will be
implementation matter, so I would like to avoid mention it in this draft.

>
> #11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line
> and insert "a" before "case" in the 2nd to the last line.
> The 1st server in the public telecom network that receives the
> P-Private-Network-Indication header field in an incoming request
> should check if the originating enterprise can include the
> indicateddomain name in the header field (also see comment #15

[MO] I will make these editorial corrections.

>
> #12. Page 12, Section 7.1.3: Change "breakout" to "break-out"
> in the 2nd line to be consistent.  Is there a need to include
> "with a value" in the last line?  The text would imply that this
> header field is not removed if it does not contain a value.
> This header field should always be removed.

[MO] I will correct "breakout" to "break-out".
I agree and will delete "with a value".

>
> #13. Page 13, 1st paragraph, last sentence: "for a specific enterprise"
> probably does not apply to the case with a common domain name used by
> two enterprises.

[MO] I will correct "for a specific enterprise" to
"for a specific enterprise(s)".

>
> #14. Page 13, 2nd paragraph, 2nd line: Change "the following" to "describ=
ed below".

[MO] I will correct it as you proposed.

>
> #15. Page 13, Section 9:  Change "physically" to "physical" in the 5th li=
ne.
> When an enterprise includes the P-Private-Network-Indication header field
> in a request, should the public telecom network check if the originating
> enterprise can use that domain name?  If an enterprise wrongly uses anoth=
er
> enterprise's domain name without any verification, the only impact is tha=
t
> rules for another enterprise is applied to the traffic related to this re=
quest.
> But for the purpose of security, the public telecom network would be
> provisioned with the domain names that can be used in the this header fie=
ld
> for each served enterprise.

[MO] I will correct "physically" to "physical".
Regarding the verification of domain name by the public telecom network,
I will put a new subsection as follows;

   7.1.4. P-Private-Network-Indication verification
   When proxies supporting this specification receive a P-Private-Network-I=
ndication
   header field in a SIP request from a trusted node, proxies MUST check wh=
ether
   the received domain name in the request is the same as the domain name a=
ssociated
   with the provisioned domain name. If the received domain name does not m=
atch,
   proxies MUST remove the P-Private-Network-Indication header field.

>
> #16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd l=
ine.
> Change "understand the" to "understand this".

[MO] I will delete "such as the own proxy" and
correct "understands the" to "understands this".

Many Thanks,
Mayumi


>
>
> -----Original Message-----
> From: Atle Monrad [mailto:atle.monrad@ERICSSON.COM]
> Sent: Thursday, August 15, 2013 5:35 AM
> To: 3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG
> Subject: FW: [dispatch] New version of draft-vanelburg-dispatch-private-n=
etwork-ind
>
> Again
>
> Kindly review and/or advocate support for this draft on the dispatch-list=
.
>
> It seems to be close to completion!!
>
> thanks
> /a
> ________________________________
>
>
> Atle Monrad
> 3GPP CT Chairman
>
> Group Function Technology - Standardization and Technical Regulation Eric=
sson
>
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh=
alf Of Atle Monrad
> Sent: 29. juli 2013 10:40
> To: Mayumi Ohsugi; dispatch@ietf.org
> Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-n=
etwork-ind
>
> All
>
> Thanks to Mayumi to pick up the remaining topics on this draft.
>
> I have reviewed the new version.
>
> I have no comments and can confirm that 3GPP would like to get the draft =
completed to finish one of our long time outstanding dependencies.
>
> cheers
> /atle
> ________________________________
>
>
> Atle Monrad
> 3GPP CT Chairman
>
> Group Function Technology - Standardization and Technical Regulation Eric=
sson
>
>
>
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh=
alf Of Mayumi Ohsugi
> Sent: 16. juli 2013 04:50
> To: dispatch@ietf.org
> Subject: [dispatch] New version of draft-vanelburg-dispatch-private-netwo=
rk-ind
>
> Hi,
>
> I have submitted the following draft:
>
> http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-02.tx=
t
>
> The draft was discussed in DISPATCH list three years ago.
> While it has been expired for more than two years, the draft has been ref=
erred in 3GPP IMS specifications and the P-Private-Network-Indication heade=
r field is now implemented by some vendors for enterprise customers.
>
> We have updated the draft to solve the remaining issues from Expert Revie=
w (by John Elwell) of three years ago.
>
> Any comments are welcome.
>
> Thanks,
> Mayumi
>
> -----
> Mayumi Ohsugi, NTT
> _______________________________________________
> 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
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2904 / Virus Database: 3211/6577 - Release Date: 08/14/13
>


From mary.ietf.barnes@gmail.com  Thu Aug 29 06:52:14 2013
Return-Path: <mary.ietf.barnes@gmail.com>
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 7E1DC21F9F12 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 06:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.609
X-Spam-Level: 
X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 85HYyWqukZaz for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 06:52:07 -0700 (PDT)
Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86221F8749 for <dispatch@ietf.org>; Thu, 29 Aug 2013 06:52:07 -0700 (PDT)
Received: by mail-qe0-f48.google.com with SMTP id 1so203286qec.35 for <dispatch@ietf.org>; Thu, 29 Aug 2013 06:52:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iDglijzvbKyG1NKsmIUCzkmr8DoAzboJ2i8D95sJMls=; b=Qhi7HVH7hYmNIo9K/awtnIJ0nIQ5Sx6WZfnLRI3gX0DCTToxyPEzIHhRH3iEGoUzFP xgU5M8vIMHkzEarh+qh4bwe2OEEpFTm3ivFUVZY1SIjJu2D642plk9MLii8JZoiwlGU/ QYGtUf0568fJdQJMVfTJW9S7QjCrYOF3X8PXQbW3+bC/4bzGG4ZZ1jS/nK+xXMjHc5C5 r9HKhOrI0KtTCuCfKeJzL3ztEJzbsBwxetOrHztsOhDryfrH7zrXIYYo+aARBBxBAbAD UAvsamTzMu1Ve4MxdbvZDfdc6YsuW6okW1kKBD2O01Bwzf4au6TWCO1QL9azow8QCGSL qCMw==
MIME-Version: 1.0
X-Received: by 10.224.73.137 with SMTP id q9mr157203qaj.13.1377784326519; Thu, 29 Aug 2013 06:52:06 -0700 (PDT)
Received: by 10.49.71.243 with HTTP; Thu, 29 Aug 2013 06:52:06 -0700 (PDT)
In-Reply-To: <521E3328.2030005@alum.mit.edu>
References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> <C5E08FE080ACFD4DAE31E4BDBF944EB11664BC1E@xmb-aln-x02.cisco.com> <949EF20990823C4C85C18D59AA11AD8B08A50B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <CAHBDyN7Md3rh4--AjVWaRpt866XiwXD7EHC52LgAbNsVBPokCA@mail.gmail.com> <521E3328.2030005@alum.mit.edu>
Date: Thu, 29 Aug 2013 08:52:06 -0500
Message-ID: <CAHBDyN4NsdjB8GX=rntW9eOBBZeDWywBPxhKt9ZMWam+Lcgv6Q@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=001a11c3bed45c582504e51669dd
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 13:52:14 -0000

--001a11c3bed45c582504e51669dd
Content-Type: text/plain; charset=ISO-8859-1

That's fine then. I was just answering Keith's concern as to how we
dispatch things and highlighting the fact that it's up to the target WG as
to whether they adopt the work (and then do anything they might need to do
to get it in the charter).

Mary.


On Wed, Aug 28, 2013 at 12:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>wrote:

> I don't think we need a charter change to sipcore for this.
>
>
> On 8/28/13 1:12 PM, Mary Barnes wrote:
>
>> Yes, as usual, when there is consensus in the DISPATCH WG as to an
>> existing WG that seems most appropriate for the work, it is then up to
>> that WG to make the decision as to whether the WG participants are
>> interested in working on that item. In which case, the WG chairs work
>> with the ADs to get it added to their charter. This is the exact way we
>> handled the logging requirements being dispatching to INSIPID.
>>
>> Mary.
>>
>>
>> On Wed, Aug 28, 2013 at 12:06 PM, DRAGE, Keith (Keith)
>> <keith.drage@alcatel-lucent.**com <keith.drage@alcatel-lucent.com><mailto:
>> keith.drage@alcatel-**lucent.com <keith.drage@alcatel-lucent.com>>>
>>
>> wrote:
>>
>>     I assume that "dispatch" means the DISPATCH working group considers
>>     that SIPCORE is the appropriate place to study this. It is up to
>>     SIPCORE to gauge interest and decide if work is appropriate.
>>
>>     Keith
>>
>>      > -----Original Message-----
>>      > From: dispatch-bounces@ietf.org
>>     <mailto:dispatch-bounces@ietf.**org <dispatch-bounces@ietf.org>>
>> [mailto:dispatch-bounces@ietf.**org <dispatch-bounces@ietf.org>
>>     <mailto:dispatch-bounces@ietf.**org <dispatch-bounces@ietf.org>>] On
>>      > Behalf Of Cullen Jennings (fluffy)
>>      > Sent: 28 August 2013 17:46
>>      > To: Paul Kyzivat
>>      > Cc: dispatch@ietf.org <mailto:dispatch@ietf.org>
>>      > Subject: Re: [dispatch] Dispatch request:
>>     draft-kaplan-dispatch-sip-205-
>>      > response-00
>>      >
>>      >
>>      > On Jul 29, 2013, at 9:06 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>     <mailto:pkyzivat@alum.mit.edu>**> wrote:
>>      >
>>      > > As sipcore co-chair, I also think sipcore will ultimately be
>>     the right
>>      > place for this.
>>      >
>>      > Given it's been a month with no objections to this. I think we
>> should
>>      > consider this successfully dispatched to sip core. If folks feel
>>     this was
>>      > the wrong decision, let the chairs know and we can
>>     fix/change/justify this
>>      > decision.
>>      >
>>      >
>>      > ______________________________**_________________
>>      > dispatch mailing list
>>      > dispatch@ietf.org <mailto:dispatch@ietf.org>
>>
>>      > https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>>     ______________________________**_________________
>>     dispatch mailing list
>>     dispatch@ietf.org <mailto:dispatch@ietf.org>
>>     https://www.ietf.org/mailman/**listinfo/dispatch<https://www.ietf.org/mailman/listinfo/dispatch>
>>
>>
>>
>

--001a11c3bed45c582504e51669dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That&#39;s fine then. I was just answering Keith&#39;s con=
cern as to how we dispatch things and highlighting the fact that it&#39;s u=
p to the target WG as to whether they adopt the work (and then do anything =
they might need to do to get it in the charter).<div>
<br></div><div>Mary.</div></div><div class=3D"gmail_extra"><br><br><div cla=
ss=3D"gmail_quote">On Wed, Aug 28, 2013 at 12:28 PM, Paul Kyzivat <span dir=
=3D"ltr">&lt;<a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pky=
zivat@alum.mit.edu</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I don&#39;t think we need a charter change t=
o sipcore for this.<div class=3D"im"><br>
<br>
On 8/28/13 1:12 PM, Mary Barnes wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
Yes, as usual, when there is consensus in the DISPATCH WG as to an<br>
existing WG that seems most appropriate for the work, it is then up to<br>
that WG to make the decision as to whether the WG participants are<br>
interested in working on that item. In which case, the WG chairs work<br>
with the ADs to get it added to their charter. This is the exact way we<br>
handled the logging requirements being dispatching to INSIPID.<br>
<br>
Mary.<br>
<br>
<br>
On Wed, Aug 28, 2013 at 12:06 PM, DRAGE, Keith (Keith)<br></div>
&lt;<a href=3D"mailto:keith.drage@alcatel-lucent.com" target=3D"_blank">kei=
th.drage@alcatel-lucent.<u></u>com</a> &lt;mailto:<a href=3D"mailto:keith.d=
rage@alcatel-lucent.com" target=3D"_blank">keith.drage@alcatel-<u></u>lucen=
t.com</a>&gt;&gt;<div class=3D"im">
<br>
wrote:<br>
<br>
=A0 =A0 I assume that &quot;dispatch&quot; means the DISPATCH working group=
 considers<br>
=A0 =A0 that SIPCORE is the appropriate place to study this. It is up to<br=
>
=A0 =A0 SIPCORE to gauge interest and decide if work is appropriate.<br>
<br>
=A0 =A0 Keith<br>
<br>
=A0 =A0 =A0&gt; -----Original Message-----<br>
=A0 =A0 =A0&gt; From: <a href=3D"mailto:dispatch-bounces@ietf.org" target=
=3D"_blank">dispatch-bounces@ietf.org</a><br></div><div class=3D"im">
=A0 =A0 &lt;mailto:<a href=3D"mailto:dispatch-bounces@ietf.org" target=3D"_=
blank">dispatch-bounces@ietf.<u></u>org</a>&gt; [mailto:<a href=3D"mailto:d=
ispatch-bounces@ietf.org" target=3D"_blank">dispatch-bounces@ietf.<u></u>or=
g</a><br>

=A0 =A0 &lt;mailto:<a href=3D"mailto:dispatch-bounces@ietf.org" target=3D"_=
blank">dispatch-bounces@ietf.<u></u>org</a>&gt;] On<br>
=A0 =A0 =A0&gt; Behalf Of Cullen Jennings (fluffy)<br>
=A0 =A0 =A0&gt; Sent: 28 August 2013 17:46<br>
=A0 =A0 =A0&gt; To: Paul Kyzivat<br></div><div class=3D"im">
=A0 =A0 =A0&gt; Cc: <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">=
dispatch@ietf.org</a> &lt;mailto:<a href=3D"mailto:dispatch@ietf.org" targe=
t=3D"_blank">dispatch@ietf.org</a>&gt;<br>
=A0 =A0 =A0&gt; Subject: Re: [dispatch] Dispatch request:<br>
=A0 =A0 draft-kaplan-dispatch-sip-205-<br>
=A0 =A0 =A0&gt; response-00<br>
=A0 =A0 =A0&gt;<br>
=A0 =A0 =A0&gt;<br>
=A0 =A0 =A0&gt; On Jul 29, 2013, at 9:06 AM, Paul Kyzivat &lt;<a href=3D"ma=
ilto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit.edu</a><br>=
</div><div class=3D"im">
=A0 =A0 &lt;mailto:<a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blan=
k">pkyzivat@alum.mit.edu</a>&gt;<u></u>&gt; wrote:<br>
=A0 =A0 =A0&gt;<br>
=A0 =A0 =A0&gt; &gt; As sipcore co-chair, I also think sipcore will ultimat=
ely be<br>
=A0 =A0 the right<br>
=A0 =A0 =A0&gt; place for this.<br>
=A0 =A0 =A0&gt;<br>
=A0 =A0 =A0&gt; Given it&#39;s been a month with no objections to this. I t=
hink we should<br>
=A0 =A0 =A0&gt; consider this successfully dispatched to sip core. If folks=
 feel<br>
=A0 =A0 this was<br>
=A0 =A0 =A0&gt; the wrong decision, let the chairs know and we can<br>
=A0 =A0 fix/change/justify this<br>
=A0 =A0 =A0&gt; decision.<br>
=A0 =A0 =A0&gt;<br>
=A0 =A0 =A0&gt;<br>
=A0 =A0 =A0&gt; ______________________________<u></u>_________________<br>
=A0 =A0 =A0&gt; dispatch mailing list<br></div>
=A0 =A0 =A0&gt; <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">disp=
atch@ietf.org</a> &lt;mailto:<a href=3D"mailto:dispatch@ietf.org" target=3D=
"_blank">dispatch@ietf.org</a>&gt;<div class=3D"im"><br>
=A0 =A0 =A0&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" =
target=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/dispatch</a>=
<br>
=A0 =A0 ______________________________<u></u>_________________<br>
=A0 =A0 dispatch mailing list<br></div>
=A0 =A0 <a href=3D"mailto:dispatch@ietf.org" target=3D"_blank">dispatch@iet=
f.org</a> &lt;mailto:<a href=3D"mailto:dispatch@ietf.org" target=3D"_blank"=
>dispatch@ietf.org</a>&gt;<br>
=A0 =A0 <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch" target=
=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/dispatch</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>

--001a11c3bed45c582504e51669dd--

From worley@shell01.TheWorld.com  Thu Aug 29 08:22:20 2013
Return-Path: <worley@shell01.TheWorld.com>
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 9BEC821F8E70 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 08:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.135
X-Spam-Level: 
X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 GuvvRBXyHFaZ for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 08:22:11 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4434C21F9097 for <dispatch@ietf.org>; Thu, 29 Aug 2013 08:22:10 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r7TFLUBl031374 for <dispatch@ietf.org>; Thu, 29 Aug 2013 11:21:32 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r7TFLUTk195257 for <dispatch@ietf.org>; Thu, 29 Aug 2013 11:21:30 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r7TFLUHc193847; Thu, 29 Aug 2013 11:21:30 -0400 (EDT)
Date: Thu, 29 Aug 2013 11:21:30 -0400 (EDT)
Message-Id: <201308291521.r7TFLUHc193847@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: dispatch@ietf.org
Subject: [dispatch] Comments on draft-vanelburg-dispatch-private-network-ind-02
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 15:22:23 -0000

The abstract of -02 is:

   This document specifies the SIP P-Private-Network-Indication P-header
   used by the 3rd-Generation Partnership Project (3GPP).  The use of
   this private network indication extension is only applicable inside
   an administrative domain with previously agreed-upon policies for
   generation, transport and usage of such information.  A private
   network indication allows nodes in such a domain to treat private
   network traffic according to a different set of rules than the set
   applicable to public network traffic.  The indication also
   distinguishes traffic from one private network from another private
   network.

What is absent from the abstract is a statement telling what the
header *means*.  E.g., "The P-Private-Network-Indication indicates
that the message is part of the message traffic of a private network,
and identifies that private network."

Given that the proposed header name is 28 characters long, some
thought should be given to abbreviating it.

Dale

From mary.ietf.barnes@gmail.com  Thu Aug 29 10:51:26 2013
Return-Path: <mary.ietf.barnes@gmail.com>
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 76C8C21E80B2; Thu, 29 Aug 2013 10:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.432
X-Spam-Level: 
X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VULic7Q4lH5o; Thu, 29 Aug 2013 10:51:26 -0700 (PDT)
Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C7CE821E80A3; Thu, 29 Aug 2013 10:51:25 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 5so391446qeb.17 for <multiple recipients>; Thu, 29 Aug 2013 10:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0SixG49d2BcD6v2tWblXiAdrtKigap+IcmsE1DpYe1Y=; b=HbJYGq8FyjDpoEc50YwOI5E4X7oQz9Q7UHDOabbS2zoqzMQSkE7y6eOZml53VytGcf iEJzBFXBuYs0P26zcZbI96QFnCrkhdiZN2M7BOSCznqdoVFTA5MKW9xp2YC/9932lPLu vbqll2w7njPUcXDGNdAskPaX7ImtaxrYzhPS02vkZFH5l+AMQtCUIl6cHRs6kuN05pH+ r8OFbZHYYMb+qqNrX3BHGTJ3DWKI32BHePV3DdU4ZLGUXlXwOwAj3rhAZrjkeuOdGauy elS2OZDsT0asyxIOr+UzyVIc0k73fYvgqlNAMeH2y7VJ3jLtW5ba/Ghj5/Pelo3vn7i6 ZuMA==
MIME-Version: 1.0
X-Received: by 10.224.160.194 with SMTP id o2mr6703117qax.3.1377798684160; Thu, 29 Aug 2013 10:51:24 -0700 (PDT)
Received: by 10.49.71.243 with HTTP; Thu, 29 Aug 2013 10:51:24 -0700 (PDT)
Date: Thu, 29 Aug 2013 12:51:24 -0500
Message-ID: <CAHBDyN5_fXVG-i0BiffxJRKFfRSXcvq916KP6Ty+zgyvJqFXZw@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "rai@ietf.org" <rai@ietf.org>
Content-Type: multipart/alternative; boundary=089e01536d7a245e0304e519c115
Cc: DISPATCH <dispatch@ietf.org>
Subject: [dispatch] New non-WG specific mailing lists
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 17:51:26 -0000

--089e01536d7a245e0304e519c115
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

There have been a few non-WG mailing lists created recently that might be
of interest to folks.  We've added these to the RAI area wiki:
http://trac.tools.ietf.org/area/rai/trac/wiki
It would be good if folks could update the wiki as they find other non-WG
specific mailing list that are of interest to the RAI area.

Note, I'm sending this email to both DISPATCH and RAI area mailing list
since only about half of the people on the DISPATCH list are on the RAI
list. Folks might *really* want to subscribe to the latter - it's not at
all a busy list and you may be missing conversations that are of interest
to the general RAI community by not being on that list.

Regards,
Mary.

--089e01536d7a245e0304e519c115
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>There have been a few non-WG ma=
iling lists created recently that might be of interest to folks. =A0We&#39;=
ve added these to the RAI area wiki:</div><div><font class=3D"" color=3D"#0=
00000"><font class=3D"Apple-style-span" face=3D"arial, helvetica, sans-seri=
f"><a href=3D"http://trac.tools.ietf.org/area/rai/trac/wiki">http://trac.to=
ols.ietf.org/area/rai/trac/wiki</a> =A0=A0</font><br>
</font></div><div><font class=3D"" color=3D"#000000"><font class=3D"Apple-s=
tyle-span" face=3D"arial, helvetica, sans-serif">It would be good if folks =
could update the wiki as they find other non-WG specific mailing list that =
are of interest to the RAI area.=A0</font></font></div>
<div><font class=3D"" color=3D"#000000"><font class=3D"Apple-style-span" fa=
ce=3D"arial, helvetica, sans-serif"><br></font></font></div><div><font clas=
s=3D"" color=3D"#000000"><font class=3D"Apple-style-span" face=3D"arial, he=
lvetica, sans-serif">Note, I&#39;m sending this email to both DISPATCH and =
RAI area mailing list since only about half of the people on the DISPATCH l=
ist are on the RAI list. Folks might *really* want to subscribe to the latt=
er - it&#39;s not at all a busy list and you may be missing conversations t=
hat are of interest to the general RAI community by not being on that list.=
=A0</font></font></div>
<div><font class=3D"" color=3D"#000000"><font class=3D"Apple-style-span" fa=
ce=3D"arial, helvetica, sans-serif"><br></font></font></div><div><font clas=
s=3D"" color=3D"#000000"><font class=3D"Apple-style-span" face=3D"arial, he=
lvetica, sans-serif">Regards,</font></font></div>
<div><font class=3D"" color=3D"#000000"><font class=3D"Apple-style-span" fa=
ce=3D"arial, helvetica, sans-serif">Mary.=A0</font></font></div></div>

--089e01536d7a245e0304e519c115--

From keith.drage@alcatel-lucent.com  Thu Aug 29 11:44:44 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 7A5F511E8131 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 11:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.308
X-Spam-Level: 
X-Spam-Status: No, score=-110.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8, 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 2ZTDlwIrPyLg for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 11:44:39 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5D021F9371 for <dispatch@ietf.org>; Thu, 29 Aug 2013 11:44:36 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7TIiUZh004506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2013 13:44:32 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r7TIiQJk001738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 20:44:28 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 29 Aug 2013 20:44:27 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp>, "Yu, James" <james.yu@neustar.biz>
Thread-Topic: [dispatch] New version of draft-vanelburg-dispatch-private-network-ind
Thread-Index: AQHOpJLMH5oT2EoFUk6eZ3oiUrkhFZmsgT6A
Date: Thu, 29 Aug 2013 18:44:26 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B08B1F8@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <51E4B4ED.4060305@ntt-at.co.jp> <7D2F7D7ADBA812449F25F4A69922881C14AA59@ESESSMB203.ericsson.se> <7D2F7D7ADBA812449F25F4A69922881C16E34A@ESESSMB203.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080C73A3@STNTEXMB10.cis.neustar.com> <521F07CB.4040305@ntt-at.co.jp>
In-Reply-To: <521F07CB.4040305@ntt-at.co.jp>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: Re: [dispatch] New version of	draft-vanelburg-dispatch-private-network-ind
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 18:44:44 -0000

The proposed changes are OK except:

#9:	I would prefer we mentioned multiple domain names and subdomains, rathe=
r than deleting subdomains.

#10:	I agree we should not specify this. Break-in in 3GPP would be an appli=
cation server type function, and it is up to the enterprise how it wants to=
 instruct the public network to handle such break-in. It could be a single =
default value. It could be based on the Request-URI in the request. It coul=
d be based on all sorts of things.

Additionally in reviewing this I spotted in subclause 7.1.1 a "breaking" th=
at should be "break-in".

Regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Mayumi Ohsugi
> Sent: 29 August 2013 09:35
> To: Yu, James
> Cc: dispatch@ietf.org; Cullen Jennings
> Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private-
> network-ind
>=20
> Hi James,
>=20
> Thank you for the comments to the P-Private-Network-Indication draft.
> See inline.
>=20
> (2013/08/29 6:59), Yu, James wrote:
> > Mayumi,
> >
> > I have a few comments below.
> >
> > Best Regards,
> >
> > James
> >
> > -------------------
> >
> > #1. Page 4, Section 1.1, 2nd sentence:  Remove the parentheses
> > and either leave the sentence at the same place or move it to a footnot=
e.
>=20
> [MO] I will remove the parentheses.
>=20
> >
> > #2. Page 5, Section 1.5, 1st paragraph: Change the sentence
> > containing "network element (supporting this specification)
> > traversed" to "A private network indication as proposed by
> > this document that is received in an incoming request indicates
> > to the receiving network element (supporting this specification)
> > that this request is related to a private network traffic as
> > opposed to a public network traffic.".
>=20
> [MO] I prefer a little shorter sentence. I will correct it to
> "A private network indication as proposed by this document
>   indicates to the receiving network element (supporting this
>   specification) that this request is related to a private
>   network traffic as opposed to a public network traffic."
>=20
>=20
> > Change "on behalf to" to"on behalf of" in the 2nd to the last line.
>=20
> [MO] Yes, I will.
>=20
> >
> > #3. Page 6, Section 1.5, the last set of items 1 and 2:
> > Change "As caller" to "Caller" in item 1.
> > Change "network" to "networks" in the 1st line and "is" to "are"
> > in the 3rd line of item 2.
>=20
> [MO] I will make these editorial corrections.
>=20
> >
> > #4. Page 8, 1st paragraph and Figure 1 (and other places?):
> >  It may be better to use "pre-arranged domain name" instead of
> > "common domain".  Suggest to change the 1st paragraph to
> > "There may be circumstances where traffic between two different
> > enterprises are tagged as private network traffic using a
> > pre-arranged domain name agreed by the two involved enterprises."
>=20
> [MO] I agree your suggestion is much better.
> I will change the sentence as you proposed.
>=20
> >
> > #5. Page 8, last paragraph, 6th line: Change "break out" to "break-out"=
.
>=20
> [MO] I will correct it.
>=20
> >
> > #6. Page 10, Figure 3:  Between the enterprise phone and the
> > hosted enterprise service for enterprise 1, should it be
> > "public network traffic" because there is no need to include
> > the P-Private-Network-Indication header field in the request
> > in either direction.
>=20
> [MO] The traffic can be either public or private.
> This figure shows the example where the traffic is tagged as private.
> I will correct the explanation of Figure 3 as follows;
> "Traffic from the enterprise phones would not normally be
>   tagged, but it can be tagged as private network traffic."
>=20
> >
> > #7. Page 10, Section 5, R1: Change "that indicates" to "to indicate".
>=20
> [MO] I will.
>=20
> >
> > #8. Page 11, last paragraph: Insert "a" before "globally" in the 2nd
> line.
> > Also the 2nd line says "associated with the originating enterprise".
> > For a common domain, the PNI would be associated with both the
> > originating and terminating enterprises.
>=20
> [MO] I will insert "a" before "globally" and
> correct "associated with the originating enterprise" to
> "associated with the originating and/or terminating enterprise(s)".
>=20
> >
> > #9. Page 12, 1st paragraph:  "subdomains" is mentioned when anenterpris=
e
> > needs more than one identifier.  But the I-D should notrule out that
> > an enterprise can use multiple domain names so long as it owns them.
>=20
> [MO] I will delete the sentence regarding subdomain
> in order not to mention about subdomain in this draft.
>=20
> >
> > #10. Page 12, Section 7.1.1: If a common domain name is used,
> > the PNI would correspond to two enterprises in the last sentence.
> > In case an enterprise has more than one identifiers, the proxy would
> > need to know which identifier is to be used when it needs to convert
> > public network traffic to private network .  I don't know if the proxy
> > has the knowledge to know the appropriate identifier to use based on
> > the incoming request.  If not, there should be a default identifier
> > and the procedure needs to be discussed.
>=20
> [MO] I will correct "enterprise" to "enterprise(s)".
> Regarding the multiple identifiers, which identity should be used will be
> implementation matter, so I would like to avoid mention it in this draft.
>=20
> >
> > #11. Page 12, Section 7.1.2: Change "on" to "in" in the 4th line
> > and insert "a" before "case" in the 2nd to the last line.
> > The 1st server in the public telecom network that receives the
> > P-Private-Network-Indication header field in an incoming request
> > should check if the originating enterprise can include the
> > indicateddomain name in the header field (also see comment #15
>=20
> [MO] I will make these editorial corrections.
>=20
> >
> > #12. Page 12, Section 7.1.3: Change "breakout" to "break-out"
> > in the 2nd line to be consistent.  Is there a need to include
> > "with a value" in the last line?  The text would imply that this
> > header field is not removed if it does not contain a value.
> > This header field should always be removed.
>=20
> [MO] I will correct "breakout" to "break-out".
> I agree and will delete "with a value".
>=20
> >
> > #13. Page 13, 1st paragraph, last sentence: "for a specific enterprise"
> > probably does not apply to the case with a common domain name used by
> > two enterprises.
>=20
> [MO] I will correct "for a specific enterprise" to
> "for a specific enterprise(s)".
>=20
> >
> > #14. Page 13, 2nd paragraph, 2nd line: Change "the following" to
> "described below".
>=20
> [MO] I will correct it as you proposed.
>=20
> >
> > #15. Page 13, Section 9:  Change "physically" to "physical" in the 5th
> line.
> > When an enterprise includes the P-Private-Network-Indication header
> field
> > in a request, should the public telecom network check if the originatin=
g
> > enterprise can use that domain name?  If an enterprise wrongly uses
> another
> > enterprise's domain name without any verification, the only impact is
> that
> > rules for another enterprise is applied to the traffic related to this
> request.
> > But for the purpose of security, the public telecom network would be
> > provisioned with the domain names that can be used in the this header
> field
> > for each served enterprise.
>=20
> [MO] I will correct "physically" to "physical".
> Regarding the verification of domain name by the public telecom network,
> I will put a new subsection as follows;
>=20
>    7.1.4. P-Private-Network-Indication verification
>    When proxies supporting this specification receive a P-Private-Network=
-
> Indication
>    header field in a SIP request from a trusted node, proxies MUST check
> whether
>    the received domain name in the request is the same as the domain name
> associated
>    with the provisioned domain name. If the received domain name does not
> match,
>    proxies MUST remove the P-Private-Network-Indication header field.
>=20
> >
> > #16. Page 14, 1st paragraph: Not clear about "the own proxy" in the 2nd
> line.
> > Change "understand the" to "understand this".
>=20
> [MO] I will delete "such as the own proxy" and
> correct "understands the" to "understands this".
>=20
> Many Thanks,
> Mayumi
>=20
>=20
> >
> >
> > -----Original Message-----
> > From: Atle Monrad [mailto:atle.monrad@ERICSSON.COM]
> > Sent: Thursday, August 15, 2013 5:35 AM
> > To: 3GPP_TSG_CT_IETF-COORD@LIST.ETSI.ORG
> > Subject: FW: [dispatch] New version of draft-vanelburg-dispatch-private=
-
> network-ind
> >
> > Again
> >
> > Kindly review and/or advocate support for this draft on the dispatch-
> list.
> >
> > It seems to be close to completion!!
> >
> > thanks
> > /a
> > ________________________________
> >
> >
> > Atle Monrad
> > 3GPP CT Chairman
> >
> > Group Function Technology - Standardization and Technical Regulation
> Ericsson
> >
> >
> >
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Atle Monrad
> > Sent: 29. juli 2013 10:40
> > To: Mayumi Ohsugi; dispatch@ietf.org
> > Subject: Re: [dispatch] New version of draft-vanelburg-dispatch-private=
-
> network-ind
> >
> > All
> >
> > Thanks to Mayumi to pick up the remaining topics on this draft.
> >
> > I have reviewed the new version.
> >
> > I have no comments and can confirm that 3GPP would like to get the draf=
t
> completed to finish one of our long time outstanding dependencies.
> >
> > cheers
> > /atle
> > ________________________________
> >
> >
> > Atle Monrad
> > 3GPP CT Chairman
> >
> > Group Function Technology - Standardization and Technical Regulation
> Ericsson
> >
> >
> >
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Mayumi Ohsugi
> > Sent: 16. juli 2013 04:50
> > To: dispatch@ietf.org
> > Subject: [dispatch] New version of draft-vanelburg-dispatch-private-
> network-ind
> >
> > Hi,
> >
> > I have submitted the following draft:
> >
> > http://www.ietf.org/id/draft-vanelburg-dispatch-private-network-ind-
> 02.txt
> >
> > The draft was discussed in DISPATCH list three years ago.
> > While it has been expired for more than two years, the draft has been
> referred in 3GPP IMS specifications and the P-Private-Network-Indication
> header field is now implemented by some vendors for enterprise customers.
> >
> > We have updated the draft to solve the remaining issues from Expert
> Review (by John Elwell) of three years ago.
> >
> > Any comments are welcome.
> >
> > Thanks,
> > Mayumi
> >
> > -----
> > Mayumi Ohsugi, NTT
> > _______________________________________________
> > 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
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2013.0.2904 / Virus Database: 3211/6577 - Release Date:
> 08/14/13
> >
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From keith.drage@alcatel-lucent.com  Thu Aug 29 11:44:47 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 470D621E80A3 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 11:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.582
X-Spam-Level: 
X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 BcHUBPYCmX-4 for <dispatch@ietfa.amsl.com>; Thu, 29 Aug 2013 11:44:41 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C959421F9EE5 for <dispatch@ietf.org>; Thu, 29 Aug 2013 11:44:41 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7TIiUEY004503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2013 13:44:32 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r7TIiRvP001758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 20:44:28 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 29 Aug 2013 20:44:27 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Dale R. Worley" <worley@ariadne.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] Comments on draft-vanelburg-dispatch-private-network-ind-02
Thread-Index: AQHOpMuc3ziQCFWyLUaMNLfibjb2jpmshO5Q
Date: Thu, 29 Aug 2013 18:44:27 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B08B1FC@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <201308291521.r7TFLUHc193847@shell01.TheWorld.com>
In-Reply-To: <201308291521.r7TFLUHc193847@shell01.TheWorld.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [dispatch] Comments on	draft-vanelburg-dispatch-private-network-ind-02
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2013 18:44:47 -0000

Read section 1.3 for reasons not to change the name of the header field.

I also think the abstract is long enough as it is and your proposed sentenc=
e can be inferred from the text, sufficiently for bibliographies and so on =
to identify what the document is about. To include what you want, what woul=
d you delete?

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Dale R. Worley
> Sent: 29 August 2013 16:22
> To: dispatch@ietf.org
> Subject: [dispatch] Comments on draft-vanelburg-dispatch-private-network-
> ind-02
>=20
> The abstract of -02 is:
>=20
>    This document specifies the SIP P-Private-Network-Indication P-header
>    used by the 3rd-Generation Partnership Project (3GPP).  The use of
>    this private network indication extension is only applicable inside
>    an administrative domain with previously agreed-upon policies for
>    generation, transport and usage of such information.  A private
>    network indication allows nodes in such a domain to treat private
>    network traffic according to a different set of rules than the set
>    applicable to public network traffic.  The indication also
>    distinguishes traffic from one private network from another private
>    network.
>=20
> What is absent from the abstract is a statement telling what the
> header *means*.  E.g., "The P-Private-Network-Indication indicates
> that the message is part of the message traffic of a private network,
> and identifies that private network."
>=20
> Given that the proposed header name is 28 characters long, some
> thought should be given to abbreviating it.
>=20
> Dale
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From worley@shell01.TheWorld.com  Fri Aug 30 07:32:10 2013
Return-Path: <worley@shell01.TheWorld.com>
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 9CA1911E8103 for <dispatch@ietfa.amsl.com>; Fri, 30 Aug 2013 07:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.083
X-Spam-Level: 
X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 Y1YLCjTTXcT8 for <dispatch@ietfa.amsl.com>; Fri, 30 Aug 2013 07:32:04 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B62BA11E80F5 for <dispatch@ietf.org>; Fri, 30 Aug 2013 07:32:04 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r7UEU0UK011860; Fri, 30 Aug 2013 10:30:02 -0400
Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r7UEQivH247622; Fri, 30 Aug 2013 10:26:44 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r7UEQg8q247642; Fri, 30 Aug 2013 10:26:42 -0400 (EDT)
Date: Fri, 30 Aug 2013 10:26:42 -0400 (EDT)
Message-Id: <201308301426.r7UEQg8q247642@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
In-reply-to: <949EF20990823C4C85C18D59AA11AD8B08B1FC@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@alcatel-lucent.com)
References: <201308291521.r7TFLUHc193847@shell01.TheWorld.com> <949EF20990823C4C85C18D59AA11AD8B08B1FC@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Comments on	draft-vanelburg-dispatch-private-network-ind-02
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2013 14:32:10 -0000

> From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
> 
> I also think the abstract is long enough as it is and your proposed
> sentence can be inferred from the text, sufficiently for
> bibliographies and so on to identify what the document is about. To
> include what you want, what would you delete?

I'd say that everything in the abstract can be inferred from the text,
but the point of an abstract is that you should be able to read it
without reading the text and yet know what the text is about.  I think
you've been thinking about PPNI long enough that you don't notice that
its purpose isn't obvious to the naive reader.

In regard to the size of the abstract, certainly you could omit
sentence 4, "The indication also distinguishes traffic from one
private network from another private network." as that would be
redundant after adding my proposed sentence between sentences 1 and 2.
If that isn't sufficient, I would propose removing sentence 2, "The
use of ...", as that is pretty much common to all P- headers (and is
stated in detail in section 1.2), and isn't as important as describing
what the header is *for*.

So I propose this as an improved abstract:

    This document specifies the SIP P-Private-Network-Indication
    P-header used by the 3rd-Generation Partnership Project (3GPP).
    The P-Private-Network-Indication indicates that the message is
    part of the message traffic of a private network, and identifies
    that private network.  A private network indication allows nodes
    to treat private network traffic according to a different set of
    rules than the set applicable to public network traffic.

Dale