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

From: [email-masked]
Date: Tue, 11 Nov 2003 04:30:20 +0900

[Document] draft-ietf-v6ops-mech-v2-01.txt
Submitter name: itojun
Submitter email address: [email-masked]
Date first submitted: Sat,  8 Nov 2003 07:02:22 +0900 (JST)
Reference: <[email-masked]>
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.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Nov 2003 01:13:57 +0200 (EET)

On Tue, 11 Nov 2003 [email-masked] wrote:
[...]

Filed:

https://rt.psg.com/Ticket/Display.html?id=236

(took some trying, but managed in the end.)

Now, all we have to do is wait for the editor's proposed resolution.

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 10 Nov 2003 20:36:50 -0800 (PST)

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
[email-masked]

[email-masked] wrote:

reasons:

Requested change: 
resolution 1:

resoltion 2:

resolution 3:

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Nov 2003 15:28:48 +0200 (EET)

On Mon, 10 Nov 2003, Fred Templin wrote:
[...]
> bogging down the authors?

I'm not sure what's your specific concern here.

To clarify, we're not recording discussions in the issue tracker.  Any 
follow-up comments etc. are done on the list.  The document editor, then, 
at some  point, proposes a resolution to the issue.  That is also 
discussed on the list.  The resolution is recorded in the issue tracker.

I fully support first discussing the issues on the list.  That's fine, and 
that's why there is the "Reference" field in the template.

Remember, the issue tracker is not meant to be an exclusive tool in the 
document improvement process.  It's mostly aimed to be a tool where the 
submitter of an issue wants to get the issue formally recorded, and taken 
care of, using a process.