From dromasca@avaya.com Sun Jan 6 03:02:51 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FD821F8792; Sun, 6 Jan 2013 03:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ6B074GJO76; Sun, 6 Jan 2013 03:02:50 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC921F876E; Sun, 6 Jan 2013 03:02:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiELAIbQt1CHCzI1/2dsb2JhbABEgX9tvRkWbAeCIAEBAxIoPxIBFQcOCwlCJgEEDg0ah24BC6F7nQyNToJSYQOXHYRxijeCcoIh X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="383181475" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jan 2013 05:53:20 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jan 2013 05:37:44 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Sun, 6 Jan 2013 06:02:56 -0500 From: "Romascanu, Dan (Dan)" To: "gen-art@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-sipcore-priority-00 Thread-Index: Ac3r/WFC4Hd4LmqrRT+lKfz3Gc1Hnw== Date: Sun, 6 Jan 2013 11:02:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0572F5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: [sipcore] Gen-ART review of draft-ietf-sipcore-priority-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 11:02:51 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/Ge= nArtfaq>. Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Document: draft-ietf-sipcore-priority-00 Reviewer: Dan Romascanu Review Date: 1/6/13 IETF LC End Date: 1/7/13 IESG Telechat date: 1/10/13 Summary: ready for publication, one minor issue Major issues: none Minor issues: In the IANA considerations section this document requires IAN= A to create a new registry with the suggested name "Priority Header Field V= alues". For clarity purposes, taking into account that other protocols may = also carry priority fields in headers, I suggest that a better name would b= e "SIP Priority Header Field Values"=20 Nits/editorial comments: Regards, Dan From ibc@aliax.net Wed Jan 9 03:33:40 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2321F86C0 for ; Wed, 9 Jan 2013 03:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbeZXo9lNq+F for ; Wed, 9 Jan 2013 03:33:39 -0800 (PST) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03F21F8651 for ; Wed, 9 Jan 2013 03:33:28 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id b23so1387367vbz.26 for ; Wed, 09 Jan 2013 03:33:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=kmphwwKK9Orz5SnKsjLTQsLH7MdLkg8D45V3xS9XJeo=; b=kuiSlNirUISt5xa15FW6bmPH5/DZrz82IecR7ORCm7k4vArhBQOQkNNyXgeyDUzAtN O8N3L5IWjSpLhkJwFQkr3QROQpDL+GxhYsHCbc2gD6mp/r62A9WWwb4yBJgOxOXwNGGV B4u0WzvKcndHjQcv5KrfbO6Kay4yC/pyr4fAh4fjHsJyR7Of3fmxWAP/jFvIE4HUhU8x xIJOo2jA6+CLKA3gvopqHY9H7vi4biK9MANJpnP9lN0vjtlFfgwNee6DQRo8HMozgxcl jnbD7IG1OAEiBoVjaHNVP/1a8gIaWNF5wUgbqvqmyQX+E5Uh+DHLeWsyA1I+cA0/fGI5 WtFA== Received: by 10.221.11.205 with SMTP id pf13mr87368501vcb.70.1357731208088; Wed, 09 Jan 2013 03:33:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.59.11.97 with HTTP; Wed, 9 Jan 2013 03:33:08 -0800 (PST) In-Reply-To: <50ED4128.8020104@intertex.se> References: <50ED4128.8020104@intertex.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Jan 2013 12:33:08 +0100 Message-ID: To: Martin Vopatek , "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnSTJxNtiyvBVgkqVug23oIgU0B3Ca3npBjGkMN1PDLHsjrUyggqi/Uaoxli0rMZDaKI7c6 Cc: draft-ietf-sipcore-sip-websocket@tools.ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-sip-websocket-06: comment X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 11:33:40 -0000 2013/1/9 Martin Vopatek : > Regarding draft-ietf-sipcore-sip-websocket-06. > > * Section 5.2.2 SIP URI Transport Parameter says: > "The updated augmented BNF (Backus-Naur Form) for this parameter is > the following (the original BNF for this parameter can be found in > [RFC3261], which was then updated by [RFC4168]):" > > But it looks like RFC 4168 only updates the transport part of the Via > header field. > Not the SIP URI transport parameter which this section specifies. Thanks a lot Martin, you are right. This will be addressed in revision 07 of the draft along with other pending improvements/changes provided by other members of the SIPCORE WG. --=20 I=C3=B1aki Baz Castillo From rjsparks@nostrum.com Wed Jan 9 11:31:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB1B21F8818; Wed, 9 Jan 2013 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4ZgKWA3GlQc; Wed, 9 Jan 2013 11:31:19 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD3221F8613; Wed, 9 Jan 2013 11:31:19 -0800 (PST) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r09JVI7R028332 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 13:31:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50EDC586.7000008@nostrum.com> Date: Wed, 09 Jan 2013 13:31:18 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: iesg@ietf.org, "sipcore@ietf.org" References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> In-Reply-To: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 19:31:20 -0000 SIPCORE WG - At the urging of a few ADs, I'd like to capture a brief statement of _why_ the working group chose IETF Review for this registry over a lighter-weight mechanism. Would anyone object to adding this text to the IANA registration section: "This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. Efforts considering adding a Priority value should consider whether the SIP Resource-Priority or even a different protocol would be more appropriate for achieving their requirements." Please respond ASAP. RjS On 1/8/13 11:13 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-sipcore-priority-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Russ's DISCUSS, but it's trivial to fix and discussion has > already converged on that. > > The shepherd writeup says this: > > The policy for adding new values to the registry was intentionally > chosen to be IETF Review. We do not anticipate many additions, and > feel this level of review will ensure that any such additions are > well considered. > > I have discussed this with Robert, and am happy to clear my DISCUSS on it > (having had the discussion) and move it to a non-blocking comment. Our > discussion made it clear that there have been problems with attempts to > use this header field, that scrutiny of the usage proposals is important, > and that a single expert isn't appropriate because conversation within > the SIP community is often important in teasing out issue with > proposals. > > That said, if you can find a way to put a paragraph explaining that into > the document, as an explanation to and a warning to those who might want > to mint new values for this header field, I think it would be useful. I > don't think it should take much, though I understand that there are > political land mines that you'll want to step around as you do it. > > And remember that this is non-blocking, so if you really can't see a good > way to say it I'm not going to insist further. > > From rbarnes@bbn.com Wed Jan 9 15:27:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43D321F850C; Wed, 9 Jan 2013 15:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCqej2LfU4-f; Wed, 9 Jan 2013 15:27:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 001A721F84BB; Wed, 9 Jan 2013 15:27:56 -0800 (PST) Received: from ros-dhcp192-1-51-63.bbn.com ([192.1.51.63]:64064) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tt53s-00047t-0A; Wed, 09 Jan 2013 18:27:56 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: <50EDC586.7000008@nostrum.com> Date: Wed, 9 Jan 2013 18:27:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <55973D9C-4906-409F-8DF8-C4D6C94630D8@bbn.com> References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> <50EDC586.7000008@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1499) Cc: "sipcore@ietf.org" , iesg@ietf.org Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:27:57 -0000 That text looks fine to me. I think it summarizes the consensus of the = group well. --Richard=20 On Jan 9, 2013, at 2:31 PM, Robert Sparks wrote: > SIPCORE WG - >=20 > At the urging of a few ADs, I'd like to capture a brief statement of = _why_ the working > group chose IETF Review for this registry over a lighter-weight = mechanism. Would > anyone object to adding this text to the IANA registration section: >=20 > "This policy was chosen over lighter-weight policies due the potential = architectural impact of the semantics associated with new values. = Efforts considering adding a Priority value should consider whether the = SIP Resource-Priority or even a different protocol would be more = appropriate for achieving their requirements." >=20 > Please respond ASAP. >=20 > RjS >=20 >=20 > On 1/8/13 11:13 AM, Barry Leiba wrote: >> Barry Leiba has entered the following ballot position for >> draft-ietf-sipcore-priority-00: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I support Russ's DISCUSS, but it's trivial to fix and discussion has >> already converged on that. >>=20 >> The shepherd writeup says this: >>=20 >> The policy for adding new values to the registry was = intentionally >> chosen to be IETF Review. We do not anticipate many additions, = and >> feel this level of review will ensure that any such additions are >> well considered. >>=20 >> I have discussed this with Robert, and am happy to clear my DISCUSS = on it >> (having had the discussion) and move it to a non-blocking comment. = Our >> discussion made it clear that there have been problems with attempts = to >> use this header field, that scrutiny of the usage proposals is = important, >> and that a single expert isn't appropriate because conversation = within >> the SIP community is often important in teasing out issue with >> proposals. >>=20 >> That said, if you can find a way to put a paragraph explaining that = into >> the document, as an explanation to and a warning to those who might = want >> to mint new values for this header field, I think it would be useful. = I >> don't think it should take much, though I understand that there are >> political land mines that you'll want to step around as you do it. >>=20 >> And remember that this is non-blocking, so if you really can't see a = good >> way to say it I'm not going to insist further. >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Wed Jan 9 15:30:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7F911E80A2; Wed, 9 Jan 2013 15:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL5wje8SbaP0; Wed, 9 Jan 2013 15:30:56 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6631021F850C; Wed, 9 Jan 2013 15:30:56 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r09NUoAY053024 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 17:30:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50EDFDAA.90409@nostrum.com> Date: Wed, 09 Jan 2013 17:30:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Richard Barnes References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> <50EDC586.7000008@nostrum.com> <55973D9C-4906-409F-8DF8-C4D6C94630D8@bbn.com> In-Reply-To: <55973D9C-4906-409F-8DF8-C4D6C94630D8@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , iesg@ietf.org Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:30:57 -0000 It sounds fine to me as well. /a On 1/9/13 17:27, Richard Barnes wrote: > That text looks fine to me. I think it summarizes the consensus of the group well. > --Richard > > > On Jan 9, 2013, at 2:31 PM, Robert Sparks wrote: > >> SIPCORE WG - >> >> At the urging of a few ADs, I'd like to capture a brief statement of _why_ the working >> group chose IETF Review for this registry over a lighter-weight mechanism. Would >> anyone object to adding this text to the IANA registration section: >> >> "This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. Efforts considering adding a Priority value should consider whether the SIP Resource-Priority or even a different protocol would be more appropriate for achieving their requirements." >> >> Please respond ASAP. >> >> RjS >> >> >> On 1/8/13 11:13 AM, Barry Leiba wrote: >>> Barry Leiba has entered the following ballot position for >>> draft-ietf-sipcore-priority-00: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I support Russ's DISCUSS, but it's trivial to fix and discussion has >>> already converged on that. >>> >>> The shepherd writeup says this: >>> >>> The policy for adding new values to the registry was intentionally >>> chosen to be IETF Review. We do not anticipate many additions, and >>> feel this level of review will ensure that any such additions are >>> well considered. >>> >>> I have discussed this with Robert, and am happy to clear my DISCUSS on it >>> (having had the discussion) and move it to a non-blocking comment. Our >>> discussion made it clear that there have been problems with attempts to >>> use this header field, that scrutiny of the usage proposals is important, >>> and that a single expert isn't appropriate because conversation within >>> the SIP community is often important in teasing out issue with >>> proposals. >>> >>> That said, if you can find a way to put a paragraph explaining that into >>> the document, as an explanation to and a warning to those who might want >>> to mint new values for this header field, I think it would be useful. I >>> don't think it should take much, though I understand that there are >>> political land mines that you'll want to step around as you do it. >>> >>> And remember that this is non-blocking, so if you really can't see a good >>> way to say it I'm not going to insist further. >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gsalguei@cisco.com Wed Jan 9 15:34:36 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF521F845A for ; Wed, 9 Jan 2013 15:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yI-VcVXl4mK for ; Wed, 9 Jan 2013 15:34:35 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9756021F86EC for ; Wed, 9 Jan 2013 15:34:35 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r09NYYgT003569 for ; Wed, 9 Jan 2013 18:34:34 -0500 (EST) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r09NYY6Q021746; Wed, 9 Jan 2013 18:34:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <50EDC586.7000008@nostrum.com> Date: Wed, 9 Jan 2013 18:34:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6260F677-B66D-4A8C-B3FE-0978546DCD82@cisco.com> References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> <50EDC586.7000008@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1283) Cc: sipcore@ietf.org, The IESG Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 23:34:36 -0000 The suggested text sounds perfectly reasonable to me. Cheers, Gonzalo On Jan 9, 2013, at 2:31 PM, Robert Sparks wrote: > SIPCORE WG - >=20 > At the urging of a few ADs, I'd like to capture a brief statement of = _why_ the working > group chose IETF Review for this registry over a lighter-weight = mechanism. Would > anyone object to adding this text to the IANA registration section: >=20 > "This policy was chosen over lighter-weight policies due the potential = architectural impact of the semantics associated with new values. = Efforts considering adding a Priority value should consider whether the = SIP Resource-Priority or even a different protocol would be more = appropriate for achieving their requirements." >=20 > Please respond ASAP. >=20 > RjS >=20 >=20 > On 1/8/13 11:13 AM, Barry Leiba wrote: >> Barry Leiba has entered the following ballot position for >> draft-ietf-sipcore-priority-00: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I support Russ's DISCUSS, but it's trivial to fix and discussion has >> already converged on that. >>=20 >> The shepherd writeup says this: >>=20 >> The policy for adding new values to the registry was = intentionally >> chosen to be IETF Review. We do not anticipate many additions, = and >> feel this level of review will ensure that any such additions are >> well considered. >>=20 >> I have discussed this with Robert, and am happy to clear my DISCUSS = on it >> (having had the discussion) and move it to a non-blocking comment. = Our >> discussion made it clear that there have been problems with attempts = to >> use this header field, that scrutiny of the usage proposals is = important, >> and that a single expert isn't appropriate because conversation = within >> the SIP community is often important in teasing out issue with >> proposals. >>=20 >> That said, if you can find a way to put a paragraph explaining that = into >> the document, as an explanation to and a warning to those who might = want >> to mint new values for this header field, I think it would be useful. = I >> don't think it should take much, though I understand that there are >> political land mines that you'll want to step around as you do it. >>=20 >> And remember that this is non-blocking, so if you really can't see a = good >> way to say it I'm not going to insist further. >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From jmpolk@cisco.com Wed Jan 9 20:53:37 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8BC1F0D0C; Wed, 9 Jan 2013 20:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTIFZCu0xpDG; Wed, 9 Jan 2013 20:53:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 84C361F0D05; Wed, 9 Jan 2013 20:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2946; q=dns/txt; s=iport; t=1357793616; x=1359003216; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=+LeDbalApGrQpGZ5/JhByFy1b+9f7sNtDeJFhBFGMtE=; b=UVK8fcfYhuSFf93OIGZLYT7U/8NFcEri280Q4bY17qbeY6Hw0flITsEZ ttlY3cT7YalYg0r5psKHacG1d9Fm/MK23NUdY3n+c3ovnOSP9iizAE/wK Jo2uLQc0DUVpTdQK4lmUXUnDadfQydI2YeLuK9hUdHjSlpf/fe+ulDBUn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALJG7lCtJXG9/2dsb2JhbABEvWoWc4IeAQEBBAEBATUCMQMbBwQOCgkVEA8KDjAGARIJC4gFDLYSjGKDV2EDiGKdc4MTgVA X-IronPort-AV: E=Sophos;i="4.84,441,1355097600"; d="scan'208";a="157805471" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 10 Jan 2013 04:53:35 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0A4rZuE024660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 04:53:35 GMT Message-Id: <201301100453.r0A4rZuE024660@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Jan 2013 22:53:36 -0600 To: Robert Sparks , , "sipcore@ietf.org" From: James Polk In-Reply-To: <50EDC586.7000008@nostrum.com> References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> <50EDC586.7000008@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 04:53:37 -0000 At 01:31 PM 1/9/2013, Robert Sparks wrote: >SIPCORE WG - > >At the urging of a few ADs, I'd like to capture a brief statement of >_why_ the working >group chose IETF Review for this registry over a lighter-weight >mechanism. Would >anyone object to adding this text to the IANA registration section: > >"This policy was chosen over lighter-weight policies due the >potential architectural impact of the semantics associated with new >values. Efforts considering adding a Priority value should consider >whether the SIP Resource-Priority ...[RFC4412]... >or even a different protocol would be more appropriate for achieving >their requirements." I'm fine with the above reference added. James >Please respond ASAP. > >RjS > > >On 1/8/13 11:13 AM, Barry Leiba wrote: >>Barry Leiba has entered the following ballot position for >>draft-ietf-sipcore-priority-00: No Objection >> >>When responding, please keep the subject line intact and reply to all >>email addresses included in the To and CC lines. (Feel free to cut this >>introductory paragraph, however.) >> >> >>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >>I support Russ's DISCUSS, but it's trivial to fix and discussion has >>already converged on that. >> >>The shepherd writeup says this: >> >> The policy for adding new values to the registry was intentionally >> chosen to be IETF Review. We do not anticipate many additions, and >> feel this level of review will ensure that any such additions are >> well considered. >> >>I have discussed this with Robert, and am happy to clear my DISCUSS on it >>(having had the discussion) and move it to a non-blocking comment. Our >>discussion made it clear that there have been problems with attempts to >>use this header field, that scrutiny of the usage proposals is important, >>and that a single expert isn't appropriate because conversation within >>the SIP community is often important in teasing out issue with >>proposals. >> >>That said, if you can find a way to put a paragraph explaining that into >>the document, as an explanation to and a warning to those who might want >>to mint new values for this header field, I think it would be useful. I >>don't think it should take much, though I understand that there are >>political land mines that you'll want to step around as you do it. >> >>And remember that this is non-blocking, so if you really can't see a good >>way to say it I'm not going to insist further. >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From brian.rosen@neustar.biz Thu Jan 10 06:25:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD5F21F8833; Thu, 10 Jan 2013 06:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub195Y5gkNeL; Thu, 10 Jan 2013 06:25:14 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id B8BB521F881A; Thu, 10 Jan 2013 06:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1357827902; x=1673185585; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=L+DUpmedAwjTcwBq9UuK5 /Scl1btrZkpTy2dZrH8cSU=; b=JvOCiVdmnOs3cy6729rMpCmgobgvOn98azGwr GYsZLCBUbmQue3Cvp1RfOXDpY0bU0pZFNdVh4aUUQfYHfmBSg== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP id J041123128.13808710; Thu, 10 Jan 2013 09:25:01 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 10 Jan 2013 09:25:09 -0500 From: "Rosen, Brian" To: Robert Sparks Date: Thu, 10 Jan 2013 09:25:09 -0500 Thread-Topic: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) Thread-Index: Ac3vPkum4h6uW9F3SAG/4jYrC+SXlg== Message-ID: References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> <50EDC586.7000008@nostrum.com> In-Reply-To: <50EDC586.7000008@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: vehblWIuSPtg1dP2GujkRA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "iesg@ietf.org" Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 14:25:16 -0000 Very good idea. =20 Brian On Jan 9, 2013, at 2:31 PM, Robert Sparks wrote: > SIPCORE WG - >=20 > At the urging of a few ADs, I'd like to capture a brief statement of _why= _ the working > group chose IETF Review for this registry over a lighter-weight mechanism= . Would > anyone object to adding this text to the IANA registration section: >=20 > "This policy was chosen over lighter-weight policies due the potential ar= chitectural impact of the semantics associated with new values. Efforts con= sidering adding a Priority value should consider whether the SIP Resource-P= riority or even a different protocol would be more appropriate for achievin= g their requirements." >=20 > Please respond ASAP. >=20 > RjS >=20 >=20 > On 1/8/13 11:13 AM, Barry Leiba wrote: >> Barry Leiba has entered the following ballot position for >> draft-ietf-sipcore-priority-00: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> I support Russ's DISCUSS, but it's trivial to fix and discussion has >> already converged on that. >>=20 >> The shepherd writeup says this: >>=20 >> The policy for adding new values to the registry was intentionally >> chosen to be IETF Review. We do not anticipate many additions, and >> feel this level of review will ensure that any such additions are >> well considered. >>=20 >> I have discussed this with Robert, and am happy to clear my DISCUSS on i= t >> (having had the discussion) and move it to a non-blocking comment. Our >> discussion made it clear that there have been problems with attempts to >> use this header field, that scrutiny of the usage proposals is important= , >> and that a single expert isn't appropriate because conversation within >> the SIP community is often important in teasing out issue with >> proposals. >>=20 >> That said, if you can find a way to put a paragraph explaining that into >> the document, as an explanation to and a warning to those who might want >> to mint new values for this header field, I think it would be useful. I >> don't think it should take much, though I understand that there are >> political land mines that you'll want to step around as you do it. >>=20 >> And remember that this is non-blocking, so if you really can't see a goo= d >> way to say it I'm not going to insist further. >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From jgunn6@csc.com Thu Jan 10 06:40:00 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB7421F868F; Thu, 10 Jan 2013 06:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYR+ZU1EbUgn; Thu, 10 Jan 2013 06:39:59 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.255.50]) by ietfa.amsl.com (Postfix) with ESMTP id C550821F8496; Thu, 10 Jan 2013 06:39:58 -0800 (PST) Received: from [216.82.253.243:34465] by server-7.bemta-7.messagelabs.com id 15/0E-20845-DB2DEE05; Thu, 10 Jan 2013 14:39:57 +0000 X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-171.messagelabs.com!1357828796!24286974!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6111 invoked from network); 10 Jan 2013 14:39:57 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jan 2013 14:39:57 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0AEdfnH019235; Thu, 10 Jan 2013 09:39:55 -0500 In-Reply-To: <201301100453.r0A4rZuE024660@rcdn-core2-2.cisco.com> References: <20130108171322.6165.66995.idtracker@ietfa.amsl.com> <50EDC586.7000008@nostrum.com> <201301100453.r0A4rZuE024660@rcdn-core2-2.cisco.com> To: James Polk MIME-Version: 1.0 X-KeepSent: CB33A3BA:17EBB001-85257AEF:00504656; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Thu, 10 Jan 2013 09:39:52 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 01/10/2013 09:34:56 AM, Serialize complete at 01/10/2013 09:34:56 AM Content-Type: multipart/alternative; boundary="=_alternative 00508DC985257AEF_=" Cc: sipcore-bounces@ietf.org, "sipcore@ietf.org" , iesg@ietf.org Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-priority-00: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 14:40:00 -0000 This is a multipart message in MIME format. --=_alternative 00508DC985257AEF_= Content-Type: text/plain; charset="US-ASCII" I am fine with it, including James's comment. I just think the wording is terribly ironic considering the hoops we had to jump through to show that we needed "Resource Priority", and that "Priority" wasn't enough. Janet sipcore-bounces@ietf.org wrote on 01/09/2013 11:53:36 PM: > From: James Polk > To: Robert Sparks , , > "sipcore@ietf.org" > Date: 01/09/2013 11:53 PM > Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf- > sipcore-priority-00: (with COMMENT) > Sent by: sipcore-bounces@ietf.org > > At 01:31 PM 1/9/2013, Robert Sparks wrote: > >SIPCORE WG - > > > >At the urging of a few ADs, I'd like to capture a brief statement of > >_why_ the working > >group chose IETF Review for this registry over a lighter-weight > >mechanism. Would > >anyone object to adding this text to the IANA registration section: > > > >"This policy was chosen over lighter-weight policies due the > >potential architectural impact of the semantics associated with new > >values. Efforts considering adding a Priority value should consider > >whether the SIP Resource-Priority > > ...[RFC4412]... > > >or even a different protocol would be more appropriate for achieving > >their requirements." > > I'm fine with the above reference added. > > James > > > >Please respond ASAP. > > > >RjS > > > > > >On 1/8/13 11:13 AM, Barry Leiba wrote: > >>Barry Leiba has entered the following ballot position for > >>draft-ietf-sipcore-priority-00: No Objection > >> > >>When responding, please keep the subject line intact and reply to all > >>email addresses included in the To and CC lines. (Feel free to cut this > >>introductory paragraph, however.) > >> > >> > >>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > >>for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> > >> > >>---------------------------------------------------------------------- > >>COMMENT: > >>---------------------------------------------------------------------- > >> > >>I support Russ's DISCUSS, but it's trivial to fix and discussion has > >>already converged on that. > >> > >>The shepherd writeup says this: > >> > >> The policy for adding new values to the registry was intentionally > >> chosen to be IETF Review. We do not anticipate many additions, and > >> feel this level of review will ensure that any such additions are > >> well considered. > >> > >>I have discussed this with Robert, and am happy to clear my DISCUSS on it > >>(having had the discussion) and move it to a non-blocking comment. Our > >>discussion made it clear that there have been problems with attempts to > >>use this header field, that scrutiny of the usage proposals is important, > >>and that a single expert isn't appropriate because conversation within > >>the SIP community is often important in teasing out issue with > >>proposals. > >> > >>That said, if you can find a way to put a paragraph explaining that into > >>the document, as an explanation to and a warning to those who might want > >>to mint new values for this header field, I think it would be useful. I > >>don't think it should take much, though I understand that there are > >>political land mines that you'll want to step around as you do it. > >> > >>And remember that this is non-blocking, so if you really can't see a good > >>way to say it I'm not going to insist further. > >> > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=_alternative 00508DC985257AEF_= Content-Type: text/html; charset="US-ASCII"
I am fine with it, including James's comment.

