Subject: [Gen-art] A *new* batch of IETF LC reviews - 17 Jan 2007

From: "Mary Barnes" <[email-masked]>
Date: Thu, 17 Jan 2008 22:13:12 -0600

Hi all,

Here's the link to the new LC assignments for this week:
http://www.alvestrand.no/ietf/gen/art/reviewers-080117-lc.html

With the assignments captured in the spreadsheets: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

The standard template is included below.

Thanks, 
Mary. 

-------------------------------------------------------------------

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: 
Reviewer: 
Review Date:  
IETF LC End Date: 
IESG Telechat date: (if known)

Summary:

Comments:

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Jan 2008 19:46:22 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

Document: Session Description Protocol (SDP) Attributes for OMA
		BCAST Service and Content Protection
Reviewer: Joel M. Halpern
Review Date: 20-January-2007
IETF LC End Date: Completed?
IESG Telechat date: N/A

Summary:	This document seems ready for publication as an Informational 
RFC, assuming that such is the right status for the assignment.

Comments:
	Given that presumably 3GPP and 3GPP2 broadcast media services would be 
expected to see "wide use", some additional description of why an 
informational document is sufficient for this registration would seem 
appropriate.  At a guess, the reason is that interoperability is only 
envisioned with devices complying with the suite of relevant 
specifications, and therefore that suite constitutes the necessary 
documentation.  But that should be stated clearly.  (Already noted by 
Russ.)  Note that as a proposed standard I would expect slightly more 
documentation of the bcastversion (what is the current version at the 
time of filing.)  I would expect a rather better explanation of the us 
of the stkmstream attribute.  I can guess what is intended.  I presume 
that it is not particularly remarkable as an SDP behavior.  But for 
those not as conversant with SDP, if it were a PS I would expect a bit 
more text (if I am guessing right, it wouldn't take a lot.)

	It seems odd that the definitions of the attribute values of the SDP 
attributes define the valu in terms of XML data types.  SDP is not XML, 
is it?  (At a guess, the semantics can be applied, and result in 
meaningful strings.  It just seems a strange way to define the legal 
values.)