draft-ietf-v6ops-mech-v2-01.txt (first use of template!)

[itojun@iijlab.net]

[Document] draft-ietf-v6ops-mech-v2-01.txt
Submitter name: itojun
Submitter email address: itojun@iijlab.net
Date first submitted: Sat,  8 Nov 2003 07:02:22 +0900 (JST)
Reference: <20031107220222.A55C993@coconut.itojun.org>
Comment type: T
Priority: SHOULD
Section: 3.7
Rationale/Explanation of issue: 
	suggestion in section 3.7 (quoted below) is unneecessary, or seems
	too strong.

	reasons:
	- coupling link-local address with tunnel endpoint IPv4 address makes
	  it harder to switch tunnel endpoint IPv4 address - reconfiguration
	  of IPv6 link-local address (usually used for nexthop) is needed.
	  therefore i prefer them to be separate.  it is from my long
	  operational experience.
	- RFC2472 section 4.1 has better way to generate interface ID.
	- SHOULD is too strong as the use of different selection algorithm
	  of link-local address here does not impose any interoperability issue.

	RFC1933 did not have such requirement (SHOULD).  RFC2893
	introduced this.  i did voiced my concern but was not integrated into
	RFC2893.

>   The Interface Identifier [RFC2373] for such an Interface SHOULD be
>   the 32-bit IPv4 address of that interface, with the bytes in the same
>   order in which they would appear in the header of an IPv4 packet,
>   padded at the left with zeros to a total of 64 bits.  Note that the
>   "Universal/Local" bit is zero, indicating that the Interface
>   Identifier is not globally unique.  When the host has more than one
>   IPv4 address in use on the physical interface concerned, an
>   administrative choice of one of these IPv4 addresses is made when
>   forming the link-local address.
 
Requested change: 
	resolution 1:
	remove the 3.7 paragraph 2, paragraph 3, and figure.

	resoltion 2:
	change SHOULD on 1st line of paragraph 2 line to MAY.

	resolution 3:
	change SHOULD on 1st line of paragraph 2 line to MAY.
	add reference to RFC2472 section 4.1 as an alternative.