Last Call Review of draft-ietf-mmusic-rtsp-nat-evaluation-14
review-ietf-mmusic-rtsp-nat-evaluation-14-opsdir-lc-banks-2014-09-19-00

Hello,
        I've been asked to perform an ops-dir review of
        draft-ietf-mmusic-rtsp-nat-evaluation-14. I am SUPER late with this
        review, although I continue to be called out on the last calls/special
        requests list, and so here it is. I'm happy to buy the authors a
        beverage of choice in Hawaii for my tardiness (and review below. :))

Summary: Not ready

Overall, it might not be the way we do things here in Ops-dir, but I'd kick
this document back to the WG for editorial reasons. While I don't find any
major technical problems, in my humble opinion, this draft needs some editorial
love. In some regards it reads as if it's been written by more than one author,
and while not a problem in and of itself, it shouldn't become the reader's
problem that it was. Indeed, I find typos and grammatical errors throughout the
pages; I find concepts referred to and defined later/past first reference. I
find this draft to be one that's taken a considerable amount of time to read
through and parse and make sense of. It shouldn't be this hard. I think this
draft could benefit greatly from having a clearly defined problem/solution,
with clear discussion points and introduction of key
problems/solutions/requirements, and a definitive demarc between what's in and
out of scope.

Having said that, having a traditional "editor" review the document would
probably help immensely; I don't see huge technical issues with the content,
and the issues below could probably easily be resolved. I've organized my
review into 2 parts: minor nits, and editorial nits, where I'm sure there's
some bleed from one to the other. I've also cut off the editorial nits; they
were sucking in an enormous amount of my time, and if I'm going to invest that
time, I'd like to invest it with the authors directly. I'm happy to help mark
up the text, if the authors see fit. I did stop adding new nits, because
they're continuing copies of previously noted issues.

It's worth noting that I review top down; as I see it/read it in the document,
I write. If you refer to a term for the first time in section 1, but define it
in section 5, I'll leave you a nit, because you're referring to a term that's
not yet been defined. Just an FYI, to help you make heads and tails of the
review below.

Thanks
Sarah

Minor nits:
- In the introduction, you discuss using an ALG, but then talk about home
firewalls using a similar filtering behaviour to NAT and that this type of
firewall can be handled using the same solution as employed for NAT traversal
instead of relying on ALGs". While I think I understand what you're trying to
say here, you might consider being specific about the "similar filtering
behaviour to NAT" and clear on which solution NAT traversal implements, and
hence you'd like to copy. After all, in the very next sentence, you state that
this document describes several NAT-traversal mechanisms for RTSP. :)

- the introduction section as a whole could be clearer. See the editorial nits
below. You refer to "the resulting ICE-based RTSP NAT traversal mechanism ..."
but I can't figure out, for the life of me, WHY you mention it here. Is it one
of the mechanisms you define/discuss below? Why only this one, and not others?
As a newcomer to this draft, I find the introduction a bit confusing and I
believe you could be clear(er) in it's writing.

- nowhere in the abstract or introduction does confusion between NAT or
NAT-traversal come into play with firewalls; I'm unclear as to why section 1.2
exists?

- section 2, Detecting the loss of NAT mappings, the document introduction
states that the document itself will be telling me different things, but I find
this section a little lacking in definitiveness.  For example, ".... it may be
the result of a middle box blocking the traffic." OK, it MAY be - so what else
could it be, and how would I know when it IS the middle box blocking the
traffic? Or, consider, "However, for a receiver to be more certain <snip to end
of paragraph>, it is likely the RTP mapping has been removed." I get it,
likely, but that's not definitive either. Are there other reasons that this
might happen and how would I attribute the outcome to which scenario?

