Attached is my review of the specified document, submitted as part of
the Gen-ART process. For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Document Tag: draft-ietf-sipping-transc-framework-04
Document Title: Framework for Transcoding with the Session Initiation
Protocol (SIP)
Intended Status: Informational
Shepherding AD: Jon Peterson
Review Trigger: Aug 3 Telechat
To the Author/Editor: Please wait for direction from your document
shepherd or AD before posting a new version of the draft.
---------------- Begin review ----------------
Summary: This draft is ready for publication as an Informational RFC
I had no major concerns with the document, I found it well written and
easy to understand even though I'm not familiar with all the details
of the relevant technologies. I did have a few minor ideas about
places where it could possible be improved even more, assuming that
work is being done. If there are no other changes to be done, it is
probably not worth the delay of another edit/review cycle to make
these changes. But if the document is being changed due to some other
issues, the editors might consider these changes as well.
Minor comments
--------------
I do not believe that all the Normative references are, in fact,
Normative. In particular, [1] and [8] are only referenced in a "for
example ... could be used" style, which is clearly only Informative.
There is a transcoding case that I think might be a useful example,
but doesn't appear anywhere in the document. If there is a rewrite,
you may wish to mention it somewhere for additional support. Perhaps
in the introduction. The case I'm thinking of is where the two ends
do not support a common bandwidth, perhaps one end only supports high
quality (and therefore high bandwidth) video, but the other end is
bandwidth constrained and requires a different encoding with lower BW
requirements. For most combinations like this, it would be possible
to have a transcoder that solves the mismatch. It might even be
offered as a standard option at the ingress to the lower BW portion of
the network.
I note that this document along with references [10] and [11] actually
forms a loosely coupled set, where I understand this document is an
informational overview and the other two are details of the two
approaches. I applaud this approach, if that's what is intended, but
would like to see that relationship described in this document. Once
again, a suggestion for better clarity, but not worth holding up the
document if nothing else is being changed.
----------------------------------------------------------------
The following editorial issues are noted for the convenience
of possible copy editors but are not part of the technical review.
Clarity
-------
In Section 3 very near the top of Page 5, you have a reference for
3pcc to reference [7]. Would it also be productive to reference [10]
as well there? Also, that paragraph has no reference for the bridge
model. Should [11] be referenced?
Typos
-----
Section 3.1: "This model also allows to invoke" => "This model also
allows invoking"
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