I just think the wording is terribly ironic considering the hoops we had to jump through to show that we needed "Resource Priority", and that  "Priority" wasn't enough.

Janet

sipcore-bounces@ietf.org wrote on 01/09/2013 11:53:36 PM:

> From: James Polk <jmpolk@cisco.com>
> To: Robert Sparks <rjsparks@nostrum.com>, <iesg@ietf.org>,
> "sipcore@ietf.org" <sipcore@ietf.org>
> Date: 01/09/2013 11:53 PM
> Subject: Re: [sipcore] Barry Leiba's No Objection on draft-ietf-
> sipcore-priority-00: (with COMMENT)
> Sent by: sipcore-bounces@ietf.org
>
> At 01:31 PM 1/9/2013, Robert Sparks wrote:
> >SIPCORE WG -
> >
> >At the urging of a few ADs, I'd like to capture a brief statement of
> >_why_ the working
> >group chose IETF Review for this registry over a lighter-weight
> >mechanism. Would
> >anyone object to adding this text to the IANA registration section:
> >
> >"This policy was chosen over lighter-weight policies due the
> >potential architectural impact of the semantics associated with new
> >values. Efforts considering adding a Priority value should consider
> >whether the SIP Resource-Priority
>
> ...[RFC4412]...
>
> >or even a different protocol would be more appropriate for achieving
> >their requirements."
>
> I'm fine with the above reference added.
>
> James
>
>
> >Please respond ASAP.
> >
> >RjS
> >
> >
> >On 1/8/13 11:13 AM, Barry Leiba wrote:
> >>Barry Leiba has entered the following ballot position for
> >>draft-ietf-sipcore-priority-00: No Objection
> >>
> >>When responding, please keep the subject line intact and reply to all
> >>email addresses included in the To and CC lines. (Feel free to cut this
> >>introductory paragraph, however.)
> >>
> >>
> >>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> >>for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >>
> >>
> >>----------------------------------------------------------------------
> >>COMMENT:
> >>----------------------------------------------------------------------
> >>
> >>I support Russ's DISCUSS, but it's trivial to fix and discussion has
> >>already converged on that.
> >>
> >>The shepherd writeup says this:
> >>
> >>      The policy for adding new values to the registry was intentionally
> >>      chosen to be IETF Review. We do not anticipate many additions, and
> >>      feel this level of review will ensure that any such additions are
> >>      well considered.
> >>
> >>I have discussed this with Robert, and am happy to clear my DISCUSS on it
> >>(having had the discussion) and move it to a non-blocking comment.  Our
> >>discussion made it clear that there have been problems with attempts to
> >>use this header field, that scrutiny of the usage proposals is important,
> >>and that a single expert isn't appropriate because conversation within
> >>the SIP community is often important in teasing out issue with
> >>proposals.
> >>
> >>That said, if you can find a way to put a paragraph explaining that into
> >>the document, as an explanation to and a warning to those who might want
> >>to mint new values for this header field, I think it would be useful.  I
> >>don't think it should take much, though I understand that there are
> >>political land mines that you'll want to step around as you do it.
> >>
> >>And remember that this is non-blocking, so if you really can't see a good
> >>way to say it I'm not going to insist further.
> >>
> >
> >_______________________________________________
> >sipcore mailing list
> >sipcore@ietf.org
> >https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
 --=_alternative 00508DC985257AEF_=-- From adam@nostrum.com Thu Jan 10 10:12:44 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E9821F8A0D for ; Thu, 10 Jan 2013 10:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heRA+XGSruCY for ; Thu, 10 Jan 2013 10:12:43 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A316021F8967 for ; Thu, 10 Jan 2013 10:12:43 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0AICgfw074283 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Jan 2013 12:12:42 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50EF049A.2020202@nostrum.com> Date: Thu, 10 Jan 2013 12:12:42 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "'SIPCORE'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [sipcore] Not meeting in Orlando X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:12:44 -0000 [as chair] SIPCORE participants: At the moment, we do not see any reason to request a timeslot for face-to-face discussions at the upcoming meeting in Orlando. If anyone objects to this course of action, please contact to me and Paul as rapidly as possible. Our deadline for requesting a slot is Monday. Thanks! /a From internet-drafts@ietf.org Fri Jan 11 13:59:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9121F88B9; Fri, 11 Jan 2013 13:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHB07sOOblUE; Fri, 11 Jan 2013 13:59:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C72421F88AE; Fri, 11 Jan 2013 13:59:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111215957.15476.594.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 13:59:57 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-11.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:59:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) fo= r Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-11.txt Pages : 36 Date : 2013-01-11 Abstract: This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Fri Jan 11 14:12:26 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2762F21F8A50 for ; Fri, 11 Jan 2013 14:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2b367YhSAl2 for ; Fri, 11 Jan 2013 14:12:25 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB021F8953 for ; Fri, 11 Jan 2013 14:12:25 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id d13so215661qak.4 for ; Fri, 11 Jan 2013 14:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7rNlgCrO95bOzorYvnQw4CFK3dLieEji5K2IqJkssg0=; b=zcObZbX1ji6UIo/tn4XFvkGFrJ6Aw6DoOUCvelJ4/wMkFBGHRbWduWRd8W9Pmb/DzP WcZkx79VsocUHzFBNOi7djvN4k3mOZ9Dtpd7uMIjzUX198/C/5YtVcd2nHWmLntoFAzn YmChVeUeJTpxiP4Ea2LfpmZYzUgIXLtwHfwygNVYxFeByNU8qDCvfFoG7RH73IRavvml ZQUZSq3QYwh/PSNQuXwjG/KyRnK76xURoQFrcjBT/+NWNrrhy62vRrkpTLmCAAbHy3+w UFYzvtbOruz/Sm7mJzowg7MYlcw3ZUERCRN6JC+jpr4cHHk4Qk80/cLRu9cy14GL5iOK l7fA== MIME-Version: 1.0 Received: by 10.229.178.199 with SMTP id bn7mr15391640qcb.14.1357942344670; Fri, 11 Jan 2013 14:12:24 -0800 (PST) Received: by 10.49.131.199 with HTTP; Fri, 11 Jan 2013 14:12:24 -0800 (PST) In-Reply-To: <20130111215957.15476.594.idtracker@ietfa.amsl.com> References: <20130111215957.15476.594.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 16:12:24 -0600 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Fwd: I-D Action: draft-ietf-sipcore-rfc4244bis-11.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 22:12:26 -0000 Hi all, The document has been updated to reflect the comments made after the WG and IETF last call for this document, during the WG last call for draft-ietf-sipcore-rfc4244bis-callflows. The changes are as follows: 1) Added text in the intro (section1) and overview (section 4) to indicate the priv-value of "history" and the option tag of "histinfo" are defined in this document (Marianne's comments MM#1 and MM#2), with references to the relevant sections describing normative behavior. 2) Clarified that the hi-entries are added in chronological order (Dale's comments). 3) Added text around the fact that the hi-index can be the same for multiple entries in the case of forking by a proxy that does not support History-info (per Dale and Paul's comments). 4) Added text in section 12 voicemail application example that if the "rc" tag is not present, then the behavior can default to that as defined in RFC 4458 (Marianne's comment MM#4). 5) Fixed the example in section 5.1 to show that the UAC adds and hi-entry (Brett's comment). 6) Fixed a few typos. Please note that the call flow document has not yet been updated based upon the WGLC comments. Regards, Mary. ---------- Forwarded message ---------- From: Date: Fri, Jan 11, 2013 at 3:59 PM Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-11.txt To: i-d-announce@ietf.org Cc: sipcore@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-11.txt Pages : 36 Date : 2013-01-11 Abstract: This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From iesg-secretary@ietf.org Mon Jan 14 13:00:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30CC21F8B58; Mon, 14 Jan 2013 13:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfH-u52FF2BP; Mon, 14 Jan 2013 13:00:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866BF21F8B62; Mon, 14 Jan 2013 13:00:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114210019.15005.16280.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 13:00:19 -0800 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Protocol Action: 'IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field' to Proposed Standard (draft-ietf-sipcore-priority-00.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:00:21 -0000 The IESG has approved the following document: - 'IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field' (draft-ietf-sipcore-priority-00.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-priority/ Technical Summary This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. This header field was defined in [RFC3261], section 20.26. It was clearly specified in a way that allows for the creation of new values beyond those originally specified; however, no registry has been established for it. Working Group Summary This work was initiated because the ECRIT WG had a need to define a new value for the Priority header field, for use in new document draft-ietf-ecrit-psap-callback. RFC 3261 was written to allow such extensions, but had no mechanism to manage extensions. The chairs of ECRIT and SIPCORE and the ADs discussed this and considered various mechanisms to move forward. The alternatives considered were: - construct the ECRIT document as an update to RFC 3261, extending the syntax of the Priority header field. - construct the ECRIT document as an update to RFC 3261, introducing an IANA registry for Priority header field values, populating it with those values defined in RFC 3261 and also the desired new value. - publish a new draft, in the SIPCORE WG, that updates RFC 3261, introducing an IANA registry for Priority header field values, and populating it with those values defined in RFC 3261. Then the ECRIT WG can modify their document to register the new value in accord with the new registration procedures. We concluded that the last approach was the cleanest one. This draft is result. Document Quality Are there existing implementations of the protocol? This defines no new protocol. draft-ietf-ecrit-psap-callback is progressing in parallel and will make use of the new registration mechanism. Have a significant number of vendors indicated their plan to implement the specification? N/A Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? The document is very simple, so didn't require great effort to review. The primary commenters on the draft were Christer Holmberg and Keith Drage. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Robert Sparks RFC-Editor Note: Please make the following three changes to version -00 of this draft) Change 1 (replaces text): OLD: This document adds a new registry, "Priority Header Field Values." NEW: This document adds a new sub-registry, "Priority Header Field Values" to the "Session Initiation Protocol (SIP) Parameters" registry page. Change 2 (only adds text): OLD: The policy for registration of values in this registry is "IETF Review," as that term is defined by [RFC5226]. NEW: The policy for registration of values in this registry is "IETF Review," as that term is defined by [RFC5226]. This policy was chosen over lighter-weight policies due the potential architectural impact of the semantics associated with new values. Efforts considering adding a Priority value should consider whether the SIP Resource-Priority [RFC4412] or even a different protocol would be more appropriate for achieving their requirements. Change 3 : Please add an informational reference to RFC4412. From rjsparks@nostrum.com Wed Jan 16 11:19:43 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3921F8AA3 for ; Wed, 16 Jan 2013 11:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap+D4nkNHweX for ; Wed, 16 Jan 2013 11:19:43 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 78D1221F8A6C for ; Wed, 16 Jan 2013 11:19:43 -0800 (PST) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0GJJgUE026102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 16 Jan 2013 13:19:42 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50F6FD4E.7010806@nostrum.com> Date: Wed, 16 Jan 2013 13:19:42 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "sipcore@ietf.org" References: <50B38C22.9080307@nostrum.com> In-Reply-To: <50B38C22.9080307@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Subject: [sipcore] Registration deadline approaching (Re: Registration for SIPit 30 is open) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:19:44 -0000 The registration deadline for SIPit 30 is February 4, just over two weeks away. If you plan to attend, but have not yet registered, please do so today. Note that we will be testing against RTCWeb implementations during Tuesdays multiparty test. See www.sipit.net for more info. RjS On 11/26/12 9:34 AM, Robert Sparks wrote: > Registration for SIPit 30 is open at http://www.regonline.com/sipit30 > > SIPit 30 will be hosted by Cisco in Raleigh-Durham, North Carolina, > February 18-22 2013. > > Additional details are available at http://www.sipit.net. > > See you there! > > RjS > From worley@shell01.TheWorld.com Fri Jan 18 09:11:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A466421F865B for ; Fri, 18 Jan 2013 09:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut0k1Jpmw7UD for ; Fri, 18 Jan 2013 09:11:09 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B57AA21F869C for ; Fri, 18 Jan 2013 09:11:08 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0IHAinu002408 for ; Fri, 18 Jan 2013 12:10:46 -0500 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0IHAhrm001273 for ; Fri, 18 Jan 2013 12:10:43 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0IHAePs001270; Fri, 18 Jan 2013 12:10:40 -0500 (EST) Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST) Message-Id: <201301181710.r0IHAePs001270@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: SIPCORE Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:11:10 -0000 I've got a few questions about 4244bis. I think that there are understood answers to most of them, but we might have to update the wording to remove ambiguity. 1. When an entity receives a (non-100) provisional response to a request, should it modify the hi-entry by adding a Reason value carrying the status of the response? The current text (section 10.2) clearly requires it. If the request eventually receives a failure response, the 1xx Reason will (probably) later be replaced by the failure code. (But not necessarily: see section 10.2 paragraph 3.) The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this situation is section 3.1 message F8, and the 180 status is not reported in a Reason header-value for (which thus contradicts section 10.2). The alternative is that 1xx responses do not set the Reason value (although they do add to the cache any new hi-entries they carry). This would require changing the text in section 9.3 step 2 and section 10.2. 2. During the life of the document, there was confusion about how hi-entries were to be organized. The intention of the original writer and the current draft is that hi-entries are accumulated in a cache in the order the entity receives them (in requests and responses), allowing hi-entries that have the *same* index but *different* URIs, and (implicitly) eliminating duplicates. But some people who have worked on the draft (including myself) were for a while mistaken in believing that the hi-entries were to be organized into a tree, and hence the index values needed to be unique, and the History-Info header would list the hi-entries in tree-walking order (technically, "preorder"). The confusion was abetted by there being no examples that distinguish the two techniques. Unfortunately, the -11 draft doesn't eliminate all the remnants of the mistake. I haven't gone through -11 in detail, but "preorder" appears in section 9.2 and section 10.3, so at least those sections describe the accumulation of hi-entries incorrectly. 3. Due to the confusion discussed in #2, we have to consider whether consensus was actually found in the WGLC. We thought we had consensus, but people did not have the same understanding of this aspect of the draft. (Ugh.) 4. If a downstream entity that does not support History-Info forks a request to entities that do support History-Info, an entity can receive two hi-entries with the same index that were not generated for the same fork of the request. Conversely, an entity will receive responses that contain hi-entries that are duplicates of entries that are already in the cache. These facts imply that there is a process by which an entity determines whether a received hi-entry is "the same" as an hi-entry already in the cache (and so doesn't need to be added again). Since index values cannot be depended upon to be unique, we really ought to state what the comparison rule is. I think it is sufficient to use the rule "the same index value and the URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason header fields)". This won't always give the result one would want (if a non-supporting downstream element forks the request to two target URIs that ultimately arrive at the same element, two hi-entries could be generated with the same index and URI), but this rule is simple, well-defined, and should work well in almost all situations. 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7 do not show the History-Info value in the final 200 response to the UAC. This final value would be useful, in particular, because they give further examples of how proxies process History-Info. 6. Interestingly, despite the fact that there can be duplicate index values, when a request is received by a UAS, there is no ambiguity in the history when tracing *back* from the last hi-entry (the one that denotes the UAS). This is because even if this UAS is "down one fork" from a forking non-supporting proxy, none of the hi-entries generated "down the other fork" will be present in the request the UAS sees. This is in contrast to the situation at the UAC, which may see hi-entries with duplicate indexes, and the interpretation of "rc", "mp", and "np" parameters can be ambiguous. 7. In example 3.6 message F6 in draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is: History-Info: ;index=1 History-Info: ;\ index=1.1;rc=1 History-Info: ;index=1.2;mp=1 History-Info: ;\ index=1.2.1;rc=1.2 History-Info: ;\ index=1.3;mp=1.2 History-Info: ;\ index=1.3.1;rc=1.3 This is what we intend, as it shows both where the index=1.3 URI came from (sip:bob@example.com) as well as why the index=1.3 fork was generated (because sip:carol@example.com failed). But it points out that we need to improve the description in rfc4244bis section 5 of what the values of the "rc" (etc.) parameters are. A naive reader might think "rc=1.2" in the 1.3 entry means that was generated as a contact for . Instead, it means that the 1.3 fork was generated *because* the 1.2 fork returned a response; it was generated *from* the index=1 URI. Actually, the real rules for interpreting "rc" (etc.) are not simple: 1) If the index-val in the param points to an entry with a Reason header-param whose value is "SIP;cause=3xx" (after removing escaping!), then: - the URI was one of the Contact values in the 3xx response - that response was why the new fork was generated. 2) If the index-val in the param points to the parent of this hi-entry, then: - the URI was generated from the URI of the parent hi-entry - the fork was not generated due to the response from any other fork. 3) If the index-val in the param points to an hi-entry that is not the parent, and that hi-entry does not contain a Reason header-param containing a 3xx status, then: - the URI was generated from the URI of the parent hi-entry - the fork was generated due to the response from the hi-entry with the specified index-val. And this doesn't match the section 5 definition of the value of "rc" (etc.), which is: The "rc" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was retargeted Dale From internet-drafts@ietf.org Tue Jan 29 12:49:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4627521F888C; Tue, 29 Jan 2013 12:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkEi4AzzqeJA; Tue, 29 Jan 2013 12:49:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5DB21F8834; Tue, 29 Jan 2013 12:49:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130129204912.30730.77135.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 12:49:12 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 20:49:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-02.txt Pages : 46 Date : 2013-01-29 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/