| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
OK. It looks like we are in synch.
One minor point: I believe that you may also want to list NSIS
in your list of NAT control protocol that are out-of-scope.
> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx]
> Sent: Friday, February 18, 2005 03:38
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: Re: [Ietf-behave] New draft: Application Design Guidelines
>
>
> On Thursday 17 February 2005 20:36, Francois Audet wrote:
> > Good job. This is great.
>
> Thanks! :)
>
> > Some minor comments:
> >
> > - Section 1.2: More importantly than "so far none of these
> protocols have
> > become widely accepted", it should be stated that it may
> not be feasible
> > or desireable in many architectures to have the
> application controlling
> > the NAT.
>
> Sounds good. How about this rewritten Section 1.2:
>
> 1.2. Explicit Communication with NATs
>
> Several protocols exist that allow applications to obtain external
> communication endpoints through explicit interaction with
> NATs in the
> path [SOCKS, RSIP, MIDCOM, UPNP]. None of these protocols have yet
> become widely accepted, however, and in many network
> scenarios it may
> not be feasible or desirable for applications to identify,
> locate, or
> control NATs in their communication path. This document therefore
> leaves such protocols out of scope, focusing exclusively on NAT
> traversal techniques that do not require the application to
> communicate explicitly with NATs in the path.
>
> > - It's a little unclear to me what REQ-6 is trying to say.
>
> REQ-6 is admittedly a little vague at the moment, and perhaps
> should be either
> made more specific or removed. One particular thing I had in
> mind when
> writing this requirement was that if an application wants to
> subject NATs in
> the path to a long complicated battery of tests in order to traverse
> symmetric NATs and such, the application ideally shouldn't
> force the user to
> wait until all these tests are done before even being able to
> traverse
> BEHAVE-compliant NATs. In other words, the task of gathering
> information for
> or setting up fancy non-BEHAVE traversal procedures shouldn't
> unduly delay
> the operation of the simple BEHAVE traversal procedure over
> BEHAVE-compliant
> NATs.
>
> But this probably isn't a very critical issue, and if we
> can't come up with a
> clear way to state it, I would be happy with eliminating at least the
> "formal" recommendation and just leaving the informal
> discussion text in the
> body of 2.5.
>
> > - Need a value for XX in REQ-7. Something smaller than half
> of 2 minutes
> > (to match nat-behave). My guess is 30s. We could also talk about
> > detecting
> > the timeout. I think that there were text about that in
> either STUN
> > or ICE,
> > I forget. In any case, should be marked as "opened issue" for now.
>
> Sure. 30s sounds reasonable to me. This keepalive period
> would obviously be
> too long for some existing NATs that have timeouts as short
> as 20 seconds,
> but 20 seconds is so unreasonably short that we can probably
> just classify
> such NATs as "broken" and assume the NAT-BEHAVE timeout.
>
> I also agree that we probably need some text discussing
> timeout detection,
> though it's not yet obvious to me what the specific
> recommendation(s) should
> be on that. I'll take a look back at STUN and ICE; thanks
> for the pointers.
>
> > Also, we probably need to add some material on RTP/RTCP usage. For
> > example, we need to discuss the fact that if RTP/RTCP address/port
> > pairs do not respect the parity and contiguity rule, the
> application
> > MUST list them separately (and not derive them
> algorithmically). Also,
> > that if they are advertized seperately, media must be sent to those
> > addresses, and rules on substracting one (as per RFC 3550 do not
> > apply). Maybe list RFC 3605 as as the mechanism used by SDP to list
> > them separately.
> >
> > I agree with Dan on the symmetric RTP draft being folded in.
>
> Yes, these suggestions all sound good to me. Since (as I
> mentioned to Dan)
> I'm not yet very familiar with RTP/RTCP, would you guys mind
> providing some
> initial text on this topic to be added to the draft?
>
> Thanks,
> Bryan
>
>