From: Michael Thornburgh
Sent: Friday, June 21, 2013 2:35 PM
hi Ben. thanks for your review. comments/replies inline.
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: Thursday, June 20, 2013 4:07 PM
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.
this memo documents an existing network transport protocol that is widely
deployed and in widespread
use in the Internet. we felt that the IETF community (and in particular the
participants in the
Transport and Services Area) is the most appropriate community with which to
share this work: 1)
members of this community have the necessary and relevant expertise not only
to understand the
protocol, but to make use of it potentially in new applications beyond Flash;
2) it is a transport
protocol similar in many ways to TCP and SCTP and widely deployed and used;
3) Adobe is interested in
pursuing standardization of this protocol (with all that entails) if there is
community interest, and
the IETF is definitely the right place for that.
we are very grateful that Martin Stiemerling chose to sponsor this document.
with regard to comments in later messages in this thread, i'd be happy to
include some (IESG-supplied)
boilerplate in the document to clarify that it is not the product of an IETF
WG. however, note that
both the title and first sentence of the Introduction indicate that this is
"Adobe's blahblahblah",
consistent with other vendor-protocol RFCs and consistent with IESG editorial
insistence (as told to
me by a former TSV AD). see RFC 4332 and RFC 6802 for two examples of
vendor-specific/supplied
protocols. see also the IESG note in RFC 4332 as an example disclaimer that
could be added.
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?
this memo is the authoritative specification for Adobe's RTMFP. Adobe owns
change control. i believe
the second and third paragraphs of the Introduction indicate to a reader that
this draft represents
RTMFP as deployed in the named Adobe products at the time of writing.
-- 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.
i will expand on applicability beyond what i specify in the first paragraph
of the Introduction, in
general terms such as the kinds of functionality we use this protocol for in
Flash. note that
interoperation with certain Adobe products, such as Flash Player, requires
additional information such
as the Flash-specific Cryptography Profile and syntax/semantics of mapping
Flash's "Real Time
Messaging Protocol (RTMP)" messages onto RTMFP flows. these Flash-specific
profiles and mappings are
application-layer for RTMFP, analogous to HTTP over TCP.
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.
you're not the first person to be confused by that construct. i will change
instances of "MUST ONLY"
to "is allowed only if" (or similar) and remove the definition for "MUST
ONLY" from Section 1.2.
-- 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.
yes, all endpoints have certificates. in the RTMFP-for-Flash world, these
certificates are not X.509
certs, and are anonymous and ephemeral.
-- 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?
yes, endpoints need a common cryptography profile to interoperate. there is
no repository for crypto
profile documentation at this time. currently, there is one defined
cryptography profile (the one used
for Flash communication) that is not publicly documented, because i do not
yet have permission to
publish it. i (meaning me personally) hope that a memo documenting the
crypto/application profile for
Flash communication (as being a widely deployed and used profile for RTMFP)
would also be published
someday as an I-D and hopefully an Informational RFC.
-- 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?
this should be "It is RECOMMENDED that multiple endpoints not have the same
identity." if two
endpoints have the same identity, then they will be indistinguishable. this
will not break RTMFP, but
might confuse an application. that being said, there could potentially be
reasons to have different
endpoints with indistinguishable identities and that potential should not be
normatively prohibited.
-- "Authenticity MAY comprise verifying an issuer signature chain in a
public key infrastructure"
Is that really normative, or just an observation of fact?
that "MAY" should be "can".
-- " 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.
i will add a note that if the canonical EPD is the same for two distinct
identities, then the
"duplicate session" logic in section 3.5.1.1.1 (paragraph 6 step 1) might
abort a new opening session
to the second identity, which might not be desired.
-- "A comparison function MAY comprise performing a lexicographic
ordering..."
Is that really normative, or just an example of something one might do?
that "MAY" should be "can".
-- "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?
again, that SHOULD should be reworded to RECOMMENDED. i will change
"identical" to "bitwise
identical".
-- 3.5, last paragraph:
Can you offer guidance on reasonable buffer size and number ranges?
i assume you mean "3.4, last paragraph" (referring to packet reassembly
buffers). i will add some
guidance and a "for example". the guidance will depend on how that RTMFP
will be used and the
expected amount of resources available to it.
-- 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?
both of those SHOULDs should be RECOMMENDEDs.
-- 3.5.1.1.1 throughout, and following sections:
Does the upper case AND have special meaning?
upper case is the closest to bold face available in this format. the
intention is to emphasize (since
there are multiple conditionals) that all conditionals are required to hold.
-- 3.5.1.4, Deployment Note:
How would a redirector know which endpoints might do this? Or should it
never initiate a session?
this is guidance for designing and deploying an RTMFP system. the redirector
wouldn't know -- the
designer should design the system such that the described circumstance
doesn't happen (for example, by
having the redirector never initiate a session). this is properly a SHOULD
NOT since doing so can
cause undesired behavior (as described). it is not desirable to give a
normative prohibition or
recommendation against a redirector initiating any sessions. i feel this
paragraph gives the
narrowest normative limitation and an explanation for that limitation.
-- 3.5.2:
Do I infer correctly that two endpoints need not share the same congestion
control algorithm to
communicate?
correct. the timestamp echo facility, ack behavior (as described for flow
receivers), and limitations
on aggressiveness in 3.5.2/.* impose the normative envelope in which any
congestion control algorithms
should interoperate.
-- 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?
this should be a RECOMMENDED. the far end will work just fine if Next User
Data is never used.
*** Nits/editorial comments:
-- General: There's quite a bit of inconsistent use of third-person vs
second-person language.
i will try to clean that up.
-- 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.
others have commented that they'd prefer sections 2 and 3 to be swapped. i
resisted that as this order
("here are the pieces" and then "here's how they fit together") is my
preferred way of explaining
stuff. also swapping those sections would be a huge editorial change which
might have significant
cross-reference and forward/back reference implications and could introduce
hard-to-detect errors into
the spec. however, i think i can move the overview (or a summary thereof) to
earlier in the spec
(probably in Section 1).
-- 3.5.1.4, Deployment Note:
s/which/that
good catch.
-- 3.5.1.6, last paragraph:
Which diagram? (An explicit cross-ref would help.)
oops. that paragraph used to be the postamble of the figure, so it obviously
meant "this figure".
i'll change "the figure" to "Figure 17".
-- 3.5.2:
What is meant by "aggressive" in this context? Aggressive in avoiding
congestion, or aggressive in
sending data?
aggressive in sending data. i'll make that clarification.
-- 3.6.2.3.1 and subsequent sections:
Does the all-caps "FIRST" have special meaning?
it is all-caps for typographical emphasis.
thank you!
-michael thornburgh