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

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]

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