Hi Gorry, What I meant to suggest is that I see this draft as a part of a bigger picture -- a picture that might be split between DCCP and BEHAVE, sure. I hope we can have a good discussion about NAT issues tomorrow. As far as client/server confusion, for example, scenario 2: "2. Public server connects to private client." This seems to imply that the server initiates the connection, which doesn't happen in DCCP. Now with your later changes that gets somewhat grey, but it's confusing in the beginning. Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Tuesday, December 04, 2007 8:24 PM > To: Phelan, Tom > Cc: 'dccp' working group > Subject: Re: Comments on draft-fairhurst-dccp-behave-update-01.txt > > > 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. > > >
