From nobody Wed Jun  3 05:02:59 2015
Return-Path: <yoshigev@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD45B1A6FDB for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 05:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5yctUUXTZxn for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 05:02:56 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC9C1A6F87 for <sipcore@ietf.org>; Wed,  3 Jun 2015 05:02:56 -0700 (PDT)
Received: by wifw1 with SMTP id w1so19117506wif.0 for <sipcore@ietf.org>; Wed, 03 Jun 2015 05:02:55 -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:content-type; bh=YkqBBgTEqTf8Jhny+GKUKPU0NbGvDQ9zQDzpMgX02ZA=; b=jT7HBZqI6mnkyjVloeNclx/nc3SSe/y6sWYE2gtRKL/+CeY+psFmFnq3UryAI4l8pS oLCd7vem3HJQM5L6L9CZrqmBHqiz2hBSuHSOxXJaasa9GO7DDbyKJF/lWsWFczJ/4SO/ t5qARbfsuH7l5oFB8V+S7+FG5AXQEaJtYYm7l8gPVrdqL0gbVLF8h0EwEdkuFewk16AC wqhH9M0xEhb3Q/wLSufdesJKwIZh9vz03Oru/iEngajlsdoKItnUzuAx+B6cDwxqiN9M abT5FC42voTNvx8uvyVRUdjsbTQ7aXL63ERx8sgHVjokSMQZTMXdf5Q3uCTWPP7ZIO9M jGtg==
MIME-Version: 1.0
X-Received: by 10.194.177.230 with SMTP id ct6mr9557965wjc.31.1433332975184; Wed, 03 Jun 2015 05:02:55 -0700 (PDT)
Received: by 10.194.133.193 with HTTP; Wed, 3 Jun 2015 05:02:55 -0700 (PDT)
Date: Wed, 3 Jun 2015 15:02:55 +0300
Message-ID: <CAF_j7yb4szADPR7BO9+fGW+pWvQkwRuO3PNKNrL7Lastpk+3+A@mail.gmail.com>
From: Yehoshua Gev <yoshigev@gmail.com>
To: sipcore <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary=089e013d1d9cd4b18705179bd643
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/Y4QBaqPnFZMevMpJdwS3l1cc0qE>
Subject: [sipcore] Minor comments on draft-ietf-sipcore-refer-explicit-subscription-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 12:02:59 -0000

--089e013d1d9cd4b18705179bd643
Content-Type: text/plain; charset=UTF-8

A.
On section 8, paragraph 2, the following sentence:

   With this update, there may multiple
   subscribers to any given refer event state.


Should probably be:

   With this update, there may >>be<< multiple
   subscribers to any given refer event state.


B.
On section 4.4, it is not clear that the reference to "section 2.4.6"
refers to RFC 3515.
And on section 4.6, the link of "section 2.4.5" points to the current draft
instead of to RFC 3515.


Best,
Yehoshua Gev

--089e013d1d9cd4b18705179bd643
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A.<div>On section 8, paragraph 2, the following sentence:<=
br></div><div><div><pre class=3D"" style=3D"font-size:13.3333330154419px;ma=
rgin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">   With this update, there=
 may multiple
   subscribers to any given refer event state.
</pre></div><div><br></div><div>Should probably be:</div><div><pre class=3D=
"" style=3D"font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;c=
olor:rgb(0,0,0)">   With this update, there may &gt;&gt;be&lt;&lt; multiple
   subscribers to any given refer event state.
</pre></div><div><br></div><div>B.<br>On section 4.4, it is not clear that =
the reference to &quot;section 2.4.6&quot; refers to RFC 3515.</div><div>An=
d on section 4.6, the link of &quot;section 2.4.5&quot; points to the curre=
nt draft instead of to RFC 3515.</div><div><br></div><div><br></div><div>Be=
st,</div><div>Yehoshua Gev</div><div><br></div></div></div>

--089e013d1d9cd4b18705179bd643--


From nobody Wed Jun  3 15:53:01 2015
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92DA1B300A; Wed,  3 Jun 2015 15:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ-F88epYblV; Wed,  3 Jun 2015 15:52:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25A1B300E; Wed,  3 Jun 2015 15:52:55 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <20150603225255.28317.78722.idtracker@ietfa.amsl.com>
Date: Wed, 03 Jun 2015 15:52:55 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/LhosK9rpsEwaioqUKl2OUoBR_-E>
Cc: sipcore@ietf.org
Subject: [sipcore] Last Call: <draft-ietf-sipcore-6665-clarification-00.txt> (A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework) to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 22:53:00 -0000

The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'A clarification on the use of Globally Routable User Agent URIs
   (GRUUs) in the Session Initiation Protocol (SIP) Event Notification
   Framework'
  <draft-ietf-sipcore-6665-clarification-00.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Experience since the publication of the most recent SIP Events
   framework has shown that there is room for interpretation around the
   use of Globally Routable User Agent URIs in that specification.  This
   document clarifies the intended behavior.

   This document updates RFC 6665.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Wed Jun  3 16:37:55 2015
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B67C1B308F; Wed,  3 Jun 2015 16:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q333eHIuySSK; Wed,  3 Jun 2015 16:37:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D601B3085; Wed,  3 Jun 2015 16:37:52 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <20150603233752.9545.2109.idtracker@ietfa.amsl.com>
Date: Wed, 03 Jun 2015 16:37:52 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/WEIGxSGPpqRSrC4TDdt-DVHU83w>
Cc: sipcore@ietf.org
Subject: [sipcore] Last Call: <draft-ietf-sipcore-refer-explicit-subscription-02.txt> (Explicit Subscriptions for the REFER Method) to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 23:37:54 -0000

The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Explicit Subscriptions for the REFER Method'
  <draft-ietf-sipcore-refer-explicit-subscription-02.txt> as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The Session Initiation Protocol (SIP) REFER request, as defined by
   RFC3515, triggers an implicit SIP-Specific Event Notification
   framework subscription.  Conflating the start of the subscription
   with handling the REFER request makes negotiating SUBSCRIBE
   extensions impossible, and complicates avoiding SIP dialog sharing.
   This document defines extensions to REFER to remove the implicit
   subscription and, if desired, replace it with an explicit one.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Wed Jun  3 16:38:31 2015
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFD81B3089; Wed,  3 Jun 2015 16:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6nXMZIE5PAw; Wed,  3 Jun 2015 16:38:26 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD4C1A8AAD; Wed,  3 Jun 2015 16:38:26 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <20150603233826.8955.40177.idtracker@ietfa.amsl.com>
Date: Wed, 03 Jun 2015 16:38:26 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/KPqayOW3nEzt5pKYVA_AjWLiGN0>
Cc: sipcore@ietf.org
Subject: [sipcore] Last Call: <draft-ietf-sipcore-refer-clarifications-04.txt> (Clarifications for the use of REFER with RFC6665) to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 23:38:28 -0000

The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Clarifications for the use of REFER with RFC6665'
  <draft-ietf-sipcore-refer-clarifications-04.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The SIP REFER method relies on the SIP-Specific Event Notification
   Framework.  That framework was revised by RFC6665.  This document
   highlights the implications of the requirement changes in RFC6665,
   and updates the definition of the REFER method, RFC3515, to clarify
   and disambiguate the impact of those changes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Wed Jun  3 16:45:25 2015
Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD33C1A8908 for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 16:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC6BIwEFB2Jl for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 16:45:22 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509821A0387 for <sipcore@ietf.org>; Wed,  3 Jun 2015 16:45:22 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t53NjBDr036161 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <sipcore@ietf.org>; Wed, 3 Jun 2015 18:45:22 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: SIPCORE <sipcore@ietf.org>
Date: Wed, 03 Jun 2015 18:45:11 -0500
Message-ID: <736121A5-1C16-4651-8556-5174AA5DE215@nostrum.com>
References: <DF3686D5-8396-44AE-99C6-9717069E5972@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/qRVZdUtkuq4PpuobvTQ0mPMpcLU>
Subject: [sipcore] Fwd: AD Evaluation of draft-ietf-sipcore-refer-explicit-subscription-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 23:45:23 -0000

Oops, meant to include working group:

Forwarded message:

> From: Ben Campbell <ben@nostrum.com>
> To: draft-ietf-sipcore-refer-explicit-subscription.all@ietf.org
> Subject: AD Evaluation of 
> draft-ietf-sipcore-refer-explicit-subscription-02
> Date: Wed, 03 Jun 2015 18:27:07 -0500
>
> Hi,
>
> This is my AD Evaluation of 
> draft-ietf-sipcore-refer-explicit-subscription-02.
>
> Summary: This is ready for IETF LC. I have a few comments/questions, 
> but nothing that need block the last call.
>
> Substantive Comments:
>
> -- 4.3, 4th paragraph: "... return a 200 response containing ..."
>
> Containing where? This should probably mention Refer-Events-At. If 
> there's other text that says you MUST put it in that header field, I 
> missed it.
>
> -- 6:
>
> Did I miss a prohibition about putting both tags in Require at the 
> same time?
>
> -- 10, last sentence:
>
> Isn’t this redundant to similar text in refer-clarifications? Why 
> does it need to be in both?
>
> -- 8, third paragraph: "... the URI should be constructed so that it 
> is not easy to guess..."
>
> Is this intentionally non-normative? (Seems odd that the following 
> “for instance” about TLS or DTLS _is_ normative but this sentence 
> is not.)
>
> Editorial:
>
> -- 4.3, third paragraph:
>
> s/recieved/received


From nobody Wed Jun  3 16:45:34 2015
Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE141A0387 for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 16:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V0oZaOFM_My for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 16:45:26 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EEF1B308F for <sipcore@ietf.org>; Wed,  3 Jun 2015 16:45:26 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t53NjBDs036161 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <sipcore@ietf.org>; Wed, 3 Jun 2015 18:45:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: SIPCORE <sipcore@ietf.org>
Date: Wed, 03 Jun 2015 18:45:25 -0500
Message-ID: <3C33DF12-05DB-43A8-8FD0-BE1B29924D8A@nostrum.com>
References: <C2A58DC4-8640-49F4-82E0-D96024C00E8F@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/p-s_o9bJNfNwLg5YkXdLYhWPfyw>
Subject: [sipcore] Fwd: AD Evaluation of draft-ietf-sipcore-refer-clarifications-04
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 23:45:29 -0000

Oops, meant to include working group:

Forwarded message:

> From: Ben Campbell <ben@nostrum.com>
> To: draft-ietf-sipcore-refer-clarifications.all@ietf.org
> Subject: AD Evaluation of draft-ietf-sipcore-refer-clarifications-04
> Date: Wed, 03 Jun 2015 17:42:23 -0500
>
> Hi,
>
> This is my AD Evaluation of 
> draft-ietf-sipcore-refer-clarifications-04.
>
> Summary: Ready for IETF Last Call. I will kick that off together with 
> the refer-explicit-subscriptions draft when I have finished reviewing 
> that draft.
>
> Comments: None.
>
> Thanks!
>
> Ben.


