Subject: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 24 Oct 2017 16:03:06 -0700

Adam Roach has entered the following ballot position for
draft-ietf-6man-maxra-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm concerned that this normative statement is ambiguous (2nd paragraph of
section 4), and that the ambiguity around allowed values may lead to interop
issues:

   AdvDefaultLifetime
   MUST either be zero (the router is not to be used as a default
   router) or be a value between MaxRtrAdvInterval and 65535.

>From the text in section 3, I infer that MaxRtrAdvInterval is *not* an allowed
value.

>From the "no greater than 65535" language, I infer that 65535 *is* an allowed
value.

Please ensure that your normative statement here is very clear about whether
"between" is intended to include its high and low limits as acceptable values.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4 contains:

   As explained in Section 3, the relationship between MaxRtrAdvInterval
   and AdvDefaultLifetime must be chosen to take into account the
   probability of packet loss.

The use of a non-normative "must" here indicates that you probably want to
update your RFC2119 boilerplate to be RFC8174 boilerplate.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 Oct 2017 23:21:47 +0100

Adam,

With my Doc Shepard hat on.

> On Oct 25, 2017, at 12:03 AM, Adam Roach <[email-masked]> wrote:
> 

This doc is updating the text in RFC4681 which uses the same language:

 AdvDefaultLifetime

        MUST be either zero or between
        MaxRtrAdvInterval and 9000 seconds.

I read this as saying it should be more than MaxRtrAdvInterval and less than 9000.  Hence it is “between” the two values.

I am not aware of interoperability problems caused by the RC4681 “between” language.  Can you point to a problem?  This doc is changing the maximum allowed values to 65535 seconds to avoid the effects of sending too few RAs on particular types of links.

I think the text is clear.  Please describe why you think it could cause an interoperability problem.

Thanks,
Bob

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Oct 2017 19:30:15 -0500

On 10/26/17 17:21, Bob Hinden wrote:
> I am not aware of interoperability problems caused by the RC4681 
> “between” language. Can you point to a problem?

Rather than running the risk of getting caught up on the minutiae of any 
scenario I might describe, I'm going to narrow my DISCUSS to a much 
simpler assertion:

Lacking a formal definition of "between," the following normative 
statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the 
router is not to be used as a default router) or be a value between 
MaxRtrAdvInterval and 65535."

Normative statements cannot be ambiguous.

Please clarify whether this is an inclusive "between" or an exclusive 
"between."

/a

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Oct 2017 21:43:42 -0700

Adam,

It might be worth noting that if it is inclusive or exclusive has absolutely zero consequence for the protocol.

Ole

> On 26 Oct 2017, at 17:30, Adam Roach <[email-masked]> wrote:
> 
>> I am not aware of interoperability problems caused by the RC4681 “between” language. Can you point to a problem?
> 
> Rather than running the risk of getting caught up on the minutiae of any scenario I might describe, I'm going to narrow my DISCUSS to a much simpler assertion:
> 
> Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535."
> 
> Please clarify whether this is an inclusive "between" or an exclusive "between."
> 
> /a

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Oct 2017 09:41:05 -0700

At Thu, 26 Oct 2017 21:43:42 -0700,
Ole Troan <[email-masked]> wrote:

> It might be worth noting that if it is inclusive or exclusive has
> absolutely zero consequence for the protocol.

FWFIW, an implementation that I know of adopts the "inclusive" version
of "between" (it doesn't support 6man-maxra so it still only conforms
to RFC4861):

    MAYHAVE(val, "rltime", rai->rai_maxinterval * 3);
    if ((uint16_t)val && ((uint16_t)val < rai->rai_maxinterval ||
        (uint16_t)val > MAXROUTERLIFETIME)) {
        syslog(LOG_ERR,
            "<%s> router lifetime (%" PRIu32 ") on %s is invalid "
            "(must be 0 or between %d and %d)",
            __func__, val, ifi->ifi_ifname, rai->rai_maxinterval,
            MAXROUTERLIFETIME);
        goto getconfig_free_rai;
    }
