Skip to main content

Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection
draft-dondeti-oma-mmusic-sdp-attrs-00

Yes

(Cullen Jennings)

No Objection

(David Ward)
(Jari Arkko)
(Lisa Dusseault)
(Magnus Westerlund)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Cullen Jennings Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection (2008-01-24) Unknown
This is fine with me as either informational or PS.
Dan Romascanu Former IESG member
No Objection
No Objection (2008-01-24) Unknown
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 Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2008-01-23) Unknown
Agree with Russ. Running an IETF LC as PS seems the right thing to do.
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (2008-01-23) Unknown
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 Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown