Subject: [BEHAVE] New revision of behavior-discovery submitted

From: Derek MacDonald <[email-masked]>
Date: Sun, 27 Sep 2009 23:36:24 -0700

Hi all,

I've just submitted a version of behavior-discovery:
draft-ietf-behave-nat-behavior-discovery-08.txt. I don't see the new rev in
the tracker yet.

 Important changes to the document as described below; inline with text from
original comments which led to the changes.

Cullen Jenning:
>
> Discuss:
>
> The usage of RESPONSE-TARGET seems like it would only need to allow
> the response port, not IP address to be changed. This would improve
> the security situation. Why is the IP address allowed to change?
>

XOR-RESPONSE-TARGET is now RESPONSE-PORT. This also greatly simplified the
security considerations. CACHE-TIMEOUT and XOR-REFLECTED have been removed.

Dan Romascanu
Discuss:
> 1. The document presents as principal usage of NAT behavior discovery
> network diagonstics for 'network administrator or system programmer
> trying to determine the causes of network failure; particularly when
> behavior varies by load, destination, or other factors that may be
> related to NAT behavior'. This almost sounds like another OAM layer,
> or duplicating the OAM layer functionality. It is not clear however
> how this is going to be activated, will this run permanently or on
> demand, how are results being collected by an operator using discovery
> as a diagnostics tool
>
Behaviour-discovery is meant to be an applictation level mechanism. It will
be up to applications using this mechanism to determine how aggresively it
will be used, and if diagnostics will be recorded or if it will just be used
to adjust application behaviour.

>
> 2. I do not understand well what 'experimental success' section 2.3
> refers to. This is not about the success of the experiment of the
> discovery method, but rather about whether an application can improve
> its behavior. Using the 'Experimental Success' title for this section
> is confusing.
>
Success is defined as an improvement over existing behvaiour; there could be
varying levels of success. I couldn't think of a better phrase or any
percentage based metrics that have good provenance.

>
> Comment:
> At the end of Section 1:
>
>   If a draft specifies the use of any portion of this STUN usage, that
>   draft MUST document
>
Changed to "standards document"

Tim Polk
>
> It seems clear that two of the conditions for NAT behavior discovery
> to be generally
> useful are
> (1) detecting the "correct" information a reasonably high percentage
> of the time; and
>
The percentage of time that "correct" information is required will vary
greatly from application to aplication, so no one value could be selected.

> (2) unambiguous determination that the fallback mechanism should be
> invoked.
>
This is cleared up the the section describing referencing standards.

Lisa Dusseault
> Comment: [IESG Evaluation DISCUSS]
>
> This is a good document & I have a few comments. Most of the comments are
> minor; the question about discovering a STUN server with this new usage
> supported is probably the biggest issue. But it's probably not a blocking
> issue, so I plan to clear this DISCUSS and let the authors handle this
> input as
> they will, after getting a chance to discuss on the telechat.
>
> There is an unambiguous mechanism when SRV is used; when it isn't used, it
would seem that we might need to add an attribute to a Binding Response to
solve this problem. However, 5389 support can be determined, as can support
for PADDING and RESPONSE-PORT, so it might not be necessary. Personally, I
don't have a strong opinion on this either way.

I also incorporate a fair bit of the suggested text for Section 1 and the
other changes for 2, 3.6 and 7.3 from
https://datatracker.ietf.org/idtracker/draft-ietf-behave-nat-behavior-discovery/comment/99576/
.

-Derek