End-to-End Session Identification in IP-Based Multimedia Communication Networks
draft-ietf-insipid-session-id-27

[Ballot comment]
Thanks for addressing my DISCUSS, leaving my comments below for posterity.

== General ==

I do not think RFC 7206 needs to be a normative reference, but I'm also fine with the downref.

== Section 6 ==

"It should be noted that messages received by an endpoint might
  contain a "local-uuid" value that does not match what the endpoint
  expected its peer's UUID to be.  It is also possible for an endpoint
  to receive a "remote-uuid" value that does not match its generated
  UUID for the session.  Either might happen as a result of service
  interactions by intermediaries and MUST NOT affect the communication
  session."

The MUST NOT at the end there is vague and also seems a bit contradictory to the statement in Section 4.2 that "How a device acting on Session Identifiers processes or utilizes the Session Identifier is outside the scope of this document." Could you clarify what the intent of the last sentence is, and how it squares with the idea that actions taken (or not taken) based on session identifiers are not being specified here?

== Section 7 ==

"The Session-ID header field value included in a CANCEL request MUST
  be identical to the Session-ID header field value included in the
  corresponding request."

Does "corresponding request" mean original request, as in Section 6? I think it would be clearer if the text said "original INVITE request" both here and in Section 6.

== Section 11 ==

'altering the nil "remote-uuid"' seems like it could be phrased less awkwardly.

"Standard implementations SHOULD NOT expect pre-standard implementations to be consistent in their implementation" -- I don't think this needs normative language.

== Section 12 ==

I think the note about billing purposes is outside the scope of the document and should be removed. Or if not, it needs further motivation -- if someone wanted to bill based on the number of sessions a UA initiated, why would using the session identifier be an inappropriate way of counting those?

[Ballot comment]
I'm wondering why Section 11. (Compatibility with a Previous Implementation) is even needed if this document is Obsoleting RFC7329. 

I understand that there might be a transition period between the two versions, but the fact that concerns with the compatibility have already come up in Suresh's DISCUSS and that the text itself says that "we will herewith attempt to achieve backwards compatibility" (no guarantee, just an attempt), leaves me with a bad taste that rules are being added that may complicate the new implementation...

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

IANA has completed its review of draft-ietf-insipid-session-id-26.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Header Fields subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

The existing registration for Session-ID will be updated by having the reference changed from RFC7329 to [ RFC-to-be ].

Second, in the Header Field Parameters and Parameter Values subregistry also in the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

a single new registration will be made as follows:

Header Field: Session-ID
Parameter Name: remote
Predefined Values: No
Reference: [ RFC-to-be ]

IANA understands that the two actions above are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

[Ballot comment]
I'm a Yes, anticipating that Alissa's Discuss and Suresh's Discuss are resolved, and I appreciate the effort required to produce this specification. It meets an important need.

[Ballot discuss]
* Section 5

I do have a concern about backward compatibility regarding the sess-uuid. Looks like this document allows the sess-uuid to contain either uppercase or lowercase hex digits ("sess-uuid          = 32(DIGIT / %x41-46 / %x61-66)") while the legacy version in RFC7329 does not allow uppercase hex digits. Looks like a compliant implementation of the spec using upper case hex digits will fail to interoperate with a legacy implementation. I do not have a particular preference, but either this rule needs to be tightened or there needs to be some text added to Section 11 to say this will cause an interoperability issue.

[Ballot comment]
* Section 4.1

The namespace ID in section 4.1 is specified as the initialization of a C structure as described in Appendix C of RFC4122. It is missing a semicolon at the end to make it legal.

OLD:
      uuid_t NameSpace_SessionID = {
          /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
          0xa58587da,
          0xc93d,
          0x11e2,
          0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
      }

NEW:
      uuid_t NameSpace_SessionID = {
          /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
          0xa58587da,
          0xc93d,
          0x11e2,
          0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
      };

* Agree with Alissa's DISCUSS regarding persistence

[Ballot discuss]
== Section 12 ==

"This document allows for additional parameters (generic-param) to be
  included in the Session-ID header.  This is done to allow for future
  extensions while preserving backward compatibility with this
  document.  To protect privacy, the data for any generic-param
  included in the Session-ID header value MUST NOT include any user or
  device information."

To preserve the privacy properties of the session identifier, I think this prohibition needs to extend further -- not just to any user or device information, but to any identifier that persists beyond the current session. Otherwise some parameter defined in the future could easily be used to correlate sessions, while the identifier is currently specified so as to avoid that.

[Ballot comment]
== General ==

I do not think RFC 7206 needs to be a normative reference, but I'm also fine with the downref.

== Section 6 ==

"It should be noted that messages received by an endpoint might
  contain a "local-uuid" value that does not match what the endpoint
  expected its peer's UUID to be.  It is also possible for an endpoint
  to receive a "remote-uuid" value that does not match its generated
  UUID for the session.  Either might happen as a result of service
  interactions by intermediaries and MUST NOT affect the communication
  session."

The MUST NOT at the end there is vague and also seems a bit contradictory to the statement in Section 4.2 that "How a device acting on Session Identifiers processes or utilizes the Session Identifier is outside the scope of this document." Could you clarify what the intent of the last sentence is, and how it squares with the idea that actions taken (or not taken) based on session identifiers are not being specified here?

== Section 7 ==

"The Session-ID header field value included in a CANCEL request MUST
  be identical to the Session-ID header field value included in the
  corresponding request."

Does "corresponding request" mean original request, as in Section 6? I think it would be clearer if the text said "original INVITE request" both here and in Section 6.

== Section 11 ==

'altering the nil "remote-uuid"' seems like it could be phrased less awkwardly.

"Standard implementations SHOULD NOT expect pre-standard implementations to be consistent in their implementation" -- I don't think this needs normative language.

== Section 12 ==

I think the note about billing purposes is outside the scope of the document and should be removed. Or if not, it needs further motivation -- if someone wanted to bill based on the number of sessions a UA initiated, why would using the session identifier be an inappropriate way of counting those?

