Re: Review of draft-ietf-behave-dccp-04

On Friday 07 November 2008 13:00:19 ext Christian Vogt, you wrote:
> > Whether it's of any use depends on the connection model (or lack
> > thereof) of
> > the transport protocol. I don't want to presume that this would make
> > sense
> > for all future transport protocols. [...]
>
> I don't agree.  A reason for recommending endpoint-independent mapping
> and filtering is to enable applications to refer each other to a host
> behind a NAT. This is desirable independent of the transport protocol.

But whether this is useful depends on the transport protocol and/or connection 
model. It does help for unicast UDP (and UDP-Lite). It does help for TCP, 
only if simultaneous open is supported by the application, the operating 
system and the middleboxes. If does help for DCCP _only_ if the DCCP stack 
implements the simultaneous open option, which is _not_ in the baseline DCCP 
document.

It does not help with, e.g. multicast UDP. It does not mean anything for 
port-less protocol, including ICMP, proto-41, etc. It is insufficient for 
SCTP. Who knows how it applies to would-be future transports?

Besides, I think it's too late for a "factorized" BEHAVE specification. Good 
news: we have much of the baseline in the BEHAVE-UDP RFC. The other documents 
already borrow quite a lot from it, especially the general concepts and 
terminology.

> >          REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP.
>
> Make it even clearer:
>
>            REQ-6: If a NAT includes ALGs, the ALGs MUST NOT affect DCCP.

Right.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf