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

[Fred Templin <osprey67@yahoo.com>]

Seeing how this is the first use of the issue template, I

suppose I'll go ahead and take the distinction of being

the first one to complain about it.

 

I disagree with the suggestion about adopting the RFC 2472,

section 4.1 language for interface identifier construction, and

don't believe it's worth the MECH authors spending any time on.

But, now that it has been conveniently placed in the "issue tracker"

form, does that mean that the authors are obligated to dig into

the details and respond?

 

This is the very concern I was expressing in my earlier message

in terms of "issue overload" - shouldn't we be discussing the issues

on the list first so that there can be some first-pass filtering before

bogging down the authors?

 

Thanks - Fred

osprey67@yahoo.com

itojun@iijlab.net wrote:

> [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.