From nobody Wed Jun  3 16:45:43 2015
Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F3B1A8908 for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 16:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtDoui6GsCX1 for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 16:45:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F9E1A0387 for <sipcore@ietf.org>; Wed,  3 Jun 2015 16:45:41 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t53NjBDt036161 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <sipcore@ietf.org>; Wed, 3 Jun 2015 18:45:41 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: SIPCORE <sipcore@ietf.org>
Date: Wed, 03 Jun 2015 18:45:41 -0500
Message-ID: <3EC93612-13FD-4B7D-BEA7-9DD6BAF0D083@nostrum.com>
References: <6A0F5649-8E72-4A18-84E5-9BE9D27FC7F9@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/j0y0jXYSkGLz4fB4rYHkTyQ7CGo>
Subject: [sipcore] Fwd: AD Evaluation of draft-ietf-sipcore-6665-clarification-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 23:45:43 -0000

Oops, meant to include working group:

Forwarded message:

> From: Ben Campbell <ben@nostrum.com>
> To: draft-ietf-sipcore-6665-clarification.all@ietf.org
> Subject: AD Evaluation of draft-ietf-sipcore-6665-clarification-00
> Date: Wed, 03 Jun 2015 17:25:11 -0500
>
> Hi
>
> This is my AD Evaluation of draft-ietf-sipcore-6665-clarification-00.
>
> Summary: This is ready for IETF Last Call. I will kick that off 
> shortly.
>
> Comments:
>
> -- section 1: "... clarity in [2119]"
>
> Do you really mean 2119, not 6665? That is, are you suggesting a lack 
> of clarity on what MUST means, or the lack of clarity in 6665 
> mentioned in section 2?
>
> -- section 2, last paragraph : "regardless of whether such
> subscription would be created by a SUBSCRIBE or a REFER message. "
>
> I suggest you consider adding "or any other method", to future proof 
> against people coming up with new ways to create subscriptions.
>
> Thanks!
>
> Ben.


From nobody Wed Jun  3 20:07:16 2015
Return-Path: <rjsparks@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2099E1B335C for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 20:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agCESNlBTSLU for <sipcore@ietfa.amsl.com>; Wed,  3 Jun 2015 20:07:11 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF2A1B335D for <sipcore@ietf.org>; Wed,  3 Jun 2015 20:07:10 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t54379Kj054574 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for <sipcore@ietf.org>; Wed, 3 Jun 2015 22:07:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <556FC0D8.5010308@nostrum.com>
Date: Wed, 03 Jun 2015 22:07:04 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "sipcore@ietf.org" <sipcore@ietf.org>
References: <556FBF2F.8080302@nostrum.com>
In-Reply-To: <556FBF2F.8080302@nostrum.com>
X-Forwarded-Message-Id: <556FBF2F.8080302@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/HfBEcKN10F6ZGFzCxg5TkddiNrY>
Subject: [sipcore] Fwd: Re: AD Evaluation of draft-ietf-sipcore-refer-explicit-subscription-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 03:07:14 -0000

-------- Forwarded Message --------






On 6/3/15 6:27 PM, Ben Campbell wrote:
 > Hi,
 >
 > This is my AD Evaluation of
 > draft-ietf-sipcore-refer-explicit-subscription-02.
 >
 > Summary: This is ready for IETF LC. I have a few comments/questions,
 > but nothing that need block the last call.
 >
 > Substantive Comments:
 >
 > -- 4.3, 4th paragraph: "... return a 200 response containing ..."
 >
 > Containing where? This should probably mention Refer-Events-At. If
 > there's other text that says you MUST put it in that header field, I
 > missed it.

I will add a clause saying "As the Refer-Events-At header field value"

 >
 > -- 6:
 >
 > Did I miss a prohibition about putting both tags in Require at the
 > same time?

It's at "In particular, a UA can only invoke the use of one of the
extensions in a request."
I don't think we need a 2119 word here.

 >
 > -- 10, last sentence:
 >
 > Isn’t this redundant to similar text in refer-clarifications? Why does
 > it need to be in both?

I assume from context you meant 7 here, not 10.
Section 5 in -clarifications was added late in the game (only in the
current version).
It would probably be ok to remove the 2119 word from this document and
point into
clarifications instead.

 >
 > -- 8, third paragraph: "... the URI should be constructed so that it
 > is not easy to guess..."
 >
 > Is this intentionally non-normative? (Seems odd that the following
 > “for instance” about TLS or DTLS _is_ normative but this sentence is
 > not.)

I try hard to not put 2119 into security considerations sections. I find
they are more helpful if they discuss security considerations, not add
more to the protocol. The SHOULD that's there is something that I wish I
hadn't done (I wasn't paying close enough attention at the time) - it
should have been up in the protocol part of the body. Unless you think
this will cause an implementation flaw, though, I'd prefer to not touch
it unless later review makes me do major surgery to the section.

 >
 > Editorial:
 >
 > -- 4.3, third paragraph:
 >
 > s/recieved/received

ack.



From nobody Thu Jun  4 00:40:06 2015
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3B1ACD53; Thu,  4 Jun 2015 00:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww_Al6iPGex8; Thu,  4 Jun 2015 00:40:03 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70301ACE71; Thu,  4 Jun 2015 00:39:59 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-af-557000cd9ed8
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.8F.28096.DC000755; Thu,  4 Jun 2015 09:39:58 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.137]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Thu, 4 Jun 2015 09:39:57 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "ietf@ietf.org" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
Thread-Topic: [sipcore] Last Call: <draft-ietf-sipcore-6665-clarification-00.txt> (A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework) to Proposed Standard
Thread-Index: AQHQnlAMFDKoxxFcN0S4yuB7gC29TJ2b9TCA
Date: Thu, 4 Jun 2015 07:39:57 +0000
Message-ID: <39B5E4D390E9BD4890E2B31079006101128CB7D1@ESESSMB301.ericsson.se>
References: <20150603225255.28317.78722.idtracker@ietfa.amsl.com>
In-Reply-To: <20150603225255.28317.78722.idtracker@ietfa.amsl.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvre45hoJQg/VruSzunZnOZvFs43wW i68/NrE5MHssWfKTKYAxissmJTUnsyy1SN8ugSvj31GVgmPCFe3d3ewNjLsFuhg5OSQETCTW XN3FDGGLSVy4t56ti5GLQ0jgKKPE1acfGCGcxYwSJ26dAatiE9CTmLjlCCuILSLgLfF52SKw OLOApsSjnXuZQBqEBX4zSsxo7wNzRAT+MEqs/X+MCaLDSOL+ow1ANgcHi4CKxPaj4SBhXgFf ic4Nt9hAwkICjhL/5riDhDkFnCR2LP7ECGIzCshKXP3TywixS1zi1pP5TBBXC0gs2XMe6gNR iZeP/7FC2IoSV6cvZ4Ko15N4dmoWC4StLbFs4WtmiLWCEidnPmGZwCg2C8nYWUhaZiFpmYWk ZQEjyypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwPg5uOW31Q7Gg88dDzEKcDAq8fAmvMwP FWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxn6m/bemLY+d K3CMR8NH+dqkjfKvG5h+H3d+VcmRlea0lKnln+xJmX1zk+O/JR2Kfmpg+6+V0Wd9xOI3OdyS 2f+v6Ohtk8kJnHSF+7Ybs3H7jX5WW+VpMy832nv4ycyZGa5uXCqw/dRujdBjLBvWM6fvtXrg +XTJ3/5TK+8rvmljKhNi41rBosRSnJFoqMVcVJwIAG/uaTSAAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/IBFdDjSS7xlBji2bMrQNG3qzbTc>
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-6665-clarification-00.txt> (A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework) to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 07:40:05 -0000

Hello,

COMMENT:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The draft http://tools.ietf.org/html/draft-ietf-sipcore-6665-clarification-=
00 uses inconsistent terminology. It uses "subscription requests (implicit =
or explicit)" and "request that might create a subscription to the associat=
ed dialog" and both seem to be the same. It would be better to use one term=
 only.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Kind regards

Ivo Sedlacek

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of The IESG
Sent: 4. =E8ervna 2015 0:53
To: IETF-Announce
Cc: sipcore@ietf.org
Subject: [sipcore] Last Call: <draft-ietf-sipcore-6665-clarification-00.txt=
> (A clarification on the use of Globally Routable User Agent URIs (GRUUs) =
in the Session Initiation Protocol (SIP) Event Notification Framework) to P=
roposed Standard


The IESG has received a request from the Session Initiation Protocol Core W=
G (sipcore) to consider the following document:
- 'A clarification on the use of Globally Routable User Agent URIs
   (GRUUs) in the Session Initiation Protocol (SIP) Event Notification
   Framework'
  <draft-ietf-sipcore-6665-clarification-00.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final=
 comments on this action. Please send substantive comments to the ietf@ietf=
.org mailing lists by 2015-06-17. Exceptionally, comments may be sent to ie=
sg@ietf.org instead. In either case, please retain the beginning of the Sub=
ject line to allow automated sorting.

Abstract


   Experience since the publication of the most recent SIP Events
   framework has shown that there is room for interpretation around the
   use of Globally Routable User Agent URIs in that specification.  This
   document clarifies the intended behavior.

   This document updates RFC 6665.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/ball=
ot/


No IPR declarations have been submitted directly on this I-D.


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


From nobody Thu Jun  4 15:46:35 2015
Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E7E1A895C for <sipcore@ietfa.amsl.com>; Thu,  4 Jun 2015 15:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34qqWbgkHpbd for <sipcore@ietfa.amsl.com>; Thu,  4 Jun 2015 15:46:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBEE1A8958 for <sipcore@ietf.org>; Thu,  4 Jun 2015 15:46:31 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t54MkUa1066706 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 4 Jun 2015 17:46:31 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <5570D546.1090405@nostrum.com>
Date: Thu, 04 Jun 2015 17:46:30 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, SIPCORE <sipcore@ietf.org>
References: <6A0F5649-8E72-4A18-84E5-9BE9D27FC7F9@nostrum.com> <3EC93612-13FD-4B7D-BEA7-9DD6BAF0D083@nostrum.com>
In-Reply-To: <3EC93612-13FD-4B7D-BEA7-9DD6BAF0D083@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/bPmGbQX-gnJzBIQRX6CE_cvydEQ>
Subject: Re: [sipcore] Fwd: AD Evaluation of draft-ietf-sipcore-6665-clarification-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 22:46:33 -0000

On 6/3/15 18:45, Ben Campbell wrote:
> -- section 1: "... clarity in [2119]"
>
> Do you really mean 2119, not 6665? That is, are you suggesting a lack 
> of clarity on what MUST means, or the lack of clarity in 6665 
> mentioned in section 2?

Yes, this should point to RFC 6665. I presume we can fix this with an 
RFC editor's note.

> -- section 2, last paragraph : "regardless of whether such
> subscription would be created by a SUBSCRIBE or a REFER message. "
>
> I suggest you consider adding "or any other method", to future proof 
> against people coming up with new ways to create subscriptions.

Section 4.2.1 of RFC 6665 is pretty clear about normatively forbidding 
new ways to create subscriptions. This was one of a small set of key 
flaws in the original 3265 mechanism that prompted work on a bis draft. 
I fear that adding "or any other method" would dilute the absolute 
prohibition on adding new methods by implying that some other method may 
somehow be allowed.

For easy reference: https://tools.ietf.org/html/rfc6665#section-4.2.1

/a


