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

[Ballot comment]
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 ?

[Ballot comment]
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...

[Ballot 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 ?

[Ballot discuss]
RFC 3326 doesn't specify what the receiver will do if two reason values have the same protocol value. Are we reasonably sure that existing implementations of SIP won't throw an error if they get this, or does there need to be some sort of negotiation mechanism?

# Shepherd Writeup for draft-ietf-sipcore-multiple-reasons
Shepherd: Brian Rosen (br@brianrosen.net)
## Document History
1. The consensus for this document within the workgroup was very strong.  A relatively large cross section of the work group read the doc and believed it was ready to publish, 
2. This is a very simple draft, with a waiting use case, that had no dissent, pretty much at all.  There were no negative comments in WGLC
3. No one has threatened an appeal or indicated any displeasure, let alone extreme displeasure with the draft.
4. There are entities who are planning implementations but the shepherd is unaware of existing implementations.  However, this document is required for recent developments in stir, which has wide deployment, and we expect quite a few implementations shortly. 
## Additional Reviews
5. This document is needed by stir, and stir members have reviewed the document.
6. No special reviews are needed by this document.
7. This document does not describe a YANG model.
8. There is no formal language description in this document, and thus no automated checks are required.
## Document Shepherd Checks
9. It is the shepherd’s opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.
10. We do not expect any issues with cross area reviews.  This is a very simple document with very little impact beyond the simple change it makes to RFC3326.
11. This document should be Proposed Standard.  It makes normative changes to a PS document (RFC3326) and describes a change to the SIP protocol.
12. What type of RFC publication is being requested on the IETF stream, which is reflected in Datatracker. 
13. The sole author has indicated that he not aware of any IPR that should be disclosed..
14. The sole author has indicated his willingness to be listed as such.
15. There is an informative reference that will need to be updated as the document proceeds.  The referenced document is moving through the process smoothly.  The shepherd does not believe there are any more nits that need to be addressed.
16. The references are all correctly designated as normative.
17. All references are to IETF documents.
18. There are no downrefs.
19. There are no normative references to other non-published documents.  There is an informative reference to draft-ietf-stir-identity header-errors-handling which is in WGLC
20. This document will update RFC3326.  This is correctly represented in the document.
21. There are no IANA considerations.


--- Edit (WK): Some sort of parser monkeyed with the formatting, so I reformatted the above with `tr  '\n' ' ' | perl -pne 's/(\d+\.)/\n\n$1/g' | sed 's/  //'`

## Document History

1.  The consensus for this document within the workgroup was very strong.  A relatively large cross section of the work group read the doc and believed it was ready to publish,

2.  This is a very simple draft, with a waiting use case, that had no dissent, pretty much at all.  There were no negative comments in WGLC

3.  No one has threatened an appeal or indicated any displeasure, let alone extreme displeasure with the draft.

4.  There are entities who are planning implementations but the shepherd is unaware of existing implementations.  However, this document is required for recent developments in stir, which has wide deployment, and we expect quite a few implementations shortly. ## Additional Reviews

5.  This document is needed by stir, and stir members have reviewed the document.

6.  No special reviews are needed by this document.

7.  This document does not describe a YANG model.

8.  There is no formal language description in this document, and thus no automated checks are required.

## Document Shepherd Checks

9.  It is the shepherd’s opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.

10.  We do not expect any issues with cross area reviews.  This is a very simple document with very little impact beyond the simple change it makes to RFC 3326.

11.  This document should be Proposed Standard.  It makes normative changes to a PS document (RFC3326) and describes a change to the SIP protocol.

12.  What type of RFC publication is being requested on the IETF stream, which is reflected in Datatracker.

13.  The sole author has indicated that he not aware of any IPR that should be disclosed..

14.  The sole author has indicated his willingness to be listed as such.

15.  There is an informative reference that will need to be updated as the document proceeds.  The referenced document is moving through the process smoothly.  The shepherd does not believe there are any more nits that need to be addressed.

16.  The references are all correctly designated as normative.

17.  All references are to IETF documents.

18.  There are no downrefs.

19.  There are no normative references to other non-published documents.  There is an informative reference to draft-ietf-stir-identity header-errors-handling which is in WGLC

20.  This document will update RFC 3326.  This is correctly represented in the document.

21.  There are no IANA considerations. 

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sipcore-multiple-reasons-01, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-10):

