Multiple SIP Reason Header Field Values
draft-ietf-sipcore-multiple-reasons-01
Yes
Murray Kucherawy
No Objection
Alvaro Retana
Erik Kline
John Scudder
Lars Eggert
Robert Wilton
Zaheduzzaman Sarker
Éric Vyncke
Note: This ballot was opened for revision 01 and is now closed.
Murray Kucherawy
Yes
Alvaro Retana
No Objection
Erik Kline
No Objection
John Scudder
No Objection
Lars Eggert
No Objection
Martin Duke
(was Discuss)
No Objection
Comment
(2022-10-24)
Thanks for addressing my DISCUSS.
Paul Wouters
(was Discuss)
No Objection
Comment
(2022-10-27)
Old DISCUSS: [ Resolved, as the document does not allow existing protocols to use this feature, only to be RFC'ed protocols. As such, there is no backwards compatibility issue. As written, it does allow another document to later on change if for existing protocols (eg SIP) but that document would than have to deal the its Operational Issue ] 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 ?
Robert Wilton
No Objection
Roman Danyliw
No Objection
Comment
(2022-10-24)
Thank you to Joseph Salowey for the SECDIR review.
Warren Kumari
No Objection
Comment
(2022-10-26)
I was going to ballot DISCUSS on this, but I see that Paul W has beat me to the punch. If a "legacy" implementation gets multiple values for a protocol, it is likely to be OK with this, or is it likely to explode in a massive fireball? I have absolutely no idea how many implementations there are, how restrictive their parsers are, etc (AKA, "Nah, we thought about this, and it's all good" is enough to satisfy me). Also, thanks for keeping the document so short and sweet...
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection