Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
draft-ietf-sipping-sip-offeranswer-18

[Ballot discuss]
IMO, the current document still uses inappropriately "normative" language. I understand that this is supposed to not be normative, but to be the best thinking of the authors of how best to interpret ambiguities in the current specifications and to provide input into future standards development. Below I've made some suggestions of textual changes. First, I make the motivation explicit in the introduction. Second, I strike the reference to RFC 2119, as I think it unnecessary. Finally, I take the 7 occurrences of RFC 2119 language where it is not contained in a quote and re-word it to indicate that we're talking about a requirement of the original specification, not a new requirement.

I am not committed to this wording, but I think this would completely address the issue I have with the document, and I do not think it changes the content of the document at all. Please let me know what you think.

In the Introduction:

  This document does not make normative changes.  Rather, it recommends
  how to use the existing standards to best effect.  This document also
  provides a reference for future standards development work on the SIP
  offer/answer model.

Replace with:

  This document describes ambiguities in the current specifications and
  the authors' understanding of the correct interpretation of these
  specifications. This document is not intended to make any changes to
  those specifications, but rather is intended to provide a reference
  for future standards development work on the SIP offer/answer model.

Strike section 1.1.

In 3.1.1:

      1.  If the first SDP that UAC received is included in an
          unreliable provisional response to the INVITE request, UAC
          MUST treat it as an answer.  But the SDP is not a true answer
          by regulations, therefore the offer/answer exchange is not yet
          completed.

Replace with:

1. If the first SDP that the UAC received is included in an
  an unreliable provisional response to the INVITE request,
  RFC 3261 (*section #*) requires that it be treated as an
  answer. However, since the SDP is not a true answer according
  to (* ??? *), the offer/answer exchange is not yet completed.

Also in 3.1.1:

      2.  After UAC has received the answer in a reliable provisional
          response to the INVITE, any SDP in subsequent responses to the
          INVITE MUST be ignored.

Replace with:

  2.  After UAC has received the answer in a reliable provisional
  response to the INVITE, RFC 3261 requires that any SDP in
  subsequent responses be ignored.

Also in 3.1.1:

      1.  All SDP in the responses to the INVITE request MUST be the
          same exactly.

Replace with:
         
1. RFC 3261 requires all SDP in the responses to the INVITE
  request to be identical.

Also in 3.1.1:
 
      3.  UAS MAY send any provisional response without a SDP regardless
          of the transmission of the answer.

Replace with:

3. RFC 3261 permist UAS to send any provisional response without a SDP
  regardless of the transmission of the answer.

In 3.1.2:

  When a UAC does not include a SDP body in the INVITE request, it
  expects an offer to be received with the first reliable non-failure
  response.  And a UAS MUST include an offer in the first reliable non-
  failure response and should not include any SDP in the other
  responses to the INVITE request.

Replace with:

  When a UAC does not include a SDP body in the INVITE request, it
  expects an offer to be received with the first reliable non-failure
  response, and a UAS is therefore required to include an offer in
  the first reliable non-failure response and ought not include any
  SDP in the other responses to the INVITE request.

In 3.4:

  If a re-INVITE fails, the session parameters in effect prior to the
  re-INVITE MUST remain unchanged, as if no re-INVITE had been issued.
  ([RFC3261] section 14.1 UAC Behavior.)
 
Replace with:

  RFC3261 section 14.1 requires that the session parameters in effect
  prior to a re-INVITE remain unchanged if the re-INVITE fails, as if
  no re-INVITE had been issued.

In 5.4:

  [RFC3264] specifies that an agent MUST be capable of receiving SDP
  with a connection address of 0.0.0.0, in which case it means that
  neither RTP nor RTCP should be sent to the peer.

Replace with:

  [RFC3264] requires that an agent be capable of receiving SDP
  with a connection address of 0.0.0.0, in which case it means that
  neither RTP nor RTCP should be sent to the peer.

[Ballot discuss]
IMO, the current document still uses inappropriately "normative" language. I understand that this is supposed to not be normative, but to be the best thinking of the authors of how best to interpret ambiguities in the current specifications and to provide input into future standards development. Below I've made some suggestions of textual changes. First, I make the motivation explicit in the introduction. Second, I strike the reference to RFC 2119, as I think it unnecessary. Finally, I take the 7 occurrences of RFC 2119 language where it is not contained in a quote and re-word it to indicate that we're talking about a requirement of the original specification, not a new requirement.

I am not committed to this wording, but I think this would completely address the issue I have with the document, and I do not think it changes the content of the document at all. Please let me know what you think.

In the Introduction:

  This document does not make normative changes.  Rather, it recommends
  how to use the existing standards to best effect.  This document also
  provides a reference for future standards development work on the SIP
  offer/answer model.

Replace with:

  This document describes ambiguities in the current specifications and
  the authors' understanding of the correct interpretation of these
  specifications. This document is not intended to make any changes to
  those specifications, but rather is intended to provide a reference
  for future standards development work on the SIP offer/answer model.

Strike section 1.1.

In 3.1.1:

      1.  If the first SDP that UAC received is included in an
          unreliable provisional response to the INVITE request, UAC
          MUST treat it as an answer.  But the SDP is not a true answer
          by regulations, therefore the offer/answer exchange is not yet
          completed.

Replace with:

1. If the first SDP that the UAC received is included in an
  an unreliable provisional response to the INVITE request,
  RFC 3261 (*section #*) requires that it be treated as an
  answer. However, since the SDP is not a true answer according
  to (* ??? *), the offer/answer exchange is not yet completed.

Also in 3.1.1:

      2.  After UAC has received the answer in a reliable provisional
          response to the INVITE, any SDP in subsequent responses to the
          INVITE MUST be ignored.

Replace with:

  2.  After UAC has received the answer in a reliable provisional
  response to the INVITE, RFC 3261 requires that any SDP in
  subsequent responses be ignored.

Also in 3.1.1:

      1.  All SDP in the responses to the INVITE request MUST be the
          same exactly.

Replace with:
         
1. RFC 3261 requires all SDP in the responses to the INVITE
  request to be identical.

Also in 3.1.1:
 
      3.  UAS MAY send any provisional response without a SDP regardless
          of the transmission of the answer.

Replace with:

3. RFC 3261 permist UAS to send any provisional response without a SDP
  regardless of the transmission of the answer.

In 3.1.2:

  When a UAC does not include a SDP body in the INVITE request, it
  expects an offer to be received with the first reliable non-failure
  response.  And a UAS MUST include an offer in the first reliable non-
  failure response and should not include any SDP in the other
  responses to the INVITE request.

Replace with:

  When a UAC does not include a SDP body in the INVITE request, it
  expects an offer to be received with the first reliable non-failure
  response, and a UAS is therefore required to include an offer in
  the first reliable non-failure response and ought not include any
  SDP in the other responses to the INVITE request.

In 3.4:

  If a re-INVITE fails, the session parameters in effect prior to the
  re-INVITE MUST remain unchanged, as if no re-INVITE had been issued.
  ([RFC3261] section 14.1 UAC Behavior.)
 
Replace with:

  RFC3261 section 14.1 requires that the session parameters in effect
  prior to a re-INVITE remain unchanged if the re-INVITE fails, as if
  no re-INVITE had been issued.

In 5.4:

  [RFC3264] specifies that an agent MUST be capable of receiving SDP
  with a connection address of 0.0.0.0, in which case it means that
  neither RTP nor RTCP should be sent to the peer.

Replace with:

  [RFC3264] requires that an agent be capable of receiving SDP
  with a connection address of 0.0.0.0, in which case it means that
  neither RTP nor RTCP should be sent to the peer.

[Ballot discuss]
IMO, the current document still uses inappropriately "normative" language. I understand that this is supposed to not be normative, but to be the best thinking of the authors of how best to interpret ambiguities in the current specifications and to provide input into future standards development. Below I've made some suggestions of textual changes. First, I make the motivation explicit in the introduction. Second, I strike the reference to RFC 2119, as I think it unnecessary. Finally, I take the 7 occurrences of RFC 2119 language where it is not contained in a quote and re-word it to indicate that we're talking about a requirement of the original specification, not a new requirement.

I am not committed to this wording, but I think this would completely address the issue I have with the document, and I do not think it changes the content of the document at all. Please let me know what you think.

In the Introduction:

  This document does not make normative changes.  Rather, it recommends
  how to use the existing standards to best effect.  This document also
  provides a reference for future standards development work on the SIP
  offer/answer model.

Replace with:

  This document describes ambiguities in the current specifications and
  the authors' understanding of the correct interpretation of these
  specifications. This document is not intended to make any changes to
  those specifications, but rather is intended to provide a reference
  for future standards development work on the SIP offer/answer model.

Strike section 1.1.

In 3.1.1:

      1.  If the first SDP that UAC received is included in an
          unreliable provisional response to the INVITE request, UAC
          MUST treat it as an answer.  But the SDP is not a true answer
          by regulations, therefore the offer/answer exchange is not yet
          completed.

Replace with:

1. If the first SDP that the UAC received is included in an
  an unreliable provisional response to the INVITE request,
  RFC 3261 (*section #*) requires that it be treated as an
  answer. However, since the SDP is not a true answer according
  to (* ??? *), the offer/answer exchange is not yet completed.

Also in 3.1.1:

      2.  After UAC has received the answer in a reliable provisional
          response to the INVITE, any SDP in subsequent responses to the
          INVITE MUST be ignored.

Replace with:

  2.  After UAC has received the answer in a reliable provisional
  response to the INVITE, RFC 3261 requires that any SDP in
  subsequent responses be ignored.

Also in 3.1.1:

      1.  All SDP in the responses to the INVITE request MUST be the
          same exactly.

Replace with:
         
1. RFC 3261 requires all SDP in the responses to the INVITE
  request to be identical.

Also in 3.1.1:
 
      3.  UAS MAY send any provisional response without a SDP regardless
          of the transmission of the answer.

Replace with:

3. RFC 3261 permist UAS to send any provisional response without a SDP
  regardless of the transmission of the answer.

In 3.1.2:

  When a UAC does not include a SDP body in the INVITE request, it
  expects an offer to be received with the first reliable non-failure
  response.  And a UAS MUST include an offer in the first reliable non-
  failure response and should not include any SDP in the other
  responses to the INVITE request.

Replace with:

  When a UAC does not include a SDP body in the INVITE request, it
  expects an offer to be received with the first reliable non-failure
  response, and a UAS is therefore required to include an offer in
  the first reliable non-failure response and ought not include any
  SDP in the other responses to the INVITE request.

In 3.4:

  If a re-INVITE fails, the session parameters in effect prior to the
  re-INVITE MUST remain unchanged, as if no re-INVITE had been issued.
  ([RFC3261] section 14.1 UAC Behavior.)
 
Replace with:

  RFC3261 section 14.1 requires that the session parameters in effect
  prior to a re-INVITE remain unchanged if the re-INVITE fails, as if
  no re-INVITE had been issued.

In 5.4:

  [RFC3264] specifies that an agent MUST be capable of receiving SDP
  with a connection address of 0.0.0.0, in which case it means that
  neither RTP nor RTCP should be sent to the peer.

Replace with:

  [RFC3264] requires that an agent be capable of receiving SDP
  with a connection address of 0.0.0.0, in which case it means that
  neither RTP nor RTCP should be sent to the peer.

[Ballot discuss]
Please add some text in the security considerations to point to where the mechanisms to protect the offer/answer exchange from tampering by 3rd parties is located (i.e., point to 4744 and 3261).

[Ballot discuss]
I saw no followup to Juergen Schoenwalder's secdir review, in particular the following:

It seems all these relevant specifications are on the standards track
while this clarification, which tries to handle situations that can lead to
"failed or degraded calls", is submitted as an Informational document.
Should this not be standards track, formerly updating the relevant
RFCs? I see in the IESG writeup that this has been discussed before,
the proposed move to publish this as Informational still sounds
surprising to me as an outsider. If there is consensus to resolve the
ambiguities as described in the document, then why not via a
standards-track action?  Or is the idea that this resolution simply
can be ignored or that something very different might be invented?
That latter would more speak for Experimental then.

I tend to agree and would like to hear more of the thinking before I move to No Objection. There is a good deal of "normative sounding" text in this document, so Standards Track or Experimental seems more reasonable.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (SIP (Session Initiation Protocol) Usage of the Offer/Answer Model) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'SIP (Session Initiation Protocol) Usage of the Offer/Answer Model'
  as an Informational RFC

  This document began in the SIPPING working group, which reached
  consensus to request publication of an earlier version. After IETF
  Last Call, the community identified and made several significant changes
  and additions to the document.

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 2011-01-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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipping-sip-offeranswer/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipping-sip-offeranswer/

PROTO questionnaire for: draft-ietf-sipping-sip-offeranswer-08.txt

To be Published as: Informational

Prepared by: Mary Barnes (mary.barnes@nortel.com) on 26 April 2008


(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Mary Barnes is the document shepherd. She has reviewed this version of
the document and believes it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, the document has been adequately reviewed.
There are no concerns over the depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
No.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns or issues. There is no IPR disclosure.

(1.e) 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?

There is WG consensus behind this document and no one has
expressed concerns about its progression.

(1.f) 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
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. The draft has been validated for nits using idnits 2.08.08 and
there are no nits.


(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, the document references are split. All references are published
RFCs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, the IANA sections exists and appropriately states that this
document has no
actions for IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

This is an informational document, thus there is no formal language.

(1.k) 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 Session Initiation Protocol (SIP) utilizes the
offer/answer
model to establish and update multimedia sessions using the
Session
Description Protocol (SDP). The description of the
offer/answer
model in SIP is dispersed across multiple RFCs. This
document
summarizes all the current usages of the offer/answer model
in SIP
communication.

Working Group Summary
The SIPPING WG supports the development and advancement of
this document.

Document Quality
This document has no normative protocol impacts.
The document has been thorughly reviewed in the SIPPING WG,
with
several WG members (Byron Campen, Jonathan Rosenberg,
RAjeev Seth
and B.Nataraju) performing detailed reviews during initial
WG
review, during each of the two WGLCs for this document and
following
the WGLCs to ensure the document was updated consistent
with WG
consensus.

Personnel
Mary Barnes is the WG chair shepherd. Jon Peterson is the
responsible Area director.