Skip to main content

Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
draft-ietf-behave-dccp-05

Yes

(Magnus Westerlund)

No Objection

(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Pasi Eronen)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
(was Discuss) No Objection
No Objection (2008-11-05) Unknown
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 IESG member
No Objection
No Objection (2008-11-05) Unknown
Support Tim's Discuss
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection (2008-11-06) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2008-11-06) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2008-11-05) Unknown
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,/
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown