[Sip] P- headers vs. requirements in sip change process

[Rohan Mahy <[e-mail]>]

Hi,

>From tsvarea-sipchange the requirements for P- headers are:

   1. Expert Review
   2. No option tags, response codes, or methods
   3. No overlap with planned/chartered extensions
   4. Purely informational in nature
   5. Does not undermine security
   6. Clearly documented in RFC
   7. Appropriate applicability statement

I've taken a stab at documenting compliance with these requirements.
I've also included an evaluation of call-auth as a comparison.

Please note that in future proposed P- headers should go through SIPPING.

draft-ietf-sip-call-auth

1. Expert Review
   Via the SIP working group as WG document
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Minor caveats, well documented
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Yes, very narrow in scope

draft-ietf-sip-asserted-identity

1. Expert Review
   Via WG as WG document
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   Some overlap with future crytographic identity work,
   scope of overlap intentionally narrow
4. Purely informational in nature
   OK
5. Does not undermine security
   Minor caveats, usage well documented
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Yes, very narrow scope

draft-garcia-sip-visited-network-id

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Negligible impact, well documented
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Needs to provide more general usage guidance

draft-garcia-sip-called-party-id

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   some overlap with request-history work, very narrow in scope
4. Purely informational in nature
   OK
5. Does not undermine security
   Some privacy concerns
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Needs to provide more general usage guidance,
   Should mention the partial overlap with request history

draft-garcia-sip-associated-uri

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Some privacy concerns, can be addressed
   with standard mechanisms
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Needs to provide more general usage guidance

draft-henrikson-sip-charging-information

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   ?
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Some good general guidance given, need to explain when NOT to use

draft-henrikson-sip-orig-dialog-id

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   significant overlap with SIP state, and cookies
   (chartered work)
4. Purely informational in nature
   Unclear. Appears to change algorithm used for SIP routing
5. Does not undermine security
   Unclear
6. Clearly documented in RFC
   Not yet
7. Appropriate applicability statement
   Needs to provide more general usage guidance

draft-mills-sip-access-network-info

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Some privacy concerns; generally well addressed in security section
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   No applicability statement present

draft-willis-sip-svcrtdisco

1. Expert Review
   good level of review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   minor caveats addressed in security considerations
6. Clearly documented in RFC
   Yes
7. Appropriate applicability statement
   Some general guidance given, need to explain when NOT to use

In addition there is an informational event package proposed...

draft-beckmann-sip-reg-event

1. Expert Review
   some review in SIP, really needs review in SIMPLE
2. No template-packages
   OK
3. No overlap with planned/chartered extensions
   This appears to be a generically useful event package
   which should be addressed as a charter item in SIPPING
   Jonathan Rosenberg proposed such a document
4. Does not contradict normative behavior
   OK
5. Does not undermine security
   Mechanism introduces no new security concerns
6. Clearly documented in RFC
   Needs more detail - underspecified
7. Appropriate applicability statement
   No applicability statement present
   Probably not needed if this becomes a general purpose mechanism






_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip