Subject: Re: Exception to "MUST NOT"

From: "Jiwoong Lee" <[email-masked]>
Date: Tue, 25 Sep 2001 11:29:28 +0900

James and Ken, 

Quite interesting remarks you have made. I agree to Ken's syllogistics and I love James' consideration on corporeal world practice.

Let's begin at the beginning. What is the requirement level for exceptions of "MUST NOTs" ?

First, in RFC terms, MAY has the equal value to MAY NOT. In fact, there is no definition on "MAY NOT" in RFC 2119. 

Exceptions to MUST NOTs means there are cases which are not prohibited. The semantics gives me the implication that the appripriate requirement level is placed between "SHOULD NOT" and "MAY".

Jiwoong

----- Original Message ----- 
From: "James P. Salsman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, September 22, 2001 5:35 AM
Subject: Re: Exception to "MUST NOT"

> Ken,
> 
> You have a sharp eye, but the excluded middle of syllogistic logic 
> has different semantics than the pragmatic logic of restrictions 
> (such as statutory law and RFC requirements.)
> 
> For example, you are not allowed to use a cellphone on a plane, but 
> will you be prosecuted if you do use one to thwart a hijacking?  No.
> 
> This is a favorite topic of mine.  I hope you do not think I was 
> trolling, but I was checking to see if any Aristotelians such as 
> yourself were paying attention.
> 
> Cheers,
> James
> 
> > Date: Fri, 21 Sep 2001 16:24:36 -0400 (EDT)
> > From: Ken Calvert <[email-masked]>
> > To: "James P. Salsman" <[email-masked]>
> > Subject: Re: Exception to "MUST NOT"
> > 
> > > (NOT P) does not imply (NOT (C AND P)).
> > 
> > Of course it does.
> > 
> > For any boolean structures P and C,
> > 
> >   NOT P
> > => 
> >  (NOT C) OR (NOT P)
> > =
> >  NOT (C AND P)
> > 
> > See any text on propositional calculus.
> > 
> > KC
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Sep 2001 20:22:24 +0200

--On tirsdag, september 25, 2001 11:29:28 +0900 Jiwoong Lee <[email-masked]> 
wrote:

> James and Ken,
>
> Quite interesting remarks you have made. I agree to Ken's syllogistics
> and I love James' consideration on corporeal world practice.
>
> First, in RFC terms, MAY has the equal value to MAY NOT. In fact, there
> is no definition on "MAY NOT" in RFC 2119.
>
> Exceptions to MUST NOTs means there are cases which are not prohibited.
> The semantics gives me the implication that the appripriate requirement
> level is placed between "SHOULD NOT" and "MAY".

MUST NOT means that you never do it, and any implementation that does it is 
nonconformant to the spec.

If you find that you have to do it in some case, you have found a bug in 
the spec.

Note that English is a slippery language, and constructs like "MUST NOT do 
X unless Y, Z and W occurs" and its semantic equivalents are quite common.

Most specs have bugs.

                     Harald

---

From: "Jiwoong Lee" <[email-masked]>
Date: Thu, 27 Sep 2001 09:32:05 +0900

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
Sent: Thursday, September 27, 2001 3:22 AM

> If you find that you have to do it in some case, you have found a bug in 

Somecases. However, ICMPv6 example case, described in the first mail of this thread, has not been found but already described in the spec; which is not a bug at all.

Jiwoong

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 27 Sep 2001 11:41:02 +0200

--On 27. september 2001 09:32 +0900 Jiwoong Lee <[email-masked]> wrote:

>> MUST NOT means that you never do it, and any implementation that does it
>> is  nonconformant to the spec.
> Somecases. However, ICMPv6 example case, described in the first mail of
> this thread, has not been found but already described in the spec; which
> is not a bug at all.

I must admit to not understanding what you are saying.
could you give the RFC or draft name, and quote the text you are worried 
about?

It is always easier to understand when looking at the same problem.

                 Harald

---

From: "Jiwoong Lee" <[email-masked]>
Date: Fri, 28 Sep 2001 09:36:37 +0900

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
Sent: Thursday, September 27, 2001 6:41 PM
Subject: Re: Exception to "MUST NOT"

> could you give the RFC or draft name, and quote the text you are worried 

Yes. Please have a look on section 2.4 of RFC 2463 (ICMPv6)

    ...

    (e) An ICMPv6 error message MUST NOT be sent as a result of
        receiving:
    ...

         (e.2) a packet destined to an IPv6 multicast address (there are
               two exceptions to this rule: (1) the Packet Too Big
               Message - Section 3.2 - to allow Path MTU discovery to
               work for IPv6 multicast, and (2) the Parameter Problem
               Message, Code 2 - Section 3.4 - reporting an unrecognized
               IPv6 option that has the Option Type highest-order two
               bits set to 10), or

         (e.3) a packet sent as a link-layer multicast, (the exception
               from e.2 applies to this case too), or

         (e.4) a packet sent as a link-layer broadcast, (the exception
               from e.2 applies to this case too), or
    ...

Jiwoong

---

From: [email-masked]
Date: Fri, 28 Sep 2001 08:45:10 -0400

>                IPv6 option that has the Option Type highest-order two

Jiwoong:

I assume that what you're asking is whether for exceptions (1) and (2),
if the intent is that an ICMPv6 error MAY, SHOULD, or MUST be generated?

If so, then you are correct - the spec should probably read:

(e.2) a packet destined to an IPv6 multicast address (there are
two exceptions to this rule, where a n ICMPv6 error message <FOO> be
generated): (1) the Packet Too Big......

Unfortunately, I don't know if <FOO> should be MAY, SHOULD, or MUST.
Checking for the (mostly-similar) IPv4 case might help.  Unfortunately,
reading RFC1112, section 7.2, it says:

   quietly discarded.  An ICMP error message (Destination Unreachable,
   Time Exceeded, Parameter Problem, Source Quench, or Redirect) is
   never generated in response to a datagram destined to an IP host
   group.

So obviously, there was a decision in the working group that it should
work differently in IPv6 (or a decision that RFC1112 was buggy).  So
we can't easily extrapolate from RFC1112.

Any packet warriors with more experience than I want to clarify this?
I think I was napping when RFC2463 got written, so I don't remember why
it ended up like this... ;)
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Robert Elz <[email-masked]>
Date: Sat, 29 Sep 2001 00:09:59 +0700

Date:        Fri, 28 Sep 2001 08:45:10 -0400
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | I assume that what you're asking is whether for exceptions (1) and (2),
  | if the intent is that an ICMPv6 error MAY, SHOULD, or MUST be generated?
  | 
  | If so, then you are correct - the spec should probably read:

No, that's not needed.   All that is needed is to refer to the sections
cited - 3.2 for "too big" says MUST, 3.4 for "parameter problem" says
SHOULD.

The reason that all that "except for ..." is just to avoid contradictions
in the document.

That is, one section says

	if X happens you MUST do A.

another section says

	if Y happens, you MUST NOT do A

then something has to resolve the situation when X and Y happen
simultaneously.

In this case "A" is send an ICMP, X is "packet is too big", and Y
is "packet is sent to a multicast address".

To fix the problem (which as worded above, in this message) would be

if X and Y happen you both MUST and MUST NOT do A

the Y rule is changed to

	if Y happens, you MUST NOT do A, unless X happens as well.

Then it is clear which of the two rules is to apply when we have
both X and Y, and the contradiction is averted.

Nothing needs fixing here.

  | Any packet warriors with more experience than I want to clarify this?

To discover the reasons why ICMPs are sent in these cases you can
go back and look in the archives - but I don't think that was the
actual point of the original question.  More one of how to interpret
what to do in the exception cases.   From the rule containing the
exception alone you cannot - but read that with the rest of the doc
and all is clear.

kre

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 28 Sep 2001 15:31:25 -0400

>                from e.2 applies to this case too), or

The MUST NOT here is based on hard-learned experience with broadcast
storms with ipv4 on ethernets.

[I'm actually concerned about the two exceptions here; it seems unwise
to *ever* send an ICMP error in response to a non-unicast packet, lest
everyone else in the multicast group do the same thing and melt the
network..]

					- Bill