Agree with Russ that this document should be INFORMATIONAL

I agree with Russ's DISCUSS concerning the classification of
this document as BCP. Informational seems more appropriate.

===

Why does REQ-1 not also specify  draft-ietf-behave-sctpnat-06?

===

Limiting the rate of allocation is intended to prevent
      against CPU resource exhaustion.

d/against/

====

REQ-12:  A CGN SHOULD NOT log destination addresses or ports.

   Justification:  Destination logging at the CGN creates privacy
      issues.  

Why is this not "SHOULD NOT log destinations addresses or 
ports unless required to do so for administrative reasons"
followed by  privacy advice?

As much as the IETF finds it distasteful, this sort of logging
may well be administratively required at number of levels, 
and we should deal with minimizing the privacy issues
when this happens.

====

I'll trust the ADs who reported the DISCUSSes to solve the issues. Note that I'll have a closer look at the next version

I agree with Ralph and Russ

I still don't get why you need a MUST in REQ-4 for per-subsciber
limits. Seems over contstrained to me.

1. In section 3, the text states "If NAT behavioral requirements documents are created for additional protocols, then these new documents MUST update this list by adding themselves to it."  Do these new behavioral requirements documents need to update this document?  Does this document need to be updated each time a new behavioral document is published as an RFC?

2. For REQ-6, what is the impact of disabling translation on state tables within the NAT?  If no state is maintained, is there a DoS vulnerability for the client?  For example, if I know that traffic from X2:x2 --> X1:x1 is not translated, could I use that knowledge to attack the client?

3. REQ-8 recommends not re-using a port until 120 seconds elapses.  Is that value applicable to all transport protocols?  How do you envision a CGN enforcing that value after a crash (as mentioned in the last paragraph of the requirement justification)?

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- REQ-5 --
      It is at the SHOULD level to account for the
      fact that means other than rate limiting may be used to attain the
      same goal.

It seems, then, that there is a higher-level requirement that's missing, and that this "requirement" is really stating a suggested means to achieve it.

UPDATE: Simon explains that "It" in the above quotation refers to list item B only.  I'm requesting that he change "It" to "Item B" to make that clear.

      This state consumes resources for which, in the
      case of a CGN, subscribers may compete.  It is necessary to ensure
      that each subscriber has access to a fair share of the CGN's
      resources.  Limiting TCP sessions per subscriber and per time unit
      is an effective mitigation against inter-subscriber DoS attacks.

UPDATE: Simon also explains that the last sentence in the paragraph above needs to be removed.

For the IESG: Perhaps I'm just being contrarian today, but I *do* think this document should be BCP and not Informational. It is not a requirements document in the sense that it is laying out requirements for future protocol documents being developed by a WG; it is a consensus document listing the requirements for the operation and administration of a type of device. If that doesn't fall within the 2nd paragraph of RFC 2026 section 5, I don't know what does.

For the authors/WG: I agree with Stephen's point about REQ-1, but disagree with the solution suggested on the IESG list; I think it reversed the sense of the statement. You had:

OLD:

           If NAT behavioral requirements documents are created for
           additional protocols, then these new documents MUST update
           this list by adding themselves to it.

NEW:

           Any future NAT behavioral requirements documents for IPv4
           transport protocols will also need to consider the
           requirements for CGNs stated here.

But this loses the sense that new NAT behavioral requirements documents will impose new requirements on CGNs. Might I instead suggest:


           Any future NAT behavioral requirements documents for IPv4
           transport protocols will impose additional requirements for
           CGNs on top of those stated here.

The requirement is not a requirement for future documents; it's a requirement for CGNs.

I share Ralph's question about how this updates RFC4787.

It worries me that we are requiring the implementation of a new protocol (pcp) as part of a BCP.
It would be more work to write "you need to do all the things pcp lets you do", but it would be more in the spirit of RFC4787 to have done so.

Thank you for addressing my issue.

s4: Because you gave an out in the previous paragraph it's worth noting in the following that one reason might be that the CGN isn't following 6302:

  This requirement is at the SHOULD level to account for the fact
  that there may be other reasons for logging destination addresses
  or ports.