Re: [sipcore] Paul Wouters' Discuss on draft-ietf-sipcore-multiple-reasons-01: (with DISCUSS)

[Robert Sparks <[e-mail]>]

On 10/25/22 4:14 PM, Paul Wouters via Datatracker wrote:
> Paul Wouters has entered the following ballot position for
> draft-ietf-sipcore-multiple-reasons-01: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-multiple-reasons/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I understand the document is changing an existing MUST, and the change itself
> seems fine. But I do wonder about the operational effect of this. What if a sip
> stack complying to this new RFC talks to an old sip stack complying to the old
> RFC. Is it known what the most widely used sip stacks do in the case of
> receiving a duplicate message
mild restatement to help think this through: you meant "more than one 
Reason header field value specifying the same protocol in the same SIP 
message".
>   for the same protocol?

As I replied to Roman, we did test this extensively at SIPits back in 
the day. Implementations ignore Reason header field values for protocols 
they know nothing about, and they do the right thing for those that were 
defined at the time they were implemented.

This is also being _thoroughly_ pre-socialized in the major deployment 
environments (mostly through the related ATIS IP/NNI efforts). The 
industry pressure to do what these documents currently specify is quite 
high.

>
> Will it just ignore the duplicate ? If so, should this document specify that
> the order of these might be important ?

Why are you concerned about ordering here? The base SIP specification 
says not to reorder header field values when going through 
intermediaries. Implementation that do not know about the protocol being 
discussed in a given Reason header field value will ignore that value, 
so ordering is irrelevant in that case anyhow.


> Will it fail the entire sip packet?
Not what we've seen, and certainly not what the specifications say to do.
> If
> so, should this document specify to only use this when the other end is known
> to implement this RFC?
> Should there be a fallback mechanism that will only sent
> the 1 most important "reason" if it looks the other end is failing on our
> message with multiple reasons?

I took several stabs at writing a short response to that, but I'm going 
to fall back to "That way lies madness". That moves into defining 
protocol behavior that goes far past what the original Reason header 
definition went into, and is essentially a proposal for a new protocol 
extension that experience says will not get consensus.

>
> The WG might have experience or testing that is not obvious to me (or other
> readers of the document).
>
> Perhaps a short Operational Considerations Section would be appropriate ?
I personally don't think it would, but such a thing would be more useful 
in a document that defined a protocol to use with the Reason header that 
allowed multiple values.
>
>
>
>
>