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

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]