From nobody Fri Apr 1 22:57:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72A012D164; Fri, 1 Apr 2016 22:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 ut3hI3LDT_-o; Fri, 1 Apr 2016 22:57:15 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2567312D14C; Fri, 1 Apr 2016 22:57:15 -0700 (PDT) Received: from [192.168.0.37] (unknown [181.229.90.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8548C509B6; Sat, 2 Apr 2016 01:57:11 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <13628.1459398537@turing-police.cc.vt.edu> Date: Sat, 2 Apr 2016 02:57:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> <13628.1459398537@turing-police.cc.vt.edu> To: Valdis.Kletnieks@vt.edu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: John C Klensin , dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 05:57:17 -0000 Hello... > On Mar 31, 2016, at 1:28 AM, Valdis.Kletnieks@vt.edu wrote: >=20 > On Tue, 29 Mar 2016 15:38:59 -0400, John C Klensin said: >=20 >> Actually five families if you want to do a comprehensive job: >>=20 >> - 5321, possibly with nods to its predecessors >> - 5322 which, as you point out, is not the same as 5321 >> (and most, if not all, of the differences are >> intentional) >> - the EAI family >> - the base DNS spec family, as updated >=20 > And the corner cases when they don't agree. Consider > user@yoyo_dyne.com - how long did *that* wart get debated? :) >=20 > Those of us who were around for RFC1341 can look at the following, > and weep, and ponder what failure modes the authors of this would have > managed if they had *both* an ABNF and a regexp provided to work from, > *even if they were semantically the same*... >=20 > % egrep 'X-Mail|alt' bad.mailfile > X-Mailer: IBM Notes Release 9.0.1FP2 SHF37 August 25, 2014 > Content-Type: multipart/alternative; boundary=3D"=3D_alternative = 002EDD9148257F79_=3D" > --=3D_alternative 002EDD9148257F79_=3D > --=3D_alternative 002EDD9148257F79_=3D > --=3D_alternative 002EDD9148257F79_=3D-- > --=3D_alternative > % >=20 > (Hint: You'll probably need a fixed-space font and a lot of pondering = - the > above cost me close to 10 days of aggravation trying to figure out why = one > vendor's support emails were consistently getting eaten by my procmail > filters, before I finally spotted it=E2=80=A6) Are you referring to the fact that the boundary has two spaces between = =E2=80=9C_alternative" and =E2=80=9C002E...=E2=80=9D? Easy enough to spot. Not sure how that is germane to the topic at hand. = I have not proposed writing standardized regular expressions for = boundary parts; it is not clear why such a thing would be generally = useful. >=20 > This is why we can't have nice things.... >=20 > Oh, and those who want to tempt the Lovecraftian regexp elder gods = should > ponder the following: >=20 > http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html >=20 > (If that doesn't make Sean reconsider, *nothing* will... :) Does not make me reconsider at all. Half the work is done, just copy-and-paste! A =E2=80=9Cdeliverable=E2=80=9D e-mail address is one that is = deliverable with the modern SMTP infrastructure, i.e., that complies = with the modern formulations of RFC 5321 (and RFC 6531, for EAI). That = class of e-mail addresses is interesting, and much more straightforward = to write a regular expression for. The other ones are also interesting and will be covered. However, I = would assume that non-mail processing implementers will want to focus on = the modern RFC 5321-compliant expression(s). Regards, Sean= From nobody Sat Apr 2 01:12:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78DF12D727; Sat, 2 Apr 2016 01:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 mQMMeJfrExhs; Sat, 2 Apr 2016 01:12:14 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF4312D575; Sat, 2 Apr 2016 01:12:14 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 12D98FA006A; Sat, 2 Apr 2016 08:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1459584731; bh=yuzk+1We+fWCQZFov5RpeFVsvKk85N30tDcZWw3rWA4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YICjZc7d0QvLO0dvhQyBwvX3aInEwLPY/SODDHtU1LcieuCH/TMvTISmjBI+pXRh0 4la81AMfi/V3MlenriUHwWFhsXCN3lVC97Qy2xXyZe6dlhbULdcGohTeCsLbLubZkT p1PrsLli0lFs1gxWMI8okde5eclXYHF6VEARAEXI= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1459584730-20268-20263/11/1; Sat, 2 Apr 2016 08:12:10 +0000 From: Arnt Gulbrandsen To: dispatch@ietf.org, ietf-smtp@ietf.org Date: Sat, 2 Apr 2016 09:12:09 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: <01PYIN3BRVCI00005M@mauve.mrochek.com> References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> <13628.1459398537@turing-police.cc.vt.edu> <01PYIN3BRVCI00005M@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 08:12:16 -0000 Ned Freed writes two excellent paragraphs: > As a practical matter, there's lots of software out there that use bogus > regexps to check addresses. Anything that could possibly > improve this situation > is a win in my book. And people have occasionally been known to look at RFCs > and use what they find there. ... > Personally, I'd settle for subaddresses working more than half the time with > web forms. I could not care less about support for obsolete syntax. This, +1, +100. Arnt From nobody Sat Apr 2 06:48:07 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6D112D529; Sat, 2 Apr 2016 00:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 lKaaa-n-0tGD; Sat, 2 Apr 2016 00:14:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCA412D1E3; Sat, 2 Apr 2016 00:14:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PYIN3DEH2O009ACL@mauve.mrochek.com>; Sat, 2 Apr 2016 00:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1459580989; bh=iAc0JctClzbVTNqSK1N1hbdS/7S0vjqkXaWdRIkb2WA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=BRqBg5xXVzlUvcBXPU4nvbfd0DGEs34Rj5xpmhrzuyCal7sIyZfQkKjOeCcIWueN5 EsH+zuiibN0Qp2/zKna9bLB7Me6q07bzplbcTIFJXQ6dDXJGbDBG2HszVCAc8eiwpH hy88PWk5IKISIf+Ks7W+HJDaOXpOV/Riqa97cz5Q= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PY1MT70XR400005M@mauve.mrochek.com>; Sat, 02 Apr 2016 00:09:46 -0700 (PDT) Message-id: <01PYIN3BRVCI00005M@mauve.mrochek.com> Date: Fri, 01 Apr 2016 23:55:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 02 Apr 2016 02:57:10 -0300" References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> <13628.1459398537@turing-police.cc.vt.edu> To: Sean Leonard Archived-At: X-Mailman-Approved-At: Sat, 02 Apr 2016 06:48:05 -0700 Cc: John C Klensin , dispatch@ietf.org, Valdis.Kletnieks@vt.edu, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 07:14:57 -0000 > Hello... > > On Mar 31, 2016, at 1:28 AM, Valdis.Kletnieks@vt.edu wrote: > > > > On Tue, 29 Mar 2016 15:38:59 -0400, John C Klensin said: > > > >> Actually five families if you want to do a comprehensive job: > >> > >> - 5321, possibly with nods to its predecessors > >> - 5322 which, as you point out, is not the same as 5321 > >> (and most, if not all, of the differences are > >> intentional) > >> - the EAI family > >> - the base DNS spec family, as updated > > > > And the corner cases when they don't agree. Consider > > user@yoyo_dyne.com - how long did *that* wart get debated? :) > > > > Those of us who were around for RFC1341 can look at the following, > > and weep, and ponder what failure modes the authors of this would have > > managed if they had *both* an ABNF and a regexp provided to work from, > > *even if they were semantically the same*... > > > > % egrep 'X-Mail|alt' bad.mailfile > > X-Mailer: IBM Notes Release 9.0.1FP2 SHF37 August 25, 2014 > > Content-Type: multipart/alternative; boundary="=_alternative 002EDD9148257F79_=" > > --=_alternative 002EDD9148257F79_= > > --=_alternative 002EDD9148257F79_= > > --=_alternative 002EDD9148257F79_=-- > > --=_alternative > > % > > > > (Hint: You'll probably need a fixed-space font and a lot of pondering - the > > above cost me close to 10 days of aggravation trying to figure out why one > > vendor's support emails were consistently getting eaten by my procmail > > filters, before I finally spotted it…) > Are you referring to the fact that the boundary has two spaces between > “_alternative" and “002E...”? > Easy enough to spot. Not sure how easy it is to spot by eye, but this is why msglint utilities exist: So you don't have to. The one available at: https://github.com/NedFreed/msglint spots the problem instantly. (You're also supposed to be able to run that one from www.apps.ietf.org, but that's been down for a long time despite several requests to update its IP address.) > Not sure how that is germane to the topic at hand. I have not proposed writing > standardized regular expressions for boundary parts; it is not clear why such a > thing would be generally useful. I don't see the relevance either. > > > > This is why we can't have nice things.... > > > > Oh, and those who want to tempt the Lovecraftian regexp elder gods should > > ponder the following: > > > > http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html > > > > (If that doesn't make Sean reconsider, *nothing* will... :) > Does not make me reconsider at all. > > Half the work is done, just copy-and-paste! > > A “deliverable” e-mail address is one that is deliverable with the modern > SMTP infrastructure, i.e., that complies with the modern formulations of RFC > 5321 (and RFC 6531, for EAI). That class of e-mail addresses is interesting, > and much more straightforward to write a regular expression for. As a practical matter, there's lots of software out there that use bogus regexps to check addresses. Anything that could possibly improve this situation is a win in my book. And people have occasionally been known to look at RFCs and use what they find there. So unless someone can explain to me a likely scenario in which this going to make the general situation worse, I support the adoption and publication of this document. > The other ones are also interesting and will be covered. However, I would > assume that non-mail processing implementers will want to focus on the modern > RFC 5321-compliant expression(s). Personally, I'd settle for subaddresses working more than half the time with web forms. I could not care less about support for obsolete syntax. Ned From nobody Sat Apr 2 10:20:57 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C4C12D0D8; Sat, 2 Apr 2016 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 T6gi-qoa9iC7; Sat, 2 Apr 2016 10:20:53 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595CE12D17A; Sat, 2 Apr 2016 10:20:53 -0700 (PDT) Received: from [192.168.0.2] (unknown [181.229.89.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6DFBB509B8; Sat, 2 Apr 2016 13:20:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sat, 2 Apr 2016 14:20:49 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3A074741-4961-4E44-AFE8-363637F3ECB8@seantek.com> References: <8760w5xp8a.fsf@hobgoblin.ariadne.com> <158468C8650CEFDE15AD3A0D@JcK-HP8200.jck.com> <56FACA08.5000909@seantek.com> <1470E5C228A55B3E9D4AE851@JcK-HP8200.jck.com> <13628.1459398537@turing-police.cc.vt.edu> <01PYIN3BRVCI00005M@mauve.mrochek.com> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 17:20:56 -0000 > On Apr 2, 2016, at 5:12 AM, Arnt Gulbrandsen = wrote: >=20 > Ned Freed writes two excellent paragraphs: >> As a practical matter, there's lots of software out there that use = bogus >> regexps to check addresses. Anything that could possibly improve this = situation >> is a win in my book. And people have occasionally been known to look = at RFCs >> and use what they find there. > ... >> Personally, I'd settle for subaddresses working more than half the = time with >> web forms. I could not care less about support for obsolete syntax. >=20 > This, +1, +100. Yes, that was a major motivator for why I am proposing this work. Not to wander on the topic to elsewhere: the presence of an address that = contains + or some widely-used subaddressing character does not make it = "the same" or equivalent in any way. Only the mail server can make that = determination. I am firmly with John Levine and others in the mail camp = on this topic. An implementation that sees user+one@ and user+two@, or = user.one@ and userone@ really needs to treat these as distinct = addresses, unless the implementation is the mail server itself, in which = case, it can do whatever it is configured to do. It should not be difficult to see that any difference in the local-part = string can be used as a basis for differential routing, or not. Even if = a mail server formally supports sub-addressing, a user or admin can = choose (via Sieve scripts or otherwise) to route those messages to = different places. Sean From nobody Mon Apr 4 01:52:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C5512D0DF for ; Mon, 4 Apr 2016 01:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 FjEvu04zOtWu for ; Mon, 4 Apr 2016 01:52:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0660.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:660]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BC512D0A5 for ; Mon, 4 Apr 2016 01:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rrPTj5coRDCFP1CpWK5hdSlrf/eSWh1P0NfMuKNWHMY=; b=SHxz+I+rlLlWjIH3VgqilG8NzPaVQpN8QdouUbKWpOqQqrMCfZ6XorjvGwc7rXVmylsSWw5Hv7PZdGU2jjn1ah1fYiIVdW9FVuLf/mhDInzslQrx6e1aEhy7EsBcI+A1HoNtPmt2Dul/p5MQfADrl13QPxWnRKRzwlM05MiqVBc= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 4 Apr 2016 08:52:10 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0447.027; Mon, 4 Apr 2016 08:52:10 +0000 From: "Asveren, Tolga" To: Martin Taylor , "dispatch@ietf.org" Thread-Topic: I-D on RTP failover problem posted to mmusic Thread-Index: AdF3DhoOkQnpNWO+QpOR32SJexhDJwXQIEgQ Date: Mon, 4 Apr 2016 08:52:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: metaswitch.com; dkim=none (message not signed) header.d=none;metaswitch.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: dfbcd20b-6af7-4551-2739-08d35c6668f8 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:XFLxjQP7o24kPGDHRfMMks0TsCbYeVCoukDbd7XTv93EE6tLMBr/AN/2NbdI1U1MenAZuYCBsB2qXl3PQ6AJJ4MH8mOwI1O9eduOT+OwfwA1RYNvV+XVCXCgH8h2DeP1v1sJJPlJXe6Ee0/UpP4Zvg==; 24:+OEVlG8Y+0xIK0uYr6UFsRGV7ifG8OoD5h+FX+cF0eRAhMzlnHgy7O8DgbDU6kzOXR8+xIVnnmtqcokQhljvl8jA+gRc4xyUyGc16yr9jHw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0902222726 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(377454003)(13464003)(92566002)(3280700002)(74316001)(5008740100001)(1096002)(1220700001)(586003)(3846002)(6116002)(102836003)(2906002)(10400500002)(54356999)(2501003)(3660700001)(33656002)(19580395003)(19580405001)(5001770100001)(107886002)(81166005)(77096005)(15975445007)(87936001)(5003600100002)(11100500001)(76576001)(189998001)(99286002)(50986999)(86362001)(76176999)(2950100001)(5004730100002)(66066001)(2900100001)(122556002)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2016 08:52:10.5322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 08:52:33 -0000 This certainly is a serious problem for folks dealing with the type of envi= ronments described in the document. A solution definitely would be welcome = and I hope this initiative can move forward. So, 100% interested here and I= am also ready to contribute to the solution/document. Thanks, Tolga > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Martin > Taylor > Sent: Saturday, March 05, 2016 1:53 PM > To: dispatch@ietf.org > Subject: [dispatch] I-D on RTP failover problem posted to mmusic >=20 > I recently posted https://tools.ietf.org/html/draft-taylor-mmusic-rtp- > failover-problem-00 to mmusic. >=20 > This I-D describes a common problem associated with network functions tha= t > terminate or relay large numbers of concurrent RTP sessions such as sessi= on > border controllers or conference bridges. Network operators typically > require that no equipment or software failure shall cause more than a > second or two's interruption to any of the RTP sessions handled by such > functions. The only practical solution capable of meeting this need curr= ently > is for RTP packets to be sent to a service IP address which is capable of= being > moved quickly from one system to another, and the only way to do this > sufficiently quickly is to for both active and standby systems to be conn= ected > to the same L2 segment. This is problematic in two situations: (1) where > active and standby systems are geographically separated and (2) in L3-cen= tric > data center fabrics. >=20 > This Informational I-D is intended to stimulate discussion leading to > consensus on the need for a solution. The solution is likely to involve > extensions to SDP to communicate multiple connection addresses at session > setup time, which is why I originally submitted the I-D to mmusic. Howev= er, > the solution is also likely to require some new RTP and RTCP procedures -= so I > have posted an email to avtcore alerting them to the existence of this I-= D. >=20 > Martin >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Apr 4 03:06:22 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDF812D54F for ; Mon, 4 Apr 2016 03:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=dvJ1zyut; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=bsgh1npA 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 cPSW0u5cs38n for ; Mon, 4 Apr 2016 03:06:19 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4562612D661 for ; Mon, 4 Apr 2016 03:06:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8E556208A5 for ; Mon, 4 Apr 2016 06:06:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 04 Apr 2016 06:06:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=mPzRHHzOt8mx7L1Z iEgiqbnWZzg=; b=dvJ1zyutUUn65RMzHhi7wuMtcdiWNlT1TRszrnx0nWUjyzWz I65rQIWS6Jm2G9IQLE4CeOBTvpgL5oAYCDqsp0QBj3fJ+IzcKkW70mSwCbilk9zF W9QR/70pGkVYU8F4ZtDPWpka+3beF10IioseJbLWd0wDzklabn+MccCVgH8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=mPzRHHzOt8mx7L1ZiEgiqbnWZzg=; b=bsgh1npAjnwbKQXiP1Vw AfyjTPN/xjAXa4jQqDALzkhjtbnxiRcz4YPgkOUxvMilHsZ/Du5PcrI1dOvs1vKG pnkDIWFDTR0VO/edyjP1THQw8weCb32Zm6NYsBgkwIxmCqBRN+oavSVfKKLNZaGt I52D91uvSZZcrzIU40J/ssw= X-Sasl-enc: enMa/H36oDQyGZq3SC/H1P1lCJ/EWKzg6NCikM1tkU7q 1459764377 Received: from dhcp-8c14.meeting.ietf.org (dhcp-8c14.meeting.ietf.org [31.133.140.20]) by mail.messagingengine.com (Postfix) with ESMTPA id AD0B3C00022; Mon, 4 Apr 2016 06:06:16 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0" Date: Mon, 4 Apr 2016 07:06:15 -0300 References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> To: dispatch@ietf.org, apps-discuss@ietf.org Message-Id: <200C687E-B73D-4950-B188-956137247119@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [dispatch] Fwd: ANRP presentations at IETF-95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 10:06:21 -0000 --Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Forwarding since folks might want to check out these talks in the = IRTFOPEN session, Tuesday at 10:00am in Pacifico A. > Begin forwarded message: >=20 > From: "Eggert, Lars" > Subject: ANRP presentations at IETF-95 > Date: March 10, 2016 at 1:34:47 PM GMT-3 > To: "irtf-announce@irtf.org" , "ietf@ietf.org" = , "95attendees@ietf.org" <95attendees@ietf.org> > Reply-To: "anrp@irtf.org" >=20 > Hi, >=20 > we are extremely pleased to report that for the 2016 award period of > the Applied Networking Research Prize (ANRP), 53 eligible nominations > were received. Each submission was reviewed by several members of the > selection committee selection committee according to a diverse set of > criteria, including scientific excellence and substance, timeliness, > relevance, and potential impact on the Internet. >=20 > Based on this review, six submissions are awarded an Applied > Networking Research Prize in 2016. Two prize winners will present > their work at the IRTF Open Meeting during IETF-95 in Buenos Aires, > Argentina. The ANRPs for IETF-95 go to: >=20 > *** Roya Ensafi *** for examining how the Chinese "great firewall" > discovers hidden circumvention servers: >=20 > Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, > Nicholas Weaver, and Vern Paxson. Examining How the Great Firewall > Discovers Hidden Circumvention Servers. Proc. ACM Internet > Measurement Conference (IMC), Tokyo, Japan, October 28-30, 2015. >=20 > *** Zakir Durumeric *** for an empirical analysis of email delivery > security: >=20 > Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Elie > Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, Michael > Bailey, and J. Alex Halderman. Neither Snow Nor Rain Nor MITM=E2=80=A6= An > Empirical Analysis of Email Delivery Security. Proc. ACM Internet > Measurement Conference (IMC), Tokyo, Japan, October 28-30, 2015. >=20 > Please subscribe to the IRTF-Announce mailing list in order to receive > future calls for ANRP nominations and join ISOC to stay informed of > other networking research initiatives: >=20 > https://irtf.org/mailman/listinfo/irtf-announce > https://isoc.org/join >=20 > Regards, >=20 > Lars Eggert, IRTF Chair https://irtf.org/anrp > Mat Ford, Internet Society https://isoc.org/research/ >=20 >=20 > 2016 ANRP Selection Committee >=20 > Mark Allman, ICIR > Marcelo Bagnulo, UC3M > Lou Berger, LabN > KC Claffy, CAIDA > Mark Crovella, Boston University > Lars Eggert, NetApp > Stephen Farrell, Trinity College Dublin > Nick Feamster, Princeton > Mat Ford, ISOC > Lisandro Granville, UFRGS > Volker Hilt, Bell Labs > Suresh Krishnan, Ericsson > Al Morton, AT&T Laboratories > J=C3=B6rg Ott, Aalto University > Colin Perkins, University of Glasgow > Aiko Pras, University of Twente > J=C3=BCrgen Sch=C3=B6nw=C3=A4lder, Jacobs University Bremen > Joe Touch, USC/ISI > Rolf Winter, Hochschule Augsburg > Lixia Zhang, UCLA >=20 --Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Forwarding since folks might want to check out these talks in = the IRTFOPEN session, Tuesday at 10:00am in Pacifico A.

Begin forwarded message:

From: = "Eggert, Lars" <lars@netapp.com>
Subject: = ANRP = presentations at IETF-95
Date: = March 10, 2016 at 1:34:47 PM = GMT-3
To: = "irtf-announce@irtf.org" <irtf-announce@irtf.org>, "ietf@ietf.org" <ietf@ietf.org>, "95attendees@ietf.org" = <95attendees@ietf.org>
Reply-To: = "anrp@irtf.org" <anrp@irtf.org>

Hi,

we are extremely pleased to report that for the 2016 award = period of
the Applied Networking Research Prize (ANRP), 53 = eligible nominations
were received. Each submission was = reviewed by several members of the
selection committee = selection committee according to a diverse set of
criteria, = including scientific excellence and substance, timeliness,
relevance, and potential impact on the Internet.

Based on this review, six submissions are = awarded an Applied
Networking Research Prize in 2016. Two = prize winners will present
their work at the IRTF Open = Meeting during IETF-95 in Buenos Aires,
Argentina. The = ANRPs for IETF-95 go to:

*** Roya Ensafi = *** for examining how the Chinese "great firewall"
discovers= hidden circumvention servers:

=    Roya Ensafi, David Fifield, Philipp Winter, Nick = Feamster,
   Nicholas Weaver, and Vern = Paxson. Examining How the Great Firewall
=    Discovers Hidden Circumvention Servers. Proc. ACM = Internet
   Measurement Conference (IMC), = Tokyo, Japan, October 28-30, 2015.

*** = Zakir Durumeric *** for an empirical analysis of email delivery
security:

=    Zakir Durumeric, David Adrian, Ariana Mirian, James = Kasten, Elie
   Bursztein, Nicolas = Lidzborski, Kurt Thomas, Vijay Eranti, Michael
=    Bailey, and J. Alex Halderman. Neither Snow Nor Rain = Nor MITM=E2=80=A6 An
   Empirical Analysis = of Email Delivery Security. Proc. ACM Internet
=    Measurement Conference (IMC), Tokyo, Japan, October = 28-30, 2015.

Please subscribe to the = IRTF-Announce mailing list in order to receive
future = calls for ANRP nominations and join ISOC to stay informed of
other networking research initiatives:

   https://irtf.org/mailman/listinfo/irtf-announce
   https://isoc.org/join

Regards,

Lars Eggert, IRTF Chair =            https://irtf.org/anrp
Mat Ford, Internet Society =         https://isoc.org/research/

2016 ANRP Selection Committee

Mark Allman, ICIR
Marcelo Bagnulo, UC3M
Lou Berger, LabN
KC Claffy, CAIDA
Mark Crovella, Boston University
Lars Eggert, = NetApp
Stephen Farrell, Trinity College Dublin
Nick Feamster, Princeton
Mat Ford, ISOC
Lisandro Granville, UFRGS
Volker Hilt, Bell = Labs
Suresh Krishnan, Ericsson
Al Morton, = AT&T Laboratories
J=C3=B6rg Ott, Aalto University
Colin Perkins, University of Glasgow
Aiko Pras, = University of Twente
J=C3=BCrgen Sch=C3=B6nw=C3=A4lder, = Jacobs University Bremen
Joe Touch, USC/ISI
Rolf Winter, Hochschule Augsburg
Lixia Zhang, = UCLA


= --Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0-- From nobody Mon Apr 4 04:17:39 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55612D1D7 for ; Mon, 4 Apr 2016 04:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 R1DrAsiQmGCI for ; Mon, 4 Apr 2016 04:17:35 -0700 (PDT) Received: from forward13o.cmail.yandex.net (forward13o.cmail.yandex.net [37.9.109.182]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4291812D517 for ; Mon, 4 Apr 2016 04:17:25 -0700 (PDT) Received: from web12o.yandex.ru (web12o.yandex.ru [95.108.205.112]) by forward13o.cmail.yandex.net (Yandex) with ESMTP id E29C9217F9; Mon, 4 Apr 2016 14:17:22 +0300 (MSK) Received: from web12o.yandex.ru (localhost [127.0.0.1]) by web12o.yandex.ru (Yandex) with ESMTP id 2138937423A4; Mon, 4 Apr 2016 14:17:22 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1459768642; bh=6BiuxaL2j2HeQUTxzArzBW48k4shsa4aCzSHVWfTCZU=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=upERaSEmMkvfHmWa8LWIHKVYZVenga/DEYEp5ax7gDWVHRj9hL4xe5JSRt2m92wWW gVIYsBNt/vEU2GuJWoIF7wy99N9PZu3HWFQNkrfh+n7KaHpwuxi9PFV5xnhFeNMtrc nkDueEkq4tnabuIFetO4duyVZDELkLNoV8hh84ys= Received: by web12o.yandex.ru with HTTP; Mon, 04 Apr 2016 14:17:21 +0300 From: Anton Tveretin To: "worley@ariadne.com" In-Reply-To: <87a8lr6fts.fsf@hobgoblin.ariadne.com> References: <1197661458241466@web28m.yandex.ru> (tveretinas@yandex.ru) <87a8lr6fts.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Message-Id: <705541459768641@web12o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 04 Apr 2016 16:17:21 +0500 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] My Drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:17:38 -0000 Thanks for your reply. I will address issues in the next release, of course. > The last thing is currently not standartised. This document is to > fill the gap. This thing refers to "maintain connectivity... through a tunnel". It seems that I was too vague. I think I should remove all references to other tunnelling protocols (except L2TP) from this draft. Also, SDP spec was updated, and now payload types unambiguously form a distinct namespace from MIME types. I'm unsure that "media type" is the most appropriate term for a tunnel. 21.03.2016, 19:55, "Dale R. Worley" : > writes: >> draft-tveretin-dispatch-l2tp-sdp-01: >> Changed proposed status to INFORMATIONAL, and separated normative and >> informative references. >> I believe that the I-D should get dispatch'ed to mmusic. Or launch a >> new WG or BOF to discuss tunnelling using SIP. Someone might argue >> that Session Initiation Protocol is not to initiate sessions. :) > > Of course, what you are proposing is an application/l2tp as a *media* > type within a session. And so SIP can be used to set up an L2TP > connection as part of its media. > > Section 1 contains: > > Alice switches to data mode, uses text chat, sends > a file using Zmodem, and Bob receives it. Or Bob sends a file. Now > Alice starts a PPP [RFC1661] session. To maintain connectivity with > Bob, a tunnel (as of L2TP [RFC2661], PPTP [RFC2637], IPsec [RFC2401], > GPRS Tunneling Protocol) is needed. > > The last thing is currently not standartised. This document is to > fill the gap. > > I'm not sure what "the last thing" is; it appears to be "GPRS Tunneling > Protocol", which is currently not standardized. But since this document > is about L2TP, the sentence "This document is to fill the gap" is > incorrect. > > There needs to be some discussion of the effect of re-INVITE, subsequent > offer/answer cycles. I would expect (not knowing anything about L2TP) > that if the tunnel specified by the last offer/answer cycle was still > up, the presence of the same m= line in the current offer/answer cycle > means that the tunnel is to be continued. OTOH, it may require that the > tunnel send some sort of end-to-end check to ensure that the tunnel is > working, and a teardown/reopen cycle if it is not. (This needs to be > based on best current practices in L2TP.) > > Is there any need to carry L2TP authentication information in SDP? > > Is there practical demand for establishing tunnels as part of the media? > >> draft-tveretin-dispatch-remote-02: >> I believe that the I-D belongs to sipcore, as it defines new >> methods. Finally, I did some examples. > > Does this proposal enable any behaviors that are not already possible > (e.g., with RFC 3891, "Replaces")? > > Dale From nobody Mon Apr 4 07:39:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B826B12D75B for ; Mon, 4 Apr 2016 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 iXIvoPMJtf0j for ; Mon, 4 Apr 2016 07:39:40 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D0712D745 for ; Mon, 4 Apr 2016 07:39:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DCC147C7B1D for ; Mon, 4 Apr 2016 16:39:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EzbmSJguYEG for ; Mon, 4 Apr 2016 16:39:26 +0200 (CEST) Received: from [IPv6:2001:67c:370:176:2154:8066:f6ed:c7f7] (unknown [IPv6:2001:67c:370:176:2154:8066:f6ed:c7f7]) by mork.alvestrand.no (Postfix) with ESMTPSA id A72C87C7AD9 for ; Mon, 4 Apr 2016 16:39:25 +0200 (CEST) To: dispatch@ietf.org References: From: Harald Alvestrand Message-ID: <57027C99.1090100@alvestrand.no> Date: Mon, 4 Apr 2016 16:39:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:39:42 -0000 On 04/04/2016 10:52 AM, Asveren, Tolga wrote: > This certainly is a serious problem for folks dealing with the type of environments described in the document. A solution definitely would be welcome and I hope this initiative can move forward. So, 100% interested here and I am also ready to contribute to the solution/document. naive: Why isn't ICE the answer? Possibly with one of the extensions like trickle ICE or ICE renomination currently discussed in the ICE WG. > > Thanks, > Tolga > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Martin >> Taylor >> Sent: Saturday, March 05, 2016 1:53 PM >> To: dispatch@ietf.org >> Subject: [dispatch] I-D on RTP failover problem posted to mmusic >> >> I recently posted https://tools.ietf.org/html/draft-taylor-mmusic-rtp- >> failover-problem-00 to mmusic. >> >> This I-D describes a common problem associated with network functions that >> terminate or relay large numbers of concurrent RTP sessions such as session >> border controllers or conference bridges. Network operators typically >> require that no equipment or software failure shall cause more than a >> second or two's interruption to any of the RTP sessions handled by such >> functions. The only practical solution capable of meeting this need currently >> is for RTP packets to be sent to a service IP address which is capable of being >> moved quickly from one system to another, and the only way to do this >> sufficiently quickly is to for both active and standby systems to be connected >> to the same L2 segment. This is problematic in two situations: (1) where >> active and standby systems are geographically separated and (2) in L3-centric >> data center fabrics. >> >> This Informational I-D is intended to stimulate discussion leading to >> consensus on the need for a solution. The solution is likely to involve >> extensions to SDP to communicate multiple connection addresses at session >> setup time, which is why I originally submitted the I-D to mmusic. However, >> the solution is also likely to require some new RTP and RTCP procedures - so I >> have posted an email to avtcore alerting them to the existence of this I-D. >> >> Martin >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. From nobody Mon Apr 4 11:03:25 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C012D1BA for ; Mon, 4 Apr 2016 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.53 X-Spam-Level: X-Spam-Status: No, score=-114.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ujBvMYphI8zp for ; Mon, 4 Apr 2016 11:03:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C06712D175 for ; Mon, 4 Apr 2016 11:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1345; q=dns/txt; s=iport; t=1459793002; x=1461002602; h=from:to:cc:subject:date:message-id:mime-version; bh=NfNdk7C+v+gE1wxmhEvGR8J0sCQm8uE4HiOXpzBZVRk=; b=LCjxfhIER1uUhKiclB1mawdSX51Jv0kpRWRt70gfEiZCPRpxGjZl/2dn lBhXt8pgjtb8A2T3/hHnebqrEsYxFqNF6z1X8j2k0bUJhtJZ9iFuR7aZ4 43COQ3jBXQl9uFKkjZKSmV5NJ6wTBim21PmEdvqPRF9TVNq2iwcI2Aseu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdBQDWqwJX/4UNJK1cgzdTgQO2MIR+g?= =?us-ascii?q?XIhhWyBPDkTAQEBAQEBAWUnhDgMBHkSAQsBdCcEDogsDr1sAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQSIFYdBgn6CKwWYAQGBKoxdjw+PGQEiAj6DZ4gUfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208,217";a="257181686" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 18:03:21 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34I3Kth014199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 18:03:21 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:03:20 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 14:03:20 -0400 From: "Cullen Jennings (fluffy)" To: DISPATCH list Thread-Topic: Draft dispatch minutes IETF95 Thread-Index: AQHRjpxFeQdM2Sv/ckeONq8DjjHrgA== Date: Mon, 4 Apr 2016 18:03:20 +0000 Message-ID: <611C26A2-1E0E-43D4-8C93-CB28ED75CDF3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.80.83] Content-Type: multipart/alternative; boundary="_000_611C26A21E0E43D48C93CB28ED75CDF3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dispatch] Draft dispatch minutes IETF95 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:03:23 -0000 --_000_611C26A21E0E43D48C93CB28ED75CDF3ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft minutes are up at https://www.ietf.org/proceedings/95/minutes/minutes-95-dispatch Thank you to Dan Burnett and John Mattsson for taking these. --_000_611C26A21E0E43D48C93CB28ED75CDF3ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Draft minutes are up at 

https://www.ietf.org/proceedings/95/minutes/min= utes-95-dispatch

Thank you to Dan Burnett and John Mattsson for taking these= . 


--_000_611C26A21E0E43D48C93CB28ED75CDF3ciscocom_-- From nobody Mon Apr 4 14:10:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161F612D8A8 for ; Mon, 4 Apr 2016 14:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 lUTc7ietximx for ; Mon, 4 Apr 2016 14:10:50 -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 ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F220612D8A7 for ; Mon, 4 Apr 2016 14:10:49 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by comcast with SMTP id nBlZaKN5QnIc7nBlpaDcif; Mon, 04 Apr 2016 21:10:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459804249; bh=0dQiUeyJQBDbEZ4GtH7D2/F1ozAJ7p4CcSlfXIVCTik=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=pX0ebzg+x3GlEJeZuHRg7fOSHWvBs5DDQsHJ83OqKxeX9s4hQ4aU1HhYK7tPUtrLK whyU5MsYOAtaV/aJlooxvYvsTwKbAGvrGg20LmXJdS6JTGKGfYuWESvFgruSLrK/Cg yBEeHFZMvQLJOriKk/nyYcAGUN/70iHsBk9X7WxPvduYneI/2gyofFABXoWS9Et2NE 0AZ1vXgxnEFW0ic7NOdOAesXp7pSW3V18HLsugYdKzhHuyPXpDYjVULULAKGgZoUCz tFgioRhsaZUCM2vkLXMKCyBn2ymn7xhLAKvLkNvdXIshdUEQRKhL75+otoSi9DloyW B9LcZnQh7qdUg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id eMAo1s0021nMCLR01MAok4; Mon, 04 Apr 2016 21:10:49 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u34LAl5j005104; Mon, 4 Apr 2016 17:10:47 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u34LAlQD005101; Mon, 4 Apr 2016 17:10:47 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ned Freed In-Reply-To: <01PYIN3BRVCI00005M@mauve.mrochek.com> (ned.freed@mrochek.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 04 Apr 2016 17:10:47 -0400 Message-ID: <87pou5axm0.fsf@hobgoblin.ariadne.com> Archived-At: Cc: dispatch@ietf.org, ietf-smtp@ietf.org Subject: Re: [dispatch] [ietf-smtp] BCP proposal: regular expressions for Internet Mail identifiers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:10:51 -0000 Ned Freed writes: > So unless someone can explain to me a likely scenario in which this going to > make the general situation worse, I support the adoption and publication of > this document. Well said! Dale From nobody Tue Apr 5 01:02:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7912D112 for ; Tue, 5 Apr 2016 01:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 Leqx3qtD1S21 for ; Tue, 5 Apr 2016 01:02:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0066.outbound.protection.outlook.com [207.46.100.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635C312D0E0 for ; Tue, 5 Apr 2016 01:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ckfpzkCSAcOx++rgAD/qz2mPyY33xWOSqTHJ1OdNL34=; b=btZ0L4oXrvpnEouLCH9UGQC+f9aHm45PfrTaUAM8fYKbrhxTQuRHL1pzPFscMIo4Ec+1oeNuc31FHsmhYxVH2vYH0yZhRo15t6YggR8RLXJMdUBPQjFRsBghEUX7cN1ERCIsF5D7YhzcoEGaU4kSuzjcTacgl8eKIcCh4eG64xE= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 08:02:25 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0447.027; Tue, 5 Apr 2016 08:02:25 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , "dispatch@ietf.org" Thread-Topic: [dispatch] I-D on RTP failover problem posted to mmusic Thread-Index: AdF3DhoOkQnpNWO+QpOR32SJexhDJwXQIEgQAAxKyoAAI5o4EA== Date: Tue, 5 Apr 2016 08:02:25 +0000 Message-ID: References: <57027C99.1090100@alvestrand.no> In-Reply-To: <57027C99.1090100@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: a3954031-37d0-4569-98b1-08d35d28a038 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:zj3t63v77LetsJiFX/SIMcGheoImIStW2QxCqzPy+rs+O8g1XVQfjKQqMOq7LSiZCVimbTMGFlWGFvzr9hyVisLfaGwjoVu47/AhvvJHhVTKUGGbFVa2WRx6Qvf5TJHmcscFWtvrqBllajUJSuuxbw==; 24:MQ1tu68j15O21XeKYuGibdygFFMMJLI8uBExuPJCTrlfNvGENI8nLDtKxfbskBwRQX3MrcKl5sYzDRo6+4TQ07tZf71lUTrQelrECW6Q/kA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(164054003)(24454002)(76576001)(122556002)(11100500001)(189998001)(99286002)(3660700001)(81166005)(107886002)(87936001)(15975445007)(5003600100002)(2900100001)(77096005)(5002640100001)(5004730100002)(76176999)(86362001)(50986999)(5001770100001)(66066001)(2950100001)(102836003)(586003)(54356999)(5008740100001)(6116002)(10400500002)(2906002)(92566002)(1096002)(3846002)(1220700001)(3280700002)(74316001)(33656002)(19580405001)(2501003)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2016 08:02:25.6104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 08:02:34 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: Monday, April 04, 2016 10:39 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic >=20 > On 04/04/2016 10:52 AM, Asveren, Tolga wrote: > > This certainly is a serious problem for folks dealing with the type of > environments described in the document. A solution definitely would be > welcome and I hope this initiative can move forward. So, 100% interested > here and I am also ready to contribute to the solution/document. >=20 > naive: Why isn't ICE the answer? > Possibly with one of the extensions like trickle ICE or ICE renomination > currently discussed in the ICE WG. [TOLGA] Just some initial thoughts: We are here talking about "local candidates" on different hosts. Representi= ng them as candidates offered as part of an offer from the same entity woul= dn't be consistent with the basic concepts of ICE. IMHO, avoiding such arch= itectural abuses/forced behavior is preferable as it may cause issues soone= r or later -as it is not a "target use case" in general-, either as part of= the main protocol or in the context of some extension. What is needed is for the controlled side (using ICE terminology) to be abl= e to decide/force which of the local addresses it offered needs to be used = and trigger a change (with as few RTTs as possible) at a given point in tim= e. ICE -as it stands right now- is not suitable for these semantics AFAIK. There is also a need to support scenarios, where (after initial ICE negotia= tion is completed) to change/update the list of valid local candidates and = this ideally should be done with as few RTTs as possible. On the more practical/semi-technical side, there are deployment models/envi= ronments, where ICE is not used. A solution, which relies on using existin= g protocol facilities rather than requiring addition of support for new pro= tocols has a higher adoptability rate in general. >=20 > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Martin > >> Taylor > >> Sent: Saturday, March 05, 2016 1:53 PM > >> To: dispatch@ietf.org > >> Subject: [dispatch] I-D on RTP failover problem posted to mmusic > >> > >> I recently posted > >> https://tools.ietf.org/html/draft-taylor-mmusic-rtp- > >> failover-problem-00 to mmusic. > >> > >> This I-D describes a common problem associated with network functions > >> that terminate or relay large numbers of concurrent RTP sessions such > >> as session border controllers or conference bridges. Network > >> operators typically require that no equipment or software failure > >> shall cause more than a second or two's interruption to any of the > >> RTP sessions handled by such functions. The only practical solution > >> capable of meeting this need currently is for RTP packets to be sent > >> to a service IP address which is capable of being moved quickly from > >> one system to another, and the only way to do this sufficiently > >> quickly is to for both active and standby systems to be connected to > >> the same L2 segment. This is problematic in two situations: (1) > >> where active and standby systems are geographically separated and (2) = in > L3-centric data center fabrics. > >> > >> This Informational I-D is intended to stimulate discussion leading to > >> consensus on the need for a solution. The solution is likely to > >> involve extensions to SDP to communicate multiple connection > >> addresses at session setup time, which is why I originally submitted > >> the I-D to mmusic. However, the solution is also likely to require > >> some new RTP and RTCP procedures - so I have posted an email to > avtcore alerting them to the existence of this I-D. > >> > >> Martin > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > -- > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 5 08:00:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094C912D5E4 for ; Tue, 5 Apr 2016 04:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7Ro6xfzW_Yqc for ; Tue, 5 Apr 2016 04:49:11 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 3BCE912D571 for ; Tue, 5 Apr 2016 04:49:11 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o6so3655317qkc.2 for ; Tue, 05 Apr 2016 04:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=IlekrUK5IwAAUxVlyOHP2lzcEHD3LQQwFhD4oJxHwFg=; b=f7qnkTnWjVcZwnV1ALm5t7Hr52l2tH6skjWoPamPsJC6Bdzpat30FFzhDlirn+/8Of 4j/rrR/cxJTJdI4lAYGkzFZCY5rA7ama/wFTiuR0TqFJj3vvzy199Is500tNi/zczpw6 hm6bAWQAyNioXVa2Ix1if1FSFAkmCznU9Gxt7CUXSvsWZzsx90+vvP4yzsHzbsxpkpom iwigV+fq4sZwVtnFC1rzh4r7rQrA3RLJrDCxxDb1CU5UZNqyPFzdGmbDS/TvuRV2d7tF IgePfxLBdr73d7D/NfeajA3ahyDaspQXtKaqWSq4FuqAoRhWONAfmn0TFDRp/4ZSnBa4 mFiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=IlekrUK5IwAAUxVlyOHP2lzcEHD3LQQwFhD4oJxHwFg=; b=Jb/uja89Cbats/GUSItbDIBejSH6VEwZLLQed55dqVdFOq5YiRhFfXxKUfMPRUu+eW zjSEaSOpjU3t3RJKxhNehN9MBzXrO1DTCXu2W2P8oCgh+qBW6bw5JF0qMxpWF88VyM+f ehzVhJo9kOMU3iuOPCwgWWylXnxhpcv95vt+gp20dybUlJnn25Q4cV7CJSm4Tlw4iiWT trHw8Ci2yh1nlH93rFL7q7u+d69JzLK5eaZhS1zZSJZhiMWoFSOqppv+5819aGSDV1N4 SfMQBJ2GEsk1VcR6Ww7heDgJMo6Uu8alZBONASN+Cn/fdF9CBxlcwsmgpX8xhEHoXbea o56A== X-Gm-Message-State: AD7BkJJWMcoMuRqcwDbgu0bI9lew63dvjJblgOZ1nteAqmVPoly0h746lTQ8y4oEyEiAWQ== X-Received: by 10.55.43.131 with SMTP id r3mr39830502qkr.53.1459856950204; Tue, 05 Apr 2016 04:49:10 -0700 (PDT) Received: from dhcp-89cc.meeting.ietf.org ([31.133.138.204]) by smtp.gmail.com with ESMTPSA id 64sm14241873qhf.40.2016.04.05.04.49.08 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 04:49:09 -0700 (PDT) From: Suzanne Woolf Content-Type: multipart/alternative; boundary="Apple-Mail=_75481768-B51B-4D26-AAF3-5D406FEABEE9" Message-Id: <0EC04822-406B-4E67-B135-CE55D6DE3500@gmail.com> Date: Tue, 5 Apr 2016 07:49:07 -0400 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 08:00:49 -0700 Subject: [dispatch] ARCING BOF Tuesday morning X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 11:49:13 -0000 --Apple-Mail=_75481768-B51B-4D26-AAF3-5D406FEABEE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Some folks who are interested in internet naming across multiple = resolution contexts=E2=80=94 not just DNS=E2=80=94 have the ARCING BOF = this morning. The purpose is to consider some questions about how to = make it easier when protocol developers need to build or extend naming = systems. We=E2=80=99re particularly interested in the Applications perspective. Meeting materials: = https://datatracker.ietf.org/meeting/95/materials.html#arcing = Atlantico C, 10:00-12:00 today Suzanne Woolf Joe Hildebrand (co-chairs)= --Apple-Mail=_75481768-B51B-4D26-AAF3-5D406FEABEE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Some = folks who are interested in internet naming across multiple resolution = contexts=E2=80=94 not just DNS=E2=80=94 have the ARCING BOF this = morning. The purpose is to consider some questions about how to make it = easier when protocol developers need to build or extend naming = systems.

We=E2=80= =99re particularly interested in the Applications perspective.

Meeting = materials: https://datatracker.ietf.org/meeting/95/materials.html#arcing

Atlantico = C, 10:00-12:00 today


Suzanne Woolf
Joe Hildebrand
(co-chairs)
= --Apple-Mail=_75481768-B51B-4D26-AAF3-5D406FEABEE9-- From nobody Tue Apr 5 12:07:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E029312D62E for ; Tue, 5 Apr 2016 12:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com 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 EunpqbJwT0TL for ; Tue, 5 Apr 2016 12:07:42 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 B8FED12D8E1 for ; Tue, 5 Apr 2016 12:07:05 -0700 (PDT) Received: by mail-ob0-x22d.google.com with SMTP id j9so15935221obd.3 for ; Tue, 05 Apr 2016 12:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=op21O05VvNnTHeYkdxGgny4fcBrfqtOFV4NsIeX2CYs=; b=p2/ym+7ie0b/GxGH3jVCYq9R6O7rEDEN2UZXaZBbcwqP41alxD0hnAS5Vn3jeJ9hl9 ugoyGW+lmqQnxHJaVkLrCxsda3A3imcx+8+OvWaOBe+6EHdSmjMp22UeCOYaBkgpveRl FrbafnEajtRF4Y8eWO0VC2O/hMLFwkVvzKrVxjSjQaO73TmnqzD9qfSHDHujwRWlT93j Tkxj88LLZBtWttNbKedW5TTjFph2wt9G3BQNNwXTO0i3pyfpHz+kcfo7+BGXvVWKlXMq TIsy2Xl1IQTo0ohNiAvyWo/4e3ZOTutyD6b5YOQvNkmlK9WlTnNKKhYG+oAAei72JjzS SRoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=op21O05VvNnTHeYkdxGgny4fcBrfqtOFV4NsIeX2CYs=; b=Nc+DC/s66v/ZmehXJVCMCmhAqp021kwTROvnONGU+d/xQdPn7APeJj280t9E0kEsnG MqKCu8l3OQytb1Pjyc9BzTfKazhrhHC2HWHRLVBmAQYT8b9d8JGcAEWOOyF+TPYwx4Zn 81/wN3VoGeyUOsCYWdcIze5lRV2Pv43U/7VlW85A84YcAh/mmNGauwplVIBl6F8hAu8J n8spA+rb4aV6lJUKOW6kZNMFfXLRPf1DCen6Jfy4SU3PHb8KI3xuT3bIu4+Y9lNr+YhY 047ifwOlGlX1vhjPjod0qAKET1CxUrt+zkNKbHUBd972cucJusC9E7BLjIUg/NtHJnMs T3cA== X-Gm-Message-State: AD7BkJL6ZrSje9ptijn0Y2V/26yzV8icszp+0IqOI5pDPnal0iHtw+nUYxs0xXVkq1zBPw== X-Received: by 10.60.85.3 with SMTP id d3mr6530686oez.69.1459883203948; Tue, 05 Apr 2016 12:06:43 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id d10sm10281263oic.10.2016.04.05.12.06.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 12:06:42 -0700 (PDT) To: "Asveren, Tolga" , Harald Alvestrand , "dispatch@ietf.org" References: <57027C99.1090100@alvestrand.no> From: Emil Ivov Message-ID: <57040CC2.9050003@jitsi.org> Date: Tue, 5 Apr 2016 14:06:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 19:07:46 -0000 What bothers me a lot about this work is exactly the fact that it makes no mention of neither ICE nor DTLS/SRTP, so it makes me think that there might be a desire here to head in a direction that fits poorly with both of them. I do disagree with your assertion that ICE is somehow architecturally incompatible with this. The very fact that L2 migration is considered suboptimal by the draft and that it sounds like we are going for client-side redirection, makes me think that ICE is a mandatory path here. Now, I do also agree that, in it's current shape, ICE is suboptimal for this use case but that's a matter that is prone to improvement and I don't think it justifies an ICE-less approach. In fact, should you take such a direction, I am pretty sure that whatever you end up with is bound to have some overlap with ICE anyway. Emil On 5.04.16 г. 3:02, Asveren, Tolga wrote: > Inline... > > Thanks, Tolga > >> -----Original Message----- From: dispatch >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Monday, April 04, 2016 10:39 AM To: dispatch@ietf.org >> Subject: Re: [dispatch] I-D on RTP failover problem posted to >> mmusic >> >> On 04/04/2016 10:52 AM, Asveren, Tolga wrote: >>> This certainly is a serious problem for folks dealing with the >>> type of >> environments described in the document. A solution definitely would >> be welcome and I hope this initiative can move forward. So, 100% >> interested here and I am also ready to contribute to the >> solution/document. >> >> naive: Why isn't ICE the answer? Possibly with one of the >> extensions like trickle ICE or ICE renomination currently discussed >> in the ICE WG. > [TOLGA] Just some initial thoughts: We are here talking about "local > candidates" on different hosts. Representing them as candidates > offered as part of an offer from the same entity wouldn't be > consistent with the basic concepts of ICE. IMHO, avoiding such > architectural abuses/forced behavior is preferable as it may cause > issues sooner or later -as it is not a "target use case" in general-, > either as part of the main protocol or in the context of some > extension. What is needed is for the controlled side (using ICE > terminology) to be able to decide/force which of the local addresses > it offered needs to be used and trigger a change (with as few RTTs as > possible) at a given point in time. ICE -as it stands right now- is > not suitable for these semantics AFAIK. There is also a need to > support scenarios, where (after initial ICE negotiation is completed) > to change/update the list of valid local candidates and this ideally > should be done with as few RTTs as possible. > On the more > practical/semi-technical side, there are deployment > models/environments, where ICE is not used. A solution, which relies > on using existing protocol facilities rather than requiring addition > of support for new protocols has a higher adoptability rate in > general. >> >>> >>> Thanks, Tolga >>> >>>> -----Original Message----- From: dispatch >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Martin Taylor >>>> Sent: Saturday, March 05, 2016 1:53 PM To: dispatch@ietf.org >>>> Subject: [dispatch] I-D on RTP failover problem posted to >>>> mmusic >>>> >>>> I recently posted >>>> https://tools.ietf.org/html/draft-taylor-mmusic-rtp- >>>> failover-problem-00 to mmusic. >>>> >>>> This I-D describes a common problem associated with network >>>> functions that terminate or relay large numbers of concurrent >>>> RTP sessions such as session border controllers or conference >>>> bridges. Network operators typically require that no equipment >>>> or software failure shall cause more than a second or two's >>>> interruption to any of the RTP sessions handled by such >>>> functions. The only practical solution capable of meeting this >>>> need currently is for RTP packets to be sent to a service IP >>>> address which is capable of being moved quickly from one system >>>> to another, and the only way to do this sufficiently quickly is >>>> to for both active and standby systems to be connected to the >>>> same L2 segment. This is problematic in two situations: (1) >>>> where active and standby systems are geographically separated >>>> and (2) in >> L3-centric data center fabrics. >>>> >>>> This Informational I-D is intended to stimulate discussion >>>> leading to consensus on the need for a solution. The solution >>>> is likely to involve extensions to SDP to communicate multiple >>>> connection addresses at session setup time, which is why I >>>> originally submitted the I-D to mmusic. However, the solution >>>> is also likely to require some new RTP and RTCP procedures - so >>>> I have posted an email to >> avtcore alerting them to the existence of this I-D. >>>> >>>> Martin >>>> >>>> _______________________________________________ dispatch >>>> mailing list dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ dispatch mailing >>> list dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> -- Surveillance is pervasive. Go Dark. >> >> _______________________________________________ dispatch mailing >> list dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ dispatch mailing > list dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- https://jitsi.org -- https://jitsi.org From nobody Wed Apr 6 08:29:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C458212D11B for ; Wed, 6 Apr 2016 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 9y_4G3kV2zlr for ; Wed, 6 Apr 2016 08:29:07 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C731C12D11F for ; Wed, 6 Apr 2016 08:28:44 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id npMZaby6MVEtunpNsaj2lj; Wed, 06 Apr 2016 15:28:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459956524; bh=LrLMQO18cO3s+OfHt75gfhBpX7ITYR2nc+DH2O2oFBw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GCzELW+lckElQkQV3YwN1wSfuiQbtfUWeEfDQl3y4gV9IjnjQJGuQqQiNgGDbeW66 X1cbNgqRVuV5h9lyROY6zE9Gl/61cw2vHc5sOSmkstv8Vli0dzEIIhcY0Mgh1i/bBf ExUEMLATAZhhWpyOhGwf4jFvS45zQKlmxgLcgRWXqVfJ+32As4NphX8ybcIt4OwolJ 10uxC1tgdz47hPT0Mv1XQ29schsOHPGBrHEnroZkBhVnJI8AyZNZ1foIGsEjSdSBfq NQmORYKlnFMsqnRLwf9/DrzsXX/tcKn7ctTNcvyl97PJ/qZ4dwQLOL2xZtYkYWsUIp Ey7yI2AV9SO6g== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-09v.sys.comcast.net with comcast id f3Uj1s00P1nMCLR013UjzK; Wed, 06 Apr 2016 15:28:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u36FShBl014570; Wed, 6 Apr 2016 11:28:43 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u36FSgsG014567; Wed, 6 Apr 2016 11:28:42 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: nweinronk@btinternet.com In-Reply-To: <13829706.3548.1457773080244.JavaMail.defaultUser@defaultHost> (nweinronk@btinternet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Apr 2016 11:28:42 -0400 Message-ID: <8737qywyc5.fsf@hobgoblin.ariadne.com> Archived-At: Cc: dispatch@ietf.org Subject: [dispatch] draft-weinronk-dispatch-last-diverting-line-id and History-Info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:29:08 -0000 After listening to the recording of the Dispatch session, my opinion is divided. On the one hand, it would be conceptually best if the network asserted identity of the diverting party was attached to the diverting party's entry in History-Info as a parameter. But I can easily see that as being fragile, with inconsistent support across the SIP universe. (What exactly are the rules for scanning History-Info to determine the entry that describes the last diverting party?) And I see that as a good argument for putting this datum in a special header. (One can compare this with the P-Asserted-Identity header, which gives the "network identity" of the caller, and in the same sense conceptually ought to be a parameter of the From header.) Dale From nobody Wed Apr 6 08:36:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6160D12D11F for ; Wed, 6 Apr 2016 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 UlsDAK96WXX6 for ; Wed, 6 Apr 2016 08:36:31 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7641212D1E7 for ; Wed, 6 Apr 2016 08:36:31 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by comcast with SMTP id npUbadKYybFYYnpVOav38K; Wed, 06 Apr 2016 15:36:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459956990; bh=MtYJOYerC/jg1GwWbkPlI8i9YV8/3xUFOhexx9tLYGs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=gchqeB53mSCFJdzzYHu+oAD3ivlltDrf/H34VZmbpKj97gD/kCmAx4kvhcyRa0xuW g2aPSwwZexa9HYQUTpZaGnP+MBy+NSaY4yYwZtLNMMuqu7Gl/bwmmZMLYxouohqrOv KKCXukUZi8CQYSMaLxJOKMwA1BqGKxsrSak9qZ0KHoTNiW/SITtJRwCTDGOYNX+VeL weKWNta8WoK6TCQrGu+SwzrrbWdGUQXO0TBFQeHQFxkt5oFsrj7t7yD7oW+zV7mqtT T5zr6XLu4SmJppAlWrd9ldUE6kPJZ7j92aPEOnGhOtGk6YGivPbNcQQnp92mubrUVO 4CIVK3JEvPH/w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-05v.sys.comcast.net with comcast id f3cW1s00W1nMCLR013cWAv; Wed, 06 Apr 2016 15:36:30 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u36FaTGD015333 for ; Wed, 6 Apr 2016 11:36:29 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u36FaTB9015330; Wed, 6 Apr 2016 11:36:29 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Apr 2016 11:36:29 -0400 Message-ID: <87vb3uvjeq.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace - Improve namespace name? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:36:32 -0000 This is a minor thing, but I see in sections 3.1 and 3.2: This document introduces the MCPTT namespaces mcptt1 and mcptt2, the name coming from the 3GPP defined Mission Critical Push To Talk service. The MCPTT namespaces use the priority levels listed below from lowest to highest priority. mcpttN.1 (lowest priority) [...] where N is 1 or 2. Intended algorithm for mcptt1 is preemption, and for mcptt2 is queueing. I don't know if it can be changed in 3GPP at this late date, but it would be more mnemonic if they were named "mcptt-p" and "mcptt-q", so you could tell at a glance whether it was a preemption or a queueing priority. Dale From nobody Thu Apr 7 00:48:45 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9537712D17B for ; Thu, 7 Apr 2016 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Hb-3oQmoliiH for ; Thu, 7 Apr 2016 00:48:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5A512D0CF for ; Thu, 7 Apr 2016 00:48:41 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-c1-570610d70a23 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.F2.30858.7D016075; Thu, 7 Apr 2016 09:48:39 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.198]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 09:48:01 +0200 From: =?iso-8859-1?Q?J=F6rgen_Axell?= To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace - Improve namespace name? Thread-Index: AQHRkBobtAKranzA/k67jxdE3gBEhJ9+IjwA Date: Thu, 7 Apr 2016 07:48:01 +0000 Message-ID: <5AEA7B339C0B944BB33A6939249264AD1DABD2DB@ESESSMB305.ericsson.se> References: <87vb3uvjeq.fsf@hobgoblin.ariadne.com> In-Reply-To: <87vb3uvjeq.fsf@hobgoblin.ariadne.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7k+51AbZwg6VtqhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyri4pYu5YAVXxfkz8xkbGCdzdDFyckgImEhs 3r6DFcIWk7hwbz1bFyMXh5DAEUaJ3m3zWSGcxYwSW7vOglWxCThKXP33hx3EFhEIkfg8rZMR xBYWiJP4/O00C0Q8XuL/ZYi4iICRxKfZe4B6OThYBFQkjk2sAAnzCvhKXNy0AKxECKik83w7 M0gJp4CxxJXN9iBhRgFZifvf74FNZBYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+B3W/osTOs+3M EPV6EjemTmGDsLUlli18zQyxVlDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqclJtu ZKSXWpSZXFycn6eXl1qyiREYIwe3/DbYwfjyueMhRgEORiUeXoX9rOFCrIllxZW5hxglOJiV RHhDWNjChXhTEiurUovy44tKc1KLDzFKc7AoifNmR/4LExJITyxJzU5NLUgtgskycXBKNTAu ElnN/3dJ2AJNQRGPEypfttvN3LFJP+3TxxMPn/uHRYutjF+uNbPYPK1uQl5Gf8kEr+74+DfH NjyOuZUeMr/IP5pt3bzj6xutjyenXbipVBfWUF+Wot4ey7v8RfzvfNsDzc8t54t+FJs2Zw37 kkfzf+3d6Fh/JKa/0yr8S1zgmVsGj38ZpcUpsRRnJBpqMRcVJwIAqGIriI0CAAA= Archived-At: Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace - Improve namespace name? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 07:48:43 -0000 Hi, Thanks, that should be possible to do. They will be spelled out explicitly = also on request from Mary. The numbering was chosen following the style in = the definitions in RFC 5478. Regards, J=F6rgen -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worl= ey Sent: 06 April 2016 17:36 To: dispatch@ietf.org Subject: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace - Improve na= mespace name? This is a minor thing, but I see in sections 3.1 and 3.2: This document introduces the MCPTT namespaces mcptt1 and mcptt2, the name coming from the 3GPP defined Mission Critical Push To Talk service. The MCPTT namespaces use the priority levels listed below from lowest to highest priority. mcpttN.1 (lowest priority) [...] where N is 1 or 2. Intended algorithm for mcptt1 is preemption, and for mcptt2 is queueing. I don't know if it can be changed in 3GPP at this late date, but it would b= e more mnemonic if they were named "mcptt-p" and "mcptt-q", so you could te= ll at a glance whether it was a preemption or a queueing priority. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Apr 7 09:41:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E3212D139 for ; Thu, 7 Apr 2016 09:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QeUHAboXliO2 for ; Thu, 7 Apr 2016 09:41:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E6612D11D for ; Thu, 7 Apr 2016 09:41:52 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-06-57068dcee3f9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6A.CE.30858.ECD86075; Thu, 7 Apr 2016 18:41:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 18:41:50 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: draft-holmberg-dispatch-pani-abnf: One additional ABNF fix Thread-Index: AdGQ67n6EzDDca2XQIenenOL1xVVDQ== Date: Thu, 7 Apr 2016 16:41:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F287C1@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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F287C1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdW/d8L1u4wbPfHBbzO0+zWyydtIDV gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mr4NG8la0GnR0Xzq49sDYwL7LoYOTgkBEwk Xp0CMjmBTDGJC/fWs3UxcnEICRxhlPgz4SILhLOIUaJl01QmkAY2AQuJ7n/aIA0iAtoSR1d1 MYPYzAJKEvu2H2EFsYUFnCW+df9kg6jxkGg8284IYetJ7Ou9CVbPIqAisW9SM1g9r4CvxMN7 jWA1jEBHfD+1hgliprjErSfzmSCOE5BYsuc8M4QtKvHy8T9WCFtJYsX2S4wQ9fkSrfduMEHM FJQ4OfMJywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqc lJtuZKSXWpSZXFycn6eXl1qyiREYPQe3/DbYwfjyueMhRgEORiUeXoX9rOFCrIllxZW5hxgl OJiVRHiLu9jChXhTEiurUovy44tKc1KLDzFKc7AoifNmR/4LExJITyxJzU5NLUgtgskycXBK NTBGO2u8PbVJVejzwgtay0Xdf/vlpnqzcacFRvzZcTnLvmh3jMbZfbVGEnGN9xRfcV+8P7Wg elbKhpf/1rdMP/bzjLPlDufWohjbTJMEs717V0uYTRDkNPg640visadW8XtZlm8Rr/15+Mdm 1+PelcfWu55gUns2y7D31vSpPzrTPW4517K9X5avxFKckWioxVxUnAgApQ2IOpoCAAA= Archived-At: Cc: Ben Campbell Subject: [dispatch] draft-holmberg-dispatch-pani-abnf: One additional ABNF fix X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:41:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F287C1ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One additional PANI ABNF issue has been identified. The ABNF defines the following access-info values: operator-specific-GI =3D "operator-specific-GI" EQUAL (toke= n / quoted-string) utran-sai-3gpp =3D "utran-sai-3gpp" EQUAL (token / qu= oted-string) However, they are currently not present in the access-info value list: access-info =3D cgi-3gpp / utran-cell-id-3gpp / dsl-location / i-wlan-node-id / ci-3gpp2 / eth-location / ci-3gpp2-femto / fiber-location / np / gstn-location /local-time-zone / dvb-rcs2-node-id / extension-access-info ...should be: access-info =3D cgi-3gpp / utran-cell-id-3gpp / dsl-location / i-wlan-node-id / ci-3gpp2 / eth-location / ci-3gpp2-femto / fiber-location / np / gstn-location /local-time-zone / dvb-rcs2-node-id / operator-specific-GI / utran-sai-3gpp / extension-access-info My suggestion is to make this fix in draft-holmberg-dispatch-pani-abnf, tog= ether with the other fix. Does anyone have an issue with that? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F287C1ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One additional PANI ABNF issue has been identified.<= o:p>

 

The ABNF defines the following access-info values= :

 

         =      operator-specific-GI   =3D "operato= r-specific-GI" EQUAL (token /  quoted-string)

         =      utran-sai-3gpp      =    =3D "utran-sai-3gpp" EQUAL (token / quoted-string)

 

However, they are currently not present in the ac= cess-info value list:

 

       access-info&= nbsp;           =3D cgi-3= gpp / utran-cell-id-3gpp /

        &= nbsp;           &nbs= p;           dsl-location= / i-wlan-node-id /

        &= nbsp;           &nbs= p;           ci-3gpp2 / e= th-location /

        &= nbsp;           &nbs= p;           ci-3gpp2-fem= to / fiber-location /

        &= nbsp;           &nbs= p;           np / gstn-lo= cation /local-time-zone /

        &= nbsp;           &nbs= p;           dvb-rcs2-nod= e-id /  extension-access-info

 

...should be:

 

       access-info&= nbsp;           =3D cgi-3= gpp / utran-cell-id-3gpp /

        &= nbsp;           &nbs= p;           dsl-location= / i-wlan-node-id /

        &= nbsp;           &nbs= p;           ci-3gpp2 / e= th-location /

        &= nbsp;           &nbs= p;           ci-3gpp2-fem= to / fiber-location /

        &= nbsp;           &nbs= p;           np / gstn-lo= cation /local-time-zone /

        &= nbsp;           &nbs= p;           dvb-rcs2-nod= e-id / operator-specific-GI  /

         =             &nb= sp;          utran-sai-3g= pp / extension-access-info

 

My suggestion is to make this fix in draft-holmbe= rg-dispatch-pani-abnf, together with the other fix.

 

Does anyone have an issue with that?

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B37F287C1ESESSMB209erics_-- From nobody Thu Apr 7 10:33:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E86812D520 for ; Thu, 7 Apr 2016 10:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 MzSqqi6qMVyH for ; Thu, 7 Apr 2016 10:33:15 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4E112D1A3 for ; Thu, 7 Apr 2016 10:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10167; q=dns/txt; s=iport; t=1460050395; x=1461259995; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Rlwb4OVWBQKVbqLWLJMLd1VxAuthYguxee4GyOBXjTc=; b=ZiouO84DGn7L4akBLOb3vz0r9bYNGJDPbusu4cTc5zHHcZQMwtMa2xpC dEI7q8enOh5i6SXC+WLGUdEX6vHE/yApxIKKRUxBzvgBFOt90rKGXe4J1 rIdajIxanXulOv5//hkplllA6wpADhy99tK9CDymRCB4LNH7EgtZruM/C 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgCHmQZX/4QNJK1cgmtMU321WIRzA?= =?us-ascii?q?Q2BcxcBCYUiSgKBRTgUAQEBAQEBAWUnhEIBAQQBAQEqQQsQAgEIPwcnCxQRAQE?= =?us-ascii?q?EDgWIJw7BXwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdYJWhGyCfoIrBZgEA?= =?us-ascii?q?Y4Ljw6PIwEeAQFCg2dsiHMBAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="257891155" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 17:33:03 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u37HX3W8012113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 17:33:03 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 12:33:02 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 12:33:02 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [dispatch] draft-holmberg-dispatch-pani-abnf: One additional ABNF fix Thread-Index: AdGQ67n6EzDDca2XQIenenOL1xVVDQAB89uH Date: Thu, 7 Apr 2016 17:33:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F287C1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F287C1@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_B2995B9A0EEC4E56B24BED44B358EFCDciscocom_" MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-pani-abnf: One additional ABNF fix X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:33:17 -0000 --_000_B2995B9A0EEC4E56B24BED44B358EFCDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 7, 2016, at 1:42 PM, Christer Holmberg > wrote: Hi, One additional PANI ABNF issue has been identified. The ABNF defines the following access-info values: operator-specific-GI =3D "operator-specific-GI" EQUAL (toke= n / quoted-string) utran-sai-3gpp =3D "utran-sai-3gpp" EQUAL (token / qu= oted-string) However, they are currently not present in the access-info value list: access-info =3D cgi-3gpp / utran-cell-id-3gpp / dsl-location / i-wlan-node-id / ci-3gpp2 / eth-location / ci-3gpp2-femto / fiber-location / np / gstn-location /local-time-zone / dvb-rcs2-node-id / extension-access-info ...should be: access-info =3D cgi-3gpp / utran-cell-id-3gpp / dsl-location / i-wlan-node-id / ci-3gpp2 / eth-location / ci-3gpp2-femto / fiber-location / np / gstn-location /local-time-zone / dvb-rcs2-node-id / operator-specific-GI / utran-sai-3gpp / extension-access-info My suggestion is to make this fix in draft-holmberg-dispatch-pani-abnf, tog= ether with the other fix. Does anyone have an issue with that? None. This seems like the logical place to address both issues. Gonzalo Regards, Christer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_B2995B9A0EEC4E56B24BED44B358EFCDciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One additional PANI ABNF issue has been identified.<= o:p>

 

The ABNF defines the following access-info values= :

 

         =      operator-specific-GI   =3D "operato= r-specific-GI" EQUAL (token /  quoted-string)

         =      utran-sai-3gpp      =    =3D "utran-sai-3gpp" EQUAL (token / quoted-string)

 

However, they are currently not present in the ac= cess-info value list:

 

       access-info&= nbsp;           =3D cgi-3= gpp / utran-cell-id-3gpp /

        &= nbsp;           &nbs= p;           dsl-location= / i-wlan-node-id /

        &= nbsp;           &nbs= p;           ci-3gpp2 / e= th-location /

        &= nbsp;           &nbs= p;           ci-3gpp2-fem= to / fiber-location /

        &= nbsp;           &nbs= p;           np / gstn-lo= cation /local-time-zone /

        &= nbsp;           &nbs= p;           dvb-rcs2-nod= e-id /  extension-access-info

 

...should be:

 

       access-info&= nbsp;           =3D cgi-3= gpp / utran-cell-id-3gpp /

        &= nbsp;           &nbs= p;           dsl-location= / i-wlan-node-id /

        &= nbsp;           &nbs= p;           ci-3gpp2 / e= th-location /

        &= nbsp;           &nbs= p;           ci-3gpp2-fem= to / fiber-location /

        &= nbsp;           &nbs= p;           np / gstn-lo= cation /local-time-zone /

        &= nbsp;           &nbs= p;           dvb-rcs2-nod= e-id / operator-specific-GI  /

         =             &nb= sp;          utran-sai-3g= pp / extension-access-info

 

My suggestion is to make this fix in draft-holmbe= rg-dispatch-pani-abnf, together with the other fix.

 

Does anyone have an issue with that?


None.  This seems like the logical place to address both issues.

Gonzalo

 

Regards,

 

Christer

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_B2995B9A0EEC4E56B24BED44B358EFCDciscocom_-- From nobody Thu Apr 7 10:37:45 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23612D55E for ; Thu, 7 Apr 2016 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 s_cmXS4cR_CH for ; Thu, 7 Apr 2016 10:37:42 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B6E12D1A3 for ; Thu, 7 Apr 2016 10:37:39 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by comcast with SMTP id oDp5ad7h4d826oDsBazdC6; Thu, 07 Apr 2016 17:37:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460050659; bh=cjbZ/vgvZ+yngePfZSXUIsk6x1KkT/gA6iCQRPeuYu0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=leTXPlcyltzvq8r6qF+i5AbttO5ID3F+YQ3cK5F5/w4kdYqf9SlNElZtXNXnefy+L yeeKc+EI+JZSFX+p38Zhw87mtIqTIwed7KTZmKmmZ8wjOtOtcmLjbxZJZXFFiO7tya WtTxDNFYCxMJctocz/bsPSf1GEWdvSI+pM9H8w6KJwkv4hX7s9HjZxgHXbi08mkwTt oOufVPYpnm7bO2BumWEd2WADeip2AwemPCFoWu7F2Ap9mz3Ri+OKaeuEUGq866CcJ/ eZzl0DqsUrPwpFmCpQdsBMrqi8VT/oWgGyS2j4cPJ6CL0YkG5Sem0k0pcX0bj5Zhrf GqVN6WXtqafxA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-08v.sys.comcast.net with comcast id fVdd1s00P1nMCLR01VdeVG; Thu, 07 Apr 2016 17:37:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u37HbbvV016057; Thu, 7 Apr 2016 13:37:37 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u37HbaPQ016049; Thu, 7 Apr 2016 13:37:36 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: =?utf-8?Q?J=C3=B6rgen?= Axell In-Reply-To: <5AEA7B339C0B944BB33A6939249264AD1DABD2DB@ESESSMB305.ericsson.se> (jorgen.axell@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 07 Apr 2016 13:37:36 -0400 Message-ID: <87k2k9tj4v.fsf@hobgoblin.ariadne.com> Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace - Improve namespace name? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:37:43 -0000 J\"orgen Axell writes: > Thanks, that should be possible to do. They will be spelled out > explicitly also on request from Mary. The numbering was chosen > following the style in the definitions in RFC 5478. I have no objection to having two namespaces differentiated solely by a number. But I realized that if I tried to work with them, I would be constantly asking myself which one was queued and which was preemptive. (All 40 of 5478's its namespaces are preemptive.) Dale From nobody Fri Apr 8 13:30:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C5312D675 for ; Fri, 8 Apr 2016 13:30:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 31DDj--uLIJO for ; Fri, 8 Apr 2016 13:30:29 -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 76A3912D5FA for ; Fri, 8 Apr 2016 13:30:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-4b-570814e3fadc Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.E8.23401.3E418075; Fri, 8 Apr 2016 22:30:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 22:29:55 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: Draft new version: draft-holmberg-dispatch-pani-abnf-03 Thread-Index: AdGR1UEbgehCsKwmRo+Kz+Ms6I61Rw== Date: Fri, 8 Apr 2016 20:29:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F2BFE5@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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F2BFE5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdV/exCEe4wZePihbzO0+zWyydtIDV gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mp4cs6w4LhYRdeLK4wNjH+Euxg5OSQETCRu nJjPBmGLSVy4tx7I5uIQEjjCKHHkyVl2CGcRo8TbnweAMhwcbAIWEt3/tEEaRAS0JY6u6mIG sZkFlCT2bT/CCmILCzhKzPn1lBGixk2i/d4UNghbT6Lj0mewehYBFYmlFxcygYzkFfCVuDDL BSTMCHTD91NrmCBGikvcejKfCeI2AYkle84zQ9iiEi8f/2OFsJUkVmy/xAhRny/ROq0dzOYV EJQ4OfMJywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpc nJtuZKSXWpSZXFycn6eXl1qyiREYOwe3/LbawXjwueMhRgEORiUe3gUC7OFCrIllxZW5hxgl OJiVRHg9eDjChXhTEiurUovy44tKc1KLDzFKc7AoifPmRP4LExJITyxJzU5NLUgtgskycXBK NTAGXjK98S90jZ+J0z45cftXs6X+nvjFneu8WuqLT+OFc0pNB/8mLMzcvbyv/mFGr+xNhs5T fXM/3/1ttcfp9aqaTqNqbQen+MMXWOvTfBryVtxmOsZ3+Ei0wNMVhzeKzez+dKupS3ad23v9 /nUGFj+rxWQybI+KZnjay7v1bZ7uvc1qj41Y+00lluKMREMt5qLiRABAdHB7mQIAAA== Archived-At: Cc: Ben Campbell Subject: [dispatch] Draft new version: draft-holmberg-dispatch-pani-abnf-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 20:30:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F2BFE5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-03) of draft-holmberg-dispatch-pani-abnf. I= t now includes the additional PANI ABNF fix mentioned earlier, and a couple= of editorial fixes based on comments from Ben. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F2BFE5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-03) of  dr= aft-holmberg-dispatch-pani-abnf. It now includes the additional PANI ABNF f= ix mentioned earlier, and a couple of editorial fixes based on comments fro= m Ben.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37F2BFE5ESESSMB209erics_-- From nobody Wed Apr 13 14:56:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6948312E28D for ; Wed, 13 Apr 2016 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 K5XyRY5ENAgl for ; Wed, 13 Apr 2016 14:56:33 -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 191ED12E284 for ; Wed, 13 Apr 2016 14:56:33 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3DLuSmS098412 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2016 16:56:29 -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.10] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 13 Apr 2016 16:56:28 -0500 Message-ID: <5C8FCEE4-A25B-48A3-90B7-170AA6EF2DF9@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F2BFE5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F2BFE5@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Draft new version: draft-holmberg-dispatch-pani-abnf-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:56:34 -0000 Thanks! I put this on the agenda for the May 5 IESG telechat. Ben. On 8 Apr 2016, at 15:29, Christer Holmberg wrote: > Hi, > > I've submitted a new version (-03) of > draft-holmberg-dispatch-pani-abnf. It now includes the additional PANI > ABNF fix mentioned earlier, and a couple of editorial fixes based on > comments from Ben. > > Regards, > > Christer > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 20 08:59:25 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6047312D83C for ; Wed, 20 Apr 2016 08:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 gQaZQrwZlQWY for ; Wed, 20 Apr 2016 08:59:20 -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 579FD12D1BE for ; Wed, 20 Apr 2016 08:59:20 -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.2/8.14.9) with ESMTPSA id u3KFxF8R084643 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Apr 2016 10:59:16 -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 To: "A. Jean Mahoney" , dispatch@ietf.org References: <56DDDFCD.5040604@nostrum.com> From: Adam Roach Message-ID: <5717A753.3050903@nostrum.com> Date: Wed, 20 Apr 2016 10:59:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <56DDDFCD.5040604@nostrum.com> Content-Type: multipart/alternative; boundary="------------040406020101050905060108" Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:59:22 -0000 This is a multi-part message in MIME format. --------------040406020101050905060108 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I apologize for the delay in responding here -- due to total mailing list volume, I do not read the DISPATCH list exhaustively, and this request for review was not brought to my attention until late last week. There is a mishandling of ACK in this draft that I need to block it on, but I think it can be remedied very easily. > o P-Access-Network-Info: Add statement that the header field can > appear in the SIP ACK method. > > o P-Charging-Vector: Add statement that the header field can appear > in the SIP ACK method. These should say "SIP ACK method, but only when sent to acknowledge a 2XX-class response." Since ACKs for non-2XX responses are processed hop-by-hop, you cannot include any information in them (for the same reason you can't put information in CANCEL requests). And so... > P-Access-Network-Info header field can appear in all SIP methods > and responses, except in CANCEL methods and CANCEL responses. > The P-Charging-Vector header field can appear in all SIP methods and > responses, except in CANCEL methods and CANCEL responses ...becomes something like: "P-Access-Network-Info and P-Charging-Vector header fields can appear in all SIP methods and responses, except in CANCEL methods, CANCEL responses, and ACK methods that acknowledge non-2xx responses." One additional review note that does not affect my expert review (treat it as a last-call comment): > Add statement that the P-Visited- > Network-ID header field cannot appear in the SIP NOTIFY, PRACK, > INFO and UPDATE methods. It seems to me that it would be significantly more future proof to phase this as "...cannot appear in mid-dialog requests," as that appears to be the intention. The revised text then becomes something like: "The P-Visited-Network-ID header field can appear in all SIP methods except ACK and CANCEL; however, it cannot be sent in any mid-dialog requests." /a On 3/7/16 14:08, A. Jean Mahoney wrote: > Since this draft updates RFC 7315, which required expert review of its > header fields, Adam Roach will be conducting an expert review of this > draft according to the guidance given in RFC 5727. > > Thanks, > > Jean > > > On 3/7/16 9:33 AM, Mary Barnes wrote: >> Hi folks, >> >> This document has been proposed to be progressed as AD sponsored: >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ >> >> The document has been carefully reviewed and it is now ready to move >> forward - Jean Mahoney is the shepherd. >> >> I don't anticipate anyone would have concerns about this decision, given >> that's how RFC 7315 was progressed and this update has actually been >> much more carefully reviewed. However, f anyone has any final comments, >> please post no later than Friday, March 11th, 2016. Note, that you will >> also still have IETF LC to provide any comments. >> >> Regards, >> Mary. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------040406020101050905060108 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I apologize for the delay in responding here -- due to total mailing list volume, I do not read the DISPATCH list exhaustively, and this request for review was not brought to my attention until late last week.


There is a mishandling of ACK in this draft that I need to block it on, but I think it can be remedied very easily.

   o  P-Access-Network-Info: Add statement that the header field can
      appear in the SIP ACK method.

   o  P-Charging-Vector: Add statement that the header field can appear
      in the SIP ACK method.

These should say "SIP ACK method, but only when sent to acknowledge a 2XX-class response."

Since ACKs for non-2XX responses are processed hop-by-hop, you cannot include any information in them (for the same reason you can't put information in CANCEL requests). And so...

   P-Access-Network-Info header field can appear in all SIP methods
   and responses, except in CANCEL methods and CANCEL responses.
   The P-Charging-Vector header field can appear in all SIP methods and
   responses, except in CANCEL methods and CANCEL responses

...becomes something like: "P-Access-Network-Info and P-Charging-Vector header fields can appear in all SIP methods and responses, except in CANCEL methods, CANCEL responses, and ACK methods that acknowledge non-2xx responses."



One additional review note that does not affect my expert review (treat it as a last-call comment):

      Add statement that the P-Visited-
      Network-ID header field cannot appear in the SIP NOTIFY, PRACK,
      INFO and UPDATE methods.

It seems to me that it would be significantly more future proof to phase this as "...cannot appear in mid-dialog requests," as that appears to be the intention. The revised text then becomes something like: "The P-Visited-Network-ID header field can appear in all SIP methods except ACK and CANCEL; however, it cannot be sent in any mid-dialog requests."


/a



On 3/7/16 14:08, A. Jean Mahoney wrote:
Since this draft updates RFC 7315, which required expert review of its header fields, Adam Roach will be conducting an expert review of this draft according to the guidance given in RFC 5727.

Thanks,

Jean


On 3/7/16 9:33 AM, Mary Barnes wrote:
Hi folks,

This document has been proposed to be progressed as AD sponsored:
https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/
The document has been carefully reviewed and it is now ready to move
forward - Jean Mahoney is the shepherd.

I don't anticipate anyone would have concerns about this decision, given
that's how RFC 7315 was progressed and this update has actually been
much more carefully reviewed.  However, f anyone has any final comments,
please post no later than Friday, March 11th, 2016.  Note, that you will
also still have IETF LC to provide any comments.

Regards,
Mary.


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


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

--------------040406020101050905060108-- From nobody Wed Apr 20 09:29:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B00612D63F for ; Wed, 20 Apr 2016 09:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 o-R8JzVWTh2k for ; Wed, 20 Apr 2016 09:29:40 -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 E8E1212DB2F for ; Wed, 20 Apr 2016 09:29:39 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-38-5717ae720e64 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.80.12926.27EA7175; Wed, 20 Apr 2016 18:29:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Wed, 20 Apr 2016 18:29:23 +0200 From: Christer Holmberg To: Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1A= Date: Wed, 20 Apr 2016 16:29:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> In-Reply-To: <5717A753.3050903@nostrum.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7q27ROvFwg9vfxCz2/F3EbrF00gJW i4bOlawOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8bU1g7mgi9KFU8vnWFsYGxQ6mLk 5JAQMJGY2/SVEcIWk7hwbz1bFyMXh5DAEUaJeU1rWEASQgJLGCWW7PXsYuTgYBOwkOj+pw0S FhEolXh76jEriC0sECuxc+1GZoh4nMTFxvtsELaVRPuK62BjWARUJSY2/GACsXkFfCW2fpvD CrFrAqPE8c/XwAZxCmhLPNjwE+wgRqCDvp9aA9bALCAucevJfCaIQwUkluw5zwxhi0q8fPyP FcJWklh0+zMTyJ3MApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCy rGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjJaDW36r7mC8/MbxEKMAB6MSD29Ct3i4EGti WXFl7iFGCQ5mJRHeriVAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzZkf/ChATSE0tSs1NTC1KL YLJMHJxSDYzuCz+lhBnqd3KfnNIVO1sv3DggpuqKnFL2ARf3SRPLIiZNks2+o/ayPIfD8YNg 9V6e1oq7KbOVxfOzmFIdCw+9u2eRGCb6cK6IvK/m+t9aCQ+7dY4u7rjheCM+RPre/x0dP3aW G1Rp3xaWfuCs8OHTvatnpSLn8GQ8ybuqkL1XxdLa/zaroBJLcUaioRZzUXEiAH6GMiGSAgAA Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:29:42 -0000 SGkgQWRhbSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBTZWUgaW5saW5lLg0KDQo+VGhl cmUgaXMgYSBtaXNoYW5kbGluZyBvZiBBQ0sgaW4gdGhpcyBkcmFmdCB0aGF0IEkgbmVlZCB0byBi bG9jayBpdCBvbiwgYnV0IEkgdGhpbmsgaXQgY2FuIGJlIHJlbWVkaWVkIHZlcnkgZWFzaWx5Lg0K Pg0KPg0KPsKgwqAgb8KgIFAtQWNjZXNzLU5ldHdvcmstSW5mbzogQWRkIHN0YXRlbWVudCB0aGF0 IHRoZSBoZWFkZXIgZmllbGQgY2FuDQo+wqDCoMKgwqDCoCBhcHBlYXIgaW4gdGhlIFNJUCBBQ0sg bWV0aG9kLg0KPg0KPsKgwqAgb8KgIFAtQ2hhcmdpbmctVmVjdG9yOiBBZGQgc3RhdGVtZW50IHRo YXQgdGhlIGhlYWRlciBmaWVsZCBjYW4gYXBwZWFyDQo+wqDCoMKgwqDCoCBpbiB0aGUgU0lQIEFD SyBtZXRob2QuDQo+DQo+IFRoZXNlIHNob3VsZCBzYXkgIlNJUCBBQ0sgbWV0aG9kLCBidXQgb25s eSB3aGVuIHNlbnQgdG8gYWNrbm93bGVkZ2UgYSAyWFgtY2xhc3MgcmVzcG9uc2UuIg0KPg0KPiBT aW5jZSBBQ0tzIGZvciBub24tMlhYIHJlc3BvbnNlcyBhcmUgcHJvY2Vzc2VkIGhvcC1ieS1ob3As IHlvdSBjYW5ub3QgaW5jbHVkZSBhbnkgaW5mb3JtYXRpb24gaW4gdGhlbSAoZm9yIHRoZSBzYW1l IHJlYXNvbiB5b3UgY2FuJ3QgcHV0IGluZm9ybWF0aW9uIGluIENBTkNFTCByZXF1ZXN0cykuIEFu ZCBzby4uLg0KDQpJIGFncmVlLiBJJ2xsIGZpeCBhcyBzdWdnZXN0ZWQuDQoNCi0tLS0tLS0NCg0K PsKgwqAgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciBmaWVsZCBjYW4gYXBwZWFyIGluIGFs bCBTSVAgbWV0aG9kcw0KPsKgwqAgYW5kIHJlc3BvbnNlcywgZXhjZXB0IGluIENBTkNFTCBtZXRo b2RzIGFuZCBDQU5DRUwgcmVzcG9uc2VzLg0KPsKgwqAgVGhlIFAtQ2hhcmdpbmctVmVjdG9yIGhl YWRlciBmaWVsZCBjYW4gYXBwZWFyIGluIGFsbCBTSVAgbWV0aG9kcyBhbmQNCj7CoMKgIHJlc3Bv bnNlcywgZXhjZXB0IGluIENBTkNFTCBtZXRob2RzIGFuZCBDQU5DRUwgcmVzcG9uc2VzDQo+DQo+ IC4uLmJlY29tZXMgc29tZXRoaW5nIGxpa2U6ICJQLUFjY2Vzcy1OZXR3b3JrLUluZm8gYW5kIFAt Q2hhcmdpbmctVmVjdG9yIGhlYWRlciBmaWVsZHMgY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhv ZHMgYW5kIHJlc3BvbnNlcywgZXhjZXB0IGluIA0KPiBDQU5DRUwgbWV0aG9kcywgQ0FOQ0VMIHJl c3BvbnNlcywgYW5kIEFDSyBtZXRob2RzIHRoYXQgYWNrbm93bGVkZ2Ugbm9uLTJ4eCByZXNwb25z ZXMuIg0KDQpDb3JyZWN0LiBJJ2xsIGZpeCBhcyBzdWdnZXN0ZWQuDQoNCi0tLS0tLQ0KDQo+IE9u ZSBhZGRpdGlvbmFsIHJldmlldyBub3RlIHRoYXQgZG9lcyBub3QgYWZmZWN0IG15IGV4cGVydCBy ZXZpZXcgKHRyZWF0IGl0IGFzIGEgbGFzdC1jYWxsIGNvbW1lbnQpOg0KPg0KPg0KPsKgwqDCoMKg ICBBZGQgc3RhdGVtZW50IHRoYXQgdGhlIFAtVmlzaXRlZC1OZXR3b3JrLUlEIGhlYWRlciBmaWVs ZCBjYW5ub3QgYXBwZWFyIGluIHRoZSBTSVAgTk9USUZZLCBQUkFDSywNCj7CoMKgwqDCoMKgIElO Rk8gYW5kIFVQREFURSBtZXRob2RzLg0KPg0KPiBJdCBzZWVtcyB0byBtZSB0aGF0IGl0IHdvdWxk IGJlIHNpZ25pZmljYW50bHkgbW9yZSBmdXR1cmUgcHJvb2YgdG8gcGhhc2UgdGhpcyBhcyAiLi4u Y2Fubm90IGFwcGVhciBpbiBtaWQtZGlhbG9nIHJlcXVlc3RzLCIgYXMgdGhhdCANCj4gYXBwZWFy cyB0byBiZSB0aGUgaW50ZW50aW9uLiBUaGUgcmV2aXNlZCB0ZXh0IHRoZW4gYmVjb21lcyBzb21l dGhpbmcgbGlrZTogIlRoZSBQLVZpc2l0ZWQtTmV0d29yay1JRCBoZWFkZXIgZmllbGQgY2FuIGFw cGVhciBpbiBhbGwgDQo+IFNJUCBtZXRob2RzIGV4Y2VwdCBBQ0sgYW5kIENBTkNFTDsgaG93ZXZl ciwgaXQgY2Fubm90IGJlIHNlbnQgaW4gYW55IG1pZC1kaWFsb2cgcmVxdWVzdHMuIg0KDQpTZWVt cyByZWFzb25hYmxlLCBidXQgSSdsbCB2ZXJpZnkgd2l0aCBteSAzR1BQIGRlbGVnYXRlcy4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIDMvNy8xNiAxNDowOCwgQS4gSmVhbiBNYWhv bmV5IHdyb3RlOg0KU2luY2UgdGhpcyBkcmFmdCB1cGRhdGVzIFJGQyA3MzE1LCB3aGljaCByZXF1 aXJlZCBleHBlcnQgcmV2aWV3IG9mIGl0cyBoZWFkZXIgZmllbGRzLCBBZGFtIFJvYWNoIHdpbGwg YmUgY29uZHVjdGluZyBhbiBleHBlcnQgcmV2aWV3IG9mIHRoaXMgZHJhZnQgYWNjb3JkaW5nIHRv IHRoZSBndWlkYW5jZSBnaXZlbiBpbiBSRkMgNTcyNy4gDQoNClRoYW5rcywgDQoNCkplYW4gDQoN Cg0KT24gMy83LzE2IDk6MzMgQU0sIE1hcnkgQmFybmVzIHdyb3RlOiANCg0KSGkgZm9sa3MsIA0K DQpUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHByb3Bvc2VkIHRvIGJlIHByb2dyZXNzZWQgYXMgQUQg c3BvbnNvcmVkOiANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhvbG1i ZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy8gDQpUaGUgZG9jdW1lbnQgaGFzIGJlZW4gY2Fy ZWZ1bGx5IHJldmlld2VkIGFuZCBpdCBpcyBub3cgcmVhZHkgdG8gbW92ZSANCmZvcndhcmQgLSBK ZWFuIE1haG9uZXkgaXMgdGhlIHNoZXBoZXJkLiANCg0KSSBkb24ndCBhbnRpY2lwYXRlIGFueW9u ZSB3b3VsZCBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMgZGVjaXNpb24sIGdpdmVuIA0KdGhhdCdz IGhvdyBSRkMgNzMxNSB3YXMgcHJvZ3Jlc3NlZCBhbmQgdGhpcyB1cGRhdGUgaGFzIGFjdHVhbGx5 IGJlZW4gDQptdWNoIG1vcmUgY2FyZWZ1bGx5IHJldmlld2VkLsKgIEhvd2V2ZXIsIGYgYW55b25l IGhhcyBhbnkgZmluYWwgY29tbWVudHMsIA0KcGxlYXNlIHBvc3Qgbm8gbGF0ZXIgdGhhbiBGcmlk YXksIE1hcmNoIDExdGgsIDIwMTYuwqAgTm90ZSwgdGhhdCB5b3Ugd2lsbCANCmFsc28gc3RpbGwg aGF2ZSBJRVRGIExDIHRvIHByb3ZpZGUgYW55IGNvbW1lbnRzLiANCg0KUmVnYXJkcywgDQpNYXJ5 LiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAN CmRpc3BhdGNoIG1haWxpbmcgbGlzdCANCmRpc3BhdGNoQGlldGYub3JnIA0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaCANCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QgDQpk aXNwYXRjaEBpZXRmLm9yZyANCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGlzcGF0Y2ggDQoNCg== From nobody Thu Apr 21 12:43:34 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8657412E5F3 for ; Thu, 21 Apr 2016 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lpd3i4w1CxSM for ; Thu, 21 Apr 2016 12:43:30 -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 1BD2512E6B5 for ; Thu, 21 Apr 2016 12:43:27 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-29-57192d5dffe3 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.20.16963.D5D29175; Thu, 21 Apr 2016 21:43:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Thu, 21 Apr 2016 21:43:08 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14A== Date: Thu, 21 Apr 2016 19:43:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F6D05B@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdWjdWVzLcoOO/lcWev4vYLZZOWsBq 0dC5ktWB2WPJkp9MHrN2PmEJYIrisklJzcksSy3St0vgyvj9aCV7wTnZis8HTrE2ML6R6WLk 5JAQMJFYc/geE4QtJnHh3nq2LkYuDiGBI4wSy7o72SGcJYwSxy7cZ+5i5OBgE7CQ6P6nDRIX EVjNKHH/0j0WkG5hgViJnWs3MoPYIgJxEhcb77NB2E4Sf0+8AYuzCKhKPFt1jRHE5hXwlXj+ 7R0jxIIrjBKfNj9kBFnAKeAn8WBtBEgNI9BF30+tAbuOWUBc4taT+VCXCkgs2XOeGcIWlXj5 +B8rhK0ksfbwdhaQMcwCmhLrd+lDtCpKTOl+yA6xVlDi5MwnLBMYRWchmToLoWMWko5ZSDoW MLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMl4NbflvtYDz43PEQowAHoxIPr4KJRLgQ a2JZcWXuIUYJDmYlEV4bbclwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rw5kf/ChATSE0tSs1NT C1KLYLJMHJxSDYzOPy6I/DJfYJ25jSdP4nM9n2O1za2M1q0PubWSU3R9blxtfJS8nvP8+4t+ hpJKybetD/zN6mUW3RNbvUIsxPHdinlZjidkjrUxzGH8FMnmyb98euJesR/T4gLTmbfyz5Gb /etpbMtMlenpTX1q++Yf55iRelOzc+OC2NPijHxTMxqKL32OXKLEUpyRaKjFXFScCAC6uBKP kwIAAA== Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 19:43:32 -0000 SGkgQWRhbSwNCg0KLi4uLg0KDQo+PiBPbmUgYWRkaXRpb25hbCByZXZpZXcgbm90ZSB0aGF0IGRv ZXMgbm90IGFmZmVjdCBteSBleHBlcnQgcmV2aWV3ICh0cmVhdCBpdCBhcyBhIGxhc3QtY2FsbCBj b21tZW50KToNCj4+DQo+Pg0KPj7CoMKgwqDCoCAgQWRkIHN0YXRlbWVudCB0aGF0IHRoZSBQLVZp c2l0ZWQtTmV0d29yay1JRCBoZWFkZXIgZmllbGQgY2Fubm90IA0KPj4gICAgICBhcHBlYXIgaW4g dGhlIFNJUCBOT1RJRlksIFBSQUNLLCBJTkZPIGFuZCBVUERBVEUgbWV0aG9kcy4NCj4+DQo+PiBJ dCBzZWVtcyB0byBtZSB0aGF0IGl0IHdvdWxkIGJlIHNpZ25pZmljYW50bHkgbW9yZSBmdXR1cmUg cHJvb2YgdG8gDQo+PiBwaGFzZSB0aGlzIGFzICIuLi5jYW5ub3QgYXBwZWFyIGluIG1pZC1kaWFs b2cgcmVxdWVzdHMsIiBhcyB0aGF0IA0KPj4gYXBwZWFycyB0byBiZSB0aGUgaW50ZW50aW9uLiBU aGUgcmV2aXNlZCB0ZXh0IHRoZW4gYmVjb21lcyBzb21ldGhpbmcgbGlrZTogIlRoZSBQLVZpc2l0 ZWQtTmV0d29yay1JRCBoZWFkZXIgDQo+PiBmaWVsZCBjYW4gYXBwZWFyIGluIGFsbCBTSVAgbWV0 aG9kcyBleGNlcHQgQUNLIGFuZCBDQU5DRUw7IGhvd2V2ZXIsIGl0IGNhbm5vdCBiZSBzZW50IGlu ID5hbnkgbWlkLWRpYWxvZyByZXF1ZXN0cy4iDQo+DQo+IFNlZW1zIHJlYXNvbmFibGUsIGJ1dCBJ J2xsIHZlcmlmeSB3aXRoIG15IDNHUFAgZGVsZWdhdGVzLg0KDQpJIGhhZCBhIGNsb3NlciBsb29r IGF0IHRoaXMsIGFuZCBJIGRvbid0IHRoaW5rIHdlIGNhbiBmb3JiaWQgdXNhZ2UgaW4gYWxsIG1p ZC1kaWFsb2cgcmVxdWVzdHMuDQoNCkZvciBleGFtcGxlLCB0aGUgaGVhZGVyIGZpZWxkIGlzIGFs bG93ZWQgaW4gT1BUSU9OUywgdGhhdCBjYW4gYmUgc2VudCBpbi1kaWFsb2cuDQoNCkFsc28sIHRo ZSBoZWFkZXIgZmllbGQgaXMgYWxsb3dlZCBpbiBSRUZFUiwgYW5kIFJGQyA3NjE0IGRlZmluZXMg YSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgaW4tZGlhbG9nIFJFRkVScy4NCg0KcmUtSU5WSVRFIGlz IGFsc28gdHJpY2t5LiBUaGUgaGVhZGVyIGZpZWxkIGlzIGdlbmVyYWxseSBhbGxvd2VkIGluIElO VklURSByZXF1ZXN0cywgYnV0IHRoZXJlIGlzIG5vIHRleHQgZXhwbGljaXRseSBkaXNhbGxvd2lu ZyBpdCBpbiByZS1JTlZJVEVzLg0KDQpXaGV0aGVyIGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUg dGhlIGhlYWRlciBmaWVsZCBpbiB0aGUgbWV0aG9kcyBhYm92ZSBJIGRvbid0IGtub3cgKDNHUFAg ZG9lcyBhbGxvdyB0aGVtKSwgYnV0IGFzIHRoZSBwdXJwb3NlIGlzIG9ubHkgdG8gYWxpZ24gNzMx NSB3aXRoIDM0NTUgSSdkIHN1Z2dlc3Qgd2Uga2VlcCB0aGUgdGV4dCBhcyBpdCBpcy4NCg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KDQpPbiAzLzcvMTYgMTQ6MDgsIEEuIEpl YW4gTWFob25leSB3cm90ZToNClNpbmNlIHRoaXMgZHJhZnQgdXBkYXRlcyBSRkMgNzMxNSwgd2hp Y2ggcmVxdWlyZWQgZXhwZXJ0IHJldmlldyBvZiBpdHMgaGVhZGVyIGZpZWxkcywgQWRhbSBSb2Fj aCB3aWxsIGJlIGNvbmR1Y3RpbmcgYW4gZXhwZXJ0IHJldmlldyBvZiB0aGlzIGRyYWZ0IGFjY29y ZGluZyB0byB0aGUgZ3VpZGFuY2UgZ2l2ZW4gaW4gUkZDIDU3MjcuIA0KDQpUaGFua3MsIA0KDQpK ZWFuIA0KDQoNCk9uIDMvNy8xNiA5OjMzIEFNLCBNYXJ5IEJhcm5lcyB3cm90ZTogDQoNCkhpIGZv bGtzLCANCg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcm9wb3NlZCB0byBiZSBwcm9ncmVzc2Vk IGFzIEFEIHNwb25zb3JlZDogDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMvDQpUaGUgZG9jdW1lbnQgaGFzIGJl ZW4gY2FyZWZ1bGx5IHJldmlld2VkIGFuZCBpdCBpcyBub3cgcmVhZHkgdG8gbW92ZSBmb3J3YXJk IC0gSmVhbiBNYWhvbmV5IGlzIHRoZSBzaGVwaGVyZC4gDQoNCkkgZG9uJ3QgYW50aWNpcGF0ZSBh bnlvbmUgd291bGQgaGF2ZSBjb25jZXJucyBhYm91dCB0aGlzIGRlY2lzaW9uLCBnaXZlbiB0aGF0 J3MgaG93IFJGQyA3MzE1IHdhcyBwcm9ncmVzc2VkIGFuZCB0aGlzIHVwZGF0ZSBoYXMgYWN0dWFs bHkgYmVlbiBtdWNoIG1vcmUgY2FyZWZ1bGx5IHJldmlld2VkLsKgIEhvd2V2ZXIsIGYgYW55b25l IGhhcyBhbnkgZmluYWwgY29tbWVudHMsIHBsZWFzZSBwb3N0IG5vIGxhdGVyIHRoYW4gRnJpZGF5 LCBNYXJjaCAxMXRoLCAyMDE2LsKgIE5vdGUsIHRoYXQgeW91IHdpbGwgYWxzbyBzdGlsbCBoYXZl IElFVEYgTEMgdG8gcHJvdmlkZSBhbnkgY29tbWVudHMuIA0KDQpSZWdhcmRzLA0KTWFyeS4gDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQpkaXNw YXRjaCBtYWlsaW5nIGxpc3QgDQpkaXNwYXRjaEBpZXRmLm9yZyANCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2ggDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIA0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0IA0KZGlzcGF0 Y2hAaWV0Zi5vcmcgDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3Bh dGNoIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From nobody Mon Apr 25 04:30:34 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25C12D183 for ; Mon, 25 Apr 2016 04:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ubh0xsiWXu3D for ; Mon, 25 Apr 2016 04:30:31 -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 6123F12B04C for ; Mon, 25 Apr 2016 04:30:31 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-ed-571dffd5113b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 45.ED.12926.5DFFD175; Mon, 25 Apr 2016 13:30:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 13:30:29 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14IAF08iA Date: Mon, 25 Apr 2016 11:30:28 +0000 Message-ID: References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7pe7V/7LhBmfuaVrs+buI3WLppAWs Fg2dK1kdmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsErox7626wFDwSr7i1cRVjA+M64S5G Dg4JAROJI1Mcuhg5gUwxiQv31rN1MXJxCAkcYZTY8uI5I4SzhFFiXdsbZpAGNgELie5/2iBx EYHVjBL3L91jAekWFoiV2PFtBROILSIQJ3Gx8T4bhO0m8X7/K0YQm0VAVWLxhflgNq+AlcSd 02tYIBbMYJJ4euQuO0iCU8BPYlHnWzCbEeik76fWgA1lFhCXuPVkPhPEqQISS/acZ4awRSVe Pv7HCmKLCuhJ7HtxnhEirijx8dU+RoheHYkFuz+xQdjWEg0/drJC2NoSyxa+ZoY4SFDi5Mwn LBMYxWchWTcLSfssJO2zkLTPQtK+gJF1FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg7B3c 8lt1B+PlN46HGAU4GJV4eBdwyoYLsSaWFVfmHmKU4GBWEuEN+AQU4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzpsd+S9MSCA9sSQ1OzW1ILUIJsvEwSnVwBi8eY3MkrT7Sqf/pu9MnmRwukUvbGHJ pvrZB41EKzTlRRl2PT2XzG4xOUUzso1l/dv2O1KZBh/eC+0t2X1mT+mmVU/eWafK5erf4Kj6 krtAqPpg8l6RXyLZkvnNsf+lNq02dLkUqzPT68GLMP/6L18WTGLaoN3u/0L3b3DgBdc1T96K NIbWH1BiKc5INNRiLipOBAAbFkQfuQIAAA== Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 11:30:33 -0000 Hi Adam, Are you ok with my suggested way forward? Regards, Christer On 21/04/16 22:43, "Christer Holmberg" wrote: >Hi Adam, > >.... > >>> One additional review note that does not affect my expert review >>>(treat it as a last-call comment): >>> >>> >>> Add statement that the P-Visited-Network-ID header field cannot >>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>> >>> It seems to me that it would be significantly more future proof to >>> phase this as "...cannot appear in mid-dialog requests," as that >>> appears to be the intention. The revised text then becomes something >>>like: "The P-Visited-Network-ID header >>> field can appear in all SIP methods except ACK and CANCEL; however, it >>>cannot be sent in >any mid-dialog requests." >> >> Seems reasonable, but I'll verify with my 3GPP delegates. > >I had a closer look at this, and I don't think we can forbid usage in all >mid-dialog requests. > >For example, the header field is allowed in OPTIONS, that can be sent >in-dialog. > >Also, the header field is allowed in REFER, and RFC 7614 defines a >mechanism that allows in-dialog REFERs. > >re-INVITE is also tricky. The header field is generally allowed in INVITE >requests, but there is no text explicitly disallowing it in re-INVITEs. > >Whether it makes sense to include the header field in the methods above I >don't know (3GPP does allow them), but as the purpose is only to align >7315 with 3455 I'd suggest we keep the text as it is. > > >Regards, > >Christer > > > > > > > >On 3/7/16 14:08, A. Jean Mahoney wrote: >Since this draft updates RFC 7315, which required expert review of its >header fields, Adam Roach will be conducting an expert review of this >draft according to the guidance given in RFC 5727. > >Thanks,=20 > >Jean=20 > > >On 3/7/16 9:33 AM, Mary Barnes wrote: > >Hi folks,=20 > >This document has been proposed to be progressed as AD sponsored: >https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ >The document has been carefully reviewed and it is now ready to move >forward - Jean Mahoney is the shepherd. > >I don't anticipate anyone would have concerns about this decision, given >that's how RFC 7315 was progressed and this update has actually been much >more carefully reviewed. However, f anyone has any final comments, >please post no later than Friday, March 11th, 2016. Note, that you will >also still have IETF LC to provide any comments. > >Regards, >Mary.=20 > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org=20 >https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org=20 >https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 27 06:07:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453A712D151 for ; Wed, 27 Apr 2016 06:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 bfstzB12lAfN for ; Wed, 27 Apr 2016 06:07:32 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7667B12D164 for ; Wed, 27 Apr 2016 06:02:18 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b0-5720b858434d Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 43.B1.27088.858B0275; Wed, 27 Apr 2016 15:02:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 15:01:23 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14IAF08iAgAM+FoA= Date: Wed, 27 Apr 2016 13:01:22 +0000 Message-ID: References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7jW7EDoVwg/ZNphZ7/i5it1g6aQGr RUPnSlYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK2PCih6Wgr9SFasm72duYOwQ62Lk 5JAQMJFYMreREcIWk7hwbz1bFyMXh5DAEUaJCbM/QDlLGCX2bjjA3sXIwcEmYCHR/U8bJC4i sJpR4v6leywg3cICsRI7vq1gArFFBOIkLjbeZ4Ow/STm7tjJDmKzCKhK/Jy9jxVkDq+AlcSC c0YQ808ySRz73MoMUsMpYC3xeslnsF5GoIu+n1oDNpNZQFzi1pP5TBCXCkgs2XOeGcIWlXj5 +B8riC0qoCex78V5qG8UJa5OXw7VqydxY+oUNgjbWuLc1F+sELa2xLKFr8Hm8AoISpyc+YRl AqP4LCTrZiFpn4WkfRaS9llI2hcwsq5iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIy9g1t+ G+xgfPnc8RCjAAejEg+vgqxCuBBrYllxZe4hRgkOZiUR3iXbgUK8KYmVValF+fFFpTmpxYcY pTlYlMR5syP/hQkJpCeWpGanphakFsFkmTg4pRoYDVQWvU8IfaJr9lnie7Tfq5wX6SH5KRab PAQ8F7EcOVnqc/2v6wurlea7dx9u3Jhm3sIf+2q/hWTSpvlGk3tm9jjfDD9Vm6p0VfqsXNRm sYPubP0Sz+6ejX96SOjDwkiDgIrNTYK/kjQkV99dlcLt336QZ5OjP19dq+f0OXNMZ8y98v/W 6Ud3lFiKMxINtZiLihMBwuhRdrkCAAA= Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:07:34 -0000 Hi, One more thing: I guess we could also change =B3all responses=B2 to =B3all non-100 response= s=B2, as 100 responses are also hop-to-hop (similar to ACKs triggered by non-2xx responses). Regards, Christer On 25/04/16 14:30, "Christer Holmberg" wrote: >Hi Adam, > >Are you ok with my suggested way forward? > >Regards, > >Christer > > > >On 21/04/16 22:43, "Christer Holmberg" >wrote: > >>Hi Adam, >> >>.... >> >>>> One additional review note that does not affect my expert review >>>>(treat it as a last-call comment): >>>> >>>> >>>> Add statement that the P-Visited-Network-ID header field cannot >>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>> >>>> It seems to me that it would be significantly more future proof to >>>> phase this as "...cannot appear in mid-dialog requests," as that >>>> appears to be the intention. The revised text then becomes something >>>>like: "The P-Visited-Network-ID header >>>> field can appear in all SIP methods except ACK and CANCEL; however, it >>>>cannot be sent in >any mid-dialog requests." >>> >>> Seems reasonable, but I'll verify with my 3GPP delegates. >> >>I had a closer look at this, and I don't think we can forbid usage in all >>mid-dialog requests. >> >>For example, the header field is allowed in OPTIONS, that can be sent >>in-dialog. >> >>Also, the header field is allowed in REFER, and RFC 7614 defines a >>mechanism that allows in-dialog REFERs. >> >>re-INVITE is also tricky. The header field is generally allowed in INVITE >>requests, but there is no text explicitly disallowing it in re-INVITEs. >> >>Whether it makes sense to include the header field in the methods above I >>don't know (3GPP does allow them), but as the purpose is only to align >>7315 with 3455 I'd suggest we keep the text as it is. >> >> >>Regards, >> >>Christer >> >> >> >> >> >> >> >>On 3/7/16 14:08, A. Jean Mahoney wrote: >>Since this draft updates RFC 7315, which required expert review of its >>header fields, Adam Roach will be conducting an expert review of this >>draft according to the guidance given in RFC 5727. >> >>Thanks,=20 >> >>Jean=20 >> >> >>On 3/7/16 9:33 AM, Mary Barnes wrote: >> >>Hi folks,=20 >> >>This document has been proposed to be progressed as AD sponsored: >>https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ >>The document has been carefully reviewed and it is now ready to move >>forward - Jean Mahoney is the shepherd. >> >>I don't anticipate anyone would have concerns about this decision, given >>that's how RFC 7315 was progressed and this update has actually been much >>more carefully reviewed. However, f anyone has any final comments, >>please post no later than Friday, March 11th, 2016. Note, that you will >>also still have IETF LC to provide any comments. >> >>Regards, >>Mary.=20 >> >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 27 06:21:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C863912D7FC for ; Wed, 27 Apr 2016 06:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 lZgMPwGioecC for ; Wed, 27 Apr 2016 06:20:58 -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 9223D12D812 for ; Wed, 27 Apr 2016 06:20:17 -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.2/8.14.9) with ESMTPSA id u3RDKAov000459 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Apr 2016 08:20:12 -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 To: Christer Holmberg , "A. Jean Mahoney" , "dispatch@ietf.org" References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> From: Adam Roach Message-ID: <5720BC8A.5060709@nostrum.com> Date: Wed, 27 Apr 2016 08:20:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:21:00 -0000 Sure -- my suggestion was one for clarification. If 3GPP does, in fact, intend to allow the header field in mid-dialog messages, then my comment doesn't apply. But if they *do* intend to allow the field mid-dialog, I'm curious about why it's forbidden in the current list of methods: save for some obscure corner cases, all of the methods called out by name are sent mid-dialog, and none of the un-named methods are. Either way, it's just a suggestion. The hard block here is in the ACK handling that I pointed out. /a On 4/27/16 08:01, Christer Holmberg wrote: > Hi, > > One more thing: > > I guess we could also change ³all responses² to ³all non-100 responses², > as 100 responses are also hop-to-hop (similar to ACKs triggered by non-2xx > responses). > > Regards, > > Christer > > > On 25/04/16 14:30, "Christer Holmberg" > wrote: > >> Hi Adam, >> >> Are you ok with my suggested way forward? >> >> Regards, >> >> Christer >> >> >> >> On 21/04/16 22:43, "Christer Holmberg" >> wrote: >> >>> Hi Adam, >>> >>> .... >>> >>>>> One additional review note that does not affect my expert review >>>>> (treat it as a last-call comment): >>>>> >>>>> >>>>> Add statement that the P-Visited-Network-ID header field cannot >>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>> >>>>> It seems to me that it would be significantly more future proof to >>>>> phase this as "...cannot appear in mid-dialog requests," as that >>>>> appears to be the intention. The revised text then becomes something >>>>> like: "The P-Visited-Network-ID header >>>>> field can appear in all SIP methods except ACK and CANCEL; however, it >>>>> cannot be sent in >any mid-dialog requests." >>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>> I had a closer look at this, and I don't think we can forbid usage in all >>> mid-dialog requests. >>> >>> For example, the header field is allowed in OPTIONS, that can be sent >>> in-dialog. >>> >>> Also, the header field is allowed in REFER, and RFC 7614 defines a >>> mechanism that allows in-dialog REFERs. >>> >>> re-INVITE is also tricky. The header field is generally allowed in INVITE >>> requests, but there is no text explicitly disallowing it in re-INVITEs. >>> >>> Whether it makes sense to include the header field in the methods above I >>> don't know (3GPP does allow them), but as the purpose is only to align >>> 7315 with 3455 I'd suggest we keep the text as it is. >>> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>> Since this draft updates RFC 7315, which required expert review of its >>> header fields, Adam Roach will be conducting an expert review of this >>> draft according to the guidance given in RFC 5727. >>> >>> Thanks, >>> >>> Jean >>> >>> >>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>> >>> Hi folks, >>> >>> This document has been proposed to be progressed as AD sponsored: >>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/ >>> The document has been carefully reviewed and it is now ready to move >>> forward - Jean Mahoney is the shepherd. >>> >>> I don't anticipate anyone would have concerns about this decision, given >>> that's how RFC 7315 was progressed and this update has actually been much >>> more carefully reviewed. However, f anyone has any final comments, >>> please post no later than Friday, March 11th, 2016. Note, that you will >>> also still have IETF LC to provide any comments. >>> >>> Regards, >>> Mary. >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 27 08:07:38 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D5E12D16B for ; Wed, 27 Apr 2016 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 M8ePbGpoAMst for ; Wed, 27 Apr 2016 08:07:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6F212D85B for ; Wed, 27 Apr 2016 08:07:29 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-9e-5720d5af3a46 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 01.99.27088.FA5D0275; Wed, 27 Apr 2016 17:07:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 17:07:27 +0200 From: Christer Holmberg To: Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14IAF08iAgAM+FoD//9KdAIAAUJsA Date: Wed, 27 Apr 2016 15:07:26 +0000 Message-ID: References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> <5720BC8A.5060709@nostrum.com> In-Reply-To: <5720BC8A.5060709@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="euc-kr" Content-ID: <5E1531BC18ED484EA155CBBA63233225@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7pe6GqwrhBgt+cFns+buI3WLppAWs Fg2dK1kdmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsErozWbyUFZ6wr/jV8YWpg7LDqYuTk kBAwkTj+ciobhC0mceHeeiCbi0NI4AijRMOfs+wQzhJGia6WU4xdjBwcbAIWEt3/tEEaRARK Jd6eeswKYgsLxErs+LaCCSIeJ3Gx8T4bhB0l8b39AVgNi4CqxKOZh5hBbF4BK4kPzSuhls1k ljh1cCbYfE4BbYmvm7lBahiBDvp+ag3YTGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf2DzRQX0 JPa9OA82RkJAUWJ5vxxEq5bElx/72CBsa4l73ZugbEWJKd0P2SHOEZQ4OfMJywRG8VlIts1C 0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYdQe3/DbYwfjyueMh RgEORiUeXgVZhXAh1sSy4srcQ4wSHMxKIryiwJgV4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsd +S9MSCA9sSQ1OzW1ILUIJsvEwSnVwMj0pteRKWbaui1KNataPx6488j4kg7vGWWN6kzPjz2z 77XO9F+7xUTO9V5/1Im3WwpMD53lCllonrg9V+X/rJR1jZvP6rslWSq5/3s2WeDFwVUnjjGG sJSVurutf9LB1f5Ww+mYzeGXHpcsDhaEvU/VY34XvilGZ/rlEuGkg9fe/ys96pHeZa7EUpyR aKjFXFScCACz/YWPtgIAAA== Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 15:07:37 -0000 SGksDQoNCj5TdXJlIC0tIG15IHN1Z2dlc3Rpb24gd2FzIG9uZSBmb3IgY2xhcmlmaWNhdGlvbi4g SWYgM0dQUCBkb2VzLCBpbiBmYWN0LA0KPmludGVuZCB0byBhbGxvdyB0aGUgaGVhZGVyIGZpZWxk IGluIG1pZC1kaWFsb2cgIG1lc3NhZ2VzLCB0aGVuIG15DQo+Y29tbWVudCBkb2Vzbid0IGFwcGx5 Lg0KPg0KPkJ1dCBpZiB0aGV5ICpkbyogaW50ZW5kIHRvIGFsbG93IHRoZSBmaWVsZCBtaWQtZGlh bG9nLCBJJ20gY3VyaW91cyBhYm91dA0KPndoeSBpdCdzIGZvcmJpZGRlbiBpbiB0aGUgY3VycmVu dCBsaXN0IG9mIG1ldGhvZHM6IHNhdmUgZm9yIHNvbWUgb2JzY3VyZQ0KPmNvcm5lciBjYXNlcywg YWxsIG9mIHRoZSBtZXRob2RzIGNhbGxlZCBvdXQgYnkgbmFtZSBhcmUgc2VudCBtaWQtZGlhbG9n LA0KPmFuZCBub25lIG9mIHRoZSB1bi1uYW1lZCBtZXRob2RzIGFyZS4NCg0KT1BUSU9OUywgQllF LCBSRUZFUiAod2l0aCBSRkM3NjE1KSBhbmQgcmUtSU5WSVRFIGNhbiBiZSBzZW50IGluLWRpYWxv Zy4NCg0KSSBjYW6hr3QgZ2l2ZSBhbiBhbnN3ZXIgaGVyZSBhbmQgbm93IHdoeSB0aGUgbGlzdCBs b29rcyBsaWtlIGl0IGRvZXMsIGJ1dA0KdGhpcyBpcyBob3cgaXShr3Mgc3BlY2lmaWVkIGluIDNH UFAgOikNCg0KPkVpdGhlciB3YXksIGl0J3MganVzdCBhIHN1Z2dlc3Rpb24uIFRoZSBoYXJkIGJs b2NrIGhlcmUgaXMgaW4gdGhlIEFDSw0KPmhhbmRsaW5nIHRoYXQgSSBwb2ludGVkIG91dC4NCg0K QmFzZWQgb24geW91ciBjb21tZW50cywgdGhlIG5ldyB0ZXh0IHdvdWxkIG5vdyBzYXk6DQoNCiAg ICJUaGUgUC1Bc3NvY2lhdGVkLVVSSSBoZWFkZXIgZmllbGQgY2FuIGFwcGVhciBpbiBTSVAgUkVH SVNURVINCiAgIDJ4eCByZXNwb25zZXMuIFRoZSBQLUNhbGxlZC1QYXJ0eS1JRCBoZWFkZXIgZmll bGQgY2FuIGFwcGVhciBpbg0KICAgU0lQIElOVklURSwgT1BUSU9OUywgUFVCTElTSCwgUkVGRVIs IFNVQlNDUklCRSwgYW5kIE1FU1NBR0UgbWV0aG9kcy4NCiAgIFRoZSBQLVZpc2l0ZWQtTmV0d29y ay1JRCBoZWFkZXIgZmllbGQgY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhvZHMNCiAgIGV4Y2Vw dCBBQ0ssIEJZRSwgQ0FOQ0VMLCBOT1RJRlksIFBSQUNLLCBJTkZPIGFuZCBVUERBVEUuIFRoZQ0K ICAgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciBmaWVsZCBjYW4gYXBwZWFyIGluIGFsbCBT SVAgbWV0aG9kcw0KICAgYW5kIG5vbi0xMDAgcmVzcG9uc2VzLCBleGNlcHQgaW4gQ0FOQ0VMIG1l dGhvZHMsIENBTkNFTCByZXNwb25zZXMNCiAgIGFuZCBBQ0sgbWV0aG9kcyB0cmlnZ2VyZWQgYnkg bm9uLTJ4eCByZXNwb25zZXMuIFRoZSBQLUNoYXJnaW5nLVZlY3Rvcg0KICAgaGVhZGVyIGZpZWxk IGNhbiBhcHBlYXIgaW4gYWxsIFNJUCBtZXRob2RzIGFuZCBub24tMTAwIHJlc3BvbnNlcywNCiAg IGV4Y2VwdCBpbiBDQU5DRUwgbWV0aG9kcywgQ0FOQ0VMIHJlc3BvbnNlcyBhbmQgQUNLIG1ldGhv ZHMgdHJpZ2dlcmVkDQogICBieSBub24tMnh4IHJlc3BvbnNlcy4gVGhlIFAtQ2hhcmdpbmctRnVu Y3Rpb24tQWRkcmVzc2VzIGhlYWRlciBmaWVsZA0KICAgY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1l dGhvZHMgYW5kIG5vbi0xMDAgcmVzcG9uc2VzLCBleGNlcHQgaW4gQUNLDQogICBhbmQgQ0FOQ0VM IG1ldGhvZHMgYW5kIENBTkNFTCByZXNwb25zZXMuobENCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KDQoNCg0KDQo+DQo+L2ENCj4NCj5PbiA0LzI3LzE2IDA4OjAxLCBDaHJpc3RlciBI b2xtYmVyZyB3cm90ZToNCj4+IEhpLA0KPj4NCj4+IE9uZSBtb3JlIHRoaW5nOg0KPj4NCj4+IEkg Z3Vlc3Mgd2UgY291bGQgYWxzbyBjaGFuZ2UgqfhhbGwgcmVzcG9uc2VzqfcgdG8gqfhhbGwgbm9u LTEwMCByZXNwb25zZXOp9ywNCj4+IGFzIDEwMCByZXNwb25zZXMgYXJlIGFsc28gaG9wLXRvLWhv cCAoc2ltaWxhciB0byBBQ0tzIHRyaWdnZXJlZCBieQ0KPj5ub24tMnh4DQo+PiByZXNwb25zZXMp Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4gT24gMjUvMDQv MTYgMTQ6MzAsICJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4NCj4+IHdyb3RlOg0KPj4NCj4+PiBIaSBBZGFtLA0KPj4+DQo+Pj4gQXJlIHlvdSBvayB3 aXRoIG15IHN1Z2dlc3RlZCB3YXkgZm9yd2FyZD8NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4NCj4+ PiBDaHJpc3Rlcg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIDIxLzA0LzE2IDIyOjQzLCAiQ2hyaXN0 ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4gd3JvdGU6 DQo+Pj4NCj4+Pj4gSGkgQWRhbSwNCj4+Pj4NCj4+Pj4gLi4uLg0KPj4+Pg0KPj4+Pj4+IE9uZSBh ZGRpdGlvbmFsIHJldmlldyBub3RlIHRoYXQgZG9lcyBub3QgYWZmZWN0IG15IGV4cGVydCByZXZp ZXcNCj4+Pj4+PiAodHJlYXQgaXQgYXMgYSBsYXN0LWNhbGwgY29tbWVudCk6DQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+ICAgICAgIEFkZCBzdGF0ZW1lbnQgdGhhdCB0aGUgUC1WaXNpdGVkLU5ldHdv cmstSUQgaGVhZGVyIGZpZWxkDQo+Pj4+Pj5jYW5ub3QNCj4+Pj4+PiAgICAgICBhcHBlYXIgaW4g dGhlIFNJUCBOT1RJRlksIFBSQUNLLCBJTkZPIGFuZCBVUERBVEUgbWV0aG9kcy4NCj4+Pj4+Pg0K Pj4+Pj4+IEl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgYmUgc2lnbmlmaWNhbnRseSBtb3Jl IGZ1dHVyZSBwcm9vZiB0bw0KPj4+Pj4+IHBoYXNlIHRoaXMgYXMgIi4uLmNhbm5vdCBhcHBlYXIg aW4gbWlkLWRpYWxvZyByZXF1ZXN0cywiIGFzIHRoYXQNCj4+Pj4+PiBhcHBlYXJzIHRvIGJlIHRo ZSBpbnRlbnRpb24uIFRoZSByZXZpc2VkIHRleHQgdGhlbiBiZWNvbWVzIHNvbWV0aGluZw0KPj4+ Pj4+IGxpa2U6ICJUaGUgUC1WaXNpdGVkLU5ldHdvcmstSUQgaGVhZGVyDQo+Pj4+Pj4gZmllbGQg Y2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhvZHMgZXhjZXB0IEFDSyBhbmQgQ0FOQ0VMOyBob3dl dmVyLA0KPj4+Pj4+aXQNCj4+Pj4+PiBjYW5ub3QgYmUgc2VudCBpbiA+YW55IG1pZC1kaWFsb2cg cmVxdWVzdHMuIg0KPj4+Pj4gU2VlbXMgcmVhc29uYWJsZSwgYnV0IEknbGwgdmVyaWZ5IHdpdGgg bXkgM0dQUCBkZWxlZ2F0ZXMuDQo+Pj4+IEkgaGFkIGEgY2xvc2VyIGxvb2sgYXQgdGhpcywgYW5k IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGZvcmJpZCB1c2FnZSBpbg0KPj4+PmFsbA0KPj4+PiBtaWQt ZGlhbG9nIHJlcXVlc3RzLg0KPj4+Pg0KPj4+PiBGb3IgZXhhbXBsZSwgdGhlIGhlYWRlciBmaWVs ZCBpcyBhbGxvd2VkIGluIE9QVElPTlMsIHRoYXQgY2FuIGJlIHNlbnQNCj4+Pj4gaW4tZGlhbG9n Lg0KPj4+Pg0KPj4+PiBBbHNvLCB0aGUgaGVhZGVyIGZpZWxkIGlzIGFsbG93ZWQgaW4gUkVGRVIs IGFuZCBSRkMgNzYxNCBkZWZpbmVzIGENCj4+Pj4gbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGluLWRp YWxvZyBSRUZFUnMuDQo+Pj4+DQo+Pj4+IHJlLUlOVklURSBpcyBhbHNvIHRyaWNreS4gVGhlIGhl YWRlciBmaWVsZCBpcyBnZW5lcmFsbHkgYWxsb3dlZCBpbg0KPj4+PklOVklURQ0KPj4+PiByZXF1 ZXN0cywgYnV0IHRoZXJlIGlzIG5vIHRleHQgZXhwbGljaXRseSBkaXNhbGxvd2luZyBpdCBpbg0K Pj4+PnJlLUlOVklURXMuDQo+Pj4+DQo+Pj4+IFdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8gaW5j bHVkZSB0aGUgaGVhZGVyIGZpZWxkIGluIHRoZSBtZXRob2RzDQo+Pj4+YWJvdmUgSQ0KPj4+PiBk b24ndCBrbm93ICgzR1BQIGRvZXMgYWxsb3cgdGhlbSksIGJ1dCBhcyB0aGUgcHVycG9zZSBpcyBv bmx5IHRvIGFsaWduDQo+Pj4+IDczMTUgd2l0aCAzNDU1IEknZCBzdWdnZXN0IHdlIGtlZXAgdGhl IHRleHQgYXMgaXQgaXMuDQo+Pj4+DQo+Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IENo cmlzdGVyDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9u IDMvNy8xNiAxNDowOCwgQS4gSmVhbiBNYWhvbmV5IHdyb3RlOg0KPj4+PiBTaW5jZSB0aGlzIGRy YWZ0IHVwZGF0ZXMgUkZDIDczMTUsIHdoaWNoIHJlcXVpcmVkIGV4cGVydCByZXZpZXcgb2YgaXRz DQo+Pj4+IGhlYWRlciBmaWVsZHMsIEFkYW0gUm9hY2ggd2lsbCBiZSBjb25kdWN0aW5nIGFuIGV4 cGVydCByZXZpZXcgb2YgdGhpcw0KPj4+PiBkcmFmdCBhY2NvcmRpbmcgdG8gdGhlIGd1aWRhbmNl IGdpdmVuIGluIFJGQyA1NzI3Lg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+DQo+Pj4+IEplYW4N Cj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMy83LzE2IDk6MzMgQU0sIE1hcnkgQmFybmVzIHdyb3RlOg0K Pj4+Pg0KPj4+PiBIaSBmb2xrcywNCj4+Pj4NCj4+Pj4gVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBw cm9wb3NlZCB0byBiZSBwcm9ncmVzc2VkIGFzIEFEIHNwb25zb3JlZDoNCj4+Pj4gDQo+Pj4+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZj NzMxNS11cGRhdGUNCj4+Pj5zLw0KPj4+PiBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gY2FyZWZ1bGx5 IHJldmlld2VkIGFuZCBpdCBpcyBub3cgcmVhZHkgdG8gbW92ZQ0KPj4+PiBmb3J3YXJkIC0gSmVh biBNYWhvbmV5IGlzIHRoZSBzaGVwaGVyZC4NCj4+Pj4NCj4+Pj4gSSBkb24ndCBhbnRpY2lwYXRl IGFueW9uZSB3b3VsZCBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMgZGVjaXNpb24sDQo+Pj4+Z2l2 ZW4NCj4+Pj4gdGhhdCdzIGhvdyBSRkMgNzMxNSB3YXMgcHJvZ3Jlc3NlZCBhbmQgdGhpcyB1cGRh dGUgaGFzIGFjdHVhbGx5IGJlZW4NCj4+Pj5tdWNoDQo+Pj4+IG1vcmUgY2FyZWZ1bGx5IHJldmll d2VkLiAgSG93ZXZlciwgZiBhbnlvbmUgaGFzIGFueSBmaW5hbCBjb21tZW50cywNCj4+Pj4gcGxl YXNlIHBvc3Qgbm8gbGF0ZXIgdGhhbiBGcmlkYXksIE1hcmNoIDExdGgsIDIwMTYuICBOb3RlLCB0 aGF0IHlvdQ0KPj4+PndpbGwNCj4+Pj4gYWxzbyBzdGlsbCBoYXZlIElFVEYgTEMgdG8gcHJvdmlk ZSBhbnkgY29tbWVudHMuDQo+Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+IE1hcnkuDQo+Pj4+DQo+ Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPj4+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+Pj4+DQo+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPj4+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+Pj4+DQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IGRpc3Bh dGNoIG1haWxpbmcgbGlzdA0KPj4+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQoNCg== From nobody Wed Apr 27 08:57:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203DE12D1DD for ; Wed, 27 Apr 2016 08:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jlaQKX0BumUe for ; Wed, 27 Apr 2016 08:57:06 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1109512B040 for ; Wed, 27 Apr 2016 08:57:05 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-01-5720e1507551 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.A2.27088.051E0275; Wed, 27 Apr 2016 17:57:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 17:57:03 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , "A. Jean Mahoney" , "dispatch@ietf.org" Thread-Topic: Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored] Thread-Index: AdGgnWU3rWoswjJ4TzSpsQXBWIQ4gQ== Date: Wed, 27 Apr 2016 15:57:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F866CB@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM2K7om7AQ4Vwg9PN/BZ7/i5it1g6aQGr RUPnSlYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK2P9/kNsBR2GFT9XvmNpYPyj3sXI wSEhYCLReMSxi5ETyBSTuHBvPVsXIxeHkMARRokZm/5BOUsYJQ6+6WQHaWATsJDo/qcNEhcR WM0ocf/SPRYQR1hgCqPE3LvnmSEyMxklzs+ewQIyV0RAT6L74ComEJtFQFXiz6NvzCA2r4Cv xNMJN8FsRqDd30+tAathFhCXuPVkPhPETQISS/acZ4awRSVePv7HCmErSaw9vJ0Fol5P4sbU KWwQtrbEsoWvoeYLSpyc+YRlAqPwLCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M9FKLMpOL i/Pz9PJSSzYxAqPg4JbfBjsYXz53PMQowMGoxMOrIKsQLsSaWFZcmXuIUYKDWUmEV+4BUIg3 JbGyKrUoP76oNCe1+BCjNAeLkjhvduS/MCGB9MSS1OzU1ILUIpgsEwenVAOjvJy7wldBts+r LrIltz89qHhyXtVy4RjzC+FTG++XZmxrUz4z6/+Xj4+sze+pFa4/OrVmu7Tgdnsxf/8/eXwq zxx26fAdShb2UfLvFXi8uvZBGfO9U3+OTwwMDT4r/LN3WkqZ7p99vUeVNX+wSGe8fmDjM3up zuFdwjYyxz/qmdYbyJ1Tvr5JiaU4I9FQi7moOBEAp12sMX4CAAA= Archived-At: Subject: [dispatch] Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 15:57:08 -0000 Hi, Based on Adam's comments, I've submitted a new version (-06) of draft-holmb= erg-dispatch-rfc7315-updates. Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 27 April 2016 18:07 To: Adam Roach ; A. Jean Mahoney ; d= ispatch@ietf.org Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates= as AD sponsored Hi, >Sure -- my suggestion was one for clarification. If 3GPP does, in fact,=20 >intend to allow the header field in mid-dialog messages, then my=20 >comment doesn't apply. > >But if they *do* intend to allow the field mid-dialog, I'm curious=20 >about why it's forbidden in the current list of methods: save for some=20 >obscure corner cases, all of the methods called out by name are sent=20 >mid-dialog, and none of the un-named methods are. OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog. I can't give an answer here and now why the list looks like it does, but th= is is how it's specified in 3GPP :) >Either way, it's just a suggestion. The hard block here is in the ACK=20 >handling that I pointed out. Based on your comments, the new text would now say: "The P-Associated-URI header field can appear in SIP REGISTER 2xx responses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The P-Access-Network-Info header field can appear in all SIP methods and non-100 responses, except in CANCEL methods, CANCEL responses and ACK methods triggered by non-2xx responses. The P-Charging-Vector header field can appear in all SIP methods and non-100 responses, except in CANCEL methods, CANCEL responses and ACK methods triggered by non-2xx responses. The P-Charging-Function-Addresses header field can appear in all SIP methods and non-100 responses, except in ACK and CANCEL methods and CANCEL responses." Regards, Christer > >/a > >On 4/27/16 08:01, Christer Holmberg wrote: >> Hi, >> >> One more thing: >> >> I guess we could also change =B3all responses=B2 to =B3all non-100=20 >>responses=B2, as 100 responses are also hop-to-hop (similar to ACKs=20 >>triggered by non-2xx responses). >> >> Regards, >> >> Christer >> >> >> On 25/04/16 14:30, "Christer Holmberg"=20 >> >> wrote: >> >>> Hi Adam, >>> >>> Are you ok with my suggested way forward? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> On 21/04/16 22:43, "Christer Holmberg"=20 >>> >>> wrote: >>> >>>> Hi Adam, >>>> >>>> .... >>>> >>>>>> One additional review note that does not affect my expert review=20 >>>>>> (treat it as a last-call comment): >>>>>> >>>>>> >>>>>> Add statement that the P-Visited-Network-ID header field=20 >>>>>>cannot >>>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>>> >>>>>> It seems to me that it would be significantly more future proof=20 >>>>>>to phase this as "...cannot appear in mid-dialog requests," as=20 >>>>>>that appears to be the intention. The revised text then becomes=20 >>>>>>something >>>>>> like: "The P-Visited-Network-ID header field can appear in all=20 >>>>>>SIP methods except ACK and CANCEL; however, it cannot be sent in=20 >>>>>>>any mid-dialog requests." >>>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>>> I had a closer look at this, and I don't think we can forbid usage=20 >>>>in all mid-dialog requests. >>>> >>>> For example, the header field is allowed in OPTIONS, that can be=20 >>>> sent in-dialog. >>>> >>>> Also, the header field is allowed in REFER, and RFC 7614 defines a=20 >>>> mechanism that allows in-dialog REFERs. >>>> >>>> re-INVITE is also tricky. The header field is generally allowed in=20 >>>>INVITE requests, but there is no text explicitly disallowing it in=20 >>>>re-INVITEs. >>>> >>>> Whether it makes sense to include the header field in the methods=20 >>>>above I don't know (3GPP does allow them), but as the purpose is=20 >>>>only to align >>>> 7315 with 3455 I'd suggest we keep the text as it is. >>>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>>> Since this draft updates RFC 7315, which required expert review of=20 >>>> its header fields, Adam Roach will be conducting an expert review=20 >>>> of this draft according to the guidance given in RFC 5727. >>>> >>>> Thanks, >>>> >>>> Jean >>>> >>>> >>>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>>> >>>> Hi folks, >>>> >>>> This document has been proposed to be progressed as AD sponsored: >>>>=20 >>>>https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-upd >>>>ate >>>>s/ >>>> The document has been carefully reviewed and it is now ready to=20 >>>>move forward - Jean Mahoney is the shepherd. >>>> >>>> I don't anticipate anyone would have concerns about this decision,=20 >>>>given that's how RFC 7315 was progressed and this update has=20 >>>>actually been much more carefully reviewed. However, f anyone has=20 >>>>any final comments, please post no later than Friday, March 11th,=20 >>>>2016. Note, that you will also still have IETF LC to provide any=20 >>>>comments. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 27 11:11:44 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1165212DB8A for ; Wed, 27 Apr 2016 11:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 EHE6viww8ZLk for ; Wed, 27 Apr 2016 11:11:41 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6635C12D55E for ; Wed, 27 Apr 2016 11:11:40 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id vTvUaEqCFbFYYvTw3a4RiA; Wed, 27 Apr 2016 18:11:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461780699; bh=CW0RypCL0xnxfvxxWobgbkAZ4QzR1B4ns1kBJly8TdA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pxmQsuKDdr4+E6JfwHxA+sIspyCW8gvaiDUeYGzx9rq7UByz0GxeE4a2ZGt15rYUv sp/B7U+fAxXJweKHTheZdidpqS10leoaJp9g2+GC3uOsOI/GIzGqDULR9Z3vmnzlL5 TRc3Z/B+aE6jpDFWHrnc/Kd4mTteJSiNF97aMkL8eUUiw8pUY0z1QBU9C9if4A8eQ5 0i+kYqXyQCHCOZC6PyXcN+QK3Z6/X4fY8BixDjKOAlSgjToWBRF8jXDjT+RcHZM7N5 vvXZ/w/gU4/yfwsxD4o2blQRdRJxx3bG9sR98/mp+D5CmevlIt2KnI73KJOtXfka+D sOIEr6OwNHZ/g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id nWBe1s00f3KdFy101WBfkX; Wed, 27 Apr 2016 18:11:39 +0000 To: dispatch@ietf.org References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> <5720BC8A.5060709@nostrum.com> From: Paul Kyzivat Message-ID: <5a28aedb-cba1-062a-e846-28a1b66c1694@alum.mit.edu> Date: Wed, 27 Apr 2016 14:11:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:11:43 -0000 On 4/27/16 11:07 AM, Christer Holmberg wrote: > Hi, > >> Sure -- my suggestion was one for clarification. If 3GPP does, in fact, >> intend to allow the header field in mid-dialog messages, then my >> comment doesn't apply. >> >> But if they *do* intend to allow the field mid-dialog, I'm curious about >> why it's forbidden in the current list of methods: save for some obscure >> corner cases, all of the methods called out by name are sent mid-dialog, >> and none of the un-named methods are. > > OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog. and MESSAGE. > I cant give an answer here and now why the list looks like it does, but > this is how its specified in 3GPP :) > >> Either way, it's just a suggestion. The hard block here is in the ACK >> handling that I pointed out. > > Based on your comments, the new text would now say: > > "The P-Associated-URI header field can appear in SIP REGISTER > 2xx responses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. > The P-Visited-Network-ID header field can appear in all SIP methods > except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The > P-Access-Network-Info header field can appear in all SIP methods > and non-100 responses, except in CANCEL methods, CANCEL responses > and ACK methods triggered by non-2xx responses. The P-Charging-Vector > header field can appear in all SIP methods and non-100 responses, > except in CANCEL methods, CANCEL responses and ACK methods triggered > by non-2xx responses. The P-Charging-Function-Addresses header field > can appear in all SIP methods and non-100 responses, except in ACK > and CANCEL methods and CANCEL responses. These rules seem very arbitrary, without any obvious rationale - why are the rules different for the four different header fields? I can see that there might be a rationale, based on need during dialog establishment or maybe just *call* establishment. But if so, I would think a generic way of describing the rule would work better than enumeration. So basically, if the rationale for the difference is stated first, then it ought to make clear what messages are appropriate. When there are just different sets of enumerations without explanation it invites debate over the particular messages included. Thanks, Paul > Regards, > > Christer > > > > > > > >> >> /a >> >> On 4/27/16 08:01, Christer Holmberg wrote: >>> Hi, >>> >>> One more thing: >>> >>> I guess we could also change all responses to all non-100 responses, >>> as 100 responses are also hop-to-hop (similar to ACKs triggered by >>> non-2xx >>> responses). >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 25/04/16 14:30, "Christer Holmberg" >>> wrote: >>> >>>> Hi Adam, >>>> >>>> Are you ok with my suggested way forward? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> On 21/04/16 22:43, "Christer Holmberg" >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> .... >>>>> >>>>>>> One additional review note that does not affect my expert review >>>>>>> (treat it as a last-call comment): >>>>>>> >>>>>>> >>>>>>> Add statement that the P-Visited-Network-ID header field >>>>>>> cannot >>>>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>>>> >>>>>>> It seems to me that it would be significantly more future proof to >>>>>>> phase this as "...cannot appear in mid-dialog requests," as that >>>>>>> appears to be the intention. The revised text then becomes something >>>>>>> like: "The P-Visited-Network-ID header >>>>>>> field can appear in all SIP methods except ACK and CANCEL; however, >>>>>>> it >>>>>>> cannot be sent in >any mid-dialog requests." >>>>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>>>> I had a closer look at this, and I don't think we can forbid usage in >>>>> all >>>>> mid-dialog requests. >>>>> >>>>> For example, the header field is allowed in OPTIONS, that can be sent >>>>> in-dialog. >>>>> >>>>> Also, the header field is allowed in REFER, and RFC 7614 defines a >>>>> mechanism that allows in-dialog REFERs. >>>>> >>>>> re-INVITE is also tricky. The header field is generally allowed in >>>>> INVITE >>>>> requests, but there is no text explicitly disallowing it in >>>>> re-INVITEs. >>>>> >>>>> Whether it makes sense to include the header field in the methods >>>>> above I >>>>> don't know (3GPP does allow them), but as the purpose is only to align >>>>> 7315 with 3455 I'd suggest we keep the text as it is. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>>>> Since this draft updates RFC 7315, which required expert review of its >>>>> header fields, Adam Roach will be conducting an expert review of this >>>>> draft according to the guidance given in RFC 5727. >>>>> >>>>> Thanks, >>>>> >>>>> Jean >>>>> >>>>> >>>>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> This document has been proposed to be progressed as AD sponsored: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-update >>>>> s/ >>>>> The document has been carefully reviewed and it is now ready to move >>>>> forward - Jean Mahoney is the shepherd. >>>>> >>>>> I don't anticipate anyone would have concerns about this decision, >>>>> given >>>>> that's how RFC 7315 was progressed and this update has actually been >>>>> much >>>>> more carefully reviewed. However, f anyone has any final comments, >>>>> please post no later than Friday, March 11th, 2016. Note, that you >>>>> will >>>>> also still have IETF LC to provide any comments. >>>>> >>>>> Regards, >>>>> Mary. >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 27 11:30:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B650512DBA2 for ; Wed, 27 Apr 2016 11:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZXX4apZGXZC1 for ; Wed, 27 Apr 2016 11:30:49 -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 5CDED12DBA1 for ; Wed, 27 Apr 2016 11:30:48 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-4a-57210557a3bd Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 01.A6.12516.75501275; Wed, 27 Apr 2016 20:30:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 20:30:27 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14IAF08iAgAM+FoD//9KdAIAAUJsAgAAA1ACAACUQcA== Date: Wed, 27 Apr 2016 18:30:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F869DB@ESESSMB209.ericsson.se> References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> <5720BC8A.5060709@nostrum.com> <5a28aedb-cba1-062a-e846-28a1b66c1694@alum.mit.edu> In-Reply-To: <5a28aedb-cba1-062a-e846-28a1b66c1694@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.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7t244q2K4wd6vMhZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx72szU8EP04rN7+awNTD+1e5i5OSQEDCR aL7cxg5hi0lcuLeerYuRi0NI4AijxNupJ9khnCWMEn9PP2PpYuTgYBOwkOj+B9YsIhAscfDw ThYQW1ggVmLn2o3MEPE4iYuN99lAykUEsiSaf7mBhFkEVCV+z1nABGLzCvhKvN0+CWp8E4vE kndzwBKcAg4SjU1v2UBsRqCDvp9aAxZnFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSaw9 vJ0Fol5P4sbUKWwQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uL c9ONjPVSizKTi4vz8/TyUks2MQLj5OCW37o7GFe/djzEKMDBqMTDqyCrEC7EmlhWXJl7iFGC g1lJhDeGQTFciDclsbIqtSg/vqg0J7X4EKM0B4uSOG9O5L8wIYH0xJLU7NTUgtQimCwTB6dU A6N2z2Xu8FUXLLsvKS71qa8T3SZxyWnlcwV9A1++d2/nG1+N8f/fcvjjm8Ks9BS2wqkiYhdu dzwqyim/qXBcZoP8/S7vdbPay+QMpm5l5Oye6Hj1MfsCnViHicvfXu3+eZ9PpMrCZpXUhLQU u+LkyZnvtoUXb/uwfO3WHzvcI+bVlTX9dX8yK0aJpTgj0VCLuag4EQCEoBt2jwIAAA== Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:30:52 -0000 Hi, ... >> Based on your comments, the new text would now say: >> >> "The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all SIP methods >> except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The >> P-Access-Network-Info header field can appear in all SIP methods >> and non-100 responses, except in CANCEL methods, CANCEL responses >> and ACK methods triggered by non-2xx responses. The P-Charging-Vector >> header field can appear in all SIP methods and non-100 responses, >> except in CANCEL methods, CANCEL responses and ACK methods triggered >> by non-2xx responses. The P-Charging-Function-Addresses header field >> can appear in all SIP methods and non-100 responses, except in ACK >> and CANCEL methods and CANCEL responses." > > These rules seem very arbitrary, without any obvious rationale - why are = the rules different for the four different header fields? > > I can see that there might be a rationale, based on need during dialog es= tablishment or maybe just *call* establishment. But=20 > if so, I would think a generic way of describing the rule would work bett= er than enumeration. > > So basically, if the rationale for the difference is stated first, then i= t ought to make clear what messages are appropriate. When=20 > there are just different sets of enumerations without explanation it invi= tes debate over the particular messages included. The purpose of this task was to fix misalignments between 3455 and 7315, an= d incorporate new 3GPP requirements - which are described in section 3.3 - = and update the existing text (see below) in 7315 based on that. Old text: The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL. The P-Charging-Vector header field can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL. Regards, Christer =20 >> On 4/27/16 08:01, Christer Holmberg wrote: >>> Hi, >>> >>> One more thing: >>> >>> I guess we could also change =B3all responses=B2 to =B3all non-100=20 >>> responses=B2, as 100 responses are also hop-to-hop (similar to ACKs=20 >>> triggered by non-2xx responses). >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 25/04/16 14:30, "Christer Holmberg"=20 >>> >>> wrote: >>> >>>> Hi Adam, >>>> >>>> Are you ok with my suggested way forward? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> On 21/04/16 22:43, "Christer Holmberg"=20 >>>> >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> .... >>>>> >>>>>>> One additional review note that does not affect my expert review=20 >>>>>>> (treat it as a last-call comment): >>>>>>> >>>>>>> >>>>>>> Add statement that the P-Visited-Network-ID header field=20 >>>>>>> cannot >>>>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>>>> >>>>>>> It seems to me that it would be significantly more future proof=20 >>>>>>> to phase this as "...cannot appear in mid-dialog requests," as=20 >>>>>>> that appears to be the intention. The revised text then becomes=20 >>>>>>> something >>>>>>> like: "The P-Visited-Network-ID header field can appear in all=20 >>>>>>> SIP methods except ACK and CANCEL; however, it cannot be sent in=20 >>>>>>> >any mid-dialog requests." >>>>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>>>> I had a closer look at this, and I don't think we can forbid usage=20 >>>>> in all mid-dialog requests. >>>>> >>>>> For example, the header field is allowed in OPTIONS, that can be=20 >>>>> sent in-dialog. >>>>> >>>>> Also, the header field is allowed in REFER, and RFC 7614 defines a=20 >>>>> mechanism that allows in-dialog REFERs. >>>>> >>>>> re-INVITE is also tricky. The header field is generally allowed in=20 >>>>> INVITE requests, but there is no text explicitly disallowing it in=20 >>>>> re-INVITEs. >>>>> >>>>> Whether it makes sense to include the header field in the methods=20 >>>>> above I don't know (3GPP does allow them), but as the purpose is=20 >>>>> only to align >>>>> 7315 with 3455 I'd suggest we keep the text as it is. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>>>> Since this draft updates RFC 7315, which required expert review of=20 >>>>> its header fields, Adam Roach will be conducting an expert review=20 >>>>> of this draft according to the guidance given in RFC 5727. >>>>> >>>>> Thanks, >>>>> >>>>> Jean >>>>> >>>>> >>>>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> This document has been proposed to be progressed as AD sponsored: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-u >>>>> pdate >>>>> s/ >>>>> The document has been carefully reviewed and it is now ready to=20 >>>>> move forward - Jean Mahoney is the shepherd. >>>>> >>>>> I don't anticipate anyone would have concerns about this decision,=20 >>>>> given that's how RFC 7315 was progressed and this update has=20 >>>>> actually been much more carefully reviewed. However, f anyone has=20 >>>>> any final comments, please post no later than Friday, March 11th,=20 >>>>> 2016. Note, that you will also still have IETF LC to provide any=20 >>>>> comments. >>>>> >>>>> Regards, >>>>> Mary. >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Apr 27 11:47:08 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1812D53B for ; Wed, 27 Apr 2016 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Y7LrdHXVo-xW for ; Wed, 27 Apr 2016 11:47:05 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9FD12D534 for ; Wed, 27 Apr 2016 11:47:05 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id vUU3acOEZpUrhvUUKaQyBX; Wed, 27 Apr 2016 18:47:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1461782824; bh=3nstnnH8KQwpAOgPEu/Ff+ASGLP/a/mhqMaZVaMEH/U=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=d5r5PM29EJNrD1r13Cr7I3fs5fOTd9RdBM2hRS6VnoTRB0cPm+zo5dyQ23ZYf9pKf 5kOE2i3yu6kDDU4qMWRpfzRBHwX0/VF4PG9NjYufRhsg+/9FDL7deTPRKf8pTEc7oc xwn8JhaFj26zv8pw1z5a/9EdTGpegW33s12J8R6Fv54TW6OjIh1MSDSkxAqIwPM2Lc M/ODfkO1Q7LoM3P7m5xfRPIezL0kEip9AMFxKhB0fGLyNEZekdJGP6lB1lwsmbSnR7 3VcW9Qm/6NnG/2MUUv1NQWnknbQSF3TujR8X0rYcDBfKPUFYNac5awUT6lSHCJTuL6 WyMgNlREnyH5g== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id nWn31s00U3KdFy101Wn3ne; Wed, 27 Apr 2016 18:47:04 +0000 To: Christer Holmberg , "dispatch@ietf.org" References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> <5720BC8A.5060709@nostrum.com> <5a28aedb-cba1-062a-e846-28a1b66c1694@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F869DB@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Wed, 27 Apr 2016 14:47:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F869DB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:47:07 -0000 On 4/27/16 2:30 PM, Christer Holmberg wrote: > Hi, > > ... > >>> Based on your comments, the new text would now say: >>> >>> "The P-Associated-URI header field can appear in SIP REGISTER >>> 2xx responses. The P-Called-Party-ID header field can appear in >>> SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods. >>> The P-Visited-Network-ID header field can appear in all SIP methods >>> except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The >>> P-Access-Network-Info header field can appear in all SIP methods >>> and non-100 responses, except in CANCEL methods, CANCEL responses >>> and ACK methods triggered by non-2xx responses. The P-Charging-Vector >>> header field can appear in all SIP methods and non-100 responses, >>> except in CANCEL methods, CANCEL responses and ACK methods triggered >>> by non-2xx responses. The P-Charging-Function-Addresses header field >>> can appear in all SIP methods and non-100 responses, except in ACK >>> and CANCEL methods and CANCEL responses." >> >> These rules seem very arbitrary, without any obvious rationale - why are the rules different for the four different header fields? >> >> I can see that there might be a rationale, based on need during dialog establishment or maybe just *call* establishment. But >> if so, I would think a generic way of describing the rule would work better than enumeration. >> >> So basically, if the rationale for the difference is stated first, then it ought to make clear what messages are appropriate. When >> there are just different sets of enumerations without explanation it invites debate over the particular messages included. > > The purpose of this task was to fix misalignments between 3455 and 7315, and incorporate new 3GPP requirements - which are described in section 3.3 - and update the existing text (see below) in 7315 based on that. > > Old text: > > The P-Associated-URI header field can appear in SIP REGISTER method > and 2xx resonses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all > responses. The P-Visited-Network-ID header field can appear in all > SIP methods except ACK, BYE, and CANCEL and all responses. The > P-Access-Network-Info header field can appear in all SIP methods > except ACK and CANCEL. The P-Charging-Vector header field can appear > in all SIP methods except CANCEL. The P-Charging-Function-Addresses > header field can appear in all SIP methods except ACK and CANCEL. IIUC what you are saying is that 3GPP doesn't specify a rationale, so you don't have one to put here. I presume that whenever and wherever these lists were created there was *some* rationale, even if it wasn't recorded. Is it possible to discover that rationale and write it down? It may be that the results were not even consistent with the unstated rationale. If so, is it more important to preserve consistency with the past, or to fix the mistake? Thanks, Paul > Regards, > > Christer > > > >>> On 4/27/16 08:01, Christer Holmberg wrote: >>>> Hi, >>>> >>>> One more thing: >>>> >>>> I guess we could also change all responses to all non-100 >>>> responses, as 100 responses are also hop-to-hop (similar to ACKs >>>> triggered by non-2xx responses). >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> On 25/04/16 14:30, "Christer Holmberg" >>>> >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> Are you ok with my suggested way forward? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> On 21/04/16 22:43, "Christer Holmberg" >>>>> >>>>> wrote: >>>>> >>>>>> Hi Adam, >>>>>> >>>>>> .... >>>>>> >>>>>>>> One additional review note that does not affect my expert review >>>>>>>> (treat it as a last-call comment): >>>>>>>> >>>>>>>> >>>>>>>> Add statement that the P-Visited-Network-ID header field >>>>>>>> cannot >>>>>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>>>>> >>>>>>>> It seems to me that it would be significantly more future proof >>>>>>>> to phase this as "...cannot appear in mid-dialog requests," as >>>>>>>> that appears to be the intention. The revised text then becomes >>>>>>>> something >>>>>>>> like: "The P-Visited-Network-ID header field can appear in all >>>>>>>> SIP methods except ACK and CANCEL; however, it cannot be sent in >>>>>>>>> any mid-dialog requests." >>>>>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>>>>> I had a closer look at this, and I don't think we can forbid usage >>>>>> in all mid-dialog requests. >>>>>> >>>>>> For example, the header field is allowed in OPTIONS, that can be >>>>>> sent in-dialog. >>>>>> >>>>>> Also, the header field is allowed in REFER, and RFC 7614 defines a >>>>>> mechanism that allows in-dialog REFERs. >>>>>> >>>>>> re-INVITE is also tricky. The header field is generally allowed in >>>>>> INVITE requests, but there is no text explicitly disallowing it in >>>>>> re-INVITEs. >>>>>> >>>>>> Whether it makes sense to include the header field in the methods >>>>>> above I don't know (3GPP does allow them), but as the purpose is >>>>>> only to align >>>>>> 7315 with 3455 I'd suggest we keep the text as it is. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>>>>> Since this draft updates RFC 7315, which required expert review of >>>>>> its header fields, Adam Roach will be conducting an expert review >>>>>> of this draft according to the guidance given in RFC 5727. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jean >>>>>> >>>>>> >>>>>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> This document has been proposed to be progressed as AD sponsored: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-u >>>>>> pdate >>>>>> s/ >>>>>> The document has been carefully reviewed and it is now ready to >>>>>> move forward - Jean Mahoney is the shepherd. >>>>>> >>>>>> I don't anticipate anyone would have concerns about this decision, >>>>>> given that's how RFC 7315 was progressed and this update has >>>>>> actually been much more carefully reviewed. However, f anyone has >>>>>> any final comments, please post no later than Friday, March 11th, >>>>>> 2016. Note, that you will also still have IETF LC to provide any >>>>>> comments. >>>>>> >>>>>> Regards, >>>>>> Mary. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 27 12:29:22 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9F12D55C for ; Wed, 27 Apr 2016 12:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bMZc-iUlUmMn for ; Wed, 27 Apr 2016 12:29:19 -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 1B44B12D547 for ; Wed, 27 Apr 2016 12:29:18 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-a1-5721130c306c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2E.DB.12516.C0311275; Wed, 27 Apr 2016 21:29:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 21:29:16 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14IAF08iAgAM+FoD//9KdAIAAUJsAgAAA1ACAACUQcP//5NQAgAAqvmA= Date: Wed, 27 Apr 2016 19:29:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F86AAF@ESESSMB209.ericsson.se> References: <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> <5720BC8A.5060709@nostrum.com> <5a28aedb-cba1-062a-e846-28a1b66c1694@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F869DB@ESESSMB209.ericsson.se> In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hC6vsGK4wbGb3BZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxdf95poIf1hU3eg+zNDB+Nuhi5OSQEDCR aNo6hxXCFpO4cG89WxcjF4eQwBFGiXtrFrFCOEsYJZ51fGLpYuTgYBOwkOj+pw3SICIQLHHw 8E4WEFtYIFZi59qNzBDxOImLjffZIOwyibsNr8BqWARUJdbdnsIOYvMK+EqcbVwNtewPi8TL S3fAruAUcJB4cfst2CBGoIu+n1rDBGIzC4hL3HoynwniUgGJJXvOM0PYohIvH/+D+kBJYu3h 7SwQ9XoSN6ZOYYOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlyc m25krJdalJlcXJyfp5eXWrKJERgpB7f81t3BuPq14yFGAQ5GJR5eBVmFcCHWxLLiytxDjBIc zEoivFc5FMOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ZE/gsTEkhPLEnNTk0tSC2CyTJxcEo1 MGrNYn2Wlu+m8es4q/ubma815gZ8iDvQWnrv2GoXc40LFx9azakpzguTEXJdqS/7fw5T0Qzn +J5Pv9UNX5234XKs/Lmlb4fRo0ULzBXK6m/yKL75evCYoWmAUWfN7emLw68UxmS/+cS/NHXL 9ClisqY3FdIYzgiF736lzVO2qPX0Ktvgn30OSkosxRmJhlrMRcWJACFaNgOQAgAA Archived-At: Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:29:22 -0000 Hi, ... >>>> Based on your comments, the new text would now say: >>>> >>>> "The P-Associated-URI header field can appear in SIP REGISTER >>>> 2xx responses. The P-Called-Party-ID header field can appear in >>>> SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods= . >>>> The P-Visited-Network-ID header field can appear in all SIP methods >>>> except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The >>>> P-Access-Network-Info header field can appear in all SIP methods >>>> and non-100 responses, except in CANCEL methods, CANCEL responses >>>> and ACK methods triggered by non-2xx responses. The P-Charging-Vect= or >>>> header field can appear in all SIP methods and non-100 responses, >>>> except in CANCEL methods, CANCEL responses and ACK methods triggere= d >>>> by non-2xx responses. The P-Charging-Function-Addresses header fiel= d >>>> can appear in all SIP methods and non-100 responses, except in ACK >>>> and CANCEL methods and CANCEL responses." >>> >>> These rules seem very arbitrary, without any obvious rationale - why ar= e the rules different for the four different header fields? >>> >>> I can see that there might be a rationale, based on need during=20 >>> dialog establishment or maybe just *call* establishment. But if so, I w= ould think a generic way of describing the rule would work better than enum= eration. >>> >>> So basically, if the rationale for the difference is stated first,=20 >>> then it ought to make clear what messages are appropriate. When there a= re just different sets=20 >>> of enumerations without explanation it invites debate over the particul= ar messages included. >>> >>> The purpose of this task was to fix misalignments between 3455 and 7315= , and incorporate new 3GPP=20 >>> requirements - which are described in section 3.3 - and update the exis= ting text (see below) in 7315 based on that. >> >> Old text: >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all >> responses. The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL. The P-Charging-Vector header field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresses >> header field can appear in all SIP methods except ACK and CANCEL. > > IIUC what you are saying is that 3GPP doesn't specify a rationale, so you= don't have one to put here. I am saying that the chapter we are updating does not contain the rationale= . It's the normative text replacing the "header field tables" we used to ha= ve. Please note that each header field is more described elsewhere in the RFC. We were requested to provide justification for the changes needed due to ne= w 3GPP requirement, and that's what we've done in section 3.3. Regards, Christer >>> On 4/27/16 08:01, Christer Holmberg wrote: >>>> Hi, >>>> >>>> One more thing: >>>> >>>> I guess we could also change =B3all responses=B2 to =B3all non-100=20 >>>> responses=B2, as 100 responses are also hop-to-hop (similar to ACKs=20 >>>> triggered by non-2xx responses). >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> On 25/04/16 14:30, "Christer Holmberg" >>>> >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> Are you ok with my suggested way forward? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> On 21/04/16 22:43, "Christer Holmberg" >>>>> >>>>> wrote: >>>>> >>>>>> Hi Adam, >>>>>> >>>>>> .... >>>>>> >>>>>>>> One additional review note that does not affect my expert=20 >>>>>>>> review (treat it as a last-call comment): >>>>>>>> >>>>>>>> >>>>>>>> Add statement that the P-Visited-Network-ID header field=20 >>>>>>>> cannot >>>>>>>> appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods. >>>>>>>> >>>>>>>> It seems to me that it would be significantly more future proof=20 >>>>>>>> to phase this as "...cannot appear in mid-dialog requests," as=20 >>>>>>>> that appears to be the intention. The revised text then becomes=20 >>>>>>>> something >>>>>>>> like: "The P-Visited-Network-ID header field can appear in all=20 >>>>>>>> SIP methods except ACK and CANCEL; however, it cannot be sent=20 >>>>>>>> in >>>>>>>>> any mid-dialog requests." >>>>>>> Seems reasonable, but I'll verify with my 3GPP delegates. >>>>>> I had a closer look at this, and I don't think we can forbid=20 >>>>>> usage in all mid-dialog requests. >>>>>> >>>>>> For example, the header field is allowed in OPTIONS, that can be=20 >>>>>> sent in-dialog. >>>>>> >>>>>> Also, the header field is allowed in REFER, and RFC 7614 defines=20 >>>>>> a mechanism that allows in-dialog REFERs. >>>>>> >>>>>> re-INVITE is also tricky. The header field is generally allowed=20 >>>>>> in INVITE requests, but there is no text explicitly disallowing=20 >>>>>> it in re-INVITEs. >>>>>> >>>>>> Whether it makes sense to include the header field in the methods=20 >>>>>> above I don't know (3GPP does allow them), but as the purpose is=20 >>>>>> only to align >>>>>> 7315 with 3455 I'd suggest we keep the text as it is. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 3/7/16 14:08, A. Jean Mahoney wrote: >>>>>> Since this draft updates RFC 7315, which required expert review=20 >>>>>> of its header fields, Adam Roach will be conducting an expert=20 >>>>>> review of this draft according to the guidance given in RFC 5727. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jean >>>>>> >>>>>> >>>>>> On 3/7/16 9:33 AM, Mary Barnes wrote: >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> This document has been proposed to be progressed as AD sponsored: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315- >>>>>> u >>>>>> pdate >>>>>> s/ >>>>>> The document has been carefully reviewed and it is now ready to=20 >>>>>> move forward - Jean Mahoney is the shepherd. >>>>>> >>>>>> I don't anticipate anyone would have concerns about this=20 >>>>>> decision, given that's how RFC 7315 was progressed and this=20 >>>>>> update has actually been much more carefully reviewed. However,=20 >>>>>> f anyone has any final comments, please post no later than=20 >>>>>> Friday, March 11th, 2016. Note, that you will also still have=20 >>>>>> IETF LC to provide any comments. >>>>>> >>>>>> Regards, >>>>>> Mary. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 27 13:39:48 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467EB12D888 for ; Wed, 27 Apr 2016 13:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 dfz03nC-AzPr for ; Wed, 27 Apr 2016 13:39:44 -0700 (PDT) Received: from forward11h.cmail.yandex.net (forward11h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::9c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD94812D1C8 for ; Wed, 27 Apr 2016 13:39:43 -0700 (PDT) Received: from web17h.yandex.ru (web17h.yandex.ru [84.201.186.46]) by forward11h.cmail.yandex.net (Yandex) with ESMTP id 95729217BC; Wed, 27 Apr 2016 23:39:40 +0300 (MSK) Received: from web17h.yandex.ru (localhost [127.0.0.1]) by web17h.yandex.ru (Yandex) with ESMTP id 0C3F4C200CD; Wed, 27 Apr 2016 23:39:39 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1461789580; bh=tZV4DLTHsPp/yszgLLl1/aRStdxZmVPBUZ7VJV2v0UQ=; h=From:To:Subject:Date; b=BujDlOyaDYcHnMKTb8Gvxa+6e27CvxV/SVegnE9scYtckOOyB/LeNLKudlgNypLtk 6I0JmUSBHTY+nQ5defPcdDbuLu8NrlrkHG0YSt2WDw3XA8jPXC7ayUvy9vMVdunyJ8 ViSgwd+pOm5fgZQImGqc6Tq6vYIazEG70yAZ4JmE= Received: by web17h.yandex.ru with HTTP; Wed, 27 Apr 2016 23:39:39 +0300 From: Anton Tveretin To: "nigel.weinronk@gamma.co.uk" , DISPATCH list MIME-Version: 1.0 Message-Id: <818321461789579@web17h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 28 Apr 2016 01:39:39 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] draft-weinronk-dispatch-last-diverting-line-id-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 20:39:46 -0000 Hello, Nigel, and all, The question is interworking between SIP and ISUP. Otherwise, we all would agree that we need an extra parameter for History-Info:, and no new header. So I ask: what if a call arrives from ISUP network? How History-Info is generated? Best regards, Anton