Skip to main content

Connectivity Preconditions for Session Description Protocol (SDP) Media Streams
RFC 5898

Revision differences

Document history

Date Rev. By Action
2015-10-14
07 (System) Notify list changed from mmusic-chairs@ietf.org, draft-ietf-mmusic-connectivity-precon@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2010-07-07
07 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2010-07-07
07 Amy Vezza [Note]: 'RFC 5898' added by Amy Vezza
2010-07-06
07 (System) RFC published
2010-03-26
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-03-26
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-03-26
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-03-25
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-03-25
07 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-03-25
07 (System) IANA Action state changed to In Progress
2010-03-24
07 Cindy Morgan IESG state changed to Approved-announcement sent
2010-03-24
07 Cindy Morgan IESG has approved the document
2010-03-24
07 Cindy Morgan Closed "Approve" ballot
2010-03-24
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-03-24
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-03-16
07 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2010-03-04
07 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2010-03-04
07 Alexey Melnikov
[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [ …
[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.
2010-03-04
07 Alexey Melnikov [Ballot discuss]
2010-03-03
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-03-03
07 (System) New version available: draft-ietf-mmusic-connectivity-precon-07.txt
2009-12-06
07 Alexey Melnikov
[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [ …
[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.
2009-12-06
07 Alexey Melnikov
[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, …
[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.
2009-12-06
07 Alexey Melnikov
[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [ …
[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.
2009-12-06
07 Alexey Melnikov
[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, …
[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?
2009-11-19
07 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-11-19
07 Cullen Jennings
[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. …
[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.
2009-11-19
07 Alexey Melnikov
[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [ …
[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.
2009-11-19
07 Alexey Melnikov
[Ballot discuss]
I only have some minor comments and likely to clear upon receiving a clarifying response.

In Section 6:

  Since B asked for …
[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?
2009-11-19
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-11-19
07 Magnus Westerlund
[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 …
[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.
2009-11-19
07 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2009-11-19
07 Alexey Melnikov
[Ballot comment]
3.1.  Syntax

  The connectivity precondition type is defined by the string "conn"
  and hence we modify the grammar found in [ …
[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.
2009-11-19
07 Alexey Melnikov
[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, …
[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.)
2009-11-19
07 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-11-18
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-11-18
07 Tim Polk
[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 …
[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.
2009-11-18
07 Tim Polk
[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 …
[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.
2009-11-18
07 Tim Polk
[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 …
[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.
2009-11-18
07 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-11-18
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-11-18
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-11-18
07 Dan Romascanu
[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 …
[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.
2009-11-18
07 Dan Romascanu
[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 …
[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.
2009-11-18
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-11-17
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-11-16
07 Russ Housley
[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 …
[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.
2009-11-16
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-11-16
07 Amy Vezza State Changes to IESG Evaluation from IESG Evaluation - Defer by Amy Vezza
2009-11-16
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-11-16
07 Adrian Farrel
[Ballot comment]
In section 4, there are four numbered points...
  1.  if an explicit connectivity verification mechanism (e.g., ICE) is
      negotiated, …
[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?
2009-11-02
07 Samuel Weiler Request for Telechat review by SECDIR Completed. Reviewer: Stephen Kent.
2009-10-23
07 (System) Removed from agenda for telechat - 2009-10-22
2009-10-22
07 Samuel Weiler Request for Telechat review by SECDIR is assigned to Stephen Kent
2009-10-22
07 Samuel Weiler Request for Telechat review by SECDIR is assigned to Stephen Kent
2009-10-19
07 Alexey Melnikov State Changes to IESG Evaluation - Defer from IESG Evaluation by Alexey Melnikov
2009-10-19
07 Lars Eggert
[Ballot comment]
Section 3.2., paragraph 2:
>    Packets may be both sent and received on the media streams in
>    question.  However, such …
[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?
2009-10-19
07 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-10-18
07 Cullen Jennings [Note]: 'Please note sec-dir review comments were addressed in RFC Ed Note.
Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)' added by Cullen Jennings
2009-10-18
07 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings
2009-10-18
07 Cullen Jennings Ballot has been issued by Cullen Jennings
2009-10-18
07 Cullen Jennings Created "Approve" ballot
2009-10-18
07 Cullen Jennings State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings
2009-10-18
07 Cullen Jennings Placed on agenda for telechat - 2009-10-22 by Cullen Jennings
2009-10-14
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-10-12
07 Amanda Baber
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 …
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]
2009-10-08
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Stephen Kent.
2009-10-03
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Kent
2009-10-03
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Stephen Kent
2009-09-30
07 Amy Vezza Last call sent
2009-09-30
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-09-30
07 Cullen Jennings State Changes to Last Call Requested from AD Evaluation by Cullen Jennings
2009-09-30
07 Cullen Jennings Last Call was requested by Cullen Jennings
2009-09-30
07 (System) Ballot writeup text was added
2009-09-30
07 (System) Last call text was added
2009-09-30
07 (System) Ballot approval text was added
2009-09-30
07 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2009-07-20
07 Cindy Morgan
--- (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 …
--- (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.
2009-07-20
07 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-07-20
07 Cindy Morgan [Note]: 'Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)' added by Cindy Morgan
2009-03-09
06 (System) New version available: draft-ietf-mmusic-connectivity-precon-06.txt
2008-10-24
05 (System) New version available: draft-ietf-mmusic-connectivity-precon-05.txt
2008-07-27
07 (System) Document has expired
2008-01-23
04 (System) New version available: draft-ietf-mmusic-connectivity-precon-04.txt
2007-11-19
03 (System) New version available: draft-ietf-mmusic-connectivity-precon-03.txt
2006-06-13
02 (System) New version available: draft-ietf-mmusic-connectivity-precon-02.txt
2005-10-21
01 (System) New version available: draft-ietf-mmusic-connectivity-precon-01.txt
2005-05-03
00 (System) New version available: draft-ietf-mmusic-connectivity-precon-00.txt