(https://github.com/freebsd/freebsd/blob/master/usr.sbin/rtadvd/config.c)

But, more important, I agree with Bob and Ole in that "inclusive" vs
"exclusive" shouldn't cause an interoperability problem since hosts
are not supposed to reject an RA for a particular value of router
lifetime:

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     field can contain values up to 65535 and receivers
                     should handle any value, while the sending rules in
                     Section 6 limit the lifetime to 9000 seconds.  [...]

If anything, if we now "clarify" it to mean "exclusive", at least one
implementation will now become technically non-compliant.  So, while
my primary suggestion is not to do anything about it, if we really
need to say something, I'd suggest clarifying "whether this 'between'
is inclusive or exclusive does not matter in terms interoperability
and is left to implementations".

--
JINMEI, Tatuya

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 27 Oct 2017 12:03:29 -0500

This isn't my area of expertise, my actual area, or my ballot thread, but
...

> and is left to implementations".

If the precise meaning of the boundaries set by a MUST requirement doesn't
actually matter, I'm not understanding why this is a MUST ...  Adam can
speak for himself, but that's what *I* would be confused about.

Spencer, who might or might not be Asking For A Friend

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Oct 2017 10:33:45 -0700

At Fri, 27 Oct 2017 12:03:29 -0500,

> speak for himself, but that's what *I* would be confused about.

That's not my call either, and it's totally possible that an RFC2119
MUST was used too casually, but I guess the spirit of the MUST in this
case is to specify a sensible *range* with some stronger requirement
level so a deviant implementor or operator can't cause an extreme
effect.  But it's not important whether the exact boundary values are
included.  With this interpretation, this should read
AdvDefaultLifetime MUST be one of the following:
[lower, upper]
(lower, upper)
[lower, upper)
(lower, upper]

What 'lower' and 'upper' are is important (hence the MUST), but which
one of the above four is implemented isn't.

That makes sense to me.

--
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Oct 2017 18:50:31 +0000

Hi Adam/Spencer,
<AD Hat Off>
  Speaking as an author, I have also read this as an inclusive between and I do not see any interoperability concerns whichever way it is read, as the actual selected value is placed in the Router Lifetime value of the Router Advertisement to be communicated to the host. (As a data point, the “between” text in question is not new and has been carried over from RFC4861 which has been carried over from RFC2461 which itself was carried over from RFC1970 circa. 1996). That being said, I have no issues mentioning that this is an inclusive between as the receiving hosts are already required to accept any value in the Router Lifetime “up to 65535” according to section 4.2 of RFC4861. 

Thanks
Suresh

> On Oct 27, 2017, at 1:33 PM, 神明達哉 <[email-masked]> wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Oct 2017 15:21:25 -0500

On 10/27/17 11:41, 神明達哉 wrote:
> to RFC4861)

Right. And I think "inclusive" is probably the right answer here. Let's 
examine the statement in question: "AdvDefaultLifetime MUST either be 
zero (the router is not to be used as a default router) or be a value 
between MaxRtrAdvInterval and 65535."

Let's first consider the low end of this interval. Section 3 says: 
"AdvDefaultLifetime MUST be set to a value greater than or equal to the 
selected MaxRtrAdvInterval." Assuming "or equal to" is not a very 
complicated misspelling, would seem to indicate that the range is 
inclusive on the lower end. [1]

Now, let's consider the high end of this interval.  The normative 
statement "MaxRtrAdvInterval MUST be no greater than 65535" allows 
MaxRtrAdvInterval == 65535. In the case that MaxRtrAdvInterval == 65535, 
what would be the allowable values for AdvDefaultLifetime? If it must be 
less-than-and-never-equal-to 65535, and yet must be 
greater-than-or-equal-to MaxRtrAdvInterval, you're left in a bit of a 
pickle: "65535 <= x < 65535" cannot be solved for x. This then indicates 
that the range needs to be inclusive on the upper end.

So while I believe the answer is probably self-evident if one does the 
analysis, the problem is that one has to chain together a lot of logical 
statements to arrive at this conclusion; and such a chain is 
sufficiently non-obvious that even the document shepherd/WG chair 
appears to have arrived at a different conclusion than what this logical 
analysis would lead us to understand.

All I'm asking for is the insertion of a single word in the normative 
statement in question, so that it reads: "AdvDefaultLifetime MUST either 
be zero (the router is not to be used as a default router) or be a value 
between MaxRtrAdvInterval and 65535, inclusive."

I'm happy to keep discussing this; but for me to change my ballot 
position, you'll have to do one of the following:

 1. Change the statement to be unambiguous.
 2. Change the statement to be non-normative.
 3. Make a compelling case that it is okay for normative statements to
    be ambiguous.

/a

____
[1] This is complicated by the following language: 
"K=AdvDefaultLifetime/MaxRtrAdvInterval" and "on a theoretically perfect 
link with no losses, it would have been sufficient to have K just above 
1" -- which implies that K=1 (that is, AdvDefaultLifetime == 
MaxRtrAdvInterval) is problematic even in a theoretically perfect case. 
However, since this text is non-normative, I think it has less weight 
than the normative statements cited above.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 28 Oct 2017 09:41:48 -0700

Spencer,

> On Oct 27, 2017, at 10:03 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> This isn't my area of expertise, my actual area, or my ballot thread, but ...
> 
> If the precise meaning of the boundaries set by a MUST requirement doesn't actually matter, I'm not understanding why this is a MUST ...  Adam can speak for himself, but that's what *I* would be confused about.

Adam’s Discuss was for concern about an interoperability problem if an implementation choose to pick 65534 or 65535 seconds for the default router lifetime in the RA it sends.  Both are legal values so will be accepted by the hosts receiving the RA.  The host receiving the RA uses the lifetime to timeout the a default router entry.  A one second difference in 18.2 hours is inconsequential.

The way this works is routers will send RAs well before the timeout happens.  RFC4861 specifies the max and min times when RAs should be sent, and it doesn’t get close to the boundary.

If our goal is to ensure interoperability, I don’t see an interoperability issue here.  I note that RFC4861 where this language comes from is very widely implemented.

Bob