Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 27 April 2016 19:29 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9F12D55C for <dispatch@ietfa.amsl.com>; Wed, 27 Apr 2016 12:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMZc-iUlUmMn for <dispatch@ietfa.amsl.com>; Wed, 27 Apr 2016 12:29:19 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B44B12D547 for <dispatch@ietf.org>; Wed, 27 Apr 2016 12:29:18 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-a1-5721130c306c
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2E.DB.12516.C0311275; Wed, 27 Apr 2016 21:29:17 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 21:29:16 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored
Thread-Index: AQHReK0rXLsqd7cN3kOoNRzSlGqrZ5+TKEuAgAAob1CAAcb14IAF08iAgAM+FoD//9KdAIAAUJsAgAAA1ACAACUQcP//5NQAgAAqvmA=
Date: Wed, 27 Apr 2016 19:29:15 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37F86AAF@ESESSMB209.ericsson.se>
References: <CAHBDyN7iOPZN_jjd0_E5r+UG1jswY=-y17pr0skvPq5bJ2SrpA@mail.gmail.com> <56DDDFCD.5040604@nostrum.com> <5717A753.3050903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37F6D05B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F720BF@ESESSMB209.ericsson.se> <D343DAB9.7771%christer.holmberg@ericsson.com> <D34692DF.79BC%christer.holmberg@ericsson.com> <5720BC8A.5060709@nostrum.com> <D346AE07.79EE%christer.holmberg@ericsson.com> <5a28aedb-cba1-062a-e846-28a1b66c1694@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F869DB@ESESSMB209.ericsson.se> <cacd8217-72af-1cfd-3627-ca04d48af932@alum.mit.edu>
In-Reply-To: <cacd8217-72af-1cfd-3627-ca04d48af932@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hC6vsGK4wbGb3BZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxdf95poIf1hU3eg+zNDB+Nuhi5OSQEDCR aNo6hxXCFpO4cG89WxcjF4eQwBFGiXtrFrFCOEsYJZ51fGLpYuTgYBOwkOj+pw3SICIQLHHw 8E4WEFtYIFZi59qNzBDxOImLjffZIOwyibsNr8BqWARUJdbdnsIOYvMK+EqcbVwNtewPi8TL S3fAruAUcJB4cfst2CBGoIu+n1rDBGIzC4hL3HoynwniUgGJJXvOM0PYohIvH/+D+kBJYu3h 7SwQ9XoSN6ZOYYOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlyc m25krJdalJlcXJyfp5eXWrKJERgpB7f81t3BuPq14yFGAQ5GJR5eBVmFcCHWxLLiytxDjBIc zEoivFc5FMOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ZE/gsTEkhPLEnNTk0tSC2CyTJxcEo1 MGrNYn2Wlu+m8es4q/ubma815gZ8iDvQWnrv2GoXc40LFx9azakpzguTEXJdqS/7fw5T0Qzn +J5Pv9UNX5234XKs/Lmlb4fRo0ULzBXK6m/yKL75evCYoWmAUWfN7emLw68UxmS/+cS/NHXL 9ClisqY3FdIYzgiF736lzVO2qPX0Ktvgn30OSkosxRmJhlrMRcWJACFaNgOQAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/TourYHGSEzVpSqZNQDFfmRuTAp4>
Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 19:29:22 -0000

Hi,

...

>>>> Based on your comments, the new text would now say:
>>>>
>>>>    "The P-Associated-URI header field can appear in SIP REGISTER
>>>>    2xx responses. The P-Called-Party-ID header field can appear in
>>>>    SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.
>>>>    The P-Visited-Network-ID header field can appear in all SIP methods
>>>>    except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The
>>>>    P-Access-Network-Info header field can appear in all SIP methods
>>>>    and non-100 responses, except in CANCEL methods, CANCEL responses
>>>>    and ACK methods triggered by non-2xx responses. The P-Charging-Vector
>>>>    header field can appear in all SIP methods and non-100 responses,
>>>>    except in CANCEL methods, CANCEL responses and ACK methods triggered
>>>>    by non-2xx responses. The P-Charging-Function-Addresses header field
>>>>    can appear in all SIP methods and non-100 responses, except in ACK
>>>>    and CANCEL methods and CANCEL responses."
>>>
>>> These rules seem very arbitrary, without any obvious rationale - why are the rules different for the four different header fields?
>>>
>>> I can see that there might be a rationale, based on need during 
>>> dialog establishment or maybe just *call* establishment. But if so, I would think a generic way of describing the rule would work better than enumeration.
>>>
>>> So basically, if the rationale for the difference is stated first, 
>>> then it ought to make clear what messages are appropriate. When there are just different sets 
>>> of enumerations without explanation it invites debate over the particular messages included.
>>>
>>> The purpose of this task was to fix misalignments between 3455 and 7315, and incorporate new 3GPP 
>>> requirements - which are described in section 3.3 - and update the existing text (see below) in 7315 based on that.
>>
>> Old text:
>>
>>    The P-Associated-URI header field can appear in SIP REGISTER method
>>    and 2xx resonses.  The P-Called-Party-ID header field can appear in
>>    SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all
>>    responses.  The P-Visited-Network-ID header field can appear in all
>>    SIP methods except ACK, BYE, and CANCEL and all responses. The
>>    P-Access-Network-Info header field can appear in all SIP methods
>>    except ACK and CANCEL.  The P-Charging-Vector header field can appear
>>    in all SIP methods except CANCEL.  The P-Charging-Function-Addresses
>>    header field can appear in all SIP methods except ACK and CANCEL.
>
> IIUC what you are saying is that 3GPP doesn't specify a rationale, so you don't have one to put here.

I am saying that the chapter we are updating does not contain the rationale. It's the normative text replacing the "header field tables" we used to have.

Please note that each header field is more described elsewhere in the RFC.

We were requested to provide justification for the changes needed due to new 3GPP requirement, and that's what we've done in section 3.3.

Regards,

Christer



>>> On 4/27/16 08:01, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> One more thing:
>>>>
>>>> I guess we could also change ³all responses² to ³all non-100 
>>>> responses², as 100 responses are also hop-to-hop (similar to ACKs 
>>>> triggered by non-2xx responses).
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>> On 25/04/16 14:30, "Christer Holmberg"
>>>> <christer.holmberg@ericsson.com>
>>>> wrote:
>>>>
>>>>> Hi Adam,
>>>>>
>>>>> Are you ok with my suggested way forward?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>
>>>>> On 21/04/16 22:43, "Christer Holmberg"
>>>>> <christer.holmberg@ericsson.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Adam,
>>>>>>
>>>>>> ....
>>>>>>
>>>>>>>> One additional review note that does not affect my expert 
>>>>>>>> review (treat it as a last-call comment):
>>>>>>>>
>>>>>>>>
>>>>>>>>       Add statement that the P-Visited-Network-ID header field 
>>>>>>>> cannot
>>>>>>>>       appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods.
>>>>>>>>
>>>>>>>> It seems to me that it would be significantly more future proof 
>>>>>>>> to phase this as "...cannot appear in mid-dialog requests," as 
>>>>>>>> that appears to be the intention. The revised text then becomes 
>>>>>>>> something
>>>>>>>> like: "The P-Visited-Network-ID header field can appear in all 
>>>>>>>> SIP methods except ACK and CANCEL; however, it cannot be sent 
>>>>>>>> in
>>>>>>>>> any mid-dialog requests."
>>>>>>> Seems reasonable, but I'll verify with my 3GPP delegates.
>>>>>> I had a closer look at this, and I don't think we can forbid 
>>>>>> usage in all mid-dialog requests.
>>>>>>
>>>>>> For example, the header field is allowed in OPTIONS, that can be 
>>>>>> sent in-dialog.
>>>>>>
>>>>>> Also, the header field is allowed in REFER, and RFC 7614 defines 
>>>>>> a mechanism that allows in-dialog REFERs.
>>>>>>
>>>>>> re-INVITE is also tricky. The header field is generally allowed 
>>>>>> in INVITE requests, but there is no text explicitly disallowing 
>>>>>> it in re-INVITEs.
>>>>>>
>>>>>> Whether it makes sense to include the header field in the methods 
>>>>>> above I don't know (3GPP does allow them), but as the purpose is 
>>>>>> only to align
>>>>>> 7315 with 3455 I'd suggest we keep the text as it is.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/7/16 14:08, A. Jean Mahoney wrote:
>>>>>> Since this draft updates RFC 7315, which required expert review 
>>>>>> of its header fields, Adam Roach will be conducting an expert 
>>>>>> review of this draft according to the guidance given in RFC 5727.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jean
>>>>>>
>>>>>>
>>>>>> On 3/7/16 9:33 AM, Mary Barnes wrote:
>>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> This document has been proposed to be progressed as AD sponsored:
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-
>>>>>> u
>>>>>> pdate
>>>>>> s/
>>>>>> The document has been carefully reviewed and it is now ready to 
>>>>>> move forward - Jean Mahoney is the shepherd.
>>>>>>
>>>>>> I don't anticipate anyone would have concerns about this 
>>>>>> decision, given that's how RFC 7315 was progressed and this 
>>>>>> update has actually been much more carefully reviewed.  However, 
>>>>>> f anyone has any final comments, please post no later than 
>>>>>> Friday, March 11th, 2016.  Note, that you will also still have 
>>>>>> IETF LC to provide any comments.
>>>>>>
>>>>>> Regards,
>>>>>> Mary.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dispatch mailing list
>>>>>> dispatch@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>>
>>>>>> _______________________________________________
>>>>>> dispatch mailing list
>>>>>> dispatch@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>>
>>>>>> _______________________________________________
>>>>>> dispatch mailing list
>>>>>> dispatch@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>