I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-thornburgh-adobe-rtmfp-07
Reviewer: Ben Campbell
Review Date: 2013-06-20
IETF LC End Date: 2013-06-25
Summary: This draft is almost ready for publication as an informational RFC.
However, I have some concerns about the purpose and intended status of the
document that I think should be considered prior to publication.
Note: This is an informational draft that describes what I understand to be an
existing protocol as implemented by commercial products. Therefore, this review
does not attempt to evaluate the protocol itself. I assume the protocol is what
it is, and it is not up to the IETF to agree or disagree with it.
*** Major issues:
-- Why does this need to be published as an IETF stream RFC? If I understand
correctly, this documents an existing protocol as implemented by commercial
products. I agree with Martin's comment that there is value in publishing this
sort of thing, but I applaud the Adobe and the author for publishing it so
other implementations can interoperate with their products. But that could have
done that in an independent stream document, or even in an Adobe published
document. (Perhaps even in a prettier format ;-) ) If we publish this as an
IETF stream document, then I think it needs stronger clarification that it is
not an IETF consensus doc than just its informational status.
Along those lines:
-- Is this document the authoritative specification? (I suspect not.)
Who owns change control? I assume that to be Adobe and/or the authors. What
expectation do readers of this draft have that it represents the current
version of RTMFP at any point in time?
-- Under what circumstances would one desire to implement this? I can
infer that from the introduction, but it would be nice to see some sort of
applicability statement making it explicitly clear that this is not an IETF
protocol, and that one would implement it in order to interoperate with certain
Adobe products. I know that some of this may be implied by the fact that this
is informational rather than standards track. But I don't expect readers who
are not IETF insiders to understand that subtlety without some explicit words
to that effect. In particular, it would be good to clarify the difference
between this and the many "not quite accepted as standards track by some
working group" nature of a number of our informational RFCs that describe
protocols.
That all being said, this is overall a well written document. The rest of my
comments are mostly pedantic nits.
*** Minor issues:
-- section 1.2:
I find the use of "MUST ONLY" confusing. I gather it means "you are _allowed_
to do X only under certain conditions" rather than "you are _required_ to do X
under certain conditions." If correct, I think the words "MAY ONLY" would be
more clear. If not, then I think the construct would be better handled using
existing 2119 language.
-- section 3.2:
Do I understand correctly that all endpoints are expected to be able to present
certificates? Do you find that common in the field? I realize the nature of the
certs will depend on the security profiles.
-- sections 3.2 and 5
Do I assume correctly that endpoints need a common crypto profile to
communicate? Is there a repository where one might find crypto profile
documentation? Is there a commonly implemented one to which this draft could
refer?
-- section 3.2: "Multiple endpoints SHOULD NOT have the same identity."
Why not MUST? Will things not break if two endpoints do have the same identity?
-- "Authenticity MAY comprise verifying an issuer signature chain in a public
key infrastructure"
Is that really normative, or just an observation of fact?
-- " Canonical Endpoint Discriminators for distinct identities SHOULD be
distinct."
What if they are not? Do things break? It might be worth making this a MUST, or
adding some additional guidance about what might happen if the SHOULD is
violated.
-- "A comparison function MAY comprise performing a lexicographic ordering..."
Is that really normative, or just an example of something one might do?
-- "A test SHOULD comprise testing whether the certificates are identical."
What if it doesn't? Also, what constitutes "identical"? All fields match
values? Bitwise match? Is it simply including the same identity or identities?
Maybe an identity function provided by the crypto profile?
-- 3.5, last paragraph:
Can you offer guidance on reasonable buffer size and number ranges?
-- 3.5.1.1.1, 3rd paragraph:
What are the consequences of having a tag with less than 8 bytes of length? Is
the SHOULD reasonable here?
-- 3.5.1.1.1 throughout, and following sections:
Does the upper case AND have special meaning?
-- 3.5.1.4, Deployment Note:
How would a redirector know which endpoints might do this? Or should it never
initiate a session?
-- 3.5.2:
Do I infer correctly that two endpoints need not share the same congestion
control algorithm to communicate?
-- 3.6.2.3.2, 2nd paragraph: "...an implementation SHOULD encode a Next User
Data chunk instead of a User Data chunk"
I'm not sure why this needs to be normative, as I assume its just normal
behavior. But if it does need to be normative, why not a MUST? Can the far
endpoint reasonably handle things if the SHOULD is violated?
*** Nits/editorial comments:
-- General: There's quite a bit of inconsistent use of third-person vs
second-person language.
-- 3.1: It would be nice to see the overview earlier in the draft. I found it
difficult to read through all the data format stuff prior to section 3 putting
them into context.
-- 3.5.1.4, Deployment Note:
s/which/that
-- 3.5.1.6, last paragraph:
Which diagram? (An explicit cross-ref would help.)
-- 3.5.2:
What is meant by "aggressive" in this context? Aggressive in avoiding
congestion, or aggressive in sending data?
-- 3.6.2.3.1 and subsequent sections:
Does the all-caps "FIRST" have special meaning?