Hi Michael, Thanks for the continued responses. A few more comments inline. I deleted sections that did not seem to need further comment. In summary, all of my concerns are resolved except for the crypto profile question.
Thanks! Ben. On Jun 26, 2013, at 2:00 PM, Michael Thornburgh <mthor...@adobe.com> wrote: [...] >>> 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. > > the sponsoring AD has proposed an additional statement that will be inserted > by the RFC Editor on publication. note that draft -08 has additional > clarification that this is an Adobe protocol and is not the product of an > IETF activity. The additional statement in 08 resolves my concern in the context of this specific document. (I have mixed feelings about the idea of documenting proprietary protocols in IETF stream drafts at all, but it's not reasonable to hold any particular draft hostage over a larger policy question.) >> 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? > > this is a problem for *any* published protocol. > RTMFP (as documented in this memo) hasn't changed substantially in many > years. i have every expectation that, should a change be made to the > protocol, we would publish an updated specification. > (Let me preface this comment: This is also an issue with the general idea of publishing proprietary protocols in IETF stream documents. I'm not picking on this draft in particular, and we can consider this issue closed for the purposes of my Gen-ART review.) I disagree that this is an issue for any published protocol. In the case of an IETF produced protocol, an RFC is the definitive specification. If the IETF chooses to revise the protocol in the future, it does so by publishing a new RFC that updates or obsoletes the original. You indicate Adobe plans to do the same, and that this protocol is pretty stable. You mentioned previously that this document would be the authoritative specification. So, then maybe there's not an issue. But if Adobe maintains internal documentation that an Adobe engineer would consult to understand and implement the protocol, and you revise that documentation internally, it's going to be pretty tricky keeping the IETF -published specification in sync. >>> >>> 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? > > additional documentation is needed to interoperate (at the application layer) > with the Adobe products that implement RTMFP. i hope that the successful > publication of this memo will help me in getting the necessary approval to > publish the higher layer details of Adobe's RTMFP ecosystem. > > the situation is analogous to having published TCP, but there's a lot more > you need to know to talk to a web server with HTTPS (like TLS and HTTP). > it's still useful to know how TCP works, and plenty more to do with it than > talk to web servers. I don't think that's a fair analogy. I can use TCP for many purposes other than talking to web servers. It can even be useful all itself. But if I understand correctly, you can't expect to use RTMFP _at_all_ until you publish they crypto-profile(s). Is that correct? If so, a better analogy would be to publish TLS without any published cryptosuites. If I am correct on the inability to use the protocol at all without more documentation that does not currently exist, then I think it would be reasonable to put a clearly worded assertion to that effect early in the draft, along with a comment that you intend to publish at least one crypto profile in the future. (Perhaps an applicability statement would be helpful here.) > >>>> -- 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. > > i changed this to RECOMMENDED (because while i agree that RECOMMENDED and > SHOULD impart the same force of normative requirement for an implementer, the > words' different English meanings help the reader understand the reason for > the normative constraint). see draft -08 for additional explanation i added > for this constraint. The added text in 08 resolves my concerns. (I'm not going to get into the RECOMMENDED vs SHOULD argument other than to note that the thread on the IETF discussion list tells me that English speakers don't necessarily agree on the difference :-) ) > > [...] > >>>> *** 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. > > as i mentioned in a separate message: """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.""" Oops, sorry, I meant to cut that part out of my previous reply after seeing your other email. I seem to recall finding 2nd person language in sections that were not clearly identified as algorithm specifications, but on re-review I can't find it--so consider it dropped. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