[Ballot discuss]
(I'm entering a DISCUSS to make sure we get discussion of this topic among the ISEG before we progress the document. Whatever the outcome, I expect to clear the DISCUSS and go back to a YES position after the telechat.)

Please see the thread resulting from Elwyn's gen-art review from the 2nd IETF last call, called specifically because of the downref to RFC 7206 that was added after the first LC. This downref was due to the definitions of "communication session" and "session ID" from that RFC.

https://mailarchive.ietf.org/arch/msg/gen-art/3cLlqju62bY1w5MTA72YpOjL_GQ

[Ballot comment]
I'm wondering, given that RFC 7329 is informational and given that this doc is backwards-compatitile to it, if this doc really obsoletes RFC7329, or just updates it...?

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-session-id@ietf.org, christer.holmberg@ericsson.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (End-to-End Session Identification in IP-Based Multimedia Communication Networks) to Proposed Standard


The IESG has received a request from the INtermediary-safe SIP session ID
WG (insipid) to consider the following document:
- 'End-to-End Session Identification in IP-Based Multimedia Communication
  Networks'
  as Proposed Standard

This is a shortened second last call to consider a normative reference to
an informational RFC that has been added as a result of comments from
the initial last call. The referenced informational RFC is RFC7206

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
ietf@ietf.org mailing lists by 2016-08-18. 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


  This document describes an end-to-end Session Identifier for use in
  IP-based multimedia communication systems that enables endpoints,
  intermediary devices, and management systems to identify a session
  end-to-end, associate multiple endpoints with a given multipoint
  conference, track communication sessions when they are redirected,
  and associate one or more media flows with a given communication
  session.  While the identifier is intended to work across multiple
  protocols, this document describes its usage in SIP.

  This document also describes a backwards compatibility mechanism for
  an existing session identifier implementation (RFC 7329) that is
  sufficiently different from the procedures defined in this document.

  This document obsoletes RFC 7329.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1453/
  https://datatracker.ietf.org/ipr/2160/
  https://datatracker.ietf.org/ipr/2195/
  https://datatracker.ietf.org/ipr/1716/
  https://datatracker.ietf.org/ipr/2204/
  https://datatracker.ietf.org/ipr/2205/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7206: Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

[Ballot comment]
The authors added a normative downref to RFC7206 due to feedback from the gen-ART review from the original last call.
We are running a shortened repeat last call focusing on the downref in parallel with the IESG evaluation.  If any
material feedback results from that last call, I will change my ballot to a  discuss to hold approval until it can be resolved

[Ballot comment]
The authors added a normative downref to RFC7206 due to feedback from the gen-ART review from the original last call.
We are running a shortened repeat last call focus on just that downref in parallel with the IESG evaluation.  If any
material feedback results from that last call, I will change my ballot to a  discuss to hold approval until it can be resolved

Note added 'The authors added a normative downref to RFC7206 due to feedback from the initial IETF last call. We are
      running a shortened repeat last call focus on just that downref in parallel with the IESG evaluation.'

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

IANA has completed its review of draft-ietf-insipid-session-id-24.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Header Fields subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/

a new Header Field will be registered as follows:

Header Name: Session-ID
compact:
Reference: [ RFC-to-be ]

IANA understands that the compact: entry is to be left blank.

Second, in the Header Field Parameters and Parameter Values subregistry also in the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters/

a new value will be registered as follows:

Header Field: Session-ID
Parameter Name: remote
Predefined Values: No
Reference: [ RFC-to-be ]

IANA understands that the two actions above are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-session-id@ietf.org, christer.holmberg@ericsson.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (End-to-End Session Identification in IP-Based Multimedia Communication Networks) to Proposed Standard


The IESG has received a request from the INtermediary-safe SIP session ID
WG (insipid) to consider the following document:
- 'End-to-End Session Identification in IP-Based Multimedia Communication
  Networks'
  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
ietf@ietf.org mailing lists by 2016-08-04. 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


  This document describes an end-to-end Session Identifier for use in
  IP-based multimedia communication systems that enables endpoints,
  intermediary devices, and management systems to identify a session
  end-to-end, associate multiple endpoints with a given multipoint
  conference, track communication sessions when they are redirected,
  and associate one or more media flows with a given communication
  session.  While the identifier is intended to work across multiple
  protocols, this document describes its usage in SIP.

  This document also describes a backwards compatibility mechanism for
  an existing session identifier implementation (RFC 7329) that is
  sufficiently different from the procedures defined in this document.

  This document obsoletes RFC 7329.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1453/
  https://datatracker.ietf.org/ipr/2160/
  https://datatracker.ietf.org/ipr/2195/
  https://datatracker.ietf.org/ipr/1716/
  https://datatracker.ietf.org/ipr/2204/
  https://datatracker.ietf.org/ipr/2205/

This is my AD Evaluation of draft-ietf-insipid-session-id. I have a
number of comments, and think that at least the "substantive" comments
should be addressed prior to IETF last call.
-------------
Substantive Comments:

- Abstract: The abstract makes it sound like the draft is
multi-protocol. It's not, it's SIP specific. I recognize the idea is
that the syntax could be used across signaling protocols, but this
particular draft only defines how to do so for SIP. Please clarify.

- General

- 4.1, 2nd paragraph:Why is the requirement for version 4 or 5 UUIDs
only a SHOULD? It seems like we should really avoid any sort of
persistent identifies in the UUID. If we really need the SHOULD, please
describe when it might be reasonable to choose otherwise.

- 4.2, 2nd paragraph: "such as when a UA first initiates a SIP request,"

Should that be a SIP INVITE request, or SIP dialog-initiating request?

-- 2nd to last paragraph: Is there a normative statement elsewhere than
devices other than conference-focuses MUST NOT reuse UUIDs? (Also, the
MUST in this paragraph belongs with the section on MDUs. If this text
means to simply point out that the MDU section has this requirement,
then please state it descriptively here.)

-- last paragraph: I'm a bit uncomfortable with making storage
completely out of scope, due to the potential "information-at-rest"
security or privacy implications. (I note that RFC7206 cites 6872 for
this purpose).

- 6, paragraph 8: Has the working group discussed the privacy
implications of requiring an endpoint to keep the same UUID after a
redirect, refer, or INVITE-with-replaces? It may be that the peer and
intermediaries already know the source of the 2nd dialog is the same
that of the first, but I think it's a topic that needs some mention in
the text.

-- paragraph 10: Both the MAY and MUST seem incorrect here. The MAY is a
statement of fact, and the MUST is a description of rules elsewhere in
the draft. I suggest using descriptive language for both.

-7, first paragraph: Does the assumption of no "special treatment" means
the intermediary  passing the session-id unchanged? Removes it? Either?

-- 4th paragraph: What happens when a B2BUA that does not implement
session-id aggregates responses? If it passes through the peer UUIDs
unchanged, does anything break? Can the UAC be misled about the UUID of
the resulting peer?

-- 3rd paragraph from end: I'm confused by "A non- redirected or
rejected response", since responses neither get redirected or rejected.
Do you mean a redirection response or a rejection response? (Perhaps
using response code classes would be more clear.)

"MUST replace its own UUID" - In what message(s)?

-- 2nd to last paragraph: Why are the SHOULDs not MUSTs? Can you
describe situations in which one might reasonably not follow the
SHOULDs?

-- last paragraph: The first "MAY" seems like a statement of fact. Is
the 2nd MAY appropriate? That is, intermediary allowed to _not_ do this,
and let endpoints get out of sync?

-8, last paragraph: Why is the SHOULD not a MUST? When might one
reasonably not follow it?

-9, 2nd paragraph: Does this assume that the conference is new to each
subsequent MCU? That is, one would never use this approach to bridge two
existing conferences that already have their own UUIDs?

- 10.3: Why doesn't the b2bua send a re-invite to update the uuid as in
the next example?

- 10.5: Please don't use the name of a trademarked, commercial service
in an RFC. Can you recast this as a "web-based conference service"?

Also, this should be clarified to be one of many ways to implement this
use case, not necessarily a preferred way. (For example,  endpoints
might initiate the INVITE requests toward the focus.)

- 10.7, first bullet: It seems highly unlikely that a 3pcc server would
not be dialog stateful.

- 11: This section creates MUST level requirements for an implementation
to be backwards compatible with a pre-standard, proprietary version.
That seems to be a stretch. Did the working group really intend that an
implementation could not choose not to implement this section?

-- 4th bullet: Wny isn't the presence or absence of remote-uuid
sufficient for responses?

-- 5th bullet: This seems out of place; it's about non-compliant
implementations of this document, not about backwards compatibility.

- 6th bullet: Why would an "old" implementation include "remote-uuid" at
all?

- 12, first paragraph: The MUST here seems to conflict with the previous
SHOULD about using UUID versions other than 4 or 5. (see previous
comment).

-- 3rd paragraph: Is there an impact if something tampers with or lies
about session-Id values?

- 15: Thank you for including this.

Editorial Comments and Nits:

-1, first paragraph: Please expand SIP on first mention.

- 4.2, 4th paragraph: Please expand PBX on first mention.

-- 2nd to last paragraph: This referes to conference focus, but most of
the relevant section discusses MDUs. Please use consistent terms.
(either may be okay, but "focus" probably better captures the signaling
vs media role.)

-6, paragraph 9: What is meant by "negatively affect"? Is this allowed
to affect the session in neutral or positive ways?

-- paragraph 11: Consider s/"MUST take care to ensure"/"MUST ensure".
The "take care" part softens the message.

-- 2nd to last paragraph: Redundant normative statements. Consider
making the first one descriptive, since the second is the more precise
of the two. (This pattern repeats in section 7 paragraph 7)

- 7, 2nd paragraph: "which is why intermediaries" I think that's one
reason why. There are likely others.

-- 7th paragraph: "If an intermediary receives a SIP message without a
Session-ID header field or valid header field value..."

Does this mean either without session-id, or with session-Id but without
a valid value? (As worded, the second part reads like it means without
any valid header fields, but that doesn't make sense.)

-8, first paragraph: This seems redundant to previous sections.

10.1, paragraph before SIP detail: It's not really complete if you omit
stuff :-)

10.3: There's no description of the initial re-invite.

11, paragraph 5: It's not clear what "that" refers to.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended Status: Proposed Standard. The RFC defines a new SIP protocol header field. The type is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

        The document describes an end-to-end Session Identifier for use in
  IP-based multimedia communication systems that enables endpoints,
  intermediary devices, and management systems to identify a session
  end-to-end, associate multiple endpoints with a given multipoint
  conference, track communication sessions when they are redirected,
  and associate one or more media flows with a given communication
  session.

Working Group Summary

      The work on the document took a relatively long time in the WG. The reason
      was not so much related to controversies, or different opinions, but more related
      to the cycles the authors and contributors were able to put on the work.
      There is a consensus in the INSIPID WG to publish the document as an RFC.

Document Quality

      A number of vendors have indicated that they have implemented, or intend to
      implement, the document. Individuals representing the implementers were also
      involved in the work on the document.
     
      The document is also referenced by 3GPP, and support is required for certain IMS
      use-cases and functions.

Personnel

      Document Shepherd: Christer Holmberg (christer.holmberg@ericsson.com ¬ STRAW WG co-chair)

      Responsible Area Director: Ben Campbell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

    The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

    No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    The Document Shepherd has no concerns or issues with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    Each author has confirmed that any appropriate IPR disclosure has been filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    The IPR disclosures can be found at: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-insipid-session-id

    The disclosures were filed some years ago. The working group discussed the IPR disclosures, but still chose to progress the draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

    The WG as whole understand the draft and agree with it being published as an RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

dnits 2.14.01

/tmp/draft-ietf-insipid-session-id-22.txt:
/tmp/draft-ietf-insipid-session-id-22.txt(230): Possible code comment in line:            /* a58587da-c93d-11e2-ae90-f4ea67801e29 */.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: '0-9a-f' is mentioned on line 296, but not
    defined
    'sess-uuid          = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f...'

  == Missing Reference: 'RFCXXXX' is mentioned on line 1601, but not
    defined
    '|  Session-ID  |    remote    |        No        | [RFCXXXX]...'

  -- Obsolete informational reference (is this intentional?): RFC 2543
    (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

    The publication will obsolete RFC 7329 (informative reference).

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    There are no issues with the IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

    There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    The Document Shepherd has reviewed the BNF rules. The document does not use other types of formal languages.



As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended Status: Proposed Standard. The RFC defines a new SIP protocol header field. The type is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

        The document describes an end-to-end Session Identifier for use in
  IP-based multimedia communication systems that enables endpoints,
  intermediary devices, and management systems to identify a session
  end-to-end, associate multiple endpoints with a given multipoint
  conference, track communication sessions when they are redirected,
  and associate one or more media flows with a given communication
  session.

Working Group Summary

      The work on the document took a relatively long time in the WG. The reason
      was not so much related to controversies, or different opinions, but more related
      to the cycles the authors and contributors were able to put on the work.
      There is a consensus in the INSIPID WG to publish the document as an RFC.

Document Quality

      A number of vendors have indicated that they have implemented, or intend to
      implement, the document. Individuals representing the implementers were also
      involved in the work on the document.
     
      The document is also referenced by 3GPP, and support is required for certain IMS
      use-cases and functions.

Personnel

      Document Shepherd: Christer Holmberg (christer.holmberg@ericsson.com ¬ STRAW WG co-chair)

      Responsible Area Director: Ben Campbell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

    The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

    No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    The Document Shepherd has no concerns or issues with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    Each author has confirmed that any appropriate IPR disclosure has been filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    The IPR disclosures can be found at: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-insipid-session-id

    The disclosures were filed some years ago, and have not have any impact on the WG discussions and conclusions.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

    The WG as whole understand the draft and agree with it being published as an RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

dnits 2.14.01

/tmp/draft-ietf-insipid-session-id-22.txt:
/tmp/draft-ietf-insipid-session-id-22.txt(230): Possible code comment in line:            /* a58587da-c93d-11e2-ae90-f4ea67801e29 */.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: '0-9a-f' is mentioned on line 296, but not
    defined
    'sess-uuid          = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f...'

  == Missing Reference: 'RFCXXXX' is mentioned on line 1601, but not
    defined
    '|  Session-ID  |    remote    |        No        | [RFCXXXX]...'

  -- Obsolete informational reference (is this intentional?): RFC 2543
    (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

    The publication will obsolete RFC 7329 (informative reference).

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    There are no issues with the IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

    There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    The Document Shepherd has reviewed the BNF rules. The document does not use other types of formal languages.



As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended Status: Proposed Standard. The RFC defines a new SIP protocol header field. The type is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

        The document describes an end-to-end Session Identifier for use in
  IP-based multimedia communication systems that enables endpoints,
  intermediary devices, and management systems to identify a session
  end-to-end, associate multiple endpoints with a given multipoint
  conference, track communication sessions when they are redirected,
  and associate one or more media flows with a given communication
  session.

Working Group Summary

      The work on the document took a relatively long time in the WG. The reason
      was not so much related to controversies, or different opinions, but more related
      to the cycles the authors and contributors were able to put on the work.
      There is a consensus in the INSIPID WG to publish the document as an RFC.

Document Quality

      A number of vendors have indicated that they have implemented, or intend to
      implement, the document. Individuals representing the implementers were also
      involved in the work on the document.
     
      The document is also referenced by 3GPP, and support is required for certain IMS
      use-cases and functions.

Personnel

      Document Shepherd: Christer Holmberg (christer.holmberg@ericsson.com ¬ STRAW WG co-chair)

      Responsible Area Director: Ben Campbell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

    The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

    No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    The Document Shepherd has no concerns or issues with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    Each author has confirmed that any appropriate IPR disclosure has been filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    The IPR disclosures can be found at: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-insipid-session-id

    The disclosures were filed some years ago, and have not have any impact on the WG discussions and conclusions.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

    The WG as whole understand the draft and agree with it being published as an RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

dnits 2.14.01

/tmp/draft-ietf-insipid-session-id-22.txt:
/tmp/draft-ietf-insipid-session-id-22.txt(230): Possible code comment in line:            /* a58587da-c93d-11e2-ae90-f4ea67801e29 */.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: '0-9a-f' is mentioned on line 296, but not
    defined
    'sess-uuid          = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f...'

  == Missing Reference: 'RFCXXXX' is mentioned on line 1601, but not
    defined
    '|  Session-ID  |    remote    |        No        | [RFCXXXX]...'

  -- Obsolete informational reference (is this intentional?): RFC 2543
    (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

    The publication will obsolete RFC 7329 (informative reference).

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    There are no issues with the IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

    There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    The Document Shepherd has reviewed the BNF rules. The document does not use other types of formal languages.