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

From: Adam Roach <[email-masked]>
Date: Wed, 20 Apr 2016 10:59:15 -0500

I apologize for the delay in responding here -- due to total mailing 
list volume, I do not read the DISPATCH list exhaustively, and this 
request for review was not brought to my attention until late last week.

There is a mishandling of ACK in this draft that I need to block it on, 
but I think it can be remedied very easily.

>    o  P-Access-Network-Info: Add statement that the header field can
>       appear in the SIP ACK method.
>
>    o  P-Charging-Vector: Add statement that the header field can appear
>       in the SIP ACK method.

These should say "SIP ACK method, but only when sent to acknowledge a 
2XX-class response."

Since ACKs for non-2XX responses are processed hop-by-hop, you cannot 
include any information in them (for the same reason you can't put 
information in CANCEL requests). And so...

>    P-Access-Network-Info header field can appear in all SIP methods
>    and responses, except in CANCEL methods and CANCEL responses.
>    The P-Charging-Vector header field can appear in all SIP methods and
>    responses, except in CANCEL methods and CANCEL responses

...becomes something like: "P-Access-Network-Info and P-Charging-Vector 
header fields can appear in all SIP methods and responses, except in 
CANCEL methods, CANCEL responses, and ACK methods that acknowledge 
non-2xx responses."

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."

/a

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-updates/ 
>>
>> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Apr 2016 16:29:23 +0000

Hi Adam,

Thanks for your comments! See inline.

>There is a mishandling of ACK in this draft that I need to block it on, but I think it can be remedied very easily.
>
>
> These should say "SIP ACK method, but only when sent to acknowledge a 2XX-class response."
>
> Since ACKs for non-2XX responses are processed hop-by-hop, you cannot include any information in them (for the same reason you can't put information in CANCEL requests). And so...

I agree. I'll fix as suggested.

-------

> ...becomes something like: "P-Access-Network-Info and P-Charging-Vector header fields can appear in all SIP methods and responses, except in 
> CANCEL methods, CANCEL responses, and ACK methods that acknowledge non-2xx responses."

Correct. I'll fix as suggested.

------

> 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.

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 

Hi folks, 

Regards, 
Mary.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Apr 2016 19:43:07 +0000

Hi Adam,

....

>>      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."
>

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

Thanks, 

Jean 

Hi folks, 

This document has been proposed to be progressed as AD sponsored: 
https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/
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.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Apr 2016 11:30:28 +0000

Hi Adam,

Are you ok with my suggested way forward?

Regards,

Christer

On 21/04/16 22:43, "Christer Holmberg" <[email-masked]>
wrote:

>>> field can appear in all SIP methods except ACK and CANCEL; however, it
>>>cannot be sent in >any mid-dialog requests."
>>
>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
>
>
>
>
>
>
>
>that's how RFC 7315 was progressed and this update has actually been much
>more carefully reviewed.  However, f anyone has any final comments,

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Apr 2016 13:01:22 +0000

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 27 Apr 2016 08:20:10 -0500

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.

Either way, it's just a suggestion. The hard block here is in the ACK 
handling that I pointed out.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Apr 2016 15:07:26 +0000

Hi,

>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 :)

>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

>>>> I had a closer look at this, and I don't think we can forbid usage in
>>>>all
>>>> mid-dialog requests.
>>>>
>>>>much

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Apr 2016 14:11:38 -0400

> OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog.

and MESSAGE.

>    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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Apr 2016 18:30:26 +0000

Hi,

...

>>    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.

Regards,

Christer

>>> 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
>>>
>>>
>>>>>>> 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 
>>>>> 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
>>>>> 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
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Apr 2016 14:47:02 -0400

>    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 presume that whenever and wherever these lists were created there was 
*some* rationale, even if it wasn't recorded. Is it possible to discover 
that rationale and write it down? It may be that the results were not 
even consistent with the unstated rationale. If so, is it more important 
to preserve consistency with the past, or to fix the mistake?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Apr 2016 19:29:15 +0000

Hi,

...

>>> 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:
>>
> 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

>>>>>>>> One additional review note that does not affect my expert 
>>>>>>>> review (treat it as a last-call comment):
>>>>>>>>
>>>>>>>>
>>>>>>>> SIP methods except ACK and CANCEL; however, it cannot be sent 
>>>>>>>> in
>>>>>>>>> any mid-dialog requests."
>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>