From: The IESG
To: IETF-Announce
CC: br@brianrosen.net, draft-ietf-sipcore-multiple-reasons@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Multiple SIP Reason Header Field Values) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core WG
(sipcore) to consider the following document: - 'Multiple SIP Reason Header
Field Values'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The SIP Reason Header Field as defined in RFC 3326 allows only one
  Reason value per protocol value.  Experience with more recently
  defined protocols shows it is useful to allow multiple values with
  the same protocol value.  This update to RFC 3326 allows multiple
  values for an indicated registered protocol when that protocol
  defines what the presence of multiple values means.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-multiple-reasons/



No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for draft-ietf-sipcore-multiple-reasons
Shepherd: Brian Rosen (br@brianrosen.net)
## Document History
1. The consensus for this document within the workgroup was very strong.  A relatively large cross section of the work group read the doc and believed it was ready to publish, 
2. This is a very simple draft, with a waiting use case, that had no dissent, pretty much at all.  There were no negative comments in WGLC
3. No one has threatened an appeal or indicated any displeasure, let alone extreme displeasure with the draft.
4. There are entities who are planning implementations but the shepherd is unaware of existing implementations.  However, this document is required for recent developments in stir, which has wide deployment, and we expect quite a few implementations shortly. 
## Additional Reviews
5. This document is needed by stir, and stir members have reviewed the document.
6. No special reviews are needed by this document.
7. This document does not describe a YANG model.
8. There is no formal language description in this document, and thus no automated checks are required.
## Document Shepherd Checks
9. It is the shepherd’s opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.
10. We do not expect any issues with cross area reviews.  This is a very simple document with very little impact beyond the simple change it makes to RFC3326.
11. This document should be Proposed Standard.  It makes normative changes to a PS document (RFC3326) and describes a change to the SIP protocol.
12. What type of RFC publication is being requested on the IETF stream, which is reflected in Datatracker. 
13. The sole author has indicated that he not aware of any IPR that should be disclosed..
14. The sole author has indicated his willingness to be listed as such.
15. There is an informative reference that will need to be updated as the document proceeds.  The referenced document is moving through the process smoothly.  The shepherd does not believe there are any more nits that need to be addressed.
16. The references are all correctly designated as normative.
17. All references are to IETF documents.
18. There are no downrefs.
19. There are no normative references to other non-published documents.  There is an informative reference to draft-ietf-stir-identity header-errors-handling which is in WGLC
20. This document will update RFC3326.  This is correctly represented in the document.
21. There are no IANA considerations.

# Shepherd Writeup for draft-ietf-sipcore-multiple-reasons
Shepherd: Brian Rosen (br@brianrosen.net)
## Document History
1. The consensus for this document within the workgroup was very strong.  A relatively large cross section of the work group read the doc and believed it was ready to publish, 
2. This is a very simple draft, with a waiting use case, that had no dissent, pretty much at all.  There were no negative comments in WGLC
3. No one has threatened an appeal or indicated any displeasure, let alone extreme displeasure with the draft.
4. There are entities who are planning implementations but the shepherd is unaware of existing implementations.  However, this document is required for recent developments in stir, which has wide deployment, and we expect quite a few implementations shortly. 
## Additional Reviews
5. This document is needed by stir, and stir members have reviewed the document.
6. No special reviews are needed by this document.
7. This document does not describe a YANG model.
8. There is no formal language description in this document, and thus no automated checks are required.
## Document Shepherd Checks
9. It is the shepherd’s opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.
10. We do not expect any issues with cross area reviews.  This is a very simple document with very little impact beyond the simple change it makes to RFC3326.
11. This document should be Proposed Standard.  It makes normative changes to a PS document (RFC3326) and describes a change to the SIP protocol.
12. What type of RFC publication is being requested on the IETF stream, which is reflected in Datatracker. 
13. The sole author has indicated that he not aware of any IPR that should be disclosed..
14. The sole author has indicated his willingness to be listed as such.
15. There is an informative reference that will need to be updated as the document proceeds.  The referenced document is moving through the process smoothly.  The shepherd does not believe there are any more nits that need to be addressed.
16. The references are all correctly designated as normative.
17. All references are to IETF documents.
18. There are no downrefs.
19. There are no normative references to other non-published documents.  There is an informative reference to draft-ietf-stir-identity header-errors-handling which is in WGLC
20. This document will update RFC3326.  This is correctly represented in the document.
21. There are no IANA considerations.

