Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

"Paul E. Jones" <paulej@packetizer.com> Tue, 31 March 2015 03:22 UTC

Return-Path: <paulej@packetizer.com>
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 70B091A8AD9 for <insipid@ietfa.amsl.com>; Mon, 30 Mar 2015 20:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.113
X-Spam-Level:
X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 iCyTu5a5v3R9 for <insipid@ietfa.amsl.com>; Mon, 30 Mar 2015 20:22:25 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 BA52F1A8AA2 for <insipid@ietf.org>; Mon, 30 Mar 2015 20:22:23 -0700 (PDT)
Received: from [192.168.1.20] (cpe-098-027-048-015.nc.res.rr.com [98.27.48.15]) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t2V3MLFr018397 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2015 23:22:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1427772142; bh=nrSm4Kk0WFito0DH6oEwIxlgEoZ91LksVoYYzsZ75Ks=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=S1VpETQCvbOMWXsLfliA4smSwrVgaHxzYsCmvwGKo5eT9IOpXChQ1UXQJNz7+KYxK gRFU9NOMhxGND9pImzNAyVmybp+89RJwOh54Ugih24FSHeJ6W3M3Qolt7aY5CJS7oX Num+JRhLvgzZyPMCXyYJzqAVh4oJtDtFX0b0b0fE=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Brett Tate <brett@broadsoft.com>, insipid@ietf.org, draft-ietf-insipid-session-id@tools.ietf.org
Date: Tue, 31 Mar 2015 03:22:36 +0000
Message-Id: <em67abb241-0d49-48c0-b810-ca7c9b3bae7c@sydney>
In-Reply-To: <928f56e17e98f35e671871af351c80c7@mail.gmail.com>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/nQ6WelBolqqqA26iQ6TDoSC-PdY>
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
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 03:22:27 -0000

Brett,

Thanks for the feedback.  I will try to incorporate your suggestions, 
resolve identified issues, etc. and address input I received from 
others.  I'll try to get a new draft out this week.

Paul

------ Original Message ------
From: "Brett Tate" <brett@broadsoft.com>
To: insipid@ietf.org; draft-ietf-insipid-session-id@tools.ietf.org
Sent: 3/30/2015 9:19:06 AM
Subject: draft-ietf-insipid-session-id-14: comments and questions

>Hi,
>
>The following are some comments concerning
>draft-ietf-insipid-session-id-14.
>
>Sorry about the delay.
>
>Thanks,
>Brett
>
>---------
>
>General comment: I find the concepts of endpoint and intermediary
>confusing within the draft. For instance if a proxy/B2BUA decides to
>reject an INVITE during call setup, does section 6 or section 7 apply? 
>I
>assume that section 6 applies (if it didn't relay the related request).
>If the proxy/B2BUA rejects a mid-dialog request (while acting as an
>intermediary for the session), section 7 applies. Adding something to
>section 2 to clarify ambiguity might help. If a device which can act as
>endpoint or intermediary rejects a re-INVITE for an unknown dialog by
>sending 481, should it do so following section 6 or section 7?
>
>General comment: I find the use of UA within draft occasionally 
>ambiguous
>concerning if it includes or excludes intermediaries such as B2BUA and
>proxy's UAS when it is used.
>
>Section 5 paragraph 2: What does "accepted" mean? For instance, does
>returning a failure response such as 407 or 401 mean that you accepted 
>the
>session? Should adjust text to remove the ambiguity.
>
>Section 5 paragraph 2: Should potentially remove "UA-generated" since 
>the
>next paragraph mentions that it can be generated by a proxy.
>
>Section 5 paragraph 7: In my opinion, the MUST should be changed to 
>SHOULD
>(along with similar changes elsewhere); however since I guess the 
>working
>group disagrees... Should add text somewhere concerning the impacts of
>race conditions, retries, CANCEL, authentication, overload, et cetera 
>upon
>the "most recently received UUID" algorithm. For instance if "most
>recently received UUID" was processed as a retry, it potentially isn't 
>the
>best choice for inclusion as the remote-uuid. Since CANCEL can contain 
>an
>older UUID, it potentially isn't the best choice for inclusion as the
>remote-uuid. Because of race conditions, the "most recently received
>UUID" is not necessarily the most recent UUID sent by the remote 
>endpoint.
>If a device returns 500 because lower CSeq, it seems strange that the 
>UAS
>MUST update the stored UUID. If the "most recently received UUID" 
>hasn't
>passed authentication (i.e. returning 401, 407, or 403), should the
>request (or the related ACK) still be allowed to alter the stored UUID?
>If an overloaded device returns a failure response (such as 503), is 
>the
>overloaded device actually supposed to still update the stored UUID to 
>be
>compliant with this mandate? If this draft is mandating an overloaded
>server process an unauthenticated request to update stored information, 
>it
>should be mentioned within section 11.
>
>Section 6 paragraph 2: Should clarify authentication behavior. For
>instance, RFC 3261 allows the challenger to behave mostly stateless 
>(such
>as by not retrying 401/407); however this draft currently appears to
>mandate maintaining additional information and perform related
>modifications.
>
>Section 6 paragraph 3: What is the intended impact of the paragraph if
>received 3xx-6xx (such as 302, 401, 407, 422, 488, or 503) for INVITE
>during call setup and it causes sending related subsequent INVITE? For
>instance, does it require the subsequent out-of-dialog INVITE to 
>contain
>the updated remote-uuid (instead of null)? I wasn't sure if there was 
>any
>leeway for the endpoint to think that the INVITEs are part of different
>communication sessions (from remote endpoint perspective).
>
>Section 6 paragraph 7: "shall" potentially should be "SHALL".
>
>Section 7 paragraph 3: The paragraph potentially should clarify the
>forking interaction (such as the aggregation concept mentioned in RFC 
>3261
>section 16.7) since only 1 of the potentially many Session-ID headers 
>will
>be relayed. For instance, the Session-ID of the selected "communication
>session" (sent within response) might be forked to all of the
>"communication sessions" (if received within subsequent transaction).
>
>Section 7 paragraph 3: If the intermediary knows it is relaying the
>request to a different session, can it fix the remote-uuid (such as
>changing it to null)?
>
>Section 7 last paragraph: Change "were last received by an endpoint" to
>"it last sent towards an endpoint".
>
>Section 9 paragraph 2: Concerning statement that the section is
>non-normative, be aware that the section does contain some MUST 
>(although
>might not be in conflict).
>
>Section 9.3 last bullet: replace "include" with "includes".
>
>Section 14.2: Potentially should add the rest of the RFC 3725 title.