Subject: Re: Exception to "MUST NOT"

From: "James P. Salsman" <[email-masked]>
Date: Fri, 21 Sep 2001 10:50:10 -0700 (PDT)

Jiwoong,

You raise an interesting question:

> This is about the requirement level in the Internet specification.
> 
> If a statement has the requirement level of 'MUST NOT' while it 
> has an exceptional case, and while the exceptional case does not 
> elucidate its requirement level, what is the appropriate requirement
> level of this exceptional case ?
> 
> I guess the answer is 'MAY'. Are you agreeable to this ?
> 
> I think ICMPv6 specification has the similar statements in it, 
> regarding to the requirement level of the generation of ICMPv6 
> packet in response to a multicast packet or to a link local
> multicast packet.

If some standard says that you "MUST NOT" generate a non-multicast 
packet in response to a multicast packet, that does not mean that 
you are not allowed to write an application that bridges multicast 
traffic if it is required.

It just has to be selective, i.e., so it won't get out of control.

(NOT P) does not imply (NOT (C AND P)).

Cheers,
James

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 28 Sep 2001 12:58:44 -0700

> > > > 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.
> > >
> > > could you give the RFC or draft name, and quote the text you are
> worried
> > > about?
> >
> > 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
> 
> 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..]

You may or may not like the specific result, but the specification here
is very clear: "you MUST NOT do X unless you are in condition Y, in
which case another rule applies." There is nothing in the process that
prevents writing a specification that way.

-- Christian Huitema