# Shepherd Writeup for draft-ietf-sipcore-multiple-reasons
Shepherd: Brian Rosen (br@brianrosen.net)
## Document History
1. The consensus for this document within the workgroup was very strong.  A relatively large cross section of the work group read the doc and believed it was ready to publish, 
2. This is a very simple draft, with a waiting use case, that had no dissent, pretty much at all.  There were no negative comments in WGLC
3. No one has threatened an appeal or indicated any displeasure, let alone extreme displeasure with the draft.
4. There are entities who are planning implementations but the shepherd is unaware of existing implementations.  However, this document is required for recent developments in stir, which has wide deployment, and we expect quite a few implementations shortly. 
## Additional Reviews
5. This document is needed by stir, and stir members have reviewed the document.
6. No special reviews are needed by this document.
7. This document does not describe a YANG model.
8. There is no formal language description in this document, and thus no automated checks are required.
## Document Shepherd Checks
9. It is the shepherd’s opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.
10. We do not expect any issues with cross area reviews.  This is a very simple document with very little impact beyond the simple change it makes to RFC3326.
11. This document should be Proposed Standard.  It makes normative changes to a PS document (RFC3326) and describes a change to the SIP protocol.
12. What type of RFC publication is being requested on the IETF stream, which is reflected in Datatracker. 
13. The sole author has indicated that he not aware of any IPR that should be disclosed..
14. The sole author has indicated his willingness to be listed as such.
15. There is an informative reference that will need to be updated as the document proceeds.  The referenced document is moving through the process smoothly.  The shepherd does not believe there are any more nits that need to be addressed.
16. The references are all correctly designated as normative.
17. All references are to IETF documents.
18. There are no downrefs.
19. There are no normative references to other non-published documents.  There is an informative reference to draft-ietf-stir-identity header-errors-handling which is in WGLC
20. This document will update RFC3326.  This is correctly represented in the document.
21. There are no IANA considerations.

Shepherd Writeup for draft-ietf-sipcore-multiple Reasons
Shepherd: Brian Rosen (br@brianrosen.net)
#Document History
1. The consensus for this document within the workgroup was very strong.  A relatively large cross section of the work group read the doc and believed it was ready to publish, 
2. This is a very simple draft, with a waiting use case, that had no dissent, pretty much at all.  There were no negative comments in WGLC
3. No one has threatened an appeal or indicated any displeasure, let alone extreme displeasure with the draft.
4. There are entities who are planning implementations but the shepherd is unaware of existing implementations.  However, this document is required for recent developments in stir, which has wide deployment, and we expect quite a few implementations shortly. 
#Additional Reviews
5. This document is needed by stir, and stir members have reviewed the document.
6. No special reviews are needed by this document.
7. This document does not describe a YANG model.
8. There is no formal language description in this document, and thus no automated checks are required.
#Document Shepherd Checks
9. It is the shepherd’s opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director.
10. We do not expect any issues with cross area reviews.  This is a very simple document with very little impact beyond the simple change it makes to RFC3326.
11. This document should be Proposed Standard.  It makes normative changes to a PS document (RFC3326) and describes a change to the SIP protocol.
12. What type of RFC publication is being requested on the IETF stream, which is reflected in Datatracker. 
13. The sole author has indicated that he not aware of any IPR that should be disclosed..
14. The sole author has indicated his willingness to be listed as such.
15. There is an informative reference that will need to be updated as the document proceeds.  The referenced document is moving through the process smoothly.  The shepherd does not believe there are any more nits that need to be addressed.
16. The references are all correctly designated as normative.
17. All references are to IETF documents.
18. There are no downrefs.
19. There are no normative references to other non-published documents.  There is an informative reference to draft-ietf-stir-identity header-errors-handling which is in WGLC
20. This document will update RFC3326.  This is correctly represented in the document.
21. There are no IANA considerations.