[pim] Re: 2nd WGLC for draft-ietf-pim-rfc1112bis

Hi Toerless

I believe we should try to get reviews from the various directorates
and also ask for review from int-area, thoughts?

Stig

On Sun, Nov 2, 2025 at 12:21 PM Toerless Eckert <[email protected]> wrote:
>
> Thanks a lot Stig.
>
> I think i fixed all your concerns with just posted -06
>
> the bad news is that thinking of security consideration lead to a significant
> amount of new text for that section (no impact on other sections) as well
> as a new appendix section. It's still IMHO significantly useful and i don't remember
> that these issues have been equally well been captured elsewhere and this is the
> right doc to do it...
>
> I'm proposing the appropriate next steps in slides for tomorrow that i just uploaded too.
>
> Cheers
>     Toerless
>
> On Fri, Oct 17, 2025 at 01:05:47PM -0700, Stig Venaas wrote:
> > Hi Toerless and WG.
> >
> > I have a few comments on the draft.
> >
> > High level comments
> >
> > Add Security Considerations and maybe an acknowledgment section?
>
> *gulb* At the risk of annoying the WG chairs, when i started to think
> of security issues, i couldn't stop... so *uhmm* i hope its considered
> to be useful. I certainly think it is because i am not aware we have any
> better place to put the stuff i wrote, and it seems quite useful especially
> as a summary for all those folks in the IETF who nowadays don't even know
> multicast anymore...
>
> > There is a normative reference to RFC 4607 which is a down reference.
> > How do we handle this?
>
> I can not find the normative reference for this right now, but in my
> understanding, downrev is about track, e.g.: standards -> BCP? -> experimental -> informational,
> but not about maturity: (full) standard -> proposed standard ( -> draft standard).
>
> In any case, RFC9776/RFC9777 also have a couple of proposed standard normative
> reference. Do you remember that there was ever a discussion about those ? I don't
>
> > Below are some more editorial comments.
> >
> > 3. Levels of conformance
> > Last paragraph should say IPv6, not IPv4?
>
> Right.
>
> > 3.1
> > It says "class D IP address".
> > Should be IPv4 address.
>
> Actually, i replaced with "IP address".
>
> It's a bit questionable whether there could actually be legally any
> Level 0 IPv6 implementation, because of rfc4291/2.8 and hence the
> need for Level 2L support on nodes that support this. But i wold
> argue to IETF/IESG reviewers that rfc4291 is still draft standard,
> so we are on the safe side if we make Level 0 and its requirement
> to discard received packets to multicast packets applicable to
> both IPv4 and IPv6 - even though it should really be a problem in
> ipv6...
>
> > 3.3 and elsewhere
> > Should the IGMPv3lite reference be IGMPv3light? It is not called
> > "lite" in RFC 5790.
> > Might it be confusing that it is called IGMPv3lite when it also
> > applies to MLDv2?
>
> Right. Removed IGMPv3lite, now only using RFC5790.
>
> > 6.1
> > Third (level 2 implementations only)
> > Also 2L?
>
> Yes.
>
> > 6.2
> > (Level 2 implementations only.)
> > Also 2L?
>
> Yes.
>
> >    A host group address or IP address from an SSM range MUST never be
> >    placed in the source address field or anywhere in a source route or
> >    record route option of an outgoing IP datagram.  These packets are
> >    not IP multicast packets but simply invalid packets.
> >
> > Shouldn't it just say that IP multicast addresses should never be in
> > the source field etc?
>
> I had assumed in rev <= 05 that "IP multicast address" == "host group address".
> I have now updated the paragraph in section 4 to fix this:
>
> IP addresses as specified in {{SSM}} are not used for ASM IP multicast and
> are not considered host groups by {{SSM}} (Terminology section, third paragraph).
> They are instead only the destination address part G of Source Specific Multicast (SSM)
> IP multicast (S,G) channels. The term IP multicast address covers both ASM host group addresses
> and SSM channel IP destination addresses.
>
> With that definition i did change the above paragraphs text to what you suggested.
>
> > In 7.2
> >    decremented on arriving datagrams that are not being forwarded.  An
> >    incoming datagram with an IP host group address in its source address
> >    field is quietly discarded.  An ICMP/ICMPv6 error message
> >
> > If I understand correctly, SSM is not regarded as host groups, in that
> > case, should this be mentioned explicitly in 6.2 or maybe better, just
> > refer to IP multicast addresses as I'm suggesting for 6.2 above.
>
> Yes. Changed!
>
> I also went through the whole document and also changed the occurrance of host group
> to IP multicast address in the Ethernet local module section (7.4).
>
> > 10.12
> > s/tern/term
> >     that [IGMPsnooping] mandates to explicit support it IGMP snooping
> > add "in", as in "support it in IGMP"
>
> Fixed.
>
> > 11.2
> >    Explanation: This type code messages where introduced by RFC1112 but
> >    modified versions thereof where also introduced by [RFC2236] and
> >    [RFC3376], so that it is clearer if all three RFCs are indicated.
> >    All other references to RFC1112 in this registry are specifically
> >    referring to that RFC in it's role of defining IGMP version 1 and
> >    thus need to continue to refer to RFC1112 and not [THIS-RFC.
> >
> > In first sentence s/This/These
> > In last sentence s/it's/its
> > In last sentence add missing ]
>
> Done.
>
>
> > A.3
> > Remove "in" here: IGMP as they had in before.
>
> I did "as they did before"... RFC editor will have the last word ;-)
>
> Thanks so much!
>     Toerless
>
> > Thanks,
> > Stig
> >
> > On Fri, Oct 17, 2025 at 12:59 PM Stig Venaas <[email protected]> wrote:
> > >
> > > Dear WG
> > >
> > > We had a working group last call for this document a while back. We
> > > got very few responses to that and there have also been some changes
> > > to this document since then.
> > >
> > > Hence we are doing a 2nd WGLC on the latest version which is now
> > > draft-ietf-pim-rfc1112bis-05. You can find the latest version at
> > > https://datatracker.ietf.org/doc/draft-ietf-pim-rfc1112bis/
> > >
> > > Please review this document and let us know whether you support
> > > publication or have any concerns or comments or suggestions for any
> > > changes by October 31st 2025.
> > >
> > > Regards,
> > > Stig
> >

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]