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

Hi Toerless

Apologies for the delay. I've requested reviews with the instructions
you suggested now. You can see the requests and the status in the data
tracker.

Regards,
Stig

On Wed, Jan 14, 2026 at 12:51 AM Toerless Eckert <[email protected]> wrote:
>
> Dear chairs
>
> Not sure if i would be able to see on datatracker if any of the reviews requests have
> been put into the system by you or if non-chair users would just see this when the
> reviews come back.
>
> Could you please tell us what's the status of those early review requests ?
>
> Thank you so much
>     Toerless
>
> On Tue, Dec 23, 2025 at 06:48:31PM +0100, Toerless Eckert wrote:
> > Hi Stig, WG
> >
> > Sorry for delay, had some other work stuff filling up my pipeline short term).
> >
> > Yes!
> >
> > a) I just uploaded -07 which simply adds to section 1 some [ To be remove
> > before publication] text to directly help those reviewers.
> >
> > b) Here are the early reviews requested. I would suggest to paste the list
> >    of reviews and suggested reviewers into the
> >    "Requester's comments and instructions" field in datatracker,
> >    so that the directorate secretaries can accordingly attempt to assign:
> >
> >    SECDIR: Brian Weis, Kyle Rose, Dave Thaler
> >    TSVDIR: Michael Tüxen, Kyle Rose
> >    INTDIR: Jen Linkova, Rick Taylor, Pascal Thubert, Michael Tüxen, Dave Thaler
> >    IOTDIR: Pascal Thubert, Eric Nordmark, Carsten Borman
> >    Note: May want to exclude Brian Haberman as he already did extensive review
> >          as PIM-WG member.
> >
> > Thanks a lot!
> >     Toerless
> >
> > On Tue, Dec 09, 2025 at 11:39:30AM -0800, Stig Venaas wrote:
> > > 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
> > > > >
> > >
> >
> > --
> > ---
> > [email protected]
> >
>
> --
> ---
> [email protected]

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