Multiple SIP Reason Header Field Values
draft-ietf-sipcore-multiple-reasons-01

Yes

Murray Kucherawy

No Objection

Erik Kline
John Scudder
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
(Alvaro Retana)
(Lars Eggert)
(Martin Duke)
(Robert Wilton)

Note: This ballot was opened for revision 01 and is now closed.

Murray Kucherawy
Yes
Erik Kline
No Objection
John Scudder
No Objection
Paul Wouters
(was Discuss) No Objection
Comment (2022-10-27) Sent 
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 ?
Roman Danyliw
No Objection
Comment (2022-10-24) Not sent 
Thank you to Joseph Salowey for the SECDIR review.
Warren Kumari
No Objection
Comment (2022-10-26) Sent 
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
Alvaro Retana Former IESG member
No Objection
No Objection () Not sent 

                            

                        
                    

                
            
                
                    

                        

                            Lars Eggert Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    ()
                                
                                
                                    
                                         Not sent
                                    
                                
                            

                        

                        
                            

                                

                            

                        
                    

                
            
                
                    

                        

                            Martin Duke Former IESG member
                        

                        

                            (was Discuss)
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2022-10-24)
                                
                                
                                    
                                         Sent
                                    
                                
                            

                        

                        
                            

                                
Thanks for addressing my DISCUSS.

                            

                        
                    

                
            
                
                    

                        

                            Robert Wilton Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    ()
                                
                                
                                    
                                         Not sent