hi Ben, all. i have uploaded a new revision -08 of this draft that addresses comments raised during the IETF Last Call, which has now concluded. Ben: i believe the "second-person" voice in this memo is used exclusively for detailing algorithms that are to be performed. i believe the imperative "do it like this" voice is appropriate to that use, so i did not change it. i also feel that the change in voice helps indicate that the implementation is being addressed/instructed. thank you for helping to improve the quality of this document. -michael thornburgh > 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@xxxxxxxxxxx] > > 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