Thanks for the response! Comments inline: Thanks!
Ben. On Jun 21, 2013, at 4:35 PM, Michael Thornburgh <mthor...@adobe.com> wrote: > 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. Some additional text (whether IESG boilerplate or otherwise) that clarifies the purpose of the draft would help a lot. > >> 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. At the time of writing yes. My concern is how a future implementor can be confident that this doc describes RTMFP as used by Adobe at points in the future. When you say this is the authoritative specification, does that mean that Adobe does not plan to modify the protocol without timely publication of an update to this document? > >> -- 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. Okay > >> 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. Works for me. > >> -- 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. Okay. > >> -- 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. I understand the issue about permission to publish, but does this document serve its purpose until you are ready to publish the crypto profile? Ideally they would be published together and this document would reference that one. Do I infer correctly that there is no way someone could create an implementation that interops with Adobe products based on the documents available at this time? > >> -- 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. As Barry mentioned, RECOMMENDED is a synonym for SHOULD. Adding some text the effect of your additional explanation would solve my concern. > >> -- "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". Okay. > >> -- " 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. Okay. > >> -- "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". Okay. > >> -- "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". See my earlier comment on SHOULD vs RECOMMENDED. The important thing is to clarify the implications of violating the SHOULD. > >> -- 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. That would probably help. The important thing is to help implementers avoid bad decisions on buffer size 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? > > both of those SHOULDs should be RECOMMENDEDs. See previous comment > >> -- 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. Understood. I'm not sure if there is a convention for that--I guess the RFC editor will either leave it or advise something else. > >> -- 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. Okay. Some words to that effect would help. > >> -- 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. Okay. > >> -- 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. See previous comments on SHOULD vs RECOMMENDED. > >> *** 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. Okay. > >> -- 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). Okay. > >> -- 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". Okay. > >> -- 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. Okay. > >> -- 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
