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.

Magnus Westerlund Yes

(Jari Arkko) No Objection

Comment (2008-11-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2008-11-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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,/

(Pasi Eronen) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

Comment (2008-11-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Support Tim's Discuss

(Chris Newman) (was Discuss) No Objection

Comment (2008-11-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2008-11-06)
No email
send info
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?

(Mark Townsley) No Objection

(David Ward) No Objection