[pim] IETF124 slot ask - Re: Re: 2nd WGLC for draft-ietf-p im-rfc1112bis

Thank you so much, Steg for the thorough review.

Will surely get a fixed version out before the WG meeting, and just asked
for a slot to present feedback to WGLC.

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?
> 
> There is a normative reference to RFC 4607 which is a down reference.
> How do we handle this?
> 
> Below are some more editorial comments.
> 
> 3. Levels of conformance
> Last paragraph should say IPv6, not IPv4?
> 
> 3.1
> It says "class D IP address".
> Should be IPv4 address.
> 
> 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?
> 
> 6.1
> Third (level 2 implementations only)
> Also 2L?
> 
> 6.2
> (Level 2 implementations only.)
> Also 2L?
> 
>    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?
> 
> 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.
> 
> 10.12
> s/tern/term
>     that [IGMPsnooping] mandates to explicit support it IGMP snooping
> add "in", as in "support it in IGMP"
> 
> 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 ]
> 
> A.3
> Remove "in" here: IGMP as they had in before.
> 
> 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]