- Section 3 could be a little clearer. I think you bring up a fantastic use
case, where the RTSP server is behind a NAT - and then you reject it. This use
case is buried inside of a paragraph where the sentences before and after it
are what you want to handle. I'd prefer, for readability, that this be broken
into clear(er) sub sections.  With my product management hat on, when I see a
section called "requirements on solutions" I expect to see the use case, the
solution, if known, and the requirements - all items you have - but jumbled
together. Consider calling out the use case you plan to cover, with it's
requirements and possible solutions, and the use case that you find to be
specifically out of scope. As a reader, I don't want you to make me work for
it. :)

- Section 3: Having said that, what IS the use case you're attempting to solve?
:)

- Section 3, item 3, I think the RTSP dual-hosting concept and explanation
warrants a bit of conversation prior to sticking it into a requirements list,
particularly when that requirement says that there should be minimal impact on
clients, and the whole concept of dual-hosting seems non-trivial.. consider
pulling the dual-hosting discussion out of list item 3, and introducing it in
the paragraph(s) prior to the enumerated requirements. Doing this would greatly
simplify your #3 requirement AND be clear, as the concept would be previously
introduced.

- Section 3, item 4: I like your ask of "should be simple to use <snip>, so
people actually turn them on" - but you assume the reader has all of the back
story. Why aren't they turned on today? Again, requirements should be clear -
the conversation around WHY this requirement is here in the list should have
already happened in the document up until this point, IMHO.

- Section 4, "the main evaluation was done prior to 2007 <snip>." WHAT main
evaluation? I have no idea what's being discussed here, and am left with the
lingering thought that a scant 7 years have passed since then and I'm wondering
if that's really OK and whatever the evaluation is, is it still relevant? For
example, what happens with CGN?

- Section 4: this section too suffers from a lack of what's IN and OUT of
scope. Its fine to reject some techniques, but call them out, or, call out the
ones you plan to focus on in the document.

- Section 4.1.2 - since I've been nit picking away, I thought this section's
methodology was very well written. Good job!

- Section 8: I appreciate that each of the techniques in the previous sections
dealt with their security implications, and I appreciate the roll up here too.

Editorial nits:

- Section 1, Introduction, replace "This type of firewalls can .." with "This
type of firewall can .."

- Section 1, Introduction, consider replacing "This document is capturing the
evaluation done in the process to recommend firewall/NAT traversal ... <snip
through end of sentence>" with: I'm not entirely sure what's trying to be said
here. Are you saying you did some testing/evaluation of NAT-traversal methods
and this document will outline some recommendations? Consider revising this
entire first sentence.

- Section 1, Introduction, consider replacing "At the time when the bulk of
work on this document was done, a single level of NAT was the dominant
deployment for NATs, and multiple level of NATs, including CGNs..." with "At
the time when the bulk of work on this document was written, a single level of
NAT was the dominant deployment for NATs. Multiple levels of NATs, including
Carrier Grade NATs (CGNs), had only been partially considered." (also, consider
bringing the next paragraph into this one. Otherwise, you're stating what seems
to be a problem you want to address, and then you don't address it - I find
myself wondering "OK... so what? What's the point here? Are you going to do
something about this?"

- Section 1.1, Network Address Translators, consider replacing "... concering
NATs and their terminology:" with "... concerning NATs and their terminology:"

- Section 1.1, Network Address Translators, are paragraphs 4 and 5 quotes from
RFC 4787? I can't quite tell where the quote ends, and your commentary begins.
Consider revising the quote (and use of double quote marks to denote this
quotation - you could use the quotes, although be clear with them, and
potentially denote the quote with an additional font change, such as italics,
to make it very easy to see where the quote beings/end and your commentary
starts).

- Section 1.3, Glossary, if you're going to call out RFCs for some glossary
items (like ICE) then you might consider being consistent and doing it for all
of them (like DNS).

- Section 3, #3, first sub bullet: consider replacing "till arrival of media"
with "until arrival of media"

(stopping here, but I'm happy to help/get on a call/mark up your text if you'd
like an outside eye to review. I'm not offended should you decline. :))