From nobody Thu Jun  4 17:48:26 2015
Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF95E1ACE0B for <sipcore@ietfa.amsl.com>; Thu,  4 Jun 2015 17:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ive6TTe_Trl for <sipcore@ietfa.amsl.com>; Thu,  4 Jun 2015 17:48:22 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8AA1ACE0A for <sipcore@ietf.org>; Thu,  4 Jun 2015 17:48:22 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t550mBcS077543 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Jun 2015 19:48:22 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Adam Roach" <adam@nostrum.com>
Date: Thu, 04 Jun 2015 19:48:11 -0500
Message-ID: <F72BB8DC-6CAF-4867-9BC4-4C3606B715A1@nostrum.com>
In-Reply-To: <5570D546.1090405@nostrum.com>
References: <6A0F5649-8E72-4A18-84E5-9BE9D27FC7F9@nostrum.com> <3EC93612-13FD-4B7D-BEA7-9DD6BAF0D083@nostrum.com> <5570D546.1090405@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/YixJPaj2f7WiTfFdebU2mwjDPNM>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-6665-clarification-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 00:48:26 -0000

On 4 Jun 2015, at 17:46, Adam Roach wrote:

> On 6/3/15 18:45, Ben Campbell wrote:
>> -- section 1: "... clarity in [2119]"
>>
>> Do you really mean 2119, not 6665? That is, are you suggesting a lack 
>> of clarity on what MUST means, or the lack of clarity in 6665 
>> mentioned in section 2?
>
> Yes, this should point to RFC 6665. I presume we can fix this with an 
> RFC editor's note.

Sure.

>
>> -- section 2, last paragraph : "regardless of whether such
>> subscription would be created by a SUBSCRIBE or a REFER message. "
>>
>> I suggest you consider adding "or any other method", to future proof 
>> against people coming up with new ways to create subscriptions.
>
> Section 4.2.1 of RFC 6665 is pretty clear about normatively forbidding 
> new ways to create subscriptions. This was one of a small set of key 
> flaws in the original 3265 mechanism that prompted work on a bis 
> draft. I fear that adding "or any other method" would dilute the 
> absolute prohibition on adding new methods by implying that some other 
> method may somehow be allowed.
>
> For easy reference: https://tools.ietf.org/html/rfc6665#section-4.2.1

Okay.

(It's hard to forbid new things when all we have to do is update or 
obsolete 6665 to remove the prohibition. But that logic could equally 
apply to any attempt to future-proof this draft as well, and I take your 
point about making sure both docs are in solidarity.)


From nobody Fri Jun  5 08:17:19 2015
Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5C1B30C9 for <sipcore@ietfa.amsl.com>; Fri,  5 Jun 2015 08:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXh6SA8yqDZ5 for <sipcore@ietfa.amsl.com>; Fri,  5 Jun 2015 08:17:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBBF1A19F2 for <sipcore@ietf.org>; Fri,  5 Jun 2015 08:17:16 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t55FHEOQ056480 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <sipcore@ietf.org>; Fri, 5 Jun 2015 10:17:15 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <5571BD7A.3080908@nostrum.com>
Date: Fri, 05 Jun 2015 10:17:14 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "'SIPCORE'" <sipcore@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/v2SOm4rSGE536Jka10O2qCJvBWY>
Subject: [sipcore] Not meeting in Prague, please review dual-stack draft.
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 15:17:17 -0000

[as chair]

Given the current level of email discussion on the SIPCORE mailing list, 
we will not be requesting time for a face-to-face slot in Prague.

However, we do have a chartered item with an associated draft that has 
attracted very little review or comment: 
https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/

The chairs strongly urge SIPCORE WG participants to spend time reviewing 
and sending comments on this document over the next few weeks, to 
potentially facilitate informal ("hallway") discussions in Prague.

/a


From nobody Fri Jun  5 13:31:02 2015
Return-Path: <gsalguei@cisco.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057A71A8A23 for <sipcore@ietfa.amsl.com>; Fri,  5 Jun 2015 13:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7YvC3zaseFB for <sipcore@ietfa.amsl.com>; Fri,  5 Jun 2015 13:30:59 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4391A8A1C for <sipcore@ietf.org>; Fri,  5 Jun 2015 13:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1016; q=dns/txt; s=iport; t=1433536259; x=1434745859; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IYRnNlGZ0lXCLMEey12dz1clcI4K2GYIVR6Bn0Fy2wk=; b=Fll3/hYwQQy2UWl6P3mHxpj9GqT64DwpftftEN2B+1mY03mQeFC+sULg vFlkz6K7f2xKTIfzV7b3hgfY13OzbliaIu3BwkcV1WcvXYkRVEiaGZJRl gPkpbXo5mrsl9aZxC2m9fdZ5oUigVEYfi+DipKNv3UpYFCQKBEEFYwNDN s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A4BABsBnJV/5RdJa1bgxBUXga9fWYJgVEKhS1KAoE3OBQBAQEBAQEBgQqEIgEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FiCUIDdtoAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4QjEQEeMweDF4EWBZMfhD+GaIEvg3iSLiSDd2+BDDqBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,560,1427760000"; d="scan'208";a="156870897"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 05 Jun 2015 20:30:58 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t55KUwZX014215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 20:30:58 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.169]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 15:30:58 -0500
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Adam Roach <adam@nostrum.com>
Thread-Topic: [sipcore] Not meeting in Prague, please review dual-stack draft.
Thread-Index: AQHQn6K4NpogTkmJRkujOvhflW0Zjp2esbmA
Date: Fri, 5 Jun 2015 20:30:58 +0000
Message-ID: <5729A4A5-C521-4B8C-8F78-179131DB35A7@cisco.com>
References: <5571BD7A.3080908@nostrum.com>
In-Reply-To: <5571BD7A.3080908@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.211.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0AFFFF6314C41C4D91C586F61A09E7DD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/4luusqPJKFQJHoYDRCSoJXU2Oos>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Not meeting in Prague, please review dual-stack draft.
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 20:31:01 -0000

Thanks for the reminder, Adam.  Review comments would be greatly appreciate=
d since the latest draft has addressed all open issues from the perspective=
 of the authors.=20

Cheers,

Gonzalo

> On Jun 5, 2015, at 11:17 AM, Adam Roach <adam@nostrum.com> wrote:
>=20
> [as chair]
>=20
> Given the current level of email discussion on the SIPCORE mailing list, =
we will not be requesting time for a face-to-face slot in Prague.
>=20
> However, we do have a chartered item with an associated draft that has at=
tracted very little review or comment: https://datatracker.ietf.org/doc/dra=
ft-johansson-sip-dual-stack/
>=20
> The chairs strongly urge SIPCORE WG participants to spend time reviewing =
and sending comments on this document over the next few weeks, to potential=
ly facilitate informal ("hallway") discussions in Prague.
>=20
> /a
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Sun Jun  7 01:37:35 2015
Return-Path: <sperreault@jive.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597441A1B1F for <sipcore@ietfa.amsl.com>; Sun,  7 Jun 2015 01:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlMcgBII_nOZ for <sipcore@ietfa.amsl.com>; Sun,  7 Jun 2015 01:37:33 -0700 (PDT)
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2B71A1A55 for <sipcore@ietf.org>; Sun,  7 Jun 2015 01:37:32 -0700 (PDT)
Received: by igbzc4 with SMTP id zc4so42640095igb.0 for <sipcore@ietf.org>; Sun, 07 Jun 2015 01:37:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fhWGWgzRVauaASMyfFrzon544dd7nQgJ45IpkZaCZ5A=; b=UL0AYd3Zew7fag90aTw/rVbbfMP2dgdl7UIarGK1ED9rEX6OXEcczbHN5umFiXMhAq OoM/PnX2fe8pZICM2q48NTA2hdh3Ab5EWCKEdAGKSMy3sOphN6lMa//+Z3bLhAWQRpyv BBt8ijtRIfQXykgOXUc5ucH8iIcQXfvJDeP0KHlkx1zxWzseFCm+n5Df3oWkzqprXNk7 mllXpR8JHZS89NGt9+UuvNQBopJxbDFMOGIRoAmZV2hgeJn5EYqfGKaeyde2tAkbZsDh p6Nel0uVQJ6i4ipKqs5aAC1l4dd8ixMhnYZzH4uKlwGFRXF/yYP24G1WiJH0fHuJWALt fsIg==
X-Gm-Message-State: ALoCoQkwHIK+db7x5vjWUheD0oCldHMJfSSJkO3LMMpLFtpdiZ5WdHUoo4X3oZtpVb/GTBvSDs2Z
X-Received: by 10.43.171.70 with SMTP id nt6mr17672202icc.73.1433666252176; Sun, 07 Jun 2015 01:37:32 -0700 (PDT)
Received: from Simons-MacBook-Air.local ([206.47.252.21]) by mx.google.com with ESMTPSA id g3sm1386544igi.10.2015.06.07.01.37.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2015 01:37:31 -0700 (PDT)
Message-ID: <557402C9.7050505@jive.com>
Date: Sun, 07 Jun 2015 04:37:29 -0400
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>, 'SIPCORE' <sipcore@ietf.org>
References: <5571BD7A.3080908@nostrum.com>
In-Reply-To: <5571BD7A.3080908@nostrum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/7rQkYfgGYxCQYRcGmP0dRrhZE24>
Subject: Re: [sipcore] Not meeting in Prague, please review dual-stack draft.
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jun 2015 08:37:34 -0000

Le 2015-06-05 11:17, Adam Roach a �crit :
> However, we do have a chartered item with an associated draft that has
> attracted very little review or comment:
> https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/

Don't you mean this one instead?
https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/

Simon


From nobody Sun Jun  7 09:33:58 2015
Return-Path: <sperreault@jive.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E421AC3C6 for <sipcore@ietfa.amsl.com>; Sun,  7 Jun 2015 09:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXjWB4GoOduE for <sipcore@ietfa.amsl.com>; Sun,  7 Jun 2015 09:33:55 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D9E1AC3C4 for <sipcore@ietf.org>; Sun,  7 Jun 2015 09:33:55 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so46311400igb.1 for <sipcore@ietf.org>; Sun, 07 Jun 2015 09:33:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TAn0yzEtlELeDh9ucUR4JFZ9xH4+yrlcrDjiE21k6bs=; b=BugRM9M1x8tf1nYqipaHHvaXXkCvnfP0qRbFEH2iqdC0anqPFmCuWdR0ikv9vyKoDn Qq89/rrxiOiJrm69m09SSkWwHWgJx5G8tQ6g2+LqPFU2/bPc2eN6d91YzP9vwfBRQ8bq F6b+SjCKV5I9co5z8wDIDUr7n0rqfgCD2rUtcMu2yNQwsS58JeRCn9PTp9Y5Q07pBaZy cj6yEzOHoYTfHKeXkvuhHN6GJ1yL6YK6NodG57lgiDSPu55n9XDrjxlmfZwbWI5MyWge O2E61n4IZC7wa2IWg3jHrxrdp8F2aeC9I46KofTf77B4mHUsvpLX8k9/C4qZA4QH8jG9 1crA==
X-Gm-Message-State: ALoCoQngMG+8z48aaCNNbHiNe2z48Z8B9kt2ywYvTU330nSJwY7112ZzHNL9JgNDQwOu9lr1XLTL
X-Received: by 10.50.23.116 with SMTP id l20mr8902327igf.13.1433694834691; Sun, 07 Jun 2015 09:33:54 -0700 (PDT)
Received: from Simons-MacBook-Air.local ([198.202.203.177]) by mx.google.com with ESMTPSA id t7sm3257326ign.8.2015.06.07.09.33.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2015 09:33:53 -0700 (PDT)
Message-ID: <55747270.9060408@jive.com>
Date: Sun, 07 Jun 2015 10:33:52 -0600
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>, 'SIPCORE' <sipcore@ietf.org>
References: <5571BD7A.3080908@nostrum.com>
In-Reply-To: <5571BD7A.3080908@nostrum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/43xNG4UuKC0A9nwZMLkCfNsPW6g>
Subject: Re: [sipcore] Not meeting in Prague, please review dual-stack draft.
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jun 2015 16:33:56 -0000

