Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
RFC 5597

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert No Objection

Section 2., paragraph 2:
>    invidual DCCP flows, as uniquely identified by the quadruple (source
  Nit: s/invidual/individual/

Section 6., paragraph 1:
>    needed for an ALG to function.  Additionaly, there are no known DCCP-
  Nit: s/Additionaly,/Additionally,/

Section 7.2., paragraph 1:
>    REQ-8: A NAT MUST support "Hairpinning" for DCCP.  Futhermore, A
  Nit: s/Futhermore,/Furthermore,/

(Magnus Westerlund; former steering group member) Yes

(Chris Newman; former steering group member) (was Discuss) No Objection

I recommend fixing this:

  "REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP."

Does "it" refer to the NAT or to the ALG?  I presume the latter but
that's not clear from the grammar.

(Cullen Jennings; former steering group member) No Objection

Support Tim's Discuss

(Dan Romascanu; former steering group member) (was Discuss) No Objection

The document completly lacks requirements or any manageability consideration for the NATs that support DCCP. I assume that a network operator should have means to understand what is the support provided by the NAT and what modes are implemented and can be configured on a given device. What is the minimal mode and status information that needs to be exposed to an operator by a NAT supporting DCCP and how is this information accessed and configured on a NAT device?

(David Ward; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

Christian Vogt's review:

I was asked to review draft-ietf-behave-dccp-04 as input for IESG
evaluation, and I got three comments:

(1) On the abstract:

        Developing NATs that meet this set of requirements will greatly
        increase the likelihood that applications using DCCP will
        function properly.

    Sounds a bit like DCCP would work well only if we develop NATs. ;-)
    Better reword to:

        Ensuring that NATs meet this set of requirements will greatly
        increase the likelihood that applications using DCCP will
        function properly.

(2) On requirements 1 and 3:

        REQ-1: A NAT MUST have an "Endpoint-Independent Mapping"
        behavior for DCCP.

        REQ-3: If application transparency is most important, it is
        RECOMMENDED that a NAT have an "Endpoint-independent filtering"
        behavior for DCCP.  If a more stringent filtering behavior is
        most important, it is RECOMMENDED that a NAT have an
        "Address-dependent filtering" behavior.

    These requirements are general and not specific to DCCP.  Would it
    make sense to specify them in a separate RFC for NATs in general,
    independent of any specific transport protocol?

(3) On requirement 6:

        REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP.

    This requirement is not 100% clear.  I am assuming it means:  "If a
    NAT includes ALGs, the NAT MUST NOT affect DCCP packets that are
    processed by one of those ALGs."  Suggest to reword the requirement
    in this way.

(Jon Peterson; former steering group member) No Objection

(Lisa Dusseault; former steering group member) No Objection

(Mark Townsley; former steering group member) No Objection

(Pasi Eronen; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection