Subject: [BEHAVE] Minor concern about one of the milestones

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Aug 2007 11:51:00 -0700

One of our milestones is

Submit standards-track document that describes how an application can  
determine the type of NAT it is behind

I think it is very hard for an application to reliably do this except  
under environments where all the traffic to the NAT is controlled.  
(Basically this was the general limitation of RFC 3489). I hope that  
the document for this milestone is more an approach to characterizing  
and testing behavior of NATs and is not a general suggestion that an  
application might be able to figure out what type of NAT it is behind  
then modify the applications behavior based on the type of NAT is is  
behind. I seem to recall the old milestone was more along the lines  
of testing but I can not find a copy of it.

Cullen <with my individual hat on>

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Aug 2007 09:24:58 -0400

I think there was consensus in the room in chicago to make this either 
informational or experimental.

-Jonathan R.

Cullen Jennings wrote:
> (Basically this was the general limitation of RFC 3489). I hope that the 
> document for this milestone is more an approach to characterizing and 
> testing behavior of NATs and is not a general suggestion that an 
> behind. I seem to recall the old milestone was more along the lines of 
> testing but I can not find a copy of it.
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Aug 2007 10:31:17 -0700

I expect to finish the BEHAVE minutes today, but the relevant part
of the minutes from this discussion in Chicago is below. 

I'd like to make sure the mailing list agrees with removing 
draft-ietf-behave-behavior-discovery and its associated milestone
from standards track.  This means the document status (and 
associated milestone) would change to Experimental or change
to Informational.

  (Per the minutes, below, Bruce and Derek will be preparing
   text and we will decide, as a separate action, if it should
   be Informational or Experimental.)

If you have objections to making draft-ietf-behave-behavior-discovery
a non-standards-track document, please reply to this email.

-d

-----

excerpt from BEHAVE's IETF-69 minutes (not yet published):

...
    * Current draft is proposed standard.  Bruce suggests this
      should be demoted to Experimental.  It's important to have
      a document that explains what was broken about RFC3489,
      and why it was broken.  Still some value in diagnosing how
      NATs work.

    comments on Experimental:

    Remi: The only protocol I'm aware of that does this is
    Teredo, which has its own mechanism, so it's not affected by
    this proposed change.

    Philip:  is anyone using behavior-discovery?

    Bruce:  if anyone needs this functionality, they're doing
    RFC3489.  Bruce knows of 3 people using this, and what
    they're doing is trying to determine if they need a relay
    server.  In some cases, where they know who they will be
    communicating to, this works fine.  In other cases, they
    aren't using it appropriately.  I want to strenghen the
    applicability statement to  make this clearer.

    Philip:  The one interesting use, which could be hurt by
    making this Experimental, is to diagnose problems in running
    ICE.  p2p-sip might be hurt by this lack of diagnostics.

    Bruce:  p2p is one possible application that could benefit
    from behavior-discovery -- with enough tests, you could
    perhaps determine if you could be a superpeer.  However, such
    a determination would be experimental at this point.

    Philip:  How quickly do we need to decide if this should be
    experimental.

    Jonathan:  I think the change to Experimental is appropriate,
    and anything using this is unreliable.  It's the difference
    between working 95% and
    99.99% of the time.

    Magnus:  There are grounds for defining this as an experiment
    and deciding how well this works before moving forward.  "Do
    we have an experiment". It seems we do have one.

    Bruce:  Today this is useful for diagnostics and
    instrumentation.  We do not have a clear view on how this can
    be useful for changing application behavior.

    Francois Audet:  This should be Informational, not
    Experimental.  People have used techniques like this for a
    long time, even before STUN, to detect bad NATs.  The fear is
    people will look at behavior-discovery and say "this is
    easier than ICE, let's use it", but making it Experimental
    won't necessarily accomplish that goal.  It certainly doesn't
    belong in standards-track.

    Dan asked for hum on standards-track:  a quiet, yet strong
    consensus to demote away from standards-track.

    Bruce:  we'll adjust the applicability statement and bring
    that to the list.
...

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Aug 2007 11:46:08 -0700

ok - I certainly understand making it informational but on  
experimental, I would ask what is the experiment? If the experiment  
is "can an application with a single IP behind a NAT reliably predict  
the NAT behavior?", well then I think we already know the answer to  
this experiment. Anyways, I was not in the room so sorry for missing  
the discussion around this.

Cullen

On Aug 14, 2007, at 6:24 AM, Jonathan Rosenberg wrote:

> I think there was consensus in the room in chicago to make this  
> either informational or experimental.
>
> -Jonathan R.
>
> Cullen Jennings wrote:
>> One of our milestones is
>> Submit standards-track document that describes how an application  
>> can determine the type of NAT it is behind
>> I think it is very hard for an application to reliably do this  
>> except under environments where all the traffic to the NAT is  
>> controlled. (Basically this was the general limitation of RFC  
>> 3489). I hope that the document for this milestone is more an  
>> approach to characterizing and testing behavior of NATs and is not  
>> a general suggestion that an application might be able to figure  
>> out what type of NAT it is behind then modify the applications  
>> behavior based on the type of NAT is is behind. I seem to recall  
>> the old milestone was more along the lines of testing but I can  
>> not find a copy of it.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Aug 2007 23:01:53 -0700

When Derek and Bruce finish their applicability text, we may know
better if this is, in fact, something we can declare as an Experiment
(hopefully with exit criteria), or if this would be Informational.

(That is, as long as we have consensus around removing the document
from standards-track!)

-d

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2007 11:46 AM
> To: Jonathan Rosenberg
> Cc: Behave WG
> Subject: Re: [BEHAVE] Minor concern about one of the milestones
> 
>