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 , 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 , 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 ." 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 ... " 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. :))