[pim] [6man] normative language and draft-eckert-pim-rfc1112bis

[Toerless Eckert <[e-mail]>]

Dear 6man (cc'ing PIM, because this work is proposed to pim, but specifically seeking
feedback from 6man here).

RFC1112 is the full internet standard specification for IP Multicast host stack (which we now
call ASM IP Multicast to distinguish from later SSM IP Multicast). As the number implies,
it predates IPv6 by quite a while, and when IPv6 was implemented, the IETF kinda "winged"/"ignored"
the specification for an IPv6 Multicast host stack for IPv6. Aka: there is no RFC with equivalent
text to RFC1112. Which for the experienced implementers back then wasn't a problem,
because we simply re-used everything from RFC1112 and only when we did changes did we
did do something new. Such as the new mapping to ethernet in RFC2464 and RFC6085.

For normal users of course, there is the strange question how comes there is no IP Multicast
sertvice for IPv6 given the absence of an RFC. And for RFCs that should be able to refer
to such a specification equally.

So, one of the goals of draft-eckert-pim-rfc1112bis is to superceed RFC1112
with a version that formalizes the applicability of this IP Multicast host stack
specification not only to IPv4, but also IPv6. [ The other two reasons are removal
of the historic IPv4 IGMPv1 protocol version from it, and adding the ASM naming ]

When discussing at IETF116 in PIM-WG, Alvaro brought up the concern that the proposed RFC1112bis
text does not have any RFC2119 language - and he brought up the experiences with RFC8200  as a warning.

So, i would love to hear feedback from 6man re. this draft as it relates to IPv6 and
specifically about the need or non-need to change the language (given how you are the
WG that did RFC8200).

I am not generally opposed to try to sprinkle MUST/SHOULD into the text, but:

- I am actually not sure if RFC2119 language in RFC8200 would have helped to avoid the
  situation we had with it. And even if it did, i think we should consider such a special
  case good guidance for our best processes. I would think there are a lot of counter examples
  with other RFCs where we simply updated documents instead of playing interpretation
  purgatory. And that is something we can and do do whether or not the affected language used 
  rfc2119 terms or not.

- If it ain't broke, don't fix it: The text of rfc1112 and especially the absence of
  rfc2119 language has in my memory (and i have been following IETF IP Multicast work since
  it was written in 1989) never been the reason for contention, but instead, as mentioned
  above, the basis for all IPv4 and IMHO also IPv6 host stack implementations.

- I for once wouldn't even know where to sprinkle in RFC2119 words to help 
  the final code because the relevsant behavior is all written as statements of facts.
  (and has proven itsell well for impleemntations).

Thanks a lot!
    Toerless