Le 2015-06-05 09:17, Adam Roach a �crit :
> However, we do have a chartered item with an associated draft that has
> attracted very little review or comment:
> https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/
> 
> The chairs strongly urge SIPCORE WG participants to spend time reviewing
> and sending comments on this document over the next few weeks, to
> potentially facilitate informal ("hallway") discussions in Prague.

My earlier comments have *not* been addressed, as far as I can see...

https://mailarchive.ietf.org/arch/msg/sipcore/bvqJHA6kLHOE0GamFfeJjN450Qc

Simon


From nobody Sun Jun  7 10:44:37 2015
Return-Path: <gsalguei@cisco.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A071AC430 for <sipcore@ietfa.amsl.com>; Sun,  7 Jun 2015 10:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0RgNnlBZzic for <sipcore@ietfa.amsl.com>; Sun,  7 Jun 2015 10:44:35 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CE71AC42F for <sipcore@ietf.org>; Sun,  7 Jun 2015 10:44:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=999; q=dns/txt; s=iport; t=1433699075; x=1434908675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h+9amcsXbLrfqgJVOGEHLy41mJKogSREPfRAEG/a24g=; b=PIYJhqyhu6POAp/ZybO05J+NDS1thWhZjROT7p1a5vOGGTTmf6sKClDR U8hJH8b/HSxqXZ2VEcxe9PLy9mst3871B6RGpcm+5cWOjvmChbuTGi41S 5xxoic7zHiMRjDPBufDk8vxszDtN07kmEhiinhDpIh++eItOorpqBm0Aj 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BYBAC2gnRV/40NJK1cgxBUXga+A2YJgVYMhS1KAoEWOBQBAQEBAQEBgQqEIgEBAQMBAQEBawsFCwIBCA4KLicLJQIEDgWIJQgNA85tAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4RTMweDF4EWBZMuhECGaoEvg3qSNCSDd2+BRoEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,569,1427760000";  d="scan'208";a="1481667"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2015 17:44:32 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t57HiWpB026044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Jun 2015 17:44:32 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.169]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sun, 7 Jun 2015 12:44:32 -0500
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Simon Perreault <sperreault@jive.com>
Thread-Topic: [sipcore] Not meeting in Prague, please review dual-stack draft.
Thread-Index: AQHQoT+9NpogTkmJRkujOvhflW0Zjp2hpK2A
Date: Sun, 7 Jun 2015 17:44:32 +0000
Message-ID: <F0305E6D-94A7-455B-BC4C-8260FF5FA3DA@cisco.com>
References: <5571BD7A.3080908@nostrum.com> <55747270.9060408@jive.com>
In-Reply-To: <55747270.9060408@jive.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.13.176]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9B0504CD7E8D3E42BCF60ABC5603E97F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/vi356tiZUED1-xIJdt_HPsnZYUg>
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Not meeting in Prague, please review dual-stack draft.
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jun 2015 17:44:36 -0000

> On Jun 7, 2015, at 9:33 AM, Simon Perreault <sperreault@jive.com> wrote:
>=20
> Le 2015-06-05 09:17, Adam Roach a =E9crit :
>> However, we do have a chartered item with an associated draft that has
>> attracted very little review or comment:
>> https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/
>>=20
>> The chairs strongly urge SIPCORE WG participants to spend time reviewing
>> and sending comments on this document over the next few weeks, to
>> potentially facilitate informal ("hallway") discussions in Prague.
>=20
> My earlier comments have *not* been addressed, as far as I can see...
>=20
> https://mailarchive.ietf.org/arch/msg/sipcore/bvqJHA6kLHOE0GamFfeJjN450Qc

Thanks, Simon.  I somehow missed these comments.  We=92ll respond shortly w=
ith proposed updates.

Cheers,

Gonzalo

