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

Note: This ballot was opened for revision 07 and is now closed.

(Cullen Jennings) Yes

Comment (2009-11-19 for -)
No email
send info
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.

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2009-10-19 for -)
No email
send info
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?

(Adrian Farrel) No Objection

Comment (2009-11-16 for -)
No email
send info
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?

(Russ Housley) No Objection

Comment (2009-11-16 for -)
No email
send info
  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.

(Alexey Melnikov) (was Discuss) No Objection

Comment (2010-03-04)
No email
send info
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.

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2009-11-18 for -)
No email
send info
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 20000 typ host

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

Magnus Westerlund (was Discuss) No Objection