Thanks Tom.
We started thinking in our Intro about firewalls, and in the process
picked up a lot of text on NATs. We *did* intend to write in terms of
DCCP client and server, so let us know what we got wrong.
We could be happy to split the NAT stuff towards the NAT draft, when and
if that is adopted somewhere. I'm going to suggest the work on ICE, etc
is really a BEHAVE issue, so we focussed only on the DCCP-specific
aspects. I'd be pleased to talk more and take any questions - on the
list or in the WG meeting.
Gorry
Phelan, Tom wrote:
Hi Gorry,
Interesting draft and at first look it looks like a pretty good solution
to the problem of getting a connection from outside a NAT to inside. I
found the intro (section 1) more confusing than helpful. First, the
terms client and server are not used per the DCCP definition. That
becomes apparent near the end of the intro, but it causes confusion
early on.
Also, I feel that the intro brings up issues that are peripheral to
what's being solved, and leads to confusion about what the intent of the
draft is. If the intro were more focused on the main problem I think
it'd help.
That being said, I'm wondering if the draft solves enough of the total
problem to be useful. The part I'm thinking of is how a device behind a
NAT discovers its public address.
>
That seems to be part of the
out-of-band signaling precursor you talk about and I understand your
desire to separate that part of the problem.
But it seems to me that for this mechanism to be really useful you also
need to have that public address discovery. That could be done in a
different draft (and maybe there's an ICEish thing that applies), but I
think that we'd need both to move forward together.
Tom P.
