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

[Paul Wouters via Datatracker <[e-mail]>]

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 for the same protocol?

Will it just ignore the duplicate ? If so, should this document specify that
the order of these might be important ? Will it fail the entire sip packet? 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?

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 ?