Subject: RE: RFC2461(bis), section 6.3.6

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Apr 2006 12:50:38 -0700

Fred

I assume you're referring to this :

   1)   Routers that are reachable or probably reachable (i.e., in any
        state other than INCOMPLETE) SHOULD be preferred over routers
        whose reachability is unknown or suspect (i.e., in the
        INCOMPLETE state, or for which no Neighbor Cache entry exists).
        Further implementation hints on default router selection when
        multiple equivalent routers are available are discussed in
        [LD-SHRE].

Can you please elaborate on what this change will do and why it is more 
inclusive? just trying to understand. 

I'll add in the reference for [LD-SHRE], thanks. 

Hesham

________________________________

	From: Templin, Fred L [mailto:[email-masked]] 
	Sent: Wednesday, April 19, 2006 11:57 AM
	To: [email-masked]
	Subject: RFC2461(bis), section 6.3.6

	I would like to see something a bit more inclusive in
(RFC2461(bis),
	section 6.3.6) for default router selection when not all routers
on the
	link are equivalent, e.g., when a wireless host sees routers
with
	varying link quality. Suggestion is to simply change:
	 
	   INCOMPLETE state, or for which no Neighbor Cache entry
exists).
	to:
	   INCOMPLETE state, for which no Neighbor Cache entry exists,
etc.).
	 
	This could either go in the next draft version or as an AUTH48
item.
	(Also the reference for [LD-SHRE] is missing.)
	 
	Fred
	[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Apr 2006 13:19:37 -0700

Hesham,

Yes, this is the passage I am concerned with. The point is
that (in some environments) not all routers on the link will
be equivalent, e.g., some routers may exhibit better QoS than
others due to different signal-to-noise ratios, queue lengths,
etc.

In those cases, hosts may prefer some routers over others
for reasons that are not related to: "...in the INCOMPLETE
state, or for which no Neighbor Cache entry exists". Adding
the "etc" allows for other cases in which reachability of
some routers is "suspect".

Fred

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]] 
Sent: Thursday, April 20, 2006 12:51 PM
To: Templin, Fred L; [email-masked]
Subject: RE: RFC2461(bis), section 6.3.6

Fred

Hesham

	 

	Fred

---

From: Thomas Narten <[email-masked]>
Date: Thu, 20 Apr 2006 20:11:15 -0400

> some routers is "suspect".

Not to sound too grumpy, but IMO, this sort of degree of wordsmithing
is what leads to the exact sort of discussion we have had with the M&O
bits.

Nothing in the current wording says you can't take link quality into
consideration (or the phase of the moon - if an implementation somehow
thought that was useful).  More to the point, what is your _real_
concern with the current wording?  That if you did take into
consideration link quality, that the result would be a "non
conformant" implementation (whatever that means)? Who would actually
notice and complain about this? Is this a result of overly-rigorous
compliance testing suites that have been developed?

Whatever happened to an implementor excercising a little common sense?
None of our specs are so detailed and precise to take into
consideration all factors, especially ones that were not even taken
into considerations at the time a spec was written.

And again (just like with the M&O discussion), the sentence at issue
has a SHOULD in it. You SHOULD do X, unless you know what you are
doing and understand the implications of not following the should. If
you take link quality into considerations (at least, assuming the
algorithm you use made sense!), that IMO would be perfectly in spirit
with the intent of that sentence says. Again, here is what SHOULD
actually means, per 2119:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

Again, exactly what problem would adding "etc." actually fix?

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Apr 2006 08:38:12 -0700

Thomas,

I think it is good to have this discussion of link quality
on the list to serve as a permanent (?) record for those
developers who might want to implement a default router
selection strategy based on factors not explicitly called

> Again, exactly what problem would adding "etc." actually fix?

adding the "etc." could not possibly do any harm, and
could possibly inform developers of the fact that they
have some degrees of freedom in their default router
selection strategy (i.e., it can't hurt and might help).
Moreover, it could go as a simple AUTH48 update so I
don't think its fair to draw a parallel between this
and the M&O discussions. To prove it, I will make this
my final submission on this topic.

Fred

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, April 20, 2006 5:11 PM
To: Templin, Fred L
Cc: Soliman, Hesham; [email-masked]
Subject: Re: RFC2461(bis), section 6.3.6 

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Apr 2006 15:45:22 -0700

> is what leads to the exact sort of discussion we have had with the M&O

I agree.  Further, I think in this case, adding the ", etc." clause  
is likely to create confusion as it can be interpreted in many ways.

I recommend that we do not adopt this proposed change.

Bob

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 Apr 2006 08:45:08 -0400

"Templin, Fred L" <[email-masked]> writes:

> out in the spec.

I guess I don't see how having a minor thread on the topic (and one
that doesn't show any deep discussion and or consensus outcome) as
making much difference either way.

> adding the "etc." could not possibly do any harm,

That I agree on!

> and could possibly inform developers of the fact that they have some
> degrees of freedom in their default router selection strategy (i.e.,
> it can't hurt and might help).

IMO, they have the freedom. And one argument against adding words
would be good to make that even more clear is that it might lead
others to argue that lack of such words in other contexts implies lack
of similar degree of freedom, which I find troubling.

> Moreover, it could go as a simple AUTH48 update so I don't think its
> fair to draw a parallel between this and the M&O discussions.

The parallel in my mind is on over analyzing the words to the point
where we are no longer protocol engineers trying to make protocols
work well (based in part on just exercising common sense), but
essentially lawyers worried about whether a spec explicitely allows or
disallows some minor variant from what is explicitely spelled out.

Thomas