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:b...@nostrum.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
