mech-v2-05pre

[Pekka Savola <pekkas@netcore.fi>]

Hi,

(editor hat on)

It appears that there is at least some form of support of clarifying
the text to more clearly state that the tunnel entrypoint should be an
IPv4 address of the encapsulator. However, there are reasons (e.g., as
Stephen mentioned) why checking this at configuration time might not
be beneficial, and others also think this is an implementation detail.  
Therefore, I've opted for doing just simple clarifications, and
leaving the rest as implementation details.

This is not felt to be sufficient, I guess the only alternative would
be to add a new 3.x section which discusses the
configuration/operational aspects of tunnels, and certain
implementation approaches (e.g., the operational status of the tunnel
based on routing information, etc.).. but IMHO that's beyond the scope
of a protocol spec.

Please see proposed text at:

http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05pre-diff.html

Note: there have been no changes relating to sending ICMPv4 messages
for unconfigured tunnels.  That issue has already been closed long
time ago, with good reasons to have it the way it is now, and there is
no reason to repeat it now.

Is this a sufficient resolution to the concerns voiced in the WG?
Please speak up (on- or off-list) within a couple of days.

(editor hat off)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings