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

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?

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.

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.

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?

  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.