Subject: Re: [dispatch] Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored]

From: Adam Roach <[email-masked]>
Date: Fri, 13 May 2016 14:33:04 -0500

The -06 version addresses the only blocking concerns that I had. From an 
expert review perspective, I approve its publication.

/a

On 4/27/16 10:57, Christer Holmberg wrote:
> Hi,
>
> Based on Adam's comments, I've submitted a new version (-06) of draft-holmberg-dispatch-rfc7315-updates.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 27 April 2016 18:07
> To: Adam Roach <[email-masked]>; A. Jean Mahoney <[email-masked]>; [email-masked]
> Subject: Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored
>
> Hi,
>
>> Sure -- my suggestion was one for clarification. If 3GPP does, in fact,
>> intend to allow the header field in mid-dialog  messages, then my
>> comment doesn't apply.
>>
>> But if they *do* intend to allow the field mid-dialog, I'm curious
>> about why it's forbidden in the current list of methods: save for some
>> obscure corner cases, all of the methods called out by name are sent
>> mid-dialog, and none of the un-named methods are.
> OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog.
>
> I can't give an answer here and now why the list looks like it does, but this is how it's specified in 3GPP :)
>
>> Either way, it's just a suggestion. The hard block here is in the ACK
>> handling that I pointed out.
> Based on your comments, the new text would now say:
>
>     "The P-Associated-URI header field can appear in SIP REGISTER
>     2xx responses. The P-Called-Party-ID header field can appear in
>     SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.
>     The P-Visited-Network-ID header field can appear in all SIP methods
>     except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The
>     P-Access-Network-Info header field can appear in all SIP methods
>     and non-100 responses, except in CANCEL methods, CANCEL responses
>     and ACK methods triggered by non-2xx responses. The P-Charging-Vector
>     header field can appear in all SIP methods and non-100 responses,
>     except in CANCEL methods, CANCEL responses and ACK methods triggered
>     by non-2xx responses. The P-Charging-Function-Addresses header field
>     can appear in all SIP methods and non-100 responses, except in ACK
>     and CANCEL methods and CANCEL responses."
>
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>> /a
>>
>> On 4/27/16 08:01, Christer Holmberg wrote:
>>> Hi,
>>>
>>> One more thing:
>>>
>>> I guess we could also change ³all responses² to ³all non-100
>>> responses²,  as 100 responses are also hop-to-hop (similar to ACKs
>>> triggered by non-2xx  responses).
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> On 25/04/16 14:30, "Christer Holmberg"
>>> <[email-masked]>
>>> wrote:
>>>
>>>> Hi Adam,
>>>>
>>>> Are you ok with my suggested way forward?
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> On 21/04/16 22:43, "Christer Holmberg"
>>>> <[email-masked]>
>>>> 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-upd
>>>>> ate
>>>>> 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
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 May 2016 19:15:36 +0000

Thanks! :)

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 13 May 2016 22:33
To: Christer Holmberg <[email-masked]>; A. Jean Mahoney <[email-masked]>; [email-masked]
Subject: Re: Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored]

The -06 version addresses the only blocking concerns that I had. From an expert review perspective, I approve its publication.

/a

On 4/27/16 10:57, Christer Holmberg wrote:
> Subject: Re: [dispatch] Progressing 
> draft-holmberg-dispatch-rfc7315-updates as AD sponsored
>
> Hi,
>
>> Sure -- my suggestion was one for clarification. If 3GPP does, in 
>> fact, intend to allow the header field in mid-dialog  messages, then 
>> my comment doesn't apply.
>>
>> about why it's forbidden in the current list of methods: save for 
>> some obscure corner cases, all of the methods called out by name are 
>> sent mid-dialog, and none of the un-named methods are.
> I can't give an answer here and now why the list looks like it does, 
> but this is how it's specified in 3GPP :)
>
>>>>> INVITE  requests, but there is no text explicitly disallowing it 
>>>>> in re-INVITEs.
>>>>>
>>>>> 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.
>>>>>
>>>>>