From nobody Tue Jan 5 09:51:52 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF061B2A59 for ; Tue, 5 Jan 2016 09:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.421 X-Spam-Level: * X-Spam-Status: No, score=1.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w31Qj9JC008U for ; Tue, 5 Jan 2016 09:51:49 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 EE9051B2A4C for ; Tue, 5 Jan 2016 09:51:41 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id f206so32228275wmf.0 for ; Tue, 05 Jan 2016 09:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to :content-type:content-transfer-encoding; bh=ORqL1pwLFhULCCRb2QEtsWVxyAx18VXwCufSiytYP6I=; b=a3o5Dt/grTDWGzXTtMIYNXoExXzsqyqi1auPdylw6Tn3u2RNZdBohH1xIEk+5WyahW 2wVsZoVz4k7Y7ygKauHvnm2WwCIW9yD1S6in45u/H4kR5cJCKGWuKP0fZPohkvtr+4Tp 2Mb8gkSiyt7T+o6S+VZef4jArNlj3RcSGmtKMHaYUuMahZSW0Z58m/8wP/nOPqjKtBq3 4NclD/fqJqvwxkaNmO0cdYMQjfHYhXj6bh2X+uVir6Lkbb+DaQC73efQ/CLQKXuuJ6Nj ogSafPDyiAi/QaKoHaQCLubcpRusR/VfqZm1tWRdXUHo0qIrQR7OegAuE6Lee11d+kGp iwCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type:content-transfer-encoding; bh=ORqL1pwLFhULCCRb2QEtsWVxyAx18VXwCufSiytYP6I=; b=NaZt3Zs1XV2CH7AoqMHuuhUd5ko+5CiAXw41RuZzY3AtgYGAsrw5qeyLv2A1pb2Z9V AF+SdJVJ73JDyEzllLoaDHC0jwWH/cMMFo5J4MYqbApxyxrXYeT5Fsr2No4YJiiGlVwd /lRHfX8P854ULuBzz5wosxqPPxQTBG9nYUv9HvY9X20JfYtW6OXyL+kFtItz7gvY/6Ze FEFtQ/JyMwDASu4wYL8mbGra5gxW6+zICQ1ZlxfdVoPOG60uMwNs6cN9vYLRRfKEzDnb hYWDy6piiSCetKvjLRG0m7AuX1FNGxeLdYNjTyHjUVYG7iEITdndsd7KI2lDAWbwmmLq aE1Q== X-Gm-Message-State: ALoCoQlnma6606/jP9WrkWN98ayYLXHq8QDTqTZjXWmhdpikwgGKEsKyhHQj4HzuoRQKknB5tvFea//stALaK8chDudfk9WPeIzEkPCPXVYVAnNrt2VdnSI= X-Received: by 10.28.0.79 with SMTP id 76mr5790410wma.27.1452016300383; Tue, 05 Jan 2016 09:51:40 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFH4a6/NsdUhMmHTreHxlK6Kbew9g== Date: Tue, 5 Jan 2016 12:51:39 -0500 Message-ID: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> To: "Paul Giralt (pgiralt)" , insipid@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 17:51:51 -0000 Hi Paul, Thanks for the response and welcome to the discussion. Reply is inline. > I propose a simpler solution that should address your > concerns and make it easy for implementers to understand > what should be done in these scenarios. This would > require a slight modification to the draft as it stands > today. I am therefore seeking your and the working group=E2=80=99s > approval to move forward with this change. If we can all > agree on this in concept, I will put together some > concrete text for inclusion in the draft. To get more feedback, you might need to raise the topic in a new thread. > In a nutshell, I propose that we make a minor change to > the text to explicitly call out the conditions under > which a UUID should be stored by endpoints and > intermediaries. I propose that an endpoint or intermediary > only store an updated remote UUID under the following > conditions: > > When receiving a request (other than ACK) that is accepted > (results in a 1XX or 2XX response), the received UUID must > be retained. If the request results in any other kind of > response, it should not be retained. This can, of course, > lead to conditions where a request is received, a > provisional response is sent (and therefore the UUID is > retained) and then for whatever reason, an error > (4XX/5XX/6XX) or redirect (3XX) response is sent. In such > a case, we will never =E2=80=9Croll back=E2=80=9D the Session ID. Concerning the mentioned "1xx", you might want to exclude 100 since 100 isn't end-to-end (even if using proxies instead of B2BUAs). For instance i= f 100 is only sent between two of the intermediaries, a resulting 500 respons= e doesn't mean that everyone agrees that the uuid actually changed. However, I guess that the same could be said for all non-reliable 1xx since a 18x sent by endpoint could be dropped (or received after 500). You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx. Some within the SIP working groups prefer to allow ACK-for-2xx to update things. For instance, see draft-ietf-insipid-session-id-16 section 9.7; th= e 3pcc sends the updated uuid within the ACK. The proposal currently appears to violate (or alter) RFC 3261 section 8.2: "If it is rejected, all state changes MUST NOT be performed". Similarly it also appears to impact the following RFC 6141 section 3.3 SHOULD: "If any o= f the changes requested in a re-INVITE or in any transaction within it have already been executed, the UAS SHOULD return a 2xx response". You might want to exclude CANCEL and its 2xx response from the algorithm (although decision might be influenced by decision concerning 100 response)= . CANCEL and related 2xx response are not end-to-end (even if using proxies instead of B2BUAs). > The only additional rule for stateful intermediaries is > that if they accept a request and then forward that request > to another destination (therefore there was no error found > with the message), this will also trigger the intermediary > to update the retained UUID. The proposal means that not all of the devices will necessarily agree if a uuid changed during failure situation. Concerning "therefore there was no error found" statement, be aware that forwarding a request does not necessarily mean that no error was found (i.e= . device can be lenient) or that the request won't eventually be rejected (with 400 or other failure response). > The remote UUID in all responses must match the UUID > received in the request if the SIP stack is able to process > the Session-ID header. This applies even if the UUID is not > going to be retained. If a re-INVITE {C,B} contains an > error but the Session-ID is successfully extracted from the > re-INVITE, the 4XX response should contain {B,C} (assuming > the receiving endpoint is still using B as the local UUID. > Otherwise B should be replaced with the correct Local UUID). > > To deal with issues where a response with a Session ID > different than what is being retained is sent in an error > response and the ACK for that response contains the new > Session ID which we chose not to retain because it was as > a result of an error, the document will state that a > Session ID received in an ACK must never update the > retained value. This should never be an issue because the > Session ID in the ACK should always match that of the > matching request, so if the endpoint receiving the request > updated the Session ID on the request, it does not need to > do so again for the ACK. Concerning "Session ID in the ACK should always match that of the matching request", it isn't always true. For instance, see draft-ietf-insipid-session-id-16 section 9.7; the 3pcc sends the updated uuid within the ACK. You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx. Some within the SIP working groups prefer to allow ACK-for-2xx to update things. > Endpoints and intermediaries always update their Remote > Session ID based on any responses received regardless of > the type of response (provided the response is > syntactically valid and can be processed, of course). Sending a non-reliable response (1xx-6xx) is not necessarily the best way t= o update something because of race conditions and similar ambiguities. However, the proposal is basically the same as the draft. > There will always be feature interactions that result in > temporarily mismatched Session IDs when intermediaries are > involved, but I don=E2=80=99t think the above proposal makes this > any worse of a problem in real-world applications. I'm currently not sure if the proposal is better or worse than draft versio= n 16. >From the rejecting device perspective, the proposal appears to be better. The proposal currently appears to leave partial changes up to rejecting device (i.e. intermediaries allowed change but rejecting device did not) without any indication to modifier to know if change was successful at the remote endpoint. This is about the same as changing some of the MUST to SHOULD (or MAY) within the current draft which would allow the rejecting device to make the decision concerning which is better for the situation. > Please see my responses inline to address your concerns=E2=80=A6. I'll respond separately if I have any comments different from those within this reply. Thanks, Brett From nobody Tue Jan 5 11:51:16 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356E81B2D57 for ; Tue, 5 Jan 2016 11:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cydM0_tvfz3M for ; Tue, 5 Jan 2016 11:51:13 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A5E1B2D47 for ; Tue, 5 Jan 2016 11:51:12 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with comcast id 2Kqz1s0014xDoy801KrCKL; Tue, 05 Jan 2016 19:51:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-05v.sys.comcast.net with comcast id 2KrB1s00K3KdFy101KrBgE; Tue, 05 Jan 2016 19:51:12 +0000 To: insipid@ietf.org References: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> From: Paul Kyzivat Message-ID: <568C1EAE.2030502@alum.mit.edu> Date: Tue, 5 Jan 2016 14:51:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1452023472; bh=0oaYNh+2I49rd/26s95M3wCdfE/vu/DSN+4dW43yDfI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=D4ZfDl2Kp4GgX217nSc4H53wkYjtNQSu1l9vF7zLVblxV+8m20svP7c8vGDcf1AMI 1bAR8Adu6+wLaTWi8nOdH5AtoZAzvmcK6/sbuopGlTsd7EJvK8plAwQ3gfoIcXAS5g Q5WzAQXIqGyd/7THeXHGqyqAKsJHWRz44QPGFKq0DG4Y9Lf+qP9cMMPYkajVmPk/IR BXYww7WOV3AUeS31cGH9BhKUyxDJljTI0pyNDcIO25QCJvaKVee/mH9Tu4kwhv4nA3 Vcku3bkV8zGxIBkWgZ5+D8I6P9eIcps+t4yOkpoXyPsOjXu1t5LQZWavzU3rXVIA6C tXu6SN2PrM4og== Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:51:15 -0000 This discussion is reinforcing my belief that this mechanism is a mess - that the chance is slim to none of getting consistent results in all the connected devices. Thanks, Paul On 1/5/16 12:51 PM, Brett Tate wrote: > Hi Paul, > > Thanks for the response and welcome to the discussion. Reply is inline. > >> I propose a simpler solution that should address your >> concerns and make it easy for implementers to understand >> what should be done in these scenarios. This would >> require a slight modification to the draft as it stands >> today. I am therefore seeking your and the working group’s >> approval to move forward with this change. If we can all >> agree on this in concept, I will put together some >> concrete text for inclusion in the draft. > > To get more feedback, you might need to raise the topic in a new thread. > > >> In a nutshell, I propose that we make a minor change to >> the text to explicitly call out the conditions under >> which a UUID should be stored by endpoints and >> intermediaries. I propose that an endpoint or intermediary >> only store an updated remote UUID under the following >> conditions: >> >> When receiving a request (other than ACK) that is accepted >> (results in a 1XX or 2XX response), the received UUID must >> be retained. If the request results in any other kind of >> response, it should not be retained. This can, of course, >> lead to conditions where a request is received, a >> provisional response is sent (and therefore the UUID is >> retained) and then for whatever reason, an error >> (4XX/5XX/6XX) or redirect (3XX) response is sent. In such >> a case, we will never “roll back” the Session ID. > > Concerning the mentioned "1xx", you might want to exclude 100 since 100 > isn't end-to-end (even if using proxies instead of B2BUAs). For instance if > 100 is only sent between two of the intermediaries, a resulting 500 response > doesn't mean that everyone agrees that the uuid actually changed. However, > I guess that the same could be said for all non-reliable 1xx since a 18x > sent by endpoint could be dropped (or received after 500). > > You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx. > Some within the SIP working groups prefer to allow ACK-for-2xx to update > things. For instance, see draft-ietf-insipid-session-id-16 section 9.7; the > 3pcc sends the updated uuid within the ACK. > > The proposal currently appears to violate (or alter) RFC 3261 section 8.2: > "If it is rejected, all state changes MUST NOT be performed". Similarly it > also appears to impact the following RFC 6141 section 3.3 SHOULD: "If any of > the changes requested in a re-INVITE or in any transaction within it have > already been executed, the UAS SHOULD return a 2xx response". > > You might want to exclude CANCEL and its 2xx response from the algorithm > (although decision might be influenced by decision concerning 100 response). > CANCEL and related 2xx response are not end-to-end (even if using proxies > instead of B2BUAs). > > >> The only additional rule for stateful intermediaries is >> that if they accept a request and then forward that request >> to another destination (therefore there was no error found >> with the message), this will also trigger the intermediary >> to update the retained UUID. > > The proposal means that not all of the devices will necessarily agree if a > uuid changed during failure situation. > > Concerning "therefore there was no error found" statement, be aware that > forwarding a request does not necessarily mean that no error was found (i.e. > device can be lenient) or that the request won't eventually be rejected > (with 400 or other failure response). > > >> The remote UUID in all responses must match the UUID >> received in the request if the SIP stack is able to process >> the Session-ID header. This applies even if the UUID is not >> going to be retained. If a re-INVITE {C,B} contains an >> error but the Session-ID is successfully extracted from the >> re-INVITE, the 4XX response should contain {B,C} (assuming >> the receiving endpoint is still using B as the local UUID. >> Otherwise B should be replaced with the correct Local UUID). >> >> To deal with issues where a response with a Session ID >> different than what is being retained is sent in an error >> response and the ACK for that response contains the new >> Session ID which we chose not to retain because it was as >> a result of an error, the document will state that a >> Session ID received in an ACK must never update the >> retained value. This should never be an issue because the >> Session ID in the ACK should always match that of the >> matching request, so if the endpoint receiving the request >> updated the Session ID on the request, it does not need to >> do so again for the ACK. > > Concerning "Session ID in the ACK should always match that of the matching > request", it isn't always true. For instance, see > draft-ietf-insipid-session-id-16 section 9.7; the 3pcc sends the updated > uuid within the ACK. > > You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx. > Some within the SIP working groups prefer to allow ACK-for-2xx to update > things. > > >> Endpoints and intermediaries always update their Remote >> Session ID based on any responses received regardless of >> the type of response (provided the response is >> syntactically valid and can be processed, of course). > > Sending a non-reliable response (1xx-6xx) is not necessarily the best way to > update something because of race conditions and similar ambiguities. > However, the proposal is basically the same as the draft. > > >> There will always be feature interactions that result in >> temporarily mismatched Session IDs when intermediaries are >> involved, but I don’t think the above proposal makes this >> any worse of a problem in real-world applications. > > I'm currently not sure if the proposal is better or worse than draft version > 16. > >>From the rejecting device perspective, the proposal appears to be better. > The proposal currently appears to leave partial changes up to rejecting > device (i.e. intermediaries allowed change but rejecting device did not) > without any indication to modifier to know if change was successful at the > remote endpoint. This is about the same as changing some of the MUST to > SHOULD (or MAY) within the current draft which would allow the rejecting > device to make the decision concerning which is better for the situation. > > >> Please see my responses inline to address your concerns…. > > I'll respond separately if I have any comments different from those within > this reply. > > Thanks, > Brett > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From nobody Tue Jan 5 14:18:04 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3E1AC3CA for ; Tue, 5 Jan 2016 14:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzkole3b3dHP for ; Tue, 5 Jan 2016 14:18:00 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BA41B2DA2 for ; Tue, 5 Jan 2016 14:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8862; q=dns/txt; s=iport; t=1452032279; x=1453241879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6BNG/HD2HZSvUNlx7oVtqFyQfHhbzfVj7EmpkGIRNQE=; b=KNJey0eNkJ+0TzR4m8Ic0/GdqO7TOF+4ay+Rg2956t2jy6c5srZLkP7A 2tquYKidNxnd4c6+Im3JzuHity71Vm7lNJJWRwe+63yqugOFUSWmE+F5i tF/5kcspxyXOHueptTbCQp0yp/i/rHizz7biKktgXlyChN58kORS+qBzf s=; X-Files: signature.asc : 842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/BABoQIxW/5tdJa1egzp+R4hTs2kOg?= =?us-ascii?q?WSGDwKBHzgUAQEBAQEBAYEKhDUBAQMBI1YFCwIBCEICAjIlAQEEDhOIGQixW5B?= =?us-ascii?q?oAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwmGVoIPCIFkgQSHcy6BGwWHaIcFiBsBg?= =?us-ascii?q?nKBZYh7gVyNIYVbiGUBIAFDghEcgV2FCCQfgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,526,1444694400"; d="asc'?scan'208";a="224484322" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2016 22:17:58 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u05MHvKK007484 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 22:17:58 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 17:17:57 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 17:17:57 -0500 From: "Paul Giralt (pgiralt)" To: Brett Tate Thread-Topic: [Insipid] draft-ietf-insipid-session-id-14: comments and questions Thread-Index: AdFH4a6/NsdUhMmHTreHxlK6Kbew9gATyd0A Date: Tue, 5 Jan 2016 22:17:56 +0000 Message-ID: <9AC1FE32-A288-4093-9844-5137735D748B@cisco.com> References: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> In-Reply-To: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.123.203] Content-Type: multipart/signed; boundary="Apple-Mail=_6A6D26F4-1625-49B3-B2D1-3E06328FB768"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 22:18:02 -0000 --Apple-Mail=_6A6D26F4-1625-49B3-B2D1-3E06328FB768 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brett, Thanks for the reply. See inline. >=20 >> In a nutshell, I propose that we make a minor change to >> the text to explicitly call out the conditions under >> which a UUID should be stored by endpoints and >> intermediaries. I propose that an endpoint or intermediary >> only store an updated remote UUID under the following >> conditions: >>=20 >> When receiving a request (other than ACK) that is accepted >> (results in a 1XX or 2XX response), the received UUID must >> be retained. If the request results in any other kind of >> response, it should not be retained. This can, of course, >> lead to conditions where a request is received, a >> provisional response is sent (and therefore the UUID is >> retained) and then for whatever reason, an error >> (4XX/5XX/6XX) or redirect (3XX) response is sent. In such >> a case, we will never =E2=80=9Croll back=E2=80=9D the Session ID. >=20 > Concerning the mentioned "1xx", you might want to exclude 100 since = 100 > isn't end-to-end (even if using proxies instead of B2BUAs). For = instance if > 100 is only sent between two of the intermediaries, a resulting 500 = response > doesn't mean that everyone agrees that the uuid actually changed. = However, > I guess that the same could be said for all non-reliable 1xx since a = 18x > sent by endpoint could be dropped (or received after 500). >=20 I actually intended to mention excluding 100 Trying for this very = reason. Thanks for highlighting my omission. > You might want to distinguish between a ACK-for-2xx versus = ACK-for-non-2xx. > Some within the SIP working groups prefer to allow ACK-for-2xx to = update > things. For instance, see draft-ietf-insipid-session-id-16 section = 9.7; the > 3pcc sends the updated uuid within the ACK. >=20 Good call out. The only reason I mentioned ignoring all ACK was to make = it simpler, but this is clearly a situation where it makes sense to = update, so we would have to distinguish between ACK-for-2xx versus = ACK-for-non-2xx. > The proposal currently appears to violate (or alter) RFC 3261 section = 8.2: > "If it is rejected, all state changes MUST NOT be performed". = Similarly it > also appears to impact the following RFC 6141 section 3.3 SHOULD: "If = any of > the changes requested in a re-INVITE or in any transaction within it = have > already been executed, the UAS SHOULD return a 2xx response=E2=80=9D. You could argue that the intermediary is not the one actually rejecting = the request bur merely relaying the rejection. The proposal says that = the device that is actually doing the rejection of the request is not = storing the UUID. For troubleshooting purposes, which is the desired = objective of the Session-ID, it makes sense to do as I proposed. > You might want to exclude CANCEL and its 2xx response from the = algorithm > (although decision might be influenced by decision concerning 100 = response). > CANCEL and related 2xx response are not end-to-end (even if using = proxies > instead of B2BUAs). >=20 Is there any situation where including CANCEL could cause a problem? = With 100 Trying my concern was that you may end up overwriting a UUID = with a Null. >=20 >> The only additional rule for stateful intermediaries is >> that if they accept a request and then forward that request >> to another destination (therefore there was no error found >> with the message), this will also trigger the intermediary >> to update the retained UUID. >=20 > The proposal means that not all of the devices will necessarily agree = if a > uuid changed during failure situation. >=20 > Concerning "therefore there was no error found" statement, be aware = that > forwarding a request does not necessarily mean that no error was found = (i.e. > device can be lenient) or that the request won't eventually be = rejected > (with 400 or other failure response). >=20 Yes, I totally understand that the request might be eventually rejected = by some other device down the line, but as an intermediary, it seems = like this is the best we can do. >=20 >> The remote UUID in all responses must match the UUID >> received in the request if the SIP stack is able to process >> the Session-ID header. This applies even if the UUID is not >> going to be retained. If a re-INVITE {C,B} contains an >> error but the Session-ID is successfully extracted from the >> re-INVITE, the 4XX response should contain {B,C} (assuming >> the receiving endpoint is still using B as the local UUID. >> Otherwise B should be replaced with the correct Local UUID). >>=20 >> To deal with issues where a response with a Session ID >> different than what is being retained is sent in an error >> response and the ACK for that response contains the new >> Session ID which we chose not to retain because it was as >> a result of an error, the document will state that a >> Session ID received in an ACK must never update the >> retained value. This should never be an issue because the >> Session ID in the ACK should always match that of the >> matching request, so if the endpoint receiving the request >> updated the Session ID on the request, it does not need to >> do so again for the ACK. >=20 > Concerning "Session ID in the ACK should always match that of the = matching > request", it isn't always true. For instance, see > draft-ietf-insipid-session-id-16 section 9.7; the 3pcc sends the = updated > uuid within the ACK. >=20 > You might want to distinguish between a ACK-for-2xx versus = ACK-for-non-2xx. > Some within the SIP working groups prefer to allow ACK-for-2xx to = update > things. >=20 Same comment as earlier. I think this makes sense to allow ACK-for-2xx = to update. >=20 >> Endpoints and intermediaries always update their Remote >> Session ID based on any responses received regardless of >> the type of response (provided the response is >> syntactically valid and can be processed, of course). >=20 > Sending a non-reliable response (1xx-6xx) is not necessarily the best = way to > update something because of race conditions and similar ambiguities. > However, the proposal is basically the same as the draft. >=20 IMHO it=E2=80=99s better than nothing. We are doing this to aid in = troubleshooting, so we make due with the information we have. >=20 >> There will always be feature interactions that result in >> temporarily mismatched Session IDs when intermediaries are >> involved, but I don=E2=80=99t think the above proposal makes this >> any worse of a problem in real-world applications. >=20 > I'm currently not sure if the proposal is better or worse than draft = version > 16. >=20 > =46rom the rejecting device perspective, the proposal appears to be = better. > The proposal currently appears to leave partial changes up to = rejecting > device (i.e. intermediaries allowed change but rejecting device did = not) > without any indication to modifier to know if change was successful at = the > remote endpoint. This is about the same as changing some of the MUST = to > SHOULD (or MAY) within the current draft which would allow the = rejecting > device to make the decision concerning which is better for the = situation. >=20 Changing MUSTs to SHOULDs would certainly address many of these issues = as well, but leave us with the issues you pointed out with RFC 3261 = section 8.2. Thanks, -Paul --Apple-Mail=_6A6D26F4-1625-49B3-B2D1-3E06328FB768 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWjEEUAAoJEADWV7cDInKs/zAP/1qPcIlzFFTixdRKM1pSrLB7 OpbCGywG6bCR+YiR5e8YAqYbl/LsTT1t1X1ldvV233GQ/OvD5G4fcajI46spgi80 A/zKd4J8/4v46gZCUxxDW9VLFoDdr3NB23z+X/TV9bMu+B44i7yObgDJpYmSf/FJ 49ytjkSryZg+Eh+RyfTIe1hBrV7yaU3rXwPdGUSRI1u3V4VDjJ1Ri2eUXg3qgN7D dHNCcHpyqD43k98qkABXjVPaEenqm1z6OV530Cty5448HpaD6AknUyiknER/LT3L 0NFK0Rt8InhoO/hOPmeKWdrIBRASt62u2P+gNpzR3Y5cDF/D/g8vsB+JcKjhJRhn GtnntU9raNo/j/b+YLJWIL17G5B6fT2RUTGokixHqHJ2r/6OJr05jJcxsAaixI/U oAo4cVvARMcZja3gG3+UlNDk7x/u0ej5kSxFK9DzQBzki4D/XeDnRqJ/re5HyQb0 EdKV37xCXXC+cHpatg5OhU1cLBoDwjlWMFKF3s9pbKYPyYAJD3sqW7k5C/Yjj4Be 5sS+IaFYjvLEYgxiKUXhM9ugNl+WsjngMGLjZnOQRXeLRNdLtBxcVBR6iTqjwsGA 6XcGqDAol9vus/7CDE3L5IAp9UWh97SE9v0WC/B3iNT59LQnclbuAOnqKR3p6eR9 +u9eZHVMzbE40bF/AUmS =Hz97 -----END PGP SIGNATURE----- --Apple-Mail=_6A6D26F4-1625-49B3-B2D1-3E06328FB768-- From nobody Tue Jan 5 14:22:22 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3771AC3CC for ; Tue, 5 Jan 2016 14:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1FYGob19XVB for ; Tue, 5 Jan 2016 14:22:19 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AF11A0200 for ; Tue, 5 Jan 2016 14:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2312; q=dns/txt; s=iport; t=1452032539; x=1453242139; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QM/8CooGsQg6LAMvEtXXHHpNNJa/jWLgutMLqNyC+fM=; b=dHUBH1XJiAZK158BzUIT+p3z/kR/kcAIFFB89grG3sbEIy2PgrikefTC jZJOXnWI6zDMntk51/9nI1csuqgsC+KfKHUft6DdMnMJW21kjqfWzgu/Y hFIULn83qmv2PFTiKl0OIGkR6ku3kzvs84wSoLlGVINaWtAaKeEJdsJOC E=; X-Files: signature.asc : 842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAgDzQIxW/5pdJa1eDoMsgT8GiFOza?= =?us-ascii?q?Q6BZIYPAoEfOBQBAQEBAQEBgQqENAEBAQMBI1YFCwIBCA4KKgICMiUCBA4FDog?= =?us-ascii?q?ZCLFbkGgBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYZWgg8IgmiHcy6BGwWXCAGCc?= =?us-ascii?q?oFliHuOfY5AASABQ4NMPnKEWYEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,526,1444694400"; d="asc'?scan'208";a="223056315" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2016 22:22:18 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u05MMI9a018462 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 22:22:18 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 17:22:17 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 17:22:17 -0500 From: "Paul Giralt (pgiralt)" To: Paul Kyzivat Thread-Topic: [Insipid] draft-ietf-insipid-session-id-14: comments and questions Thread-Index: AQHRR/JzMWCbSOSJWUGyzP+voiqgxp7t0v6A Date: Tue, 5 Jan 2016 22:22:17 +0000 Message-ID: <0F5C0FE1-7A7B-4030-B75B-0A3B137B2476@cisco.com> References: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> <568C1EAE.2030502@alum.mit.edu> In-Reply-To: <568C1EAE.2030502@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.123.203] Content-Type: multipart/signed; boundary="Apple-Mail=_A0E839D9-648B-4BB3-8EB4-5D1628520D87"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 22:22:21 -0000 --Apple-Mail=_A0E839D9-648B-4BB3-8EB4-5D1628520D87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think it=E2=80=99s all doom and gloom. I think in the = majority of cases the Session-ID will be consistent end-to-end. It is = these corner case error conditions that lead to ambiguity as to the = right thing to do which is why I=E2=80=99d prefer expected behavior be = documented as clearly as possible, even if it may knowingly result in a = situation where all devices don=E2=80=99t necessarily agree on the = Session-ID for some period of time in the call. I think there will still = be enough information in the message exchange that any post-processing = tools being used to diagnose a problem will have enough information to = correlate calls even in such scenarios. -Paul > On Jan 5, 2016, at 2:51 PM, Paul Kyzivat = wrote: >=20 > This discussion is reinforcing my belief that this mechanism is a mess = - that the chance is slim to none of getting consistent results in all = the connected devices. >=20 --Apple-Mail=_A0E839D9-648B-4BB3-8EB4-5D1628520D87 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWjEIZAAoJEADWV7cDInKs7Y4P/02ls0zBUQv5cSc3yvObuV6u CGDIOROcEhgNxWbGFW2JRoyY0aPbApJZw4RMkoE+PdToSvGbapAqk9YWFBH7lX/a 9tv9OoInZ8hQkD3Bk7XIWRxFDTB52Ft6ujVC8Xc6hT4DVg+Urv2IDax4UX8h2umO fD2vtE1vu3SVbn7mJI43AdLr38Zv8t4olQk4nVXOinQbHGCO2cFY6t8gVGg4G5E2 WAb1+1kkWhe4GKLRCcgIrvpyEV9vIQYD7LbyShBItHIbN6s9VKPyT176E5TLUEaP jcLcLGJkj2LqLm1QDIEwUOMcfis4uQKLWSrhY3zYUkcEOsb3SSIidGlYr9gRjCFt ikeja/AnZh0BpSIrrNVV7w0Dk/QKHUcpqEY+FC5Fponf9cIX/hccEy5Wqmcqar9v YwDCIdtWB/zzs5ND4Bb8vnWylK2hq+BiEnbEpOmwqsukD4bVkm5oRf9G1FPdrrrB NvM3m+lzpQttBPE1pqM4NCjrNyRO12AXs9NsVm1HK37ArSN9kD2Zez8NnnwVHg4Y lI054E/IOVFwqgAMBJAae1iYl1yb0M4NepXqrobn2UuxzwecqvGfw0ki3GXILVql yVl4RmZkarM9ikt2dKCLg3hLkXCYQ8z1w+/VF3VxxQjMQBB2s5TgcrqpQt32dJpg 44ToyYsdkcLlozlBnQqd =16U0 -----END PGP SIGNATURE----- --Apple-Mail=_A0E839D9-648B-4BB3-8EB4-5D1628520D87-- From nobody Wed Jan 6 07:07:19 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646571B2DBC for ; Wed, 6 Jan 2016 07:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWMbqpnVtgiv for ; Wed, 6 Jan 2016 07:07:17 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 DA70F1B2C07 for ; Wed, 6 Jan 2016 07:07:16 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id l65so62614306wmf.1 for ; Wed, 06 Jan 2016 07:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to :content-type:content-transfer-encoding; bh=9XqXB774y56fsaeiPl4FtzMMkczd6zaETLQ+pB/w9HU=; b=RktYb1tZKlztrUSEB+4ORd0jcmZgnr4Ndn1PXDCMSa8uXDTnk0XcN2gL6H3CUAUnB3 cbWjNxfNFyjt8tijr1NAg3lGvlDVjwmSOrQSC6juQFN5dR52ce7rw5VRoQw5BuW9D7ic f5rRS2ysKN5/5qle6QGJKESOxLl+D0dyT/+nuguHTnrGdjy+yuhJywkGV6anG/vZ+XUK 6D+RyTnTjvW63/deh6v/PE90U9yGsFQHfkdq1UzlGsjgDqhSwErqT74sZvsbzbmWkH9e BuSeLrFZ5dpLK+M2IDzIB8aLTP4T2379+6yWP8Wke7srWf4bJ7gJOpoiCanEFJlvwsc9 R3ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type:content-transfer-encoding; bh=9XqXB774y56fsaeiPl4FtzMMkczd6zaETLQ+pB/w9HU=; b=Y02sirvviv2k+5Bcsl+dHvWj4DccA6IQzcJtu8MIW5wuI8/PqNBMtOsuUvylySm9V3 fHWVVBoukrXDDSqzmTJF7KQc9gbTrSDcKU+dJaE0eWcDl49LuKatHpiPTH5bvQ1CXWP7 qIqhYd2TPyJ9FQlb/pg4mUMx1vvDt24SJr3QlEIN2ycgIntpXptFBNRixDRc8dPs/we/ 4fRfWLBCtZswfcTPug9is1CY6B1CqoCJp4e6CJXrJcBtVq8JACXHaQN0w2UCguw6R9V5 9IhFM3tcAlM1FxZL22G1d489Rzx2HAU/Ei9C3XZuehNeUbyn3ngkXpEd49ttDKziNs/T NbYg== X-Gm-Message-State: ALoCoQnACFc8PPAsZyOzgnspef37Bf5+mv5KiH3QVrbEOWxmkefS9bfsnOfqoRTkifLIEt0yEBcAwwUmYAj+ZTVzdyf6d1BPpWeyh/VnIPjzP34vXhPZiho= X-Received: by 10.194.21.101 with SMTP id u5mr108609435wje.53.1452092835327; Wed, 06 Jan 2016 07:07:15 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFIk7nfPBr0WWyqRea8Ossvwf5GUw== Date: Wed, 6 Jan 2016 10:07:14 -0500 Message-ID: <06a9f77d38a13c9991ec9a6fb7e0b042@mail.gmail.com> To: insipid@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:07:18 -0000 Hi, I'm glad to hear others within the working group agree that the draft (with or without Paul Giralt's proposed changes) provides no way to avoid intermediaries from sending inaccurate Session-ID values when generating related requests and responses. Similarly, the draft provides no way to avoid endpoints from sending inaccurate remote uuid values when generating requests and responses (although Paul Giralt's proposed change provides som= e consistency concerning responses). The inability of intermediaries to avoid sending inaccurate Session-ID values when generating related requests and responses has been why I occasionally ask for the limitation to be explicitly mentioned within the draft and why I occasionally raise issues with the draft's MUST statements. The draft currently allows intermediaries (excluding maybe any which might be required to track the uuids) to not add Session-ID when generating (instead of relaying) requests and responses. This is because the draft prefers no Session-ID instead of one which might cause a non-desired uuid change. I'm not sure if Paul Giralt intends to change this aspect of the draft. I'm not sure if the current limitations of the draft (or proposed change) will meet the expectations of the working group or 3GPP. However, I guess that the draft will continue to evolve until it is abandoned or deemed good enough. Thanks, Brett > -----Original Message----- > From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Giralt > (pgiralt) > Sent: Tuesday, January 05, 2016 5:22 PM > To: Paul Kyzivat > Cc: insipid@ietf.org > Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and > questions > > I don=E2=80=99t think it=E2=80=99s all doom and gloom. I think in the maj= ority of cases > the > Session-ID will be consistent end-to-end. It is these corner case error > conditions that lead to ambiguity as to the right thing to do which is wh= y > I=E2=80=99d prefer expected behavior be documented as clearly as possible= , even if > it > may knowingly result in a situation where all devices don=E2=80=99t neces= sarily > agree > on the Session-ID for some period of time in the call. I think there will > still be enough information in the message exchange that any > post-processing > tools being used to diagnose a problem will have enough information to > correlate calls even in such scenarios. > > -Paul > > > > On Jan 5, 2016, at 2:51 PM, Paul Kyzivat wrote: > > > > This discussion is reinforcing my belief that this mechanism is a mess = - > that the chance is slim to none of getting consistent results in all the > connected devices. > > From nobody Wed Jan 6 07:31:15 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD801A8768 for ; Wed, 6 Jan 2016 07:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRnffAjoEboE for ; Wed, 6 Jan 2016 07:31:00 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22E21A875C for ; Wed, 6 Jan 2016 07:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3773; q=dns/txt; s=iport; t=1452094259; x=1453303859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=otGAbqVCPJy7zCxegtouSzKXV+4bFsB09fxcYN9wyJI=; b=c/tVkcG7fJ2QZ76PHnGp95buxoVPE++urZBSJNGtdmAfd8fSpUBRLKih IXuayDW/Lf1Q9ZEBTOGrOSq9eDabXQbPgja7/Nz2oA/aX9dKGbJ81AKg0 odGwTtCq4wCn3N5yEbs+I8VfUfiNaD9oHzx+sdKU+9ocjRF4B1wf/9tXB Q=; X-Files: signature.asc : 842 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADdMY1W/xbLJq1ehH+IU7VFhg8Cg?= =?us-ascii?q?W0BAQEBAQGBC4Q1AQEDASNWBQsCAQhCAgIyJQEBBA4TiBkIsTCQXQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQ8JhlaCDwiCaIdzLoEbBZcKAYJygWWIfY56jkYBZIIRH?= =?us-ascii?q?IFdhUuBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,529,1444694400"; d="asc'?scan'208";a="623276516" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 15:30:57 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u06FUuCs030531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 15:30:57 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 10:30:55 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 10:30:55 -0500 From: "Paul Giralt (pgiralt)" To: Brett Tate Thread-Topic: [Insipid] draft-ietf-insipid-session-id-14: comments and questions Thread-Index: AdFIk7nfMWCbSOSJWUGyzP+voiqgxgALWjoA Date: Wed, 6 Jan 2016 15:30:55 +0000 Message-ID: References: <06a9f77d38a13c9991ec9a6fb7e0b042@mail.gmail.com> In-Reply-To: <06a9f77d38a13c9991ec9a6fb7e0b042@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.81.96.60] Content-Type: multipart/signed; boundary="Apple-Mail=_FD6487BF-FF65-4235-AA2A-2A9B49066C8A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "insipid@ietf.org" Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:31:05 -0000 --Apple-Mail=_FD6487BF-FF65-4235-AA2A-2A9B49066C8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I'm glad to hear others within the working group agree that the draft = (with > or without Paul Giralt's proposed changes) provides no way to avoid > intermediaries from sending inaccurate Session-ID values when = generating > related requests and responses. Similarly, the draft provides no way = to > avoid endpoints from sending inaccurate remote uuid values when = generating > requests and responses (although Paul Giralt's proposed change = provides some > consistency concerning responses). >=20 I still think the situations under which there are inaccurate = Session-IDs are very isolated. When an error occurs, there will likely = be some further action taken after the error that either ends up tearing = down the call or retries and succeeds. Either way, the loss of = end-to-end Session-ID agreement is short-lived and there is still enough = information contained in the Session-ID=E2=80=99s to be able to = effectively troubleshoot most, if not all, issues. Also, Section 7 already contains this text in an attempt to maintain = Session-ID consistency: "If an intermediary can determine that an = endpoint might not have received a current, correct Session-ID field, = the Intermediary SHOULD attempt to provide the correct Session-ID header = field to the endpoint such as by sending a re-INVITE message.=E2=80=9D > The inability of intermediaries to avoid sending inaccurate Session-ID > values when generating related requests and responses has been why I > occasionally ask for the limitation to be explicitly mentioned within = the > draft and why I occasionally raise issues with the draft's MUST = statements. >=20 I=E2=80=99m okay with adding some text mentioning there are situations = where the Session-ID may get out of sync and perhaps even giving an = example. If we move forward with the proposed changes, I will evaluate = any MUST statements to ensure they are still a MUST. > The draft currently allows intermediaries (excluding maybe any which = might > be required to track the uuids) to not add Session-ID when generating > (instead of relaying) requests and responses. This is because the = draft > prefers no Session-ID instead of one which might cause a non-desired = uuid > change. I'm not sure if Paul Giralt intends to change this aspect of = the > draft. >=20 I had no intention of changing this aspect of the draft. --Apple-Mail=_FD6487BF-FF65-4235-AA2A-2A9B49066C8A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWjTMvAAoJEADWV7cDInKsp0EP/inCkkJ2c5d/qYJhSLGANXjq JeM+H9YUJSB8oq35MGnnhxDvkxdSG447IrGyJ8b87Wqj30ctYQeufwANC0T8j5zO O8hXh9065cI/v63K0wehYF+ZyN7QAEbRrltLJUHvGKp/NdIjK68rqaoxPZq9+pfZ aaz7fCobLST46MfiUEffCBHmiSSqmLHNKrJN2uHmVRE5CrZs7y/Ovb6by0t6fHR+ MXFntfZd7yLV31ThUgNckwh9Vy+ZsscS/2mgYA8fpUMH1Zp93Ln1Mwx1DsrQlXt2 bPBU8Vm6HbiOGw4homN9hZsDhyId7TFiMlv1iLL8pP6O6ScRX5l2qfNhoYrpHJ14 vwXntXpNU0vppe3i7plRzxYYkxWs79N14+XkvvtCRykt9urxCRC5w43/q3/JK2/u Tpr00T9PM8LfLeEkb88/qiZVxvOFlE2/rc5eOJNCCt1Wqhm5ep0xAFkI6qni/R/5 0D3C5k0d35bchHygoOMQav+QSyyCNienJZOQ/RPBoxFrNsaNhq6JPAmNQHH/Ug6P VMVRMCoddOpKdK0+GyI9dng92yHUm4iAgKQa7tDb60Vz11RiGKNIokkKJ4TIt/9o PZGErmbIWdSzyOkBOwIluSh262E0IN9yAm5uWhqrpMXIMUZJkXDCg6t+KU4+H9hV lUBvGobWBvnUQshqATA7 =hPMm -----END PGP SIGNATURE----- --Apple-Mail=_FD6487BF-FF65-4235-AA2A-2A9B49066C8A-- From nobody Wed Jan 6 08:50:04 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB991A909D for ; Wed, 6 Jan 2016 08:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojv1GJS_iN9D for ; Wed, 6 Jan 2016 08:50:02 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 62FB91A8A68 for ; Wed, 6 Jan 2016 08:50:02 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id l65so66165076wmf.1 for ; Wed, 06 Jan 2016 08:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to :content-type; bh=CfQTWBRmQ0zAv3AgQnjSKAn4ZkEgArOQ9r3raMZkL1Q=; b=wS6tdbDoEUiIOuCnXkBCE0SkbPKEtZpsStQpRFGpNT3yn50IsTdm3v2W1lFe5dGfJE 00Za6etDP1I8R3BD5yUWmT9wbb9AwFXuZjM6+DRaae5qfvQCEPmyrGahb+tNk5jyh60W Bl5UyNhdjVTCXMseMWE3aCALF6GigtRqyZwL9SRagx5e0koN6g7f+/i5I7mHZHlVhSb+ iuo+vj9vjcnar0pVcLRYpj1du7W61T83xhljQ+UeuXdBABmiYhpfLg/MgzTu2HR4kM1v S+NnkogUdRe77cU3FjPNDFq2vl43mZcJg9a0jrRflch032M5iczu6T1fsMQhD4jp1dx3 4Yzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=CfQTWBRmQ0zAv3AgQnjSKAn4ZkEgArOQ9r3raMZkL1Q=; b=HP9NmqN7Pmb3d1Oc5hi7q4qPQdE6yRYMTg9qf3lI6hcUrJMSY1JPPJT1NJn/S9Q4VP Uk2T+NffEA/DxxUGYsvQWbzYH1zK8K9lOjgdzKvGwStVkU1xsRTRDUWkIq3cfBYZvylG vZ+PxfNw1MuTCiQY59OtGf34mLPYSfUmAU79HWQfNbbz99eu2toF472QUY41hpnsCcrP dQoubUFGrjONFYToSqpK/0/jIFj525QT4vMpSs71QCnjdT1IncrCP+kAq3aqqfUYfo5W 3Vuo63WQymFXqwciaOtPT7ZwdeHUJ0+DLvXVroLuhXfwxCHHyAaaZFjOhxPzEsFFZdBv 44Cg== X-Gm-Message-State: ALoCoQmOSrsOKvN42RYdxtDFuqmmcAjZSMSpYemSp9wuL0BLnpxi16JiKOAHxpk6NlvIqL6Wc5i6LxNL4O5Mefb0iO9LXS/NMVdiMUe0b37rPFwctjfiVJQ= X-Received: by 10.194.222.195 with SMTP id qo3mr107626078wjc.51.1452099000947; Wed, 06 Jan 2016 08:50:00 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFIohM1YHO8moVkQROqUBIiVRDGFw== Date: Wed, 6 Jan 2016 11:50:00 -0500 Message-ID: <20dd08695aa25e204594da7f6fbc9ba4@mail.gmail.com> To: "Paul Giralt (pgiralt)" , insipid@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 16:50:03 -0000 Hi, > I still think the situations under which there are > inaccurate Session-IDs are very isolated. Yes; it is limited only to situations involving a changed uuid. At worst, there are situations where an intermediary can send a request containing Session-ID with both uuid values being incorrect. At best, the inconsistency might eventually get corrected by subsequent messaging. However, it may take until the endpoint sends a BYE response (or the endpoint might not respond to BYE). Thanks, Brett From nobody Wed Jan 6 13:01:30 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22E21A06E9 for ; Wed, 6 Jan 2016 13:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB5isoDmR-t5 for ; Wed, 6 Jan 2016 13:01:27 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C021A065C for ; Wed, 6 Jan 2016 13:01:26 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id b14so93752078wmb.1 for ; Wed, 06 Jan 2016 13:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=5ivPWAoAJpUtuNxOEXQ4fTPflHXEq0xR3jHHdFSfnfE=; b=nI/Q9f44o1rDSFZ7BhWWdDPtkH6l2CEBKWTh8w1vVMo3fEoqcRVnxxrUj4Xx4ji9y7 Ha/ogPRL/Igwxt1fcJwMKechC4+xJxBeiQ/y2If2V3BGFB8o9etJSCbjQqRnGepapxSw WcQVpKUqbnEirXOt5Z0KHq2Znu89bwdAK/hM/nFh8agRZ0ue8cJzdsWaAlJXTKqoItWS FhFRzvXf4yU+1no4kH4RnnVg40DJ8t6Z84BPZbMptZKahIVWLkvj99d/+xXrRTiDVmvp wRPv7Gai1gi8fakQDO5slFChVEGGiJbtvRqn12lZhCNcVrrzxFk1ytCOvQOXgrMfIGaQ V0Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=5ivPWAoAJpUtuNxOEXQ4fTPflHXEq0xR3jHHdFSfnfE=; b=Xzw/x3RRJpzI3MrXPGcesMLZHBWKaofu9iNv1CJGnGwyDQfCojj3eEQ8KVcEoPphDy IdE22MkVT78EfJwYsu+3zRE63erjS2WycNGPtmv/AKurCVDGHVa96Ew/HlKGtjCMLOuG IK7JQMzl8HHeHL8m8A+VE7P2J9FIow/AfQ+Wdc8gciou4OGDJtRHhMUSzBTNHLxIUtTg II7BIOpSyEkX29QyuVJABdvaEDga4ZNZod/gDlVr+ah9G1i0Turpqv+ji1qbrcSLNYal Fzj8VXWHnlV3cPV+Men6oH+SDP/zRnyj3pA2tETRxzuHv0cyHG9D0cw07SNTwn83QZ4j 9KEw== X-Gm-Message-State: ALoCoQniMtBkVuKFSujPBhHn1efbpF2iCL6ZZEXDRtPox1IBymiEXGQB8WqP0vXJ7P6oJbGJHkaOMoCQTjEaZlfM6tHbDoiOpJMl7eXy8coQXc5vtA96sds= X-Received: by 10.28.30.210 with SMTP id e201mr13055766wme.42.1452114085212; Wed, 06 Jan 2016 13:01:25 -0800 (PST) From: Brett Tate References: <3281541955cae98a74545990e0bf5c35@mail.gmail.com> <9AC1FE32-A288-4093-9844-5137735D748B@cisco.com> In-Reply-To: <9AC1FE32-A288-4093-9844-5137735D748B@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFnDhLYfVMGF0bwk7F0rd0uXRgsJwHGzYd+n7TY9OA= Date: Wed, 6 Jan 2016 16:01:24 -0500 Message-ID: To: "Paul Giralt (pgiralt)" , insipid@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 21:01:29 -0000 Hi, Thanks for the response; reply is inline. > > The proposal currently appears to violate (or alter) > > RFC 3261 section 8.2: "If it is rejected, all state > > changes MUST NOT be performed". Similarly it also > > appears to impact the following RFC 6141 section 3.3 > > SHOULD: "If any of the changes requested in a re-INVITE > > or in any transaction within it have already been > > executed, the UAS SHOULD return a 2xx response=E2=80=9D. > > You could argue that the intermediary is not the one > actually rejecting the request bur merely relaying the > rejection. The proposal says that the device that is > actually doing the rejection of the request is not storing > the UUID. For troubleshooting purposes, which is the > desired objective of the Session-ID, it makes sense to > do as I proposed. The argument is weak. You are basically saying that an intermediary should remember the changed uuid even though the re-INVITE to connect a different session failed. The proposal appears to cause intermediaries (e.g. B2BUAs) to violate RFC 3261 section 8.2. Similarly it also appears to impact the following RFC 6141 section 3.3 SHOULD: "If any of the changes requested in a re-INVITE or in any transaction within it have already been executed, the UAS SHOULD return a 2xx response=E2=80=9D. > > You might want to exclude CANCEL and its 2xx response > > from the algorithm (although decision might be > > influenced by decision concerning 100 response). > > CANCEL and related 2xx response are not end-to-end (even > > if using proxies instead of B2BUAs). > > Is there any situation where including CANCEL could cause > a problem? It depends upon what you mean by problem. It can cause more inconsistencie= s because of race conditions and not being end-to-end. I'm not sure how vendors typically handle CANCEL in relation to RFC 3261 section 8.2's "all state changes MUST NOT be performed" if the CANCEL causes a 487 for re-INVITE; however based upon RFC 6141, it looks like the CANCEL changes (i= f anyone actually allows them) should be undone when sending the 487 response similar to what it mentions concerning UPDATE. Similarly depending upon ho= w long the transaction being cancelled is remembered, the CANCEL might be received after final response is sent and still result in 200 response for CANCEL. > >> The only additional rule for stateful intermediaries > >> is that if they accept a request and then forward that > >> request to another destination (therefore there was no > >> error found with the message), this will also trigger > >> the intermediary to update the retained UUID. > > > > The proposal means that not all of the devices will > > necessarily agree if a uuid changed during failure > > situation. > > > > Concerning "therefore there was no error found" statement, > > be aware that forwarding a request does not necessarily mean > > that no error was found (i.e. device can be lenient) or that > > the request won't eventually be rejected (with 400 or other > > failure response). > > Yes, I totally understand that the request might be eventually > rejected by some other device down the line, but as an > intermediary, it seems like this is the best we can do. No comment since currently unsure if the proposal is better than the draft or other potential mechanisms. > >> There will always be feature interactions that result in > >> temporarily mismatched Session IDs when intermediaries are > >> involved, but I don=E2=80=99t think the above proposal makes this > >> any worse of a problem in real-world applications. > > > > I'm currently not sure if the proposal is better or worse > > than draft version 16. > > > > From the rejecting device perspective, the proposal appears > > to be better. The proposal currently appears to leave partial > > changes up to rejecting device (i.e. intermediaries allowed > > change but rejecting device did not) without any indication > > to modifier to know if change was successful at the remote > > endpoint. This is about the same as changing some of the MUST > > to SHOULD (or MAY) within the current draft which would allow > > the rejecting device to make the decision concerning which is > > better for the situation. > > > > Changing MUSTs to SHOULDs would certainly address many of these > issues as well, but leave us with the issues you pointed out > with RFC 3261 section 8.2. Yes; however the proposal also violates RFC 3261 section 8.2 since not always rolling back (on the intermediaries) or after 101-199 (on the rejecter). And not allowing the first rejecter to potentially also violate it within the specific situation mandates inconsistency concerning the uuid values. From nobody Fri Jan 8 13:02:18 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BAB1B2BB1 for ; Fri, 8 Jan 2016 12:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2e-1zGYUlcd for ; Fri, 8 Jan 2016 12:59:16 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 638151B2BAC for ; Fri, 8 Jan 2016 12:59:16 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id DF7BDBCC2599A; Fri, 8 Jan 2016 20:59:09 +0000 (GMT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u08KxC2h028451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2016 20:59:12 GMT Received: from [135.185.238.169] (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u08KxBZC006036; Fri, 8 Jan 2016 14:59:11 -0600 (CST) To: "Dawes, Peter, Vodafone Group" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89BC37B@VOEXM31W.internal.vodafone.com> From: "Vijay K. Gurbani" Message-ID: <5690231F.10205@bell-labs.com> Date: Fri, 8 Jan 2016 14:59:11 -0600 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89BC37B@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 08 Jan 2016 13:02:08 -0800 Cc: "Arun Arunachalam \(carunach\) \(carunach@cisco.com\)" , insipid@ietf.org, "Gonzalo Salgueiro \(gsalguei@cisco.com\)" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:59:18 -0000 On 01/06/2016 10:14 AM, Dawes, Peter, Vodafone Group wrote: > Hello Vijay, Our requirements draft > (https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ) > for marking SIP sessions to be logged has received several reviews > and comments and has been corrected and improved as a result. We > think that yours is now the only review without confirmation that the > issues raised are resolved. We appreciate that many IETF contributors > are very busy and it was great that you found time to review the > draft and post to the insipid list. 3GPP has a dependency on this > logme marking functionality that is due to complete in February and > it would help a lot if this requirements draft could be completed by > then. > > Could we kindly ask you to check the following e-mails from the > insipid exploder to see if your comments are covered: Your review: > https://mailarchive.ietf.org/arch/msg/insipid/lD_87m-plpvQ-gcv_QJdydhmnuA > Our resolution of your comments: > https://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xYE Peter, all: Thank you for pinging me on this one. I am happy with the resolutions you proposed in https://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xYE In addition, I went quickly through version -04 and have one minor comment: 1/ S1: Such debugging and tests might be confined to a single service provider but might also be needed for customers who have different service providers, including providers in different countries that are interconnected through networks belonging to one or more third parties. I don't like the use of "customers" in the above paragraph; after all, the customer will most likely not even know what SIP is. The issue is that the debugging is initiated by the service provider to find a fault. Probably best to say that "Such debugging and tests might be confined to a single service provider or network may occur between the administrative domains of service providers, including providers in different countries that are interconnected through networks belonging to one or more third parties." Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Jan 8 14:59:07 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E921B2C7E for ; Fri, 8 Jan 2016 14:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcpNL0b8u4kW for ; Fri, 8 Jan 2016 14:59:04 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1675F1B2C7A for ; Fri, 8 Jan 2016 14:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3001; q=dns/txt; s=iport; t=1452293943; x=1453503543; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KVWhE20g6R3ohFSsZygaKSLunfD5gkWbx6m5RbEwD5w=; b=kVxCN+4USpVfMNZRHclfnpcZLK/NKaJu+OLY50eUAFAsXaVB9JGhNbjR YXEV7VzsDUKekDGzhCYtu+44jTlEupT1gcUpyfQVIfLi9od8ML3nNmPkS HI+22dPiGEmGSVxpjyGxPdE/kaGBjMs+QkIERZTjJvYOz+l+wmzAtirps Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBQDGPpBW/51dJa1egzpSZwYGiFO1P?= =?us-ascii?q?SSFawKBHjsRAQEBAQEBAYEKhDQBAQEDAXkFCwIBCBguMiUBAQQOBYgnCAkFwg4?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEYiGWBbIEEhCYRAR2DTIEbAQSTCoQDAYVCi?= =?us-ascii?q?BWBXI0fhWOBHwKDV4NyATgshApyDAEBhBE6gQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,541,1444694400"; d="scan'208";a="64666498" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2016 22:59:03 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u08Mx3r8026623 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jan 2016 22:59:03 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Jan 2016 16:59:02 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.009; Fri, 8 Jan 2016 16:59:02 -0600 From: "Arun Arunachalam (carunach)" To: "Vijay K. Gurbani" Thread-Topic: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 Thread-Index: AdFInPsGzgZbLErQQDeU0fTkgwM4eAB7LviAAAQvZIA= Date: Fri, 8 Jan 2016 22:59:02 +0000 Message-ID: <1A547D90-DA74-4E74-8AF3-BBD77E30F0D5@cisco.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89BC37B@VOEXM31W.internal.vodafone.com> <5690231F.10205@bell-labs.com> In-Reply-To: <5690231F.10205@bell-labs.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.150.54.109] Content-Type: text/plain; charset="Windows-1252" Content-ID: <377B7848F39BEB468A8AD5B85087F84E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Arun Arunachalam \(carunach\)" , "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 22:59:06 -0000 Thanks Vijay! We will update the text to the following: "Such debugging and tests might be confined to a single service provider or= network, may occur between the administrative domains of service providers, includin= g=20 providers in different countries that are interconnected through networks b= elonging to one or more third parties.=94 Arun On Jan 8, 2016, at 3:59 PM, Vijay K. Gurbani wrote: > On 01/06/2016 10:14 AM, Dawes, Peter, Vodafone Group wrote: >> Hello Vijay, Our requirements draft >> (https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ) >> for marking SIP sessions to be logged has received several reviews >> and comments and has been corrected and improved as a result. We >> think that yours is now the only review without confirmation that the >> issues raised are resolved. We appreciate that many IETF contributors >> are very busy and it was great that you found time to review the >> draft and post to the insipid list. 3GPP has a dependency on this >> logme marking functionality that is due to complete in February and >> it would help a lot if this requirements draft could be completed by >> then. >>=20 >> Could we kindly ask you to check the following e-mails from the >> insipid exploder to see if your comments are covered: Your review: >> https://mailarchive.ietf.org/arch/msg/insipid/lD_87m-plpvQ-gcv_QJdydhmnu= A >> Our resolution of your comments: >> https://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xY= E >=20 > Peter, all: Thank you for pinging me on this one. >=20 > I am happy with the resolutions you proposed in > https://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xYE >=20 > In addition, I went quickly through version -04 and have one minor > comment: >=20 > 1/ S1: Such debugging and tests might be confined to a single > service provider but might also be needed for customers who have > different service providers, including providers in different > countries that are interconnected through networks belonging to one > or more third parties. >=20 > I don't like the use of "customers" in the above paragraph; after all, > the customer will most likely not even know what SIP is. The issue is > that the debugging is initiated by the service provider to find a > fault. >=20 > Probably best to say that "Such debugging and tests might be confined > to a single service provider or network may occur between the > administrative domains of service providers, including providers in > different countries that are interconnected through networks belonging > to one or more third parties." >=20 > Cheers, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Mon Jan 11 07:07:19 2016 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F8A1A0218; Mon, 11 Jan 2016 07:07:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111150718.9284.27406.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 07:07:18 -0800 Archived-At: Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-reqs-05.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:07:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID Working Group of the IETF. Title : Requirements for Marking SIP Messages to be Logged Authors : Peter Dawes Chidambaram Arunachalam Filename : draft-ietf-insipid-logme-reqs-05.txt Pages : 9 Date : 2016-01-11 Abstract: SIP networks use signalling monitoring tools to debug customer reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-reqs-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 07:29:51 2016 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8921A0366; Mon, 11 Jan 2016 07:29:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160111152949.16793.38263.idtracker@ietfa.amsl.com> Date: Mon, 11 Jan 2016 07:29:49 -0800 Archived-At: Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-logme-reqs-06.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:29:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the INtermediary-safe SIP session ID Working Group of the IETF. Title : Requirements for Marking SIP Messages to be Logged Authors : Peter Dawes Chidambaram Arunachalam Filename : draft-ietf-insipid-logme-reqs-06.txt Pages : 9 Date : 2016-01-11 Abstract: SIP networks use signalling monitoring tools to debug customer reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-logme-reqs-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 07:42:07 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8041A1AB6 for ; Mon, 11 Jan 2016 07:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wk1yLLIDU-M for ; Mon, 11 Jan 2016 07:42:04 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (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 321AF1A1A96 for ; Mon, 11 Jan 2016 07:42:03 -0800 (PST) Received: from [85.158.136.83] by server-13.bemta-5.messagelabs.com id CA/86-06091-94DC3965; Mon, 11 Jan 2016 15:42:01 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-11.tower-36.messagelabs.com!1452526921!11368721!1 X-Originating-IP: [195.232.244.134] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13312 invoked from network); 11 Jan 2016 15:42:01 -0000 Received: from mailout02.vodafone.com (HELO mailout02.vodafone.com) (195.232.244.134) by server-11.tower-36.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jan 2016 15:42:01 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout02.vodafone.com (Postfix) with ESMTP id 3pfK605rrWzbdMS; Mon, 11 Jan 2016 16:42:00 +0100 (CET) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3pfK604jbyzQnXY; Mon, 11 Jan 2016 16:42:00 +0100 (CET) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3pfK604c2JzQjyJ; Mon, 11 Jan 2016 16:42:00 +0100 (CET) Received: from VOEXC15W.internal.vodafone.com (145.230.101.17) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 11 Jan 2016 16:42:00 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.89]) by voexc15w.internal.vodafone.com ([145.230.101.17]) with mapi id 14.03.0224.002; Mon, 11 Jan 2016 16:41:59 +0100 From: "Dawes, Peter, Vodafone Group" To: "Vijay K. Gurbani (vkg@bell-labs.com)" , "insipid@ietf.org" Thread-Topic: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 Thread-Index: AdFMeipZMyp4trrwT/iglcqTmH/oHg== Date: Mon, 11 Jan 2016 15:41:59 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89BF77C@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Arun Arunachalam \(carunach\) \(carunach@cisco.com\)" , "insipid-chairs@tools.ietf.org" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:42:06 -0000 Hello Vijay, All, The Introduction text has now been revised to focus on service providers no= t customers (https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-06.txt).= I added the word "or" to the text Arun quotes below to clearly separate th= e single and multiple service provider cases, i.e.=20 "Such debugging and tests might be confined to a single service provider or= network, or may occur between the administrative domains of service providers, inclu= ding=20 providers in different countries that are interconnected through networks b= elonging to one or more third parties." Apologies for jumping from -04 to -06 but I made a mistake in the -05 revis= ion. The authors believe that this latest version (-06) includes resolution= s of all review comments.=20 Regards, Peter Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 "Arun Arunachalam (carunach)" Fri, 08 January 2016 22:= 59 UTC Thanks Vijay! We will update the text to the following: "Such debugging and tests might be confined to a single service provider or= network, may occur between the administrative domains of service providers, includin= g=20 providers in different countries that are interconnected through networks b= elonging to one or more third parties." Arun On Jan 8, 2016, at 3:59 PM, Vijay K. Gurbani wrote: > On 01/06/2016 10:14 AM, Dawes, Peter, Vodafone Group wrote: >> Hello Vijay, Our requirements draft >> (https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ ) >> for marking SIP sessions to be logged has received several reviews >> and comments and has been corrected and improved as a result. We >> think that yours is now the only review without confirmation that the >> issues raised are resolved. We appreciate that many IETF contributors >> are very busy and it was great that you found time to review the >> draft and post to the insipid list. 3GPP has a dependency on this >> logme marking functionality that is due to complete in February and >> it would help a lot if this requirements draft could be completed by >> then. >>=20 >> Could we kindly ask you to check the following e-mails from the >> insipid exploder to see if your comments are covered: Your review: >> https://mailarchive.ietf.org/arch/msg/insipid/lD_87m-plpvQ-gcv_QJdydhmnu= A >> Our resolution of your comments: >> https://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xY= E >=20 > Peter, all: Thank you for pinging me on this one. >=20 > I am happy with the resolutions you proposed in > https://mailarchive.ietf.org/arch/msg/insipid/6tlXJVDw3eFaUyuEM6OXf53_xYE >=20 > In addition, I went quickly through version -04 and have one minor > comment: >=20 > 1/ S1: Such debugging and tests might be confined to a single > service provider but might also be needed for customers who have > different service providers, including providers in different > countries that are interconnected through networks belonging to one > or more third parties. >=20 > I don't like the use of "customers" in the above paragraph; after all, > the customer will most likely not even know what SIP is. The issue is > that the debugging is initiated by the service provider to find a > fault. >=20 > Probably best to say that "Such debugging and tests might be confined > to a single service provider or network may occur between the > administrative domains of service providers, including providers in > different countries that are interconnected through networks belonging > to one or more third parties." >=20 > Cheers, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Mon Jan 11 09:23:49 2016 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C821A3BA0 for ; Mon, 11 Jan 2016 07:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn9jgO1benK1 for ; Mon, 11 Jan 2016 07:58:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9CF511A1EEA for ; Mon, 11 Jan 2016 07:58:52 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 8C38FE3381C70; Mon, 11 Jan 2016 15:58:46 +0000 (GMT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u0BFwlQW008837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2016 15:58:48 GMT Received: from [135.185.238.169] (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id u0BFwlST013504; Mon, 11 Jan 2016 09:58:47 -0600 (CST) To: "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89BF77C@VOEXM31W.internal.vodafone.com> From: "Vijay K. Gurbani" Message-ID: <5693D137.4010302@bell-labs.com> Date: Mon, 11 Jan 2016 09:58:47 -0600 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C89BF77C@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2016 09:23:47 -0800 Cc: "Arun Arunachalam \(carunach\) \(carunach@cisco.com\)" , "insipid-chairs@tools.ietf.org" Subject: Re: [Insipid] Review of draft-ietf-insipid-logme-reqs-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:58:55 -0000 On 01/11/2016 09:41 AM, Dawes, Peter, Vodafone Group wrote: > Hello Vijay, All, The Introduction text has now been revised to focus > on service providers not customers > (https://www.ietf.org/id/draft-ietf-insipid-logme-reqs-06.txt). I > added the word "or" to the text Arun quotes below to clearly separate > the single and multiple service provider cases, i.e. [...] Awesome. Thanks for attending my comments; I don't have any further ones. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Tue Jan 12 14:54:36 2016 Return-Path: X-Original-To: insipid@ietf.org Delivered-To: insipid@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B14891A8974; Tue, 12 Jan 2016 14:45:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160112224524.7740.17305.idtracker@ietfa.amsl.com> Date: Tue, 12 Jan 2016 14:45:24 -0800 Archived-At: X-Mailman-Approved-At: Tue, 12 Jan 2016 14:54:34 -0800 Cc: ben@nostrum.com, insipid@ietf.org, gsalguei@cisco.com, insipid-chairs@ietf.org Subject: [Insipid] insipid - Not having a session at IETF 95 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 22:45:24 -0000 Gonzalo Salgueiro, a chair of the insipid working group, indicated that the insipid working group does not plan to hold a session at IETF 95. This message was generated and sent by the IETF Meeting Session Request Tool.