>=20
> Simon
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Mon Jun  8 19:56:10 2015
Return-Path: <dwing@cisco.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0D1A8A0E for <sipcore@ietfa.amsl.com>; Mon,  8 Jun 2015 19:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.511
X-Spam-Level: 
X-Spam-Status: No, score=-11.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18TpaMTICo0F for <sipcore@ietfa.amsl.com>; Mon,  8 Jun 2015 19:56:07 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7151A89F9 for <sipcore@ietf.org>; Mon,  8 Jun 2015 19:56:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4222; q=dns/txt; s=iport; t=1433818567; x=1435028167; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=OiWWJzNiADQhFfx/Qyqx4Tgxvavm+kIcrYFmVsZB0w4=; b=UCTD2WNX4qFw+S6JAGkFBbdhLDitU7J5UvZ8SbdbmEO7Nsluk+WwGYJt ngFKIPrZ1/ICyahYG+gPIyKtQRx17invKdQ7H8X/DF78cxD+XCQjyThYV 0+ZQiwNLjm5vQBQl8/MO74Pfq9XwX9Lnh7u/k5/nIeVxVP5Yzcs9l86dl k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BjBACkVHZV/4kNJK1cgxABwAcJgVKHOzgUAQEBAQEBAYEKhGMNgh6IE5pnlHefCQEfikGFPYNpgRYFi2ZskhoBiAmPWySEGB6CeAEBAQ
X-IronPort-AV: E=Sophos;i="5.13,577,1427760000";  d="scan'208";a="5619284"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jun 2015 02:56:06 +0000
Received: from [10.24.113.88] ([10.24.113.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t592u5SZ007481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sipcore@ietf.org>; Tue, 9 Jun 2015 02:56:06 GMT
From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= <dwing@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <E56B3AF7-6874-4A66-8426-78A98DA435B4@cisco.com>
Date: Mon, 8 Jun 2015 19:41:04 -0700
To: sipcore@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/LRdKLi9X2bn8bePrddQ4Feh5Ie0>
Subject: [sipcore] comments on draft-ietf-sipcore-dns-dual-stack-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 02:56:09 -0000

Adam encouraged me to look at draft-ietf-sipcore-dns-dual-stack-02, and =
I had a few suggestions.

Towards the end of the Introduction, it says:

  The procedures described herein
  are such that a dual-stack client SHOULD look up both A and AAAA
  records in DNS and then select the best way to set up a network flow.
  The details of how the latter is done is considered out of scope for
  this document.

I guess "network flow" means the SIP communications to the SIP server?  =
Is there a better term than "network flow" that could be used, so that =
nobody can confuse the "network flow" with the RTP session?

Section 4.1 says:

  Happy Eyeballs [RFC6555] has proven that looking up the "A or AAAA
  record" is not an effective practice for dual-stack clients and that
  it can add significant connection delay and greatly degrade user
  experience.

What we know is that 30 second long TCP connection timeouts are harmful =
to user experience.    Happy Eyeballs is but one pragmatic solution.  I =
do not agree that Happy Eyeballs proved there is a connection delay =
problem due to A lookups or with AAAA lookups.  What I think =
draft-ietf-sipcore-dns-dual-stack is trying to say is perhaps something =
like this:

 "Happy Eyeballs [RFC6555] works around connectivity delays to the OS's =
preferred address family (usually IPv6), so that the client suffers a =
connectivity delay that is only slightly worse than an single-stack =
host.  Without Happy Eyeballs, a client could suffer a 30 second delay =
to its preferred address family."


I noted that draft-ietf-sipcore-dns-dual-stack does not actually resolve =
this connectivity problem in its normative text; it seems solely worried =
about DNS lookups.  I admit that I haven't been following =
draft-ietf-sipcore-dns-dual-stack, but was it a conscious design or =
scoping decision to not worry about the IPv6 or IPv4 path to the SIP =
server, and just worry about DNS answers?



The actual recommendation at end of section 4.1 only says:

     The dual-stack client SHOULD perform an A and AAAA record lookup
     of the domain name and add the respective IPv4/IPv6 addresses to
     the list of IP addresses to be contacted.

but it doesn't say if A or AAAA should be placed at the beginning of the =
list, end of the list, or scattered randomly.  It probably matters, =
especially if we envision a long list of AAAA and long list of A =
records, and we also envision an outage of one address family.



I noticed that sections 4.1 and 4.2 make no recommendation for how =
quickly attempts should be made to contact the SIP server over IPv4 or =
IPv6, and does not discuss the harm -- or lack of harm -- of a server =
receiving identical SIP messages during that time.  I expect nothing =
harmful happens if an implementation decided to be really aggressive =
with its use of IPv6 and IPv4, but it would be good to remind =
implementors of harm or non-harm of sending messages (aggressively) =
which might be received multiple times.  Happy Eyeballs (RFC6555) =
doesn't worry about that problem because Happy Eyeballs is just =
concerned with TCP connection establishment time.  With SIP signaling =
over UDP, we don't get a 'connection' first.  Should =
draft-ietf-sipcore-dns-dual-stack discuss UDP and TCP separately, and =
should implementations do something more like RFC6555 if they are doing =
SIP over TCP, and something different if doing SIP over UDP?


Section 4.2 says:

  When indicating address family preference through SRV, IPv4-only and/
  or IPv6-only clients should be prepared to handle SRV record sets
  that don't resolve into an ip address in the address family used by
  that client.

I believe the "should" should be RFC2119 capitalized (so that it is =
normative), and I also believe it needs to be MUST, because failure to =
handle multiple SRV record sets will cause interoperability problems, =
won't it?


Next sentence of Section 4.2 says:

  In such a case, the client should simply proceed to the
  next priority and try the hostnames in the alternate address family.

s/alternate address family/supported address family/

-d







From nobody Wed Jun 10 14:15:39 2015
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125961ACE61 for <sipcore@ietfa.amsl.com>; Wed, 10 Jun 2015 14:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNxe4isUtpRX for <sipcore@ietfa.amsl.com>; Wed, 10 Jun 2015 14:15:36 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7251A899E for <sipcore@ietf.org>; Wed, 10 Jun 2015 14:15:35 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-72-5578a8f5f75d
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.82.04401.5F8A8755; Wed, 10 Jun 2015 23:15:33 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 23:15:33 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] RSeq and forking - Errata
Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tA==
Date: Wed, 10 Jun 2015 21:15:32 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvre7XFRWhBjdazCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj0/GbrAVXNSvutp1jb2DcoNDFyMkhIWAi sa5lFyOELSZx4d56ti5GLg4hgaOMEpOPH2UGSQgJLGaUWLfKrIuRg4NNwEKi+582SFhEIFDi 6pIJYCXCAgYSP768YIGIG0qcPNHOAlIuIqAncbmnGiTMIqAqsfrvErASXgFfibXrvoGtZQRa +/3UGiYQm1lAXOLWk/lMEOcISCzZc54ZwhaVePn4HyuErSSx9vB2Foh6HYkFuz+xQdjaEssW vmaGmC8ocXLmE5YJjMKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st 2cQIDPmDW36r7mC8/MbxEKMAB6MSD6/CrPJQIdbEsuLK3EOM0hwsSuK8MzbnhQoJpCeWpGan phakFsUXleakFh9iZOLglGpgDL54NCgjs4Bxp9/T5cZT71s9Mvo353nWffuKmisZey/7MGmu yzztU87Xts12RstuqRlzVLvTBTydr/lqMLlHzMgUr15TEFzvPu+D7Hf/+LvhTDeSgt3nCO8v 8DvkHHE772rACcdDS/s0eYyOptuZ9M9SeFp+v7HzZN6LrZeT+v48NWQ+nuutxFKckWioxVxU nAgAzil+VVoCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/DM8JN3oWR8yuZbRCluvv9syj62M>
Subject: Re: [sipcore] RSeq and forking - Errata
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2015 21:15:38 -0000

Hi,

Some time ago, this issue was raised, and it seems like we agreed on a way =
forward.

My colleague created an errata, but as far as I know nothing has happened.

http://www.rfc-editor.org/errata_search.php?rfc=3D3262&eid=3D4288

I guess we should agree and close the errata?

Regards,

Christer




-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 11 February 2015 22:41
To: sipcore@ietf.org
Subject: Re: [sipcore] RSeq and forking

On 2/11/15 2:54 PM, Christer Holmberg wrote:
> Hi Roland,
>
> We could add a clarifying note.
>
> But, I don't think the note should talk about "use-cases". It should=20
> simply say that, if forking occurs, RSeq values are processed per=20
> early dialog, independently from the RSeq values on other early dialogs.

+1

Note that the same is true for CSeq. It would be a very stupid implementati=
on that handled the CSeq per-dialog but not the RSeq.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
> *Sent:* 11 February 2015 11:20
> *To:* Christer Holmberg; aallen@blackberry.com; brett@broadsoft.com;=20
> sipcore@ietf.org
> *Subject:* AW: [sipcore] RSeq and forking
>
> Hi Christer,
>
> The change itself is OK for me.
>
> Since I like to have more explicit description I would like to have=20
> more text (e.g. Note) pointing to the fact that other early dialogs=20
> depending on the number of responses made reliable have other RSeq values=
.
>
> Proposal :
>
>   "As a result, if the UAC receives another reliable provisional
>
>                  response to the same request ,<new>on a given=20
> dialog</new>and its RSeq value is not one higher
>
>                  than the value of the sequence number, that response=20
> MUST NOT be
>
>                  acknowledged with a PRACK, and MUST NOT be processed=20
> further by the
>
>                  UAC.  An implementation MAY discard the response, or=20
> MAY cache the
>
>                  response in the hopes of receiving the missing=20
> responses. <new>Note that for some use cases multiples early dialogs=20
> (e.g. forking) with different RSeq exist.</new>"
>
> Best Regards
>
> Roland
>
> *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von=20
> *Christer Holmberg
> *Gesendet:* Mittwoch, 11. Februar 2015 08:53
> *An:* Andrew Allen; Brett Tate; sipcore@ietf.org=20
> <mailto:sipcore@ietf.org>
> *Betreff:* Re: [sipcore] RSeq and forking
>
> Hi,
>
> So, are people ok with my suggested text?
>
> Regards,
>
> Christer
>
> *From:*Andrew Allen [mailto:aallen@blackberry.com]
> *Sent:* 11. helmikuuta 2015 9:44
> *To:* Brett Tate; Christer Holmberg; sipcore@ietf.org=20
> <mailto:sipcore@ietf.org>
> *Subject:* RE: [sipcore] RSeq and forking
>
> +1
>
> *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Brett=20
> Tate
> *Sent:* Tuesday, February 10, 2015 6:38 AM
> *To:* Christer Holmberg; sipcore@ietf.org <mailto:sipcore@ietf.org>
> *Subject:* Re: [sipcore] RSeq and forking
>
> Hi,
>
> I agree that some vendors have misinterpreted the sentence (and other=20
> aspects of the RFC such as if only 200 and 481 are valid responses to=20
> a PRACK).
>
> The errata would mainly just be useful to quickly end debate with=20
> those who think devices are somehow supposed to magically coordinate=20
> RSeq generation with other devices when forking has occurred.
>
> *From:*sipcore [mailto:sipcore-bounces@ietf.org=20
> <mailto:sipcore-bounces@ietf.org>] *On Behalf Of *Christer Holmberg
> *Sent:* Tuesday, February 10, 2015 5:33 AM
> *To:* sipcore@ietf.org <mailto:sipcore@ietf.org>
> *Subject:* [sipcore] RSeq and forking
>
> Hi,
>
> There has been some confusion regarding RFC 3262 and forking, and I'd=20
> like to ask whether people think an errata would be useful.
>
> The text in section 4 says:
>
> "As a result, if the UAC receives another reliable provisional
>
>                  response to the same request, and its RSeq value is=20
> not one higher
>
>                  than the value of the sequence number, that response=20
> MUST NOT be
>
>                  acknowledged with a PRACK, and MUST NOT be processed=20
> further by the
>
>                  UAC.  An implementation MAY discard the response, or=20
> MAY cache the
>
>                  response in the hopes of receiving the missing responses=
."
>
> Now, in case of forking, in my opinion the UAC may receive the same=20
> (or even lower) RSeq value on different early dialogs. But, there seem=20
> to be some confusion around it.
>
> So, I wonder whether an errata would be useful, modifying the text to=20
> something like:
>
> "As a result, if the UAC receives another reliable provisional
>
>                  response to the same request,<new>on a given=20
> dialog</new>,
>
> and its RSeq value is not one higher..."
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

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


From nobody Thu Jun 11 05:03:46 2015
Return-Path: <ibc@aliax.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC011ACDC7 for <sipcore@ietfa.amsl.com>; Thu, 11 Jun 2015 05:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.278
X-Spam-Level: 
X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKB3MYdS0Jn2 for <sipcore@ietfa.amsl.com>; Thu, 11 Jun 2015 05:03:38 -0700 (PDT)
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6B21A8AA4 for <sipcore@ietf.org>; Thu, 11 Jun 2015 05:03:38 -0700 (PDT)
Received: by yken206 with SMTP id n206so2052843yke.2 for <sipcore@ietf.org>; Thu, 11 Jun 2015 05:03:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=om5gzkaJYSKKu7Pb34de2rTKyuhvHkCOBupFXGbsFbU=; b=gb9r0IprDR8ip9akzCRgWGO9WHw9SK2IUZBqYCTxvL2ZWPJSL2+2z+dC0/42sUmBfl KT8gOwdhNaZjRZe6BPZe4yXhIAkkDOj2pp6RKCw+1nsI20Z44s+pjzPpuZel5MQkR9Kl 4JzLU849DEALY9xiykRNv8RvMS4uIB7ZsrH5l7iYsA4XjD6ZC1YSkQO+g0bMy4LzPP9z JOlhtIKxUoYJ2vXiyW1rKFj18ScGe8ZeWDhmK/vzK79uEbRGZ1vxYzE64DBJFdNfSATb 2FUIaTf6HUdB0Ite75VdUwTKvZS6gfZY+PW+59gYi+iM1hEp3c9r2YaEHe3eshDUtl3O Axuw==
X-Gm-Message-State: ALoCoQn5+BNrlRbwYGwzTwWM3NL50VXp8NE4Ssb8Y9WyTJAWj7evMV8oFJagtEQw2WT0Gf5k564d
X-Received: by 10.129.148.4 with SMTP id l4mr11023658ywg.142.1434024217577; Thu, 11 Jun 2015 05:03:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.76.5 with HTTP; Thu, 11 Jun 2015 05:03:17 -0700 (PDT)
In-Reply-To: <F3D57516-62C8-4A73-AA36-05483EB87A91@iii.ca>
References: <A8FB7EFC-7F19-48EE-A9E7-5040E2BB357F@edvina.net> <AC07A53D-3827-4951-95DF-C2ADCBF182DD@edvina.net> <D10F790A-03BD-484B-91AE-79E6DA36EC6F@iii.ca> <AC77F834-2F45-4E4B-BB3D-1D4536BB77FA@edvina.net> <F3D57516-62C8-4A73-AA36-05483EB87A91@iii.ca>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Thu, 11 Jun 2015 14:03:17 +0200
Message-ID: <CALiegfmhe7xc6jbBYWEfDuS7y7Dwz4yABPeqbt7ek0ZGWmwp7w@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/gV-YUr3tgJkPIz5YOQeOOyqUWkY>
Cc: SIPCORE <sipcore@ietf.org>, Olle E Johansson <oej@edvina.net>
Subject: Re: [sipcore] ;transport=tls
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 12:03:45 -0000

2015-03-03 18:27 GMT+01:00 Cullen Jennings <fluffy@iii.ca>:
> So is there a problem different from that which needs to be solve here ?

Yes. There is a problem as people does not know what exactly they must
do in order to properly use SIP over TLS (and hence over WSS). And the
solution is easy: just make ;transport=3Dtls and ;transport=3Dwss
standard. People are already using it.

Of course there are some bullets to solve:

- A client without a "proper" TLS certificate indicates ;transport=3Dtls
in his Contact. The proxy/server he is connecting to should not
attempt to validate the client certificate (or let that be local
policy), even less in Outbound scenarios.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>


From nobody Thu Jun 11 10:24:00 2015
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA36A1A87A7 for <sipcore@ietfa.amsl.com>; Thu, 11 Jun 2015 10:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URa6_zFLtI31 for <sipcore@ietfa.amsl.com>; Thu, 11 Jun 2015 10:23:58 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88FF1A877B for <sipcore@ietf.org>; Thu, 11 Jun 2015 10:23:54 -0700 (PDT)
X-AuditID: c1b4fb2d-f794d6d000004501-9a-5579c428a549
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.17.17665.824C9755; Thu, 11 Jun 2015 19:23:52 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Thu, 11 Jun 2015 19:23:52 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: Draft discontinuation: draft-holmberg-sipcore-rkeep
Thread-Index: AdCkazmalzW0K+xzTiKRjLFqaRFnLw==
Date: Thu, 11 Jun 2015 17:23:51 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8BE099@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8BE099ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3VlfjSGWoweu/FhbTz/xltJjfeZrd YsWGA6wWp16dZrb4+mMTmwOrx9/3H5g8vjx5yeSxZMlPJo9ZO5+weHy5/JktgDWKyyYlNSez LLVI3y6BK+PgxgaWgmb5ireXvBoYn0t1MXJySAiYSHS+WckEYYtJXLi3nq2LkYtDSOAoo8T1 5j5WCGcxo8S6hwvYuxg5ONgELCS6/2mDNIgIaEos/7aVHcRmFjjIKDF/VTSILSxgI/F20WwW iBpHid13p7ND2HoSfaf+MoKMYRFQldi90R0kzCvgK3Ht3xKwckagG76fWsMEMVJc4taT+VC3 CUgs2XOeGcIWlXj5+B8rhK0ksej2Z6j6fIm9x34yQswUlDg58wnLBEbhWUhGzUJSNgtJGURc R2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERh3 B7f81t3BuPq14yFGAQ5GJR7eBa8rQoVYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgXHlNpeHS6/F/1b/dmil4qvkyfMeOJ50nWh3IOpkvZDT6XiJa7zLhZ41 r9k2kSvwYb7S4YsS608Grf60+VSkq+sRi4ADxmxJfrL32J8H1T60XBZrnjLPeuazsgahKUzy 71ftnXt3k0bNNY0zWh9jjq/lETsQde5R7AeHVDs+4bijGs+U4lnkD0kqsRRnJBpqMRcVJwIA fqOLDZwCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/YXTBKuRx7XjLj7PD3fPuvXtLWCw>
Cc: Ben Campbell <ben@nostrum.com>, "sipcore-chairs@tools.ietf.org" <sipcore-chairs@tools.ietf.org>, "alissa@cooperw.in" <alissa@cooperw.in>
Subject: [sipcore] Draft discontinuation: draft-holmberg-sipcore-rkeep
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 17:24:00 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D8BE099ESESSMB209erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have been working on a draft, draft-holmberg-sipcore-rkeep. The latest ve=
rsions have only been updates due to expiration of the previous version. Th=
e idea was that I would put more effort into it once BUNDLE etc is finalize=
d.

Anyway, as the problem that the draft addresses does not exist anymore (at =
least not as far as I know, and nobody has told me otherwise), I do NOT int=
end to continue working on the draft, and I will NOT submit a new version o=
f the draft once the current expires.

If someone else wishes to continue moving the draft forward, please let me =
know and I'm happy to provide the XML file etc.

Regards,

Christer


--_000_7594FB04B1934943A5C02806D1A2204B1D8BE099ESESSMB209erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have been working on a draft, draft-holmberg-sipco=
re-rkeep. The latest versions have only been updates due to expiration of t=
he previous version. The idea was that I would put more effort into it once=
 BUNDLE etc is finalized.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Anyway, as the problem that the draft addresses does=
 not exist anymore (at least not as far as I know, and nobody has told me o=
therwise), I do NOT intend to continue working on the draft, and I will NOT=
 submit a new version of the draft
 once the current expires. <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">If someone else wishes to continue moving the draft =
forward, please let me know and I&#8217;m happy to provide the XML file etc=
.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Christer<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_7594FB04B1934943A5C02806D1A2204B1D8BE099ESESSMB209erics_--


From nobody Wed Jun 17 13:35:03 2015
Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4138A1A0171; Wed, 17 Jun 2015 13:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f21JhIC8Ut6h; Wed, 17 Jun 2015 13:34:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D496E1A014C; Wed, 17 Jun 2015 13:34:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150617203456.26622.98828.idtracker@ietfa.amsl.com>
Date: Wed, 17 Jun 2015 13:34:56 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/2gL6bLz2k-G_kivZkvvyBh5bVQE>
Cc: draft-ietf-sipcore-refer-clarifications.ad@ietf.org, sipcore-chairs@ietf.org, draft-ietf-sipcore-refer-clarifications.shepherd@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-refer-clarifications@ietf.org
Subject: [sipcore] Ben Campbell's Yes on draft-ietf-sipcore-refer-clarifications-04
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2015 20:35:00 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-sipcore-refer-clarifications-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/


There are no remarks associated with this position.





From nobody Fri Jun 19 06:32:34 2015
Return-Path: <brett@broadsoft.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989A21A904A for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 06:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.279
X-Spam-Level: 
X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_g_t9jXYtWn for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 06:32:30 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B031A9043 for <sipcore@ietf.org>; Fri, 19 Jun 2015 06:32:30 -0700 (PDT)
Received: by wibdq8 with SMTP id dq8so18813419wib.1 for <sipcore@ietf.org>; Fri, 19 Jun 2015 06:32:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=3cZSqs5sGyr40RNFnu4216yW4tYfuQ3UGQsac+8nKE8=; b=VOVY73mHS53JRkAL8ebI7uVfOCRJgmWfN+5JyoCTjG66HfGmhK95dTVGAyJpgvnFv+ 1x/dPkDwe4u2gSIjT2qHQXaj1A/gH86RdABI9KvbbPgBDhxU4Bk3VHb/+GIAWR4qcfi3 6MbUhmRTHKEFkXkcCZ+NqOX/tGznYi1zWyXRlhRedl3tkKWlIgiRPJ3loTWpXzAd1sVg oFr3uUUg707ncswByxgu2tTrf10WWLU9z8JYnRo2+8+ke/EIirL0EBL0ptJNX0IzDyUA 90bIi+KWunyBH/PhO9czglVR5XqSjPu4yr9578q1skYOqNXNO91tjSasTctRrPkSmfAW 0mRw==
X-Gm-Message-State: ALoCoQkIPOb8ur5uYQn8qlmV6LF+nqPfJMCqEOyrM6mCM6lVG2pNOa+85/Dv2hURdljg136rTt0Q
X-Received: by 10.180.24.165 with SMTP id v5mr6680791wif.63.1434720749184; Fri, 19 Jun 2015 06:32:29 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
References: <E56B3AF7-6874-4A66-8426-78A98DA435B4@cisco.com>
In-Reply-To: <E56B3AF7-6874-4A66-8426-78A98DA435B4@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIXj57ODAPoXUKD6yohUcxuzSKVsZ0l+PTw
Date: Fri, 19 Jun 2015 09:32:27 -0400
Message-ID: <ecaa9285c817548b0f18c0a1e7725dd5@mail.gmail.com>
To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= <dwing@cisco.com>, sipcore@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/AgN1Os5ktSrCNLoymu2HzxDQrmo>
Subject: Re: [sipcore] comments on draft-ietf-sipcore-dns-dual-stack-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 13:32:32 -0000

> The actual recommendation at end of section 4.1 only says:
>
>   The dual-stack client SHOULD perform an A and AAAA record lookup
>   of the domain name and add the respective IPv4/IPv6 addresses to
>   the list of IP addresses to be contacted.
>
> but it doesn't say if A or AAAA should be placed at the beginning
> of the list, end of the list, or scattered randomly.  It probably
> matters, especially if we envision a long list of AAAA and long
> list of A records, and we also envision an outage of one address
> family.

It may or may not matter (although I agree that the draft should provide a
recommendation).  Similarly, this draft may improve or worsen call setup
delays.

The sender doesn't know if the A/AAAA records reflect the same device or
different devices.  If the records reflect the same device and the device is
down, the draft slows down the advancing to the next SRV record.

If a network administrator had been relying upon the "A or AAAA" behavior of
RFC 3263, they might desire DNS changes based upon the draft's change to "A
and AAAA".  If they do not know if the relevant devices behave per the draft
or RFC 3263, they'd likely want to configure things to work adequately for
both behaviors.


From nobody Fri Jun 19 07:57:30 2015
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2431A894C for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 07:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLxZRm2SQ-NY for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 07:57:20 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CE31A8908 for <sipcore@ietf.org>; Fri, 19 Jun 2015 07:57:19 -0700 (PDT)
X-AuditID: c1b4fb2d-f794d6d000004501-f9-55842dcd4f10
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 77.C5.17665.DCD24855; Fri, 19 Jun 2015 16:57:18 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 16:57:17 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] RSeq and forking - Errata
Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g
Date: Fri, 19 Jun 2015 14:57:17 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre453ZZQg7c7uSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj74YdbAWndSrmff7D3sD4QamLkZNDQsBE 4uPDpWwQtpjEhXvrgWwuDiGBo4wSb75MZodwFjNKXFuwkLGLkYODTcBCovufNkiDiECgxNUl E5hBbGEBA4kfX16wQMQNJU6eaIeyjSRurlrBBtLKIqAqcfS9PEiYV8BXomv2G7C9QkD2jceT wco5Bfwkfn/fBDaSEeie76fWMIHYzALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsJYnGJU9Y Iep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfd yFgvtSgzubg4P08vL7VkEyMwSg5u+a27g3H1a8dDjAIcjEo8vAkKLaFCrIllxZW5hxilOViU xHlnbM4LFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4ufPIpaVib259FEg9uW6p9Wnv+4tk fl340yMQt0jfI+ro7D+Bbd77c6femCr+5Vacd/HaTypKnbMljx+Onmh5YIWnwM6rZW8eLVbK crOeNVPj1BbnUuFUy5O7Nsu59jCwrarfdVCtWfCQZGmd4uaU42mqc02/68zhSF2zvH0xa1aE 4V0VriceSizFGYmGWsxFxYkAIBdMEXMCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/MvdpmRFCM7HoPj5-WllxRLBo2RU>
Subject: Re: [sipcore] RSeq and forking - Errata
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 14:57:25 -0000

PING.

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb=
erg
Sent: 11 June 2015 00:16
To: Paul Kyzivat; sipcore@ietf.org
Subject: Re: [sipcore] RSeq and forking - Errata


Hi,

Some time ago, this issue was raised, and it seems like we agreed on a way =
forward.

My colleague created an errata, but as far as I know nothing has happened.

http://www.rfc-editor.org/errata_search.php?rfc=3D3262&eid=3D4288

I guess we should agree and close the errata?

Regards,

Christer




-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 11 February 2015 22:41
To: sipcore@ietf.org
Subject: Re: [sipcore] RSeq and forking

On 2/11/15 2:54 PM, Christer Holmberg wrote:
> Hi Roland,
>
> We could add a clarifying note.
>
> But, I don't think the note should talk about "use-cases". It should=20
> simply say that, if forking occurs, RSeq values are processed per=20
> early dialog, independently from the RSeq values on other early dialogs.

+1

Note that the same is true for CSeq. It would be a very stupid implementati=
on that handled the CSeq per-dialog but not the RSeq.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
> *Sent:* 11 February 2015 11:20
> *To:* Christer Holmberg; aallen@blackberry.com; brett@broadsoft.com;=20
> sipcore@ietf.org
> *Subject:* AW: [sipcore] RSeq and forking
>
> Hi Christer,
>
> The change itself is OK for me.
>
> Since I like to have more explicit description I would like to have=20
> more text (e.g. Note) pointing to the fact that other early dialogs=20
> depending on the number of responses made reliable have other RSeq values=
.
>
> Proposal :
>
>   "As a result, if the UAC receives another reliable provisional
>
>                  response to the same request ,<new>on a given=20
> dialog</new>and its RSeq value is not one higher
>
>                  than the value of the sequence number, that response=20
> MUST NOT be
>
>                  acknowledged with a PRACK, and MUST NOT be processed=20
> further by the
>
>                  UAC.  An implementation MAY discard the response, or=20
> MAY cache the
>
>                  response in the hopes of receiving the missing=20
> responses. <new>Note that for some use cases multiples early dialogs=20
> (e.g. forking) with different RSeq exist.</new>"
>
> Best Regards
>
> Roland
>
> *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von=20
> *Christer Holmberg
> *Gesendet:* Mittwoch, 11. Februar 2015 08:53
> *An:* Andrew Allen; Brett Tate; sipcore@ietf.org=20
> <mailto:sipcore@ietf.org>
> *Betreff:* Re: [sipcore] RSeq and forking
>
> Hi,
>
> So, are people ok with my suggested text?
>
> Regards,
>
> Christer
>
> *From:*Andrew Allen [mailto:aallen@blackberry.com]
> *Sent:* 11. helmikuuta 2015 9:44
> *To:* Brett Tate; Christer Holmberg; sipcore@ietf.org=20
> <mailto:sipcore@ietf.org>
> *Subject:* RE: [sipcore] RSeq and forking
>
> +1
>
> *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Brett=20
> Tate
> *Sent:* Tuesday, February 10, 2015 6:38 AM
> *To:* Christer Holmberg; sipcore@ietf.org <mailto:sipcore@ietf.org>
> *Subject:* Re: [sipcore] RSeq and forking
>
> Hi,
>
> I agree that some vendors have misinterpreted the sentence (and other=20
> aspects of the RFC such as if only 200 and 481 are valid responses to=20
> a PRACK).
>
> The errata would mainly just be useful to quickly end debate with=20
> those who think devices are somehow supposed to magically coordinate=20
> RSeq generation with other devices when forking has occurred.
>
> *From:*sipcore [mailto:sipcore-bounces@ietf.org=20
> <mailto:sipcore-bounces@ietf.org>] *On Behalf Of *Christer Holmberg
> *Sent:* Tuesday, February 10, 2015 5:33 AM
> *To:* sipcore@ietf.org <mailto:sipcore@ietf.org>
> *Subject:* [sipcore] RSeq and forking
>
> Hi,
>
> There has been some confusion regarding RFC 3262 and forking, and I'd=20
> like to ask whether people think an errata would be useful.
>
> The text in section 4 says:
>
> "As a result, if the UAC receives another reliable provisional
>
>                  response to the same request, and its RSeq value is=20
> not one higher
>
>                  than the value of the sequence number, that response=20
> MUST NOT be
>
>                  acknowledged with a PRACK, and MUST NOT be processed=20
> further by the
>
>                  UAC.  An implementation MAY discard the response, or=20
> MAY cache the
>
>                  response in the hopes of receiving the missing responses=
."
>
> Now, in case of forking, in my opinion the UAC may receive the same=20
> (or even lower) RSeq value on different early dialogs. But, there seem=20
> to be some confusion around it.
>
> So, I wonder whether an errata would be useful, modifying the text to=20
> something like:
>
> "As a result, if the UAC receives another reliable provisional
>
>                  response to the same request,<new>on a given=20
> dialog</new>,
>
> and its RSeq value is not one higher..."
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

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

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


