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

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]