hi Ben. your "like to see" is entirely reasonable, and the following text will be in the next revision once my AD or Document Shepherd directs me to post it: Note to implementers: at the time of writing, the Cryptography Profile used by the above mentioned Adobe products is not publicly described by Adobe. Implementers should investigate the availability of documentation of that Cryptography Profile prior to implementing RTMFP for the purpose of interoperation with the above mentioned Adobe products. thank you. -michael thornburgh > From: Ben Campbell [mailto:ben@xxxxxxxxxxx] > Sent: Tuesday, July 09, 2013 12:59 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 wait for direction from your document shepherd or AD before posting a new version of the draft. > > Document: draft-thornburgh-adobe-rtmfp-09 > Reviewer: Ben Campbell > Review Date: 2013-07-09 > IESG Telechat date: 2013-07-11 > > Summary: This draft is essentially ready for publication as an informational RFC. There is one issue > from my previous review and related discussion that I think is almost, but not completely handled. All > other concerns from my previous review have been addressed in this version. > > Major issues: > > There has been a fair amount of discussion about how this protocol requires a crypto profile to > interoperate, and no such profiles are included, or otherwise widely published. If this were a > standards track draft, I would argue for at least one mandatory-to-implement profile to be included or > referenced. But since this is intended as an informational RFC that simply describes what certain > products are doing, that's probably okay. Furthermore, the author added a paragraph to the > introduction specifically calling out the issue, which I applaud. > > But I'd like to see that paragraph go a bit further, and explicitly mention any such profile needed to > interoperate with the commercial products mentioned in the 2nd paragraph of section 1 has not been > made available at the time of RFC publication, and that implementors should investigate the > availability of such a profile prior to implementing this protocol for the purposes of interoperating > with those products. > > Minor issues: > > None. > > Nits/editorial comments: > > None.