[pim] Re: Gorry Fairhurst's Discuss on draft-ietf-pim-zero conf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)

Nate, I'm going to top-post on this thread to try to resolve what I 
think are the final issues from me.

I appreciate the changes that have been introduced (the latest I read 
was -09). These go a long way to address my concerns, and I think this 
is producing a much more useful and clearer document, many thanks.

There are a few small issues introduced by these updates, because these 
are now formal requirements, I have re-read the document and considered 
each more carefully.

REQ-1,3,4, 6 all seem OK to me; I expect the following might be easy to 
resolve:

1) ** REQ-2 ought not be adjusted a little (because as worded it's not a 
protocol requirement), rather it seems like a design goal , I'd suggest:

The solution SHALL be designed to minimise introduction of a single 
point of failure, ensuring that operation continues even if individual 
devices or links become unavailable.

2) ** REQ-5 I question if the word "effective" is useful in a 
requirement (could we delete that word? ... or if you feel necessary... 
then explain how this will be evaluated)

3) ** REQ-7 I think this needs to also consider that some endpoint 
hardware can filter only a limited number of multicast addresses (see 
comment 1 in my IESG Comments).
Please let me know your thoughts and hopefully we can soon resolve all 
my issues. I expect to then clear my DISCUSS.

Best wishes,
Gorry

  ----

<<snip>>

On 18/11/2025 22:57, Karstens, Nate wrote:
>
> Gorry,
>
> Thanks for your review! We uploaded 
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08 and made changes based 
> on your feedback:
>
> > there are no formal requirements based on RFC-2119 keywords derived
>
> You are right. We updated section 3 to use requirements language.
>
> > I expect the declaration of keywords can also be removed
>
> I see your point – this document, being informational, does not impose 
> any requirements. It does document requirements for other protocols, 
> but this is different than imposing its own requirements. I’m not sure 
> if we should remove the reference to RFC 2119 et al. It is useful in 
> interpreting the language in section 3. It may be most appropriate to 
> move these references to the list of informational references?
>
> > From the TSV_ART review…
>
> We’ve incorporated updates from this review.
>
> Best Regards,
>
> Nate
>
> *From:*Gorry Fairhurst via Datatracker <[email protected]>
> *Sent:* Monday, October 20, 2025 07:19
> *To:* The IESG <[email protected]>
> *Cc:* [email protected]; 
> [email protected]; [email protected]
> *Subject:* [pim] Gorry Fairhurst's Discuss on 
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: (with DISCUSS and COMMENT)
>
> Gorry Fairhurst has entered the following ballot position for 
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: Discuss When 
> responding, please keep the subject line intact and reply to all email 
> addresses included in the To and CC lines. (Feel
>
> Gorry Fairhurst has entered the following ballot position for
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-07: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to 
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8FTjQUfWw$ <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8FTjQUfWw$>
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8HdhfdgYQ$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!Sh0STv2fUKkYSFJv0dneOqISoNnD-CP2_kbiVw7u1vK0CcltJubqbgwaC4Q7NGpNYwAI5MyCK8HdhfdgYQ$>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> (1) The documents says it defines requirements.
> I saw in the abstract this statement:
> "The document presents explicit requirements covering discovery", but 
> yet from
> a standards perspective it does not - there are no formal requirements 
> based on
> RFC-2119 keywords derived. That may well be suitable for an Informational
> document, and I expect the declaration of keywords can also be 
> removed, and
> this sentence could be rewritten as guidance for future work rather than
> requirements?
> (2) From the TSV_ART review:
> The document appears to be about selecting multicast IP addresses to 
> avoid link
> address collisions, rather than IP address collisions. That should be 
> made more
> clear in the title, abstract, intro, and throughout. The current text 
> is easily
> misread as focusing on IP address collisions until section 2.
> Can this be clarified in the document?
> (3) The TSV_ART review suggested:
> The document jumps between link and network issues without enough 
> context for
> the reader to distinguish between the two. Collisions should be 
> referred to
> throughout as link address collisions, not just address collisions, 
> and address
> assignment should be referred to as IP address assignment.
> Sec 5 should more clearly relate the way 32 IP addresses could map to 
> the same
> MAC address, i.e., this is because only the lower 23 bits are used of 
> the 28
> bits in the IP multicast address range. It would be very useful if the 
> reason
> for this mapping were discussed in this doc – i.e., why did we not 
> just use all
> 28 bits?
> Can this be clarified in the document?
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> Thank you Joe Touch for his TSV-ART review, I'd like to pick-up on the 
> issues
> discussed there, so include them here:
> (i) It also appears that the limited number of (host) hardware address 
> filters
> has been overlooked; i.e., if a device is capable of filtering only 4 
> multicast
> addresses in hardware, the device would more efficiently support 7 
> addresses if
> at least 3 DID collide, rather than ensuring that none collide.  When no
> addresses collide and the number of filters is exceeded, the network 
> interface
> is driven into promiscuous mode that requires software filtering – 
> i.e., it
> completely undermines the goal of this doc.
> (ii) The protocol requirements need some refinement. Resistance to 
> failure is
> NOT the same as robustness to a single point of failure; the tag 
> phrase and the
> definition need to be adjusted to align. Item 3 is “multicast 
> self-assignment
> protocol coexistence”, i.e., this isn’t about interoperation with other
> protocols in general. Item 7 (collision detection and resolution) is not a
> requirement; it is an approach to satisfying other requirements, such 
> as 1, 2,
> and 5. It would help if the tag phrases were similar (they seem to be 
> phrases
> defining properties, except for #6, which should be “supports host-level
> multiplexing” – check this throughout for all lists).
> (iii) The Note needs revision; the collisions arise after *rejoining
> disconnected networks caused by* a temporary network partition. I.e., 
> it is the
> rejoining that causes the problem, not the partitioning. The second 
> list should
> describe goals of a design; it seems odd to include “cross-platform
> availability”, as this seems to conflate deployment with OS 
> capabilities; it is
> difficult to appreciate what OS properties could ever interfere with these
> mechanisms. An example would help as would rephrasing this as “OS 
> independence”.
> ... Please see additional comments in the review that may also be helpful.
> _______________________________________________
> pim mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected] <mailto:[email protected]>
>
> ------------------------------------------------------------------------
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the 
> sole use of the intended recipient(s) and contain information that may 
> be Garmin confidential and/or Garmin legally privileged. If you have 
> received this email in error, please notify the sender by reply email 
> and delete the message. Any disclosure, copying, distribution or use 
> of this communication (including attachments) by someone other than 
> the intended recipient is prohibited. Thank you.

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