Connectivity Preconditions for Session Description Protocol (SDP) Media Streams
draft-ietf-mmusic-connectivity-precon-07

[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [RFC3312] as follows:

      precondition-type = "conn" / "qos" / token

ABNF document reference is missing here.

[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [RFC3312] as follows:

      precondition-type = "conn" / "qos" / token

ABNF document reference is missing here.

  [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

This looks Informative.

[Ballot discuss]
I only have some minor comments and likely to clear upon receiving a clarifying response.

4.2.  Explicit Connectivity Verification Mechanisms

  For example, with an
  RTP-based media stream where RTCP is not suppressed, connectivity
  MUST be ascertained for both RTP and RTCP; this is a tightening of
  the general operational semantics provided in Section 3.2, which is
  imposed by ICE.

Gonzallo agreed that the document is defining some normative behaviour when using ICE, so it should be a Normative Reference.

[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [RFC3312] as follows:

      precondition-type = "conn" / "qos" / token

ABNF document reference is missing here.
Where "token" is defined?

4.1.  Media Stream to Dialog Correlation

  In the absence of a dialog-to-media-
  stream correlation mechanism (e.g., ICE), a UAS (User Agent Server)
  MUST NOT require the offerer to confirm a connectivity precondition.

It is not clear to me what is required here. Can you elaborate?

  [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

This looks Informative.

[Ballot discuss]
I only have some minor comments and likely to clear upon receiving a clarifying response.

4.2.  Explicit Connectivity Verification Mechanisms

  For example, with an
  RTP-based media stream where RTCP is not suppressed, connectivity
  MUST be ascertained for both RTP and RTCP; this is a tightening of
  the general operational semantics provided in Section 3.2, which is
  imposed by ICE.

Does this mean that ICE is a normative dependency?

[Ballot comment]
Few notes from the call today: I think section 3.2 just needs a little bit of rewording. It was causing the some confusion. It may be just removing the sentence that starts "For Example" would solve the problem.

In section 4.3, I think folks are oK with the SHULD around SCPT remaining a SHOULD.

In section 7 on the SHOULD around preventing DOS. I would be fine with removing the sentence.

in 3.2, I would remove the sentence "In the case of RTP-based media streams,
  RTCP connectivity MAY be verified, but it is not a requirement."  as this seems to be covered by the MUST later in the doc in a more clear way. Or leave this sentence in but qualify it only when RTCP is not signaled.

[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [RFC3312] as follows:

      precondition-type = "conn" / "qos" / token

ABNF document reference is missing here.
Where "token" is defined?


4.1.  Media Stream to Dialog Correlation

  In the absence of a dialog-to-media-
  stream correlation mechanism (e.g., ICE), a UAS (User Agent Server)
  MUST NOT require the offerer to confirm a connectivity precondition.

It is not clear to me what is required here. Can you elaborate?

4.2.  Explicit Connectivity Verification Mechanisms

  For example, with an
  RTP-based media stream where RTCP is not suppressed, connectivity
  MUST be ascertained for both RTP and RTCP; this is a tightening of
  the general operational semantics provided in Section 3.2, which is
  imposed by ICE.

Does this mean that ICE is a normative dependency?

  [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

This looks Informative.

  [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
              Requirement for the Session Initiation Protocol (SIP)",
              RFC 3853, July 2004.

With the S/MIME-->SIP identity RFC Editor this can be removed or be made Informative.

[Ballot discuss]
I only have some minor comments and likely to clear upon receiving a clarifying response.

In Section 6:

  Since B asked for confirmation about the "send" connectivity (from
  A's point of view), A now sends an UPDATE (5) to B to confirm the
  connectivity from A to B:

    a=ice-pwd:asd88fgpdd777uzjYhagZg
    a=ice-ufrag:8hhY
    m=audio 20000 RTP/AVP 0
    c=IN IP4 192.0.2.1
    a=curr:conn e2e send
    a=des:conn mandatory e2e sendrecv
    a=des:conn mandatory e2e sendrecv

Is it Ok that the last line is repeated here?

    a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host


7.  Security Considerations

  Connectivity preconditions rely on mechanisms beyond SDP such as
  TCP[RFC0793] connection establishment, or ICE connectivity checks
  [I-D.ietf-mmusic-ice] to establish and verify connectivity between an
  offerer and an answerer.  An attacker that prevents those mechanism
  from succeeding can prevent media sessions from being established and
  hence it is RECOMMENDED that such mechanisms are adequately secured
  by message authentication and integrity protection.  Also, the
  mechanisms SHOULD consider how to prevent denial of service attacks.

The last sentence - how?

[Ballot discuss]
Section 3.2:

In the case of RTP-based media streams,
  RTCP connectivity MAY be verified, but it is not a requirement.

I find this exception for RTCP very strange for a number of reasons. First, RTCP is an important part of most RTP/RTCP applications. Thus not requiring RTCP to be verified, when still an application is signaling to be using RTCP seems strange. I would note that if an application in SDP signals that RTCP is not to be used, then you obviously don't need to verify connectivity you are not using. But if the application is indicating RTCP usage I strongly think it needs to be verified. Secondly, as you write later in the document it can't be utilized with ICE.

My suggestion is to remove that RTCP exception.

[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [RFC3312] as follows:

      precondition-type = "conn" / "qos" / token

ABNF document reference is missing here.
Where "token" is defined?


4.1.  Media Stream to Dialog Correlation

  In the absence of a dialog-to-media-
  stream correlation mechanism (e.g., ICE), a UAS (User Agent Server)
  MUST NOT require the offerer to confirm a connectivity precondition.

It is not clear to me what is required here. Can you elaborate?


4.3.  Verifying Connectivity for Connection-Oriented Transports

  In the case of
  TCP for example, once the TCP three-way handshake has completed (SYN,
  SYN-ACK, ACK), the TCP connection is established and data can be sent
  and received by either party (i.e., both a send and a receive
  connectivity precondition has been satisfied).  SCTP [RFC4960]
  connections have similar semantics as TCP and SHOULD be treated the
  same.

Why SHOULD and not MUST?


In Section 6:

  Since B asked for confirmation about the "send" connectivity (from
  A's point of view), A now sends an UPDATE (5) to B to confirm the
  connectivity from A to B:

    a=ice-pwd:asd88fgpdd777uzjYhagZg
    a=ice-ufrag:8hhY
    m=audio 20000 RTP/AVP 0
    c=IN IP4 192.0.2.1
    a=curr:conn e2e send
    a=des:conn mandatory e2e sendrecv
    a=des:conn mandatory e2e sendrecv

Is it Ok that the last line is repeated here?

    a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host

7.  Security Considerations

  Connectivity preconditions rely on mechanisms beyond SDP such as
  TCP[RFC0793] connection establishment, or ICE connectivity checks
  [I-D.ietf-mmusic-ice] to establish and verify connectivity between an
  offerer and an answerer.  An attacker that prevents those mechanism
  from succeeding can prevent media sessions from being established and
  hence it is RECOMMENDED that such mechanisms are adequately secured
  by message authentication and integrity protection.  Also, the
  mechanisms SHOULD consider how to prevent denial of service attacks.

The last sentence - how?

  [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

This looks Informative.

  [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
              Requirement for the Session Initiation Protocol (SIP)",
              RFC 3853, July 2004.

With the S/MIME-->SIP identity RFC Editor this can be removed or be made Informative.

[Ballot discuss]
I only have some minor comments and likely to clear upon receiving a clarifying response.


4.2.  Explicit Connectivity Verification Mechanisms

  For example, with an
  RTP-based media stream where RTCP is not suppressed, connectivity
  MUST be ascertained for both RTP and RTCP; this is a tightening of
  the general operational semantics provided in Section 3.2, which is
  imposed by ICE.

Does this mean that ICE is a normative dependency? (And currently it isn't.)

[Ballot discuss]
This is a minor DISCUSS on a suggested RFC Editor Note; that is, the following text has been
suggested by the author as a resolution to LC comments but does not appear in the tracker
or in the document:

OLD:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].

NEW:
  The SIP identity mechanism specified in RFC 4474 [RFC4474] provides
  such end-to-end integrity protection.

The replacment text isn't always correct, since the SIP identity specification also permits
a proxy server to provide identity services and to verify identities.  I would also prefer to
see the S/MIME reference preserved, even though we expect SIP identity to be the dominant
mechanism in deployments.  As a result, I suggest the following RFC Editor Note instead:

OLD:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].

NEW:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].  When the user
  agent provides identity services (rather than the proxy server),
  the SIP identity mechanism specified in RFC 4474 [RFC4474] provides
  an alternative end-to-end integrity protection.

[Ballot discuss]
This is a minor DISCUSS on a suggested RFC Editor Note; that is, the following text has been
suggested by the author as a resolution to LC comments:

OLD:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].

NEW:
  The SIP identity mechanism specified in RFC 4474 [RFC4474] provides
  such end-to-end integrity protection.

The replacment text isn't always correct, since the SIP identity specification also permits
a proxy server to provide identity services and to verify identities.  I would also prefer to
see the S/MIME reference preserved, even though we expect SIP identity to be the dominant
mechanism in deployments.  As a result, I suggest the following RFC Editor Note instead:

OLD:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].

NEW:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].  When the user
  agent provides identity services (rather than the proxy server),
  the SIP identity mechanism specified in RFC 4474 [RFC4474] provides
  an alternative end-to-end integrity protection.

[Ballot discuss]
This is a minor DISCUSS on a suggested RFC Editor Note; that is, the following text has been
suggested by the author as a resolution to LC comments:

OLD:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].

NEW:
  The SIP identity mechanism specified in RFC 4474 [RFC4474] provides
  such end-to-end integrity protection.

The replacment text isn't always correct, since the SIP identity specification also permits
a proxy server to provide identity services and to verify identities.  I woudl suggest the
following RFC Editor Note instead:


OLD:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].

NEW:
  S/MIME [RFC3853] provides such end- to-end integrity
  protection, as described in [RFC3261].  When the user
  agent provides identity services (rather than the proxy server),
  the SIP identity mechanism specified in RFC 4474 [RFC4474] provides
  an alternative end-to-end integrity protection.

[Ballot comment]
The OPS-DIR review performed by Menachem Dodge provided a couple of editorial suggetions that seemed to be accepted by the editors but not incorporated in the note to the RFC Editor or in a revised I-D:

1. It would be useful if a note was placed in section 3.1 stating that this is only a partial grammar, that this document and RFC 5027 define distinct elements for the ABNF rule named precondition-type and referring the reader to the IANA registry; and referring to section 5 for a discussion of the other precondition types.

2 Section 6. Examples
In the case of the second example which refers to Figure 2:
In SDP3 there is a repeated "a=des:conn" line:

      a=curr:conn e2e send
      a=des:conn mandatory e2e sendrecv
      a=des:conn mandatory e2e sendrecv
      a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host

I was also wondering whether SDP4 could be shown for completeness
of the example.

[Ballot comment]
The OPS-DIR review provided a couple of editorial suggetions that seemed to be accepted by the editors but not incorporated in the note to the RFC Editor or in a revised I-D:

1. It would be useful if a note was placed in section 3.1 stating that this is only a partial grammar, that this document and RFC 5027 define distinct elements for the ABNF rule named precondition-type and referring the reader to the IANA registry; and referring to section 5 for a discussion of the other precondition types.

2 Section 6. Examples
In the case of the second example which refers to Figure 2:
In SDP3 there is a repeated "a=des:conn" line:

      a=curr:conn e2e send
      a=des:conn mandatory e2e sendrecv
      a=des:conn mandatory e2e sendrecv
      a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host

I was also wondering whether SDP4 could be shown for completeness
of the example.

[Ballot comment]
The Gen-ART Review by Francis Dupont provided editorial suggestions,
  and the author said they would be included in a future revision.  A
  revision has not been posted yet.

[Ballot comment]
In section 4, there are four numbered points...
  1.  if an explicit connectivity verification mechanism (e.g., ICE) is
      negotiated, the precondition is met when the mechanism verifies
      connectivity successfully, otherwise
  2.  if a connection-oriented transport (e.g., TCP) is negotiated, the
      precondition is met when the connection is established.
  3.  in other cases, an implicit verification mechanism MAY be
      provided by the transport itself or the media stream data using
      the transport
  4.  if none of the above apply, connectivity cannot be verified
      reliably and the connectivity precondition will never be
      satisfied if requested.

This reads
if (1)
else if (2)
else (3)
else (4)

Or am I missing something?

Time to remove section 9?

[Ballot comment]
Section 3.2., paragraph 2:
>    Packets may be both sent and received on the media streams in
>    question.  However, such packets SHOULD be limited to packets that
>    are necessary to verify connectivity between the two endpoints
>    involved on the media stream.  That is, the underlying media stream
>    SHOULD NOT be cut through.  For example, ICE connectivity checks
>    [I-D.ietf-mmusic-ice] and TCP SYN and ACK packets can be exchanged on
>    media streams that support them as a way of verifying connectivity.

  I'm a bit confused about the TCP case. In Section 1, you say "(...)
  where the media is carried over (...) TCP [RFC0793], the
  connection-establishment procedures may fail." TCP establishes a
  connection with SYN/ACKs. If they are the reason for failure, how can
  you use them to verify connectivity?

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Precondition Types used with Session Initiation
Protocol (SIP)" registry at
http://www.iana.org/assignments/sip-precond-types

Precondition-Type Description Reference
----------------- ------------------------- ---------
conn Connectivity precondition
[RFC-mmusic-connectivity-precon-06]

--- (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?

Jean-Francois Mule, MMUSIC co-chair (jf.mule@cablelabs.com) is the Document Shepherd. He has personally reviewed this version of the Internet-Draft. This Internet-Draft document is ready for forwarding to the IESG for publication.


--- (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?

Sufficient reviews, no concerns.


--- (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.
No concerns.

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.

No based on July 20 search:
Total number of IPR disclosures found: 0
Total number of documents searched: 1
Search result on draft-ietf-mmusic-connectivity-precon, "Connectivity Preconditions for Session Description Protocol Media Streams"
No IPR disclosures related to draft-ietf-mmusic-connectivity-precon have been submitted

--- (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 good consensus for publication.

--- (1.f)
Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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, draft-06 checked against idnits 2.11.12

There are 2 warnings for references (one outdated for ICE-TCP which is ok and one warning due to a forward reference to the RFC-to-be).

--- (1.h)
Has the document split its references into normative and
informative?
Yes.

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?
No.

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].
No.

--- (1.i)
Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document?
Yes.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?
Yes.
Are the IANA registries clearly identified?
Yes.

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 the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?
No.


--- (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?

Yes, checked abnf with http://tools.ietf.org/tools/bap/abnf.cgi (simple token addition to an already defined rule).


--- (1.k)
The IESG approval announcement includes a Document
Announcement Write-Up.

Here is the proposed Document Announcement Write-Up:

Technical Summary
This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified.

Working Group Summary
The MMUSIC Working Group has consensus to publish this document as a Proposed Standard.

Document Quality
This document defines a new connectivity precondition type that is needed in scenarios where it is important that the media stream succeeds. It follows the guidelines provided in [RFC4032] to extend the SIP preconditions framework.


Personnel
The Document Shepherd is Jean-Francois Mule, and the Responsible Area
Director is Cullen Jennings.