Hi there,

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC  tsv-dir@ietf.org if you reply to or forward this review.

**Executive Summary:
This draft has serious issues, described in the review, and needs to be rethought.

**Review comments:

*General
- There is no place where the prior work of MIDCOM is mentioned.
Is this intentionally and did the WG not know or consider prior work of the IETF?
MIDCOM is going beyond what this draft is specifying, as it also includes firewall control, plus some further features, such as learning about the interfaces used for the MIDCOM server. 
What was the reasoning to not reuse MIDCOM or semantics developed for MIDCOM?

- The usage of RFC 2119 is missing in parts of the draft, e.g., the text in Section 4 seems to be meant as mandatory but there is almost no RFC 2119 language. 
- Is the DNCA able to allocate 2 consecutive transport ports? This is sometimes required by legacy RTP/RTCP applications. 

* Detailed review
- Section 1, 1st paragraph, a nit:
"... in their networks to deal with the depletion of available public IPv4  Addresses". This is one reason out of many. NATs are around for 10+ years, i.e., way before we were about to run out of IPv4 addresses. 
- Section 2, and rest of the document:
The terminology used in this draft is not well documented. There are NAT bindings, NAT binding rules and predefined NAT binding rules (templates?). However, the difference is not well documented, even though I understand the difference. How do you name a NAT binding which is actually used by a data exchange?
- Section 3.1, page 8, 1st paragraph,  "to increase the efficiency of the global IPv4  address pool utilization.":
Not sure that this setting is only used for this use case. How about just writing:
"Figure 2 depicts the deployment scenario where a service provider places a NAT between the host and the public Internet."
- It would be good to cite RFC6144-6147 for 6to4 to indicate on what basis the address family translation is working in this draft. The same holds true for IPv4. 
- IPv6 to IPv4 translation: I was not able to figure out how such a signaling would be. There are no examples for this or guidance at all. 
- IPv4 to IPv4 translation: It would be good to have one or some few examples to see how such DNCA messages would look like. 
- All figures: The figures are not especially meaningful for the reader and do not help in my opinion to understand the protocol, but do not hamper understanding either. 
- Section 4.2, page 15, last bullet point starting with "If a NCR redfines...":
This touches a critical point of what happens if the new number of allowed bindings is lower than the prior selected number of allowed bindings. The text is not giving a good guidance of what should happen in this case and I see it a weak point to let this open to the discretion of the implementation. For a good specification I would at least expect a RECOMMENDATION or SHOULD, better a MUST. However, this comment relates to the lack of RFC 2119 language in this section. 
- Section 4.2, page 16, bullet point "If a NCR specifies a new...":
What happens in this case with already binding rules which are installed and actively used by a data session? Is the data session stopped and the binding removed?
- Section 4.3, page 17, bullet "2. Retrieve...":
How does the DNCA peer with the NAT controller know about the available external IP addresses at the NAT? This is not clear to me. Is this a feature of another DIAMETER application or is it assumed that the controller just knows this somehow?
- Section 4.4, 1st paragraph, "In response, the DNCA...":
I cannot understand this sentence.
- Figure 8: The text belonging to this figure does not mention that the NAT bindings MUST be removed if the STR is received. This is only shown in the figure. The text seems to be incomplete and also lacking RFC 2119 language. 
- Section 4.6, 1st paragraph: What is the redundancy support mentioned there which is mandatory? Something which is a MUST must be well documented. I cannot see this here. 
- IANA section and IANA points in text:
The use of TBD throughout the draft for IANA code-points and also in the IANA section is harmful for IANA and also for the draft at best. Why are you not using meaningful identifiers for code-points and reference them in the IANA section? The use of generic TBD placeholders will just create confusion for IANA and for you.
- Section 6.1 and 6.2: I was surprise to see the list of parameters which can be included in requests and responses, after reading Section 4, where those parameters are omitted. Given all these parameters and the lack of explanation in the draft, it seems to be hard for an implementer to get the link between Section 4 and this. This needs further explanation in the draft, see also my comment about how IPv6 to IPv4 translation works and about the missing usage examples.
- Section 8.x, broken labels of the tables:
The figures in Section 8.x are actually tables, i.e., their description is incorrect and broken. 
- Section 8.5, Figure 13, "Reused QoS-attributes":
Why are the AVP codes set to TBD if they are taken from RFC 5777? E.g., Direction AVP (AVP Code 514) but not TBD!


Kind regards

  Martin Stiemerling

martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014