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.

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?

	-- 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.

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.

-- 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.

-- 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?

-- 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?

-- "Authenticity MAY comprise verifying an issuer signature chain in a public key infrastructure"

Is that really normative, or just an observation of fact?

-- " 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.

-- "A comparison function MAY comprise performing a lexicographic ordering..."

Is that really normative, or just an example of something one might do?

-- "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?

-- 3.5, last paragraph:

Can you offer guidance on reasonable buffer size and number 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?

-- 3.5.1.1.1 throughout, and following sections:

Does the upper case AND have special meaning?

-- 3.5.1.4, Deployment Note:

How would a redirector know which endpoints might do this? Or should it never initiate a session?

-- 3.5.2:

Do I infer correctly that two endpoints need not share the same congestion control algorithm to communicate?

-- 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?


*** Nits/editorial comments:

-- General: There's quite a bit of inconsistent use of third-person vs second-person language.

-- 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.

-- 3.5.1.4, Deployment Note:

s/which/that

-- 3.5.1.6, last paragraph:

Which diagram? (An explicit cross-ref would help.)

-- 3.5.2:

What is meant by "aggressive" in this context? Aggressive in avoiding congestion, or aggressive in sending data?

-- 3.6.2.3.1 and subsequent sections:

Does the all-caps "FIRST" have special meaning?