Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-10

Being more explicit (e.g., in the Introduction) about why this is being published would have been useful. Proprietary protocols can be documented for a number of reasons: historical reasons, to enable new implementations to be compatible with legacy ones, to get new implementations to use this protocol instead of a standard one, etc. Which one applies here?

Thanks for handling my discuss.

I didn't check if these coments were addressed or not. Feel
free to chat about 'em, but since they're non-blocking you
don't have to:-)

- 1.1: Saying the security is "always on" seems wrong when
that's not specified here. The first three security bullets
should be rewritten to say that the security bits are
currently missing.  (Or move those to the putative section I
suggested adding.)

- 2.1.2: Interesting that your VLU's are the same as DTNRG's
SDNVs. [RFC6256] I'm not suggesting a change just interested
that they're the same.

- 2.2.3: I think you should also re-iterate here that there
is no "Cryptography Profile" currently publicly specified.

- 2.3.6: I didn't get why or when its ok to replace a cookie
that was incorrect? Seems like a bad thing to be doing. (And
what hash function do you mean?)

- 2.3.7: initiatorCertificate: what certificate format do
you mean? RC5280 or something else? And do you mean just
one cert or a chain?

- 3.5: If you add the security bits, don't you need some more
state for certificate status checking, e.g. to do OCSP?

Whilst I agree with Spencer on the utility of the protocol, the Abstract and the introduction needs to make it clear that this is a proprietary protocol, and not a protocol endorsed by the IETF.

Whilst in this particular case this may be obvious, we need to hold all vendors to the same standard.