Thanks Michael, that note would completely resolve my concern, and change my review summary to "ready for publication".
Ben. On Jul 9, 2013, at 5:03 PM, Michael Thornburgh <mthor...@adobe.com> wrote: > 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:b...@nostrum.com] >> 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.
