Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection
RFC 5159

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

(Cullen Jennings) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

Comment (2008-01-23)
No email
send info
Comments from Al Morton, OPS-DIR:


Since the Intro says:
   OMA BCAST specifications are expected to be used by 3GPP MBMS, 3GPP2
   BCMCS and DVB-H based broadcast wireless systems.

this seems to satisfy the criteria for a Standards Track Specification,
according to RFC4566:
   ...Attributes that are
   expected to see widespread use and interoperability SHOULD be
   documented with a standards-track RFC that specifies the attribute
   more precisely.

1,$s/identifyer/identifier/g


Section 3  New SDP Attributes

The 193 page OMA Reference Document gives many examples where
the identifier for a stream is specified by attribute "streamid".
Two of the new attributes also specify ids:
   o  a=stkmstream:<id of the stkm stream>
   o  a=SRTPAuthentication:<id for SRTP authentication algorithm value>
Suggest it would be more exact to name these attributes:
   o  a=stkmstreamid:<id of the stkm stream>
   o  a=SRTPAuthenticationid:<id for SRTP authentication algorithm value>
(Naming is kind of an OPS issue)

Section 4 Security Considerations

The paragraphs describing the reasons to protect bcastversion and
stkmstream(id) could be included in the Purpose section of the
corresponding attribute specification in Section 5.


Section 5  IANA Considerations

S 5.1.3  SRTPAuthentication:<id
Suggest
OLD
      Purpose:  When SRTP is used, the attribute SRTPAuthentication states
      which authentication algorithm to use.
NEW
      Purpose:  When SRTP is used, the attribute SRTPAuthentication specifies
      one authentication algorithm to use.                          ---------
      ---

The reference to the OMA doc section 10.4 should include "[2]"
(the reference number) and is a relay to section 4 of RFC 4771 (add that)
http://tools.ietf.org/html/rfc4771#section-4

S 5.1.4  SRTPROCtxRate:
spell-out ROC in:
   Long-form attribute name:  ROC transmission rate

The reference to the OMA doc section 10.4 should include "[2]"
(the reference number) and is a relay to section 4 of RFC 4771 (add that)

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2008-01-23)
No email
send info
Agree with Russ. Running an IETF LC as PS seems the right thing to do.

(Russ Housley) (was Discuss) No Objection

(Chris Newman) No Objection

Comment (2008-01-24)
No email
send info
This is fine with me as either informational or PS.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

Comment (2008-01-24)
No email
send info
The document should be either re-classified as PS (and go through the appropriate IETF LC) or it should include text in the Introduction to explain why Informational is enough. Both paths are OK with me.

(David Ward) No Objection

Magnus Westerlund No Objection