From nobody Fri Jun 19 08:37:48 2015
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7071A9067 for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 08:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmpfG1-IZv21 for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 08:37:44 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D411A9005 for <sipcore@ietf.org>; Fri, 19 Jun 2015 08:37:44 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with comcast id iFcx1q0052S2Q5R01FdkW3; Fri, 19 Jun 2015 15:37:44 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-16v.sys.comcast.net with comcast id iFdj1q00E3Ge9ey01Fdjn1; Fri, 19 Jun 2015 15:37:43 +0000
Message-ID: <55843746.1070907@alum.mit.edu>
Date: Fri, 19 Jun 2015 11:37:42 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>,  "sipcore@ietf.org" <sipcore@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1434728264; bh=Tbr6iNoahKbwvaKqOmAwkKbAQgi8byMG/jNrSa31LvQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iC8EwDPbPAuMpofvtOB1FHUVrZn3bx28/rkFy7qOSZ0beFiEmcK+IxPbmPBj55i0R mIK0GzplZNg4Ys3PKqyZXZHklTNAUMIPP6jdRqurlMH3eiDQu2jkrLnJxMQS9llF3L WL0mtMQzpIsTmzlnVFQp4rSue59fv+FV/vSP8UuBSS8oCuq8+tBKemWCpfBBn4KoOC Qfrwe0wjm+ZFpasIgYUv8mNj78EMkO4CrPH7gc+4QSDpoFE1jxrqpZ96utwbdXqJjf z+zhrioGS9S7VBHSa8Y+9B9agOrxeyWkuCnerG0jKK0qch1ee5FS80MXTaAfoYagMO eqXtgXwpsylYg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/LRPrINt9QTYdaJWZW9qpusJrLG8>
Subject: Re: [sipcore] RSeq and forking - Errata
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 15:37:46 -0000

On 6/19/15 10:57 AM, Christer Holmberg wrote:
> PING.

I'm no longer a chair, so I don't have a say here.
Adam is away until (I think) Tuesday.

One more comment below on the earlier discussion.

...

> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 11 February 2015 22:41
> To: sipcore@ietf.org
> Subject: Re: [sipcore] RSeq and forking
>
> On 2/11/15 2:54 PM, Christer Holmberg wrote:
>> Hi Roland,
>>
>> We could add a clarifying note.
>>
>> But, I don't think the note should talk about "use-cases". It should
>> simply say that, if forking occurs, RSeq values are processed per
>> early dialog, independently from the RSeq values on other early dialogs.
>
> +1
>
> Note that the same is true for CSeq. It would be a very stupid implementation that handled the CSeq per-dialog but not the RSeq.

Note that the scope of RSeq values is a single INVITE transaction, not a 
dialog. (So, for a re-INVITE in the same dialog the RSeq value might 
turn out to be lower than that for the INVITE that established the dialog.)

But that value space is owned by the UAS for the INVITE. So, from the 
perspective of the sender of the INVITE (receiver of provisional 
responses), the value space must be managed independently for the 
combination of INVITE transaction AND dialog id. So the required logic 
is somewhat different than what is required for CSeq.

	Thanks,
	Paul


From nobody Fri Jun 19 09:01:58 2015
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0B1A914D for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 09:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRoBtxfws6Yw for <sipcore@ietfa.amsl.com>; Fri, 19 Jun 2015 09:01:46 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D56D1A913F for <sipcore@ietf.org>; Fri, 19 Jun 2015 09:01:46 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-21-55843ce8c070
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.29.04401.8EC34855; Fri, 19 Jun 2015 18:01:44 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 18:01:43 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] RSeq and forking - Errata
Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUA==
Date: Fri, 19 Jun 2015 16:01:43 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu>
In-Reply-To: <55843746.1070907@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre4Lm5ZQgwNH1SxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj8bcO5oIVnBXbb91lamBcxd7FyMkhIWAi sf/9AmYIW0ziwr31bF2MXBxCAkcZJR7t7WSEcBYzSkw738zUxcjBwSZgIdH9TxukQUQgUOLq kglgzcICBhI/vrxggYgbSpw80Q5lO0m82XAUbBmLgKrE9NM32EBsXgFfiZctC1kg5m9mlPhz dQ5YglNAR+Ldhw9gNiPQRd9PrWECsZkFxCVuPZnPBHGpgMSSPeehrhaVePn4HyuErSTRuOQJ K0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+Wm GxnrpRZlJhcX5+fp5aWWbGIERsrBLb9VdzBefuN4iFGAg1GJhzdBoSVUiDWxrLgy9xCjNAeL kjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYC5rtXnF3l1+ufK7yecV1HWWdbq7J 7bZzzy9qD6r/+HYG/2rf/Kw5BqyZhd/KMiytsuyOVb2VjmS3Oqg+SbzWxPyixOep3gFLP+1T XvlEmslxvTm/m79mTtCO0KWPDQt9XToWnYlY2Jxw76CNw4FnB7zrKttLr2oflLLuuBbCzXqF i6OY+5ISS3FGoqEWc1FxIgALp2GfdQIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/SeA7AIBRHcP0p-Zuxz1kKx-h9SI>
Subject: Re: [sipcore] RSeq and forking - Errata
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 16:01:52 -0000

Hi,

>>> Hi Roland,
>>>
>>> We could add a clarifying note.
>>>
>>> But, I don't think the note should talk about "use-cases". It should=20
>>> simply say that, if forking occurs, RSeq values are processed per=20
>>> early dialog, independently from the RSeq values on other early dialogs=
.
>>
>> +1
>>
>> Note that the same is true for CSeq. It would be a very stupid implement=
ation that handled the CSeq per-dialog but not the RSeq.
>
> Note that the scope of RSeq values is a single INVITE transaction, not a =
dialog. (So, for a re-INVITE in the same dialog the RSeq value might turn o=
ut > to be lower than that for the INVITE that established the dialog.)

Correct, that needs to be clear.

>But that value space is owned by the UAS for the INVITE. So, from the pers=
pective of the sender of the INVITE (receiver of provisional responses), >t=
he value space must be managed independently for the combination of INVITE =
transaction AND dialog id. So the required logic is somewhat >different tha=
n what is required for CSeq.

*Nodding like when I am not really sure I understood what you said, but it =
did sound correct* :)

Regards,

Christer


From nobody Mon Jun 22 02:47:42 2015
Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F721B2ED6; Mon, 22 Jun 2015 02:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.802
X-Spam-Level: 
X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B4s_kGSNlNZ; Mon, 22 Jun 2015 02:47:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6691F1B2ED3; Mon, 22 Jun 2015 02:47:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150622094739.29512.78952.idtracker@ietfa.amsl.com>
Date: Mon, 22 Jun 2015 02:47:39 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/vyPHr472NjyBwWSHtRIZofKUSzE>
Cc: sipcore-chairs@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-6665-clarification@ietf.org, draft-ietf-sipcore-6665-clarification.shepherd@ietf.org, draft-ietf-sipcore-6665-clarification.ad@ietf.org
Subject: [sipcore] Kathleen Moriarty's No Objection on draft-ietf-sipcore-6665-clarification-00: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 09:47:41 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sipcore-6665-clarification-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This was probably caught by now, but the introduction says this update
exists because of lack of clarity in RFC2119, when it was meant to say in
RFC6665.

The SecDir reviewer asked a few clarifying questions that would be good
to see answered:
https://www.ietf.org/mail-archive/web/secdir/current/msg05789.html



From nobody Mon Jun 22 06:59:52 2015
Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4509F1A912A for <sipcore@ietfa.amsl.com>; Mon, 22 Jun 2015 06:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-oVTbRw4HYv for <sipcore@ietfa.amsl.com>; Mon, 22 Jun 2015 06:59:49 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029691A9111 for <sipcore@ietf.org>; Mon, 22 Jun 2015 06:59:48 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5MDxbr4025073 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 22 Jun 2015 08:59:47 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com>
Date: Mon, 22 Jun 2015 08:59:37 -0500
Message-ID: <BE02DE62-34D3-467E-A31D-665AC5393313@nostrum.com>
In-Reply-To: <20150622094739.29512.78952.idtracker@ietfa.amsl.com>
References: <20150622094739.29512.78952.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/q_y5-30BkHDds0H0DGEB6Qqiwjk>
Cc: sipcore-chairs@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-6665-clarification@ietf.org, draft-ietf-sipcore-6665-clarification.shepherd@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-sipcore-6665-clarification.ad@ietf.org
Subject: Re: [sipcore] Kathleen Moriarty's No Objection on draft-ietf-sipcore-6665-clarification-00: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 13:59:51 -0000

Thanks for your review!

I have already put in an RFC Editor note about the incorrect reference. =


(I will leave it to Adam to address the secdir questions.)

Thanks!

Ben.

On 22 Jun 2015, at 4:47, Kathleen Moriarty wrote:

> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-sipcore-6665-clarification-00: No Objection

[..]

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This was probably caught by now, but the introduction says this update
> exists because of lack of clarity in RFC2119, when it was meant to say =
in
> RFC6665.
>
> The SecDir reviewer asked a few clarifying questions that would be good=

> to see answered:
> https://www.ietf.org/mail-archive/web/secdir/current/msg05789.html


From nobody Mon Jun 22 19:10:11 2015
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516051B31D1; Mon, 22 Jun 2015 19:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQg8uwodDtbc; Mon, 22 Jun 2015 19:10:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA901B31CD; Mon, 22 Jun 2015 19:10:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150623021007.27502.34986.idtracker@ietfa.amsl.com>
Date: Mon, 22 Jun 2015 19:10:07 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/mAAPKVh3onBWxr69JHp-yF2-HLE>
Cc: draft-ietf-sipcore-refer-clarifications.ad@ietf.org, sipcore-chairs@ietf.org, draft-ietf-sipcore-refer-clarifications.shepherd@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-refer-clarifications@ietf.org
Subject: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-refer-clarifications-04: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 02:10:10 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-sipcore-refer-clarifications-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A couple of nits, but I'm a Yes.

3GPP capitalizes "3GPP", don't they? It would be nice to match their
usage. 

It might be nice to provide a pointer of some sort, so that people who
work on the periphery of 3GPP can figure out if they are involved enough
to care about "the 3GPP environment".

In this text:

4.  Dialog reuse is prohibited

   If a peer in an existing dialog has provided a GRUU as its Contact,
   sending a REFER that might result in an additional dialog usage
   within that dialog is prohibited.  This is a direct consequence of
   [RFC6665] requiring the use of GRUU, and the requirements in section
   4.5.2 of that document.
   
I found the use of "is prohibited" somewhat strange, because this section
contains plenty of RFC 2119 language in close proximity. Am I reading
this as saying "the 2119 language is over there"? 

If so, section 4.5.2 is nearly two pages long. Is this text just pointing
to 

   Subscribers MUST NOT attempt to reuse dialogs whose remote target is
   a GRUU.
   
or to something else?



From nobody Mon Jun 22 20:24:13 2015
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146131B3291; Mon, 22 Jun 2015 20:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1nLKyBXLxFa; Mon, 22 Jun 2015 20:24:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D51B328D; Mon, 22 Jun 2015 20:24:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150623032408.4022.89969.idtracker@ietfa.amsl.com>
Date: Mon, 22 Jun 2015 20:24:08 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/-pZBQ5ne9JocRrufnxlOCoaqkb0>
Cc: sipcore@ietf.org, draft-ietf-sipcore-refer-explicit-subscription.shepherd@ietf.org, sipcore-chairs@ietf.org, draft-ietf-sipcore-refer-explicit-subscription.ad@ietf.org, draft-ietf-sipcore-refer-explicit-subscription@ietf.org
Subject: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-refer-explicit-subscription-02: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 03:24:10 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-sipcore-refer-explicit-subscription-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes, and this specification was mostly clear, but one sentence in
the text was hard for me to parse:

   If it is important that the UA
   be able to subscribe to any refer state generated by accepting this
   request, the request needs to be formed to limit the number of places
   that it will be accepted to one.
   
Is there a phrasing that's not passive English, says directly who is
responsible for doing this, and uses "one" as an adjective?

For example, would be be correct to say:

   If it is important that the UA
   be able to subscribe to any refer state generated by accepting this
   request, the UA needs to form the request so that it will obly be 
   accepted in one place.
   
?



From nobody Thu Jun 25 13:23:49 2015
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B4B1AD061; Thu, 25 Jun 2015 13:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wLUXtAjqBGa; Thu, 25 Jun 2015 13:23:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C54CE1ACF5B; Thu, 25 Jun 2015 13:23:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150625202331.23286.79025.idtracker@ietfa.amsl.com>
Date: Thu, 25 Jun 2015 13:23:31 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/xkiWYIHfEm4ilAb6lPHUZfZFWmg>
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-explicit-subscription-03.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 20:23:42 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

        Title           : Explicit Subscriptions for the REFER Method
        Author          : Robert Sparks
	Filename        : draft-ietf-sipcore-refer-explicit-subscription-03.txt
	Pages           : 14
	Date            : 2015-06-25

Abstract:
   The Session Initiation Protocol (SIP) REFER request, as defined by
   RFC3515, triggers an implicit SIP-Specific Event Notification
   framework subscription.  Conflating the start of the subscription
   with handling the REFER request makes negotiating SUBSCRIBE
   extensions impossible, and complicates avoiding SIP dialog sharing.
   This document defines extensions to REFER to remove the implicit
   subscription and, if desired, replace it with an explicit one.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sipcore-refer-explicit-subscription-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-explicit-subscription-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jun 29 13:59:44 2015
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB581B3437; Mon, 29 Jun 2015 13:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC3jPoT_Kz96; Mon, 29 Jun 2015 13:59:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3434A1B3439; Mon, 29 Jun 2015 13:59:38 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150629205938.31856.52407.idtracker@ietfa.amsl.com>
Date: Mon, 29 Jun 2015 13:59:38 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/kvdoI9JEulEMlpBWy_Vfhl5vw9c>
Cc: sipcore mailing list <sipcore@ietf.org>, sipcore chair <sipcore-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [sipcore] Protocol Action: 'Clarifications for the use of REFER with RFC6665' to Proposed Standard (draft-ietf-sipcore-refer-clarifications-04.txt)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2015 20:59:41 -0000

The IESG has approved the following document:
- 'Clarifications for the use of REFER with RFC6665'
  (draft-ietf-sipcore-refer-clarifications-04.txt) as Proposed Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/





Technical Summary

  The SIP REFER method relies on the SIP-Specific Event Notification
  Framework.  That framework was revised by RFC6665.  This document
  highlights the implications of the requirement changes in RFC6665,
  and updates the definition of the REFER method, RFC3515, to clarify
  and disambiguate the impact of those changes.

Working Group Summary

  There was some controversy and difficulty in reaching agreement on this draft.
  Before work on this draft and the companion draft (draft-ietf-sipcore-refer-
  explicit-subscription) commenced, some (notably 3GPP) made attempts to use
  existing mechanisms (RFC4488) to avoid the need for GRUUs. That mechanism as
  insufficient on its own, and so was enhanced with particular conventions.
  There was a desire to maintain compatibility with that work. This led to
  careful word smithing. That has been discussed at length within the WG.
  The results are now acceptable to all parties.

Document Quality

  The shepherd is not aware of any implementations yet. 
  It is his understanding that 3GPP release 12 has a reference,
  indicating that implementations can be expected. 

  This document has been thoroughly reviewed and discussed. Everyone
  that had something to say has aired it. 

Personnel

The shepherd is Paul Kizivat. The responsible AD is Ben Campbell.


From nobody Mon Jun 29 15:06:57 2015
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368F11B35A4; Mon, 29 Jun 2015 15:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQupujnPNlPi; Mon, 29 Jun 2015 15:06:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E18411B35AD; Mon, 29 Jun 2015 15:06:52 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150629220652.31144.7364.idtracker@ietfa.amsl.com>
Date: Mon, 29 Jun 2015 15:06:52 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/PNPKSj1uZe1LAOuBQC749hf1E28>
Cc: sipcore mailing list <sipcore@ietf.org>, sipcore chair <sipcore-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [sipcore] Protocol Action: 'Explicit Subscriptions for the REFER Method' to Proposed Standard (draft-ietf-sipcore-refer-explicit-subscription-03.txt)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2015 22:06:56 -0000

The IESG has approved the following document:
- 'Explicit Subscriptions for the REFER Method'
  (draft-ietf-sipcore-refer-explicit-subscription-03.txt) as Proposed
Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/





Technical Summary

  The Session Initiation Protocol (SIP) REFER request, as defined by
  RFC3515, triggers an implicit SIP-Specific Event Notification
  framework subscription.  Conflating the start of the subscription
  with handling the REFER request makes negotiating SUBSCRIBE
  extensions impossible, and complicates avoiding SIP dialog sharing.
  This document defines extensions to REFER to prevent the implicit
  subscription and, if desired, replace it with an explicit one.

Working Group Summary

  There was some controversy and difficulty in reaching agreement on this draft.
  Before work on this draft and the companion draft (draft-ietf-sipcore-refer-
  clarifications) commenced, some (notably 3GPP) made attempts to use existing
  mechanisms (RFC4488) to avoid the need for GRUUs. That mechanism as insufficient
  on its own, and so was enhanced with particular conventions. There was a desire
  to maintain compatibility with that work. This led to careful word smithing.
  That has been discussed at length within the WG. The results are now acceptable
  to all parties.

Document Quality

  The shepherd is not aware of any implementations yet. 
  It is the shepherd's understanding that 3GPP release 12 has a reference,
  indicating that implementations can be expected. 

  This document has been thoroughly reviewed and discussed. Everyone
  that had something to say has aired it. 

Personnel

  The document shepherd is Paul Kyzivat.
  The area director is Ben Campbell.




From nobody Tue Jun 30 06:40:37 2015
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426391AD2AF; Tue, 30 Jun 2015 06:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiibZGcTcy1u; Tue, 30 Jun 2015 06:40:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12821AD36F; Tue, 30 Jun 2015 06:40:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150630134029.24843.77428.idtracker@ietfa.amsl.com>
Date: Tue, 30 Jun 2015 06:40:29 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/qjFRK1f_LgmYVrc4LorpgZAJDAQ>
Cc: sipcore mailing list <sipcore@ietf.org>, sipcore chair <sipcore-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [sipcore] Protocol Action: 'A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework' to Proposed Standard (draft-ietf-sipcore-6665-clarification-00.txt)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
List-Id: SIP Core Working Group  <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 13:40:34 -0000

The IESG has approved the following document:
- 'A clarification on the use of Globally Routable User Agent URIs
   (GRUUs) in the Session Initiation Protocol (SIP) Event Notification
   Framework'
  (draft-ietf-sipcore-6665-clarification-00.txt) as Proposed Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-6665-clarification/





Technical Summary

  Experience since the publication of the most recent SIP Events
  framework (RFC6665) has shown that there is room for interpretation
  around the use of Globally Routable User Agent URIs in that 
  specification.  This document clarifies the intended behavior.

Working Group Summary

Context: The base SIP specification (RFC3261) introduced (implicitly) the notion of dialog reuse - multiple "usages" of a dialog. For instance, an INVITE usage combined with an event subscription, or multiple event subscriptions. The SIP REFER mechanism (RFC3515) provides a widely used mechanism that creates *implicit* SUBSCRIBE/NOTIFY dialog usages. When used within an INVITE dialog (as it typically is) it causes dialog reuse.

Unfortunately the dialog reuse concept was "half baked", and issues arose around it as it was implemented. This was discussed by RFC5057, recommending that such multiple usages be avoided. RFC5627 added the GRUU mechanism to SIP, providing a way to avoid many instances of dialog sharing. But GRUUs have been controversial - they are complex and far from universally implemented/deployed. A draft (draft-kaplan-dispatch-gruu-problematic-00) raised specific issues with deployment of GRUUs, but that draft expired without having reached consensus. It suggested that GRUUs not be used, and that other mechanisms be used to get around the need for them. But there has been no further work proposed on this since 2011.

The elephant in the room is that there are many deployments that still don't provide GRUUs, and don't intend to do so. Some continue to seek ways that they can be compliant with RFC6665 and yet still avoid implementing GRUU, by arranging their feature implementations to carefully avoid any usage that would require them to do so. 

Nevertheless, all these issues have been aired in the WG, and there is consensus to advance this draft and the companion drafts.

Document Quality

 The shepherd is not aware of any implementations yet. 
  It is my understanding that 3GPP release 12 has a reference,
  indicating that implementations can be expected. 

  This document has been thoroughly reviewed and discussed. Everyone
  that had something to say has aired it. 

Personnel

  The document shepherd is Paul Kyzivat.
  The area director is Ben Campbell.

RFC Editor Note

Please fix incorrect reference in section 1:

OLD:
   This document is intended to clarify a point of implementor confusion
   arising from lack of clarity in [RFC2119].

NEW:
   This document is intended to clarify a point of implementor confusion
   arising from lack of clarity in [RFC6665].