Subject: [Gen-art] Gen-ART review of draft-ietf-avt-avpf-ccm-09.txt

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 18 Oct 2007 10:50:49 -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).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avt-avpf-ccm-09.txt
Reviewer: Vijay K. Gurbani
Review Date: 18 Oct 2007
IESG Telechat date: 22 Oct 2007

Summary: This draft is ready for publication as a Proposed
Standard.

Some nits follow:

* In S1, it is mentioned that "This makes the use of more
  traditional control protocol means, such as Session Initiation
  Protocol (SIP) re-INVITEs [RFC3261], undesirable when used for
  the same purpose."

  I am curious: I don't believe that SIP re-INVs are used to affect
  the sort of codec control messages being discussed in this draft.
  I believe that you are pointing out that folks should not use
  other means -- like SIP re-INVs -- for this purpose in the
  *future.*  If so, I would suggest the following change:
   s/undesirable when used/undesirable if used/

* S3.2: s/There are multiple reasons/There are two reasons/

* S3.5.4: There appears to be some presentation error (or maybe it
  is an error in the underlying XML) on line three and four of that
  section.

* S3.5.4.2: You may want to consider breaking into two lines the
  equations labeled (1) and (2) at the top of page 25.  The reason
  is that as the labels appear now, they are hidden.  Thus, when you
  refer to equations (1) and (2) later, it is hard to visually see
  where these equations are.  I had to go back and use the browser's
  find command to help me locate them.

  So, if re-arranged, these equations will look like:

  OLD:
  Max_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ...
  (1)
  Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ...
  (2)

  NEW:
  Max_net media_BR_A =
      TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
  Max_net media_BR_B =
      TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)

* S4.2.1.2, top of page 39: There appears to be some
  presentation error (or maybe it is an error in the underlying
  XML) on the first two lines of the page, and this is repeated
  in the second paragraph of the page.

* S4.2.2.2: s/.Note: if any media/Note: if any media

* S4.3.3.5: Is a sub-section warranted at all if there aren't
  any remarks?

That's it.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Oct 2007 09:24:36 +0200

Thanks for the review.

We will fix the nits at first suitable time. See inline for some comments.

Cheers

Magnus

>   s/undesirable when used/undesirable if used/

Yes, and actually we probably should rephrase this to correctly cover
SIP INFO and the usage like
http://tools.ietf.org/wg/mmusic/draft-levin-mmusic-xml-media-control-11.txt

>  is an error in the underlying XML) on line three and four of that

Well, it is an artifact from using Word to generate the document.

>      TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)

Yes, probably a better way to do it.

>  in the second paragraph of the page.

More issues with using Word to generate draft.

> * S4.3.3.5: Is a sub-section warranted at all if there aren't

Well, we are trying to keep with the format used in AVPF. I think we can
spend these 4 lines on showing that we actually have thought about this
section, and it isn't erroneously missing.

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 Oct 2007 11:28:07 -0500

Magnus: Thanks for the attention to the review.  More inline.

> http://tools.ietf.org/wg/mmusic/draft-levin-mmusic-xml-media-control-11.txt

Right; the latter is probably more directly applicable to the
sort of media control messages discussed in your draft.  The
utility of SIP INFO has been debated many times in the SIP WG
mailing list -- and in fact, one such debate is brewing mightily
even as we speak -- so I'd be surprised if SIP INFO was used
in the context of your draft.  But it could happen; so pointing
it out to implementors not to use the signaling messages is still
a good idea.

Oh, and I noticed one more small nit:

S3.1: s/Basso, et al/Basso et. al/

Thanks,

- vijay

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Oct 2007 11:56:09 +0200

> it out to implementors not to use the signaling messages is still

My proposed text for this is:

This makes the use of more traditional control protocol means, such as
Session Initiation Protocol (SIP) [RFC3261], undesirable when used for
the same purpose.  That is why this solution is recommended instead of
"XML Schema for Media Control" [XML-MC], which uses SIP Info to transfer
XML messages with similar semantics to what is defined in this draft.

> S3.1: s/Basso, et al/Basso et. al/

Thank you,

I am working on a update that I will submit today to address your nits
and also other that I have received.

Cheers

Magnus Westerlund

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 Oct 2007 13:15:29 -0500

> XML messages with similar semantics to what is defined in this draft.

Magnus: That is fine.  One pedantic nit: S/SIP Info/SIP INFO.

Thank you for your kind attention to resolving the comments.

Ciao.

- vijay