Hi Tommy
Appreciate the review, I posted revision 06 now. I fixed the
capitalization of SHOULD, and I made the two editorial changes you
suggested. They
do indeed look better.
I read RFC 9170 and found it interesting. I do see the issue with
ossification. It is something we should think about for our protocols
in general,
but I don't think we should add it at this point. It requires some
thought and discussion in the working group, I would rather leave that
for later,
perhaps considering this for multicast protocols such as pim, igmp and
mld in general.
Thanks,
Stig
On Thu, Jan 20, 2022 at 8:31 AM Tommy Pauly via Datatracker
<noreply@xxxxxxxx> wrote:
>
> Reviewer: Tommy Pauly
> Review result: Ready with Issues
>
> Thanks for writing this concise and clear document. The addition of TLV
> extensions seems useful.
>
> I don't see any major issues, but there are a few minor ones.
>
> Like the genart reviewer, I believe this "should" ought to be normative:
>
> "When this extension mechanism is used, the number of Group Records in each
> Report message should be kept small enough that the entire message, including
> any extension TLVs can fit within the network MTU."
>
> In Section 4, I suggest rewording this and fixing capitalization:
>
> "To check this, one will need to walk through each of The TLVs until there are
> less than four octets left in the IP payload."
>
> to:
>
> "To check this, the parser needs to walk through each of the TLVs until there
> are less than four octets left in the IP payload."
>
> In Section 5, I suggest rewording this:
>
> "IGMP and MLD implementations, host implementations in particular, rarely
> change, and it is expected to take a long time for them to support this
> extension mechanism."
>
> to:
>
> "IGMP and MLD implementations (particularly implementations on hosts) rarely
> change, and the adoption process of this extension mechanism is expected to be
> slow."
>
> I also suggest that you consider giving guidance for preventing this new
> extension point from ossifying, given the slow rate of change. Please see the
> discussion in RFC 9170. For example, if you cannot guarantee active use and
> change, you may want to suggest synthetic use of the extension point
> ("greasing" by endpoints sending unknown type values every now and then to make
> sure receivers correctly handle unknown types).
>
>
> _______________________________________________
> pim mailing list
> pim@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/pim
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
