[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-zer oconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)

Hi Nate,

Thanks for posting this update. It addresses the remnant points in my
DISCUSS ballot which I have now cleared.

Thanks,
Ketan


On Fri, Feb 13, 2026 at 1:24 AM Karstens, Nate <[email protected]>
wrote:

> Ketan,
>
>
>
> I apologize for the significant delay since my last reply. We posted
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11 to address your concerns:
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/
>
>
>
> Please see responses below, marked *[NLK2]*.
>
>
>
> Cheers,
>
>
>
> Nate
>
>
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Friday, November 21, 2025 06:22
> *To:* Karstens, Nate <[email protected]>
> *Cc:* The IESG <[email protected]>;
> [email protected]; [email protected];
> [email protected]
> *Subject:* Re: [pim] Ketan Talaulikar's Discuss on
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)
>
>
>
> Hi Nate, Thanks for the continued discussion and the improvements being
> made to the document. Please check inline below for responses with KT2 and
> I am not following up on the points where we have reached an agreement. On
> Fri, Nov 21, 2025 at
>
> Hi Nate,
>
>
>
> Thanks for the continued discussion and the improvements being made to the
> document.
>
>
>
> Please check inline below for responses with KT2 and I am not following up
> on the points where we have reached an agreement.
>
>
>
>
>
> On Fri, Nov 21, 2025 at 3:53 AM Karstens, Nate <[email protected]>
> wrote:
>
> Ketan,
>
>
>
> Thanks for taking another look! My responses are below, denoted with
> *[NLK]*. Also, we posted a version -10.
>
>
>
> Best Regards,
>
>
>
> Nate
>
>
>
> *From:* Ketan Talaulikar <[email protected]>
> *Sent:* Thursday, November 20, 2025 02:30
> *To:* Karstens, Nate <[email protected]>
> *Cc:* The IESG <[email protected]>;
> [email protected]; [email protected];
> [email protected]
> *Subject:* Re: [pim] Ketan Talaulikar's Discuss on
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)
>
>
>
> Hi Nate, Thanks for your response and the document update. Please check
> inline below for my responses/clarifications. For the ones where I haven't
> responded, the changes and/or your responses address my comments. Thanks.
> Also, I might have
>
> Hi Nate,
>
>
>
> Thanks for your response and the document update. Please check inline
> below for my responses/clarifications.
>
>
>
> For the ones where I haven't responded, the changes and/or your responses
> address my comments. Thanks.
>
>
>
> Also, I might have sneaked a peek at some of the solutions but by and
> large my review has turned a blind eye to all those other drafts. I
> strongly recommend that if this document is to be published as an RFC it
> should be standing on its own with the necessary specifics and clarity.
>
>
>
> *[NLK] That makes sense. I think our document is intended to stand on its
> own, but knowing about the other documents might help understand why we are
> writing this document at all.*
>
>
>
> Note: I found it hard to process your style of responses where my original
> comments have been trimmed. Could you please respond inline in the future
> to preserve the context? I am dealing with a lot of context switches and
> would appreciate it if the full context was preserved during such
> discussions.
>
>
>
> *[NLK] My apologies and sorry for the additional work that caused for you.
> All future replies will be inline.*
>
>
>
> On Thu, Nov 20, 2025 at 12:26 PM Karstens, Nate <[email protected]>
> wrote:
>
> Ketan,
>
>
>
> Thanks for your review! We uploaded
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-09 and made changes based on
> your feedback:
>
>
>
> > …why the WG wishes to publish this document as an RFC…
>
>
>
> We believe that there is benefit to documenting problems with the status
> quo and providing metrics that future solutions (such as
> draft-ietf-pim-ipv6-zeroconf-assignment and draft-ietf-pim-gaap) can be
> evaluated by.
>
>
>
> KT> There is a difference between documenting and publishing as an RFC. I
> don't see the long term benefit of publication of the document given the
> state of the solution work. There are plenty of examples where such work is
> adopted but not published as an RFC. Anyway, this was not a technical point
> and I will leave this to the WG and the responsible AD's call. I'll move
> this down into comments just to make sure it is not seen as a DISCUSS
>
>
>
> *[NLK] Sounds good, thanks!*
>
>
>
> > A way to address this is to replace the "new protocol" with a "solution"
>
>
>
> Mohamed had a similar suggestion. We updated the document accordingly.
>
>
>
> KT> Thanks. I'll clear this point.
>
>
>
> *[NLK] Great, thank you!*
>
>
>
>
>
> > Assuming there is indeed the need for something new, I was looking for
> some analysis of why we need to build something new for IPv4 and why not
> just for IPv6.
>
>
>
> Our recommendation is to use IPv6, but leave that up to the protocol
> designer in case they need IPv4 for their use case.
> draft-ietf-pim-ipv6-zeroconf-assignment uses IPv6 only, while
> draft-ietf-pim-gaap supports both IPv4 and IPv6.
>
>
>
> KT> I am not sure who you are referring to by "our". I see the authors of
> this document are authors for both of those documents. Regardless, I would
> look for what is the WG consensus on this topic and it would be good to
> document the analysis on why work on IPv4 for something new. This point
> remains open.
>
>
>
> *[NLK] I think there are networks in use today that would benefit from
> host-based multicast address allocation, but where transitioning to IPv6 is
> not practical. We didn’t want to preclude anything that could be
> beneficial. I think the WG still regards IPv4 as worth maintaining because
> the charter mentions IGMP and RFC 9776 (an update to IGMPv3) was published
> earlier this year.*
>
>
>
> KT2> Some text along the lines of your response above in the introduction
> section would help. It would be better if this were one of the
> considerations that conveys that the problem needs to be solved for IPv6
> but it would be good to solve also for IPv4 (or something along those
> lines).
>
>
>
> *[NLK2] We added another paragraph to the Introduction section to address
> this.*
>
>
>
>
>
> > [Referring to RFC 4541] That RFC is almost 20 years old. Is it still
> relevant?
>
>
>
> Yes, it is still relevant :). We are working on some improvements, see
> draft-karstens-pim-multicast-snooping-optimization.
>
>
>
> KT> I find it very hard to believe that RFC4541 is still relevant and
> reflects the current state. Especially the "survey" in
> https://www.rfc-editor.org/rfc/rfc4541#section-4
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc4541*section-4__;Iw!!EJc4YC3iFmQ!U6InPKfEEzSRFhS0SwFKiXm1PWzYkxm1AGEWdvmV8SOk3vxx9cQ4mkgwdcwCTfafIxP8oCtnkPYF3WijEmoc198$>
> was only referring to IGMP and not covering MLD. IPv6/MLD text in that RFC
> gives the impression of it being "bleeding edge" while it clearly cannot be
> so in 2025? Is there any discussion that you could point me to? This
> document claims "many switches" and I would like to see some
> substantiations of those claims. This point remains open.
>
>
>
> *[NLK] We can discuss this more and get back with you. I do agree that
> IETF documentation on this is not in the best state. Some of that may be
> because ownership is not entirely clear – IETF owns network-layer and
> above, IEEE owns link-layer and below, and snooping crosses both of those
> layers. In any case, we are working on improvements.*
>
>
>
> KT2> I don't see any issue there - IETF and IEEE have a collaborative
> liaison between them. Back to the topic, I haven't seen any changes in this
> text in the latest version. At a minimum this claim needs to be revised
> perhaps from "many switches" to "some switches" and the text should include
> the clarification that there does not exist a more recent survey/analysis
> but it is likely that some of those limitations (e.g., old or "deficient"
> switches) still exist in some of the target deployments.
>
>
>
> *[NLK2] *
>
> *Sorry, I didn’t initially understand the main point you were making with
> the comment, which is that the survey results are old and may not apply
> anymore. We updated that section to point that out.*
>
>
>
> *You also mentioned MLD. My experience has been that the “IGMP/MLD
> snooping” feature in switch hardware just detects the IGMP or MLD protocols
> and kicks the Ethernet frame up to a management CPU for further handling.
> The CPU is then able to treat MAC addresses generated by IPv4 multicast and
> IPv6 multicast interchangeably as far as programming address tables in the
> switch.*
>
>
>
> *This is a limited sample of course, but illustrates that the transition
> to MLD didn’t necessarily require a large change in switch operation.*
>
> *[/NLK2]*
>
>
>
> > The reference to a 20+ year old patent (so the idea is even older) as an
> example or justification seems very odd to me
>
>
>
> I’m not sure how prevalent this feature/limitation is in the market, but
> we still encounter it in modern parts.
>
>
>
> KT> I find that response unconvincing. Is there anything lost if this
> point and the entire paragraph were removed from this document? This point
> remains open.
>
>
>
> *[NLK] Yes, section 2.1 of **draft-ietf-pim-ipv6-zeroconf-assignment*
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/__;!!EJc4YC3iFmQ!VZVZL6NsedgtdadKkEPD8oCo9u42E2jDZ7zuZ-CbKvLkIMlncbh_S43hv1pHToHnIANWGySfC7l2OJ9uGPcrIqw$>*
> describes a mitigation for this issue.*
>
>
>
> KT2> Thanks for that clarification. In which case, the problem may be
> described briefly inline to benefit the reader instead of pointing
> normatively to a 20+ year old patent. Is that possible?
>
>
>
> *[NLK2] Yeah, no problem. We improved the description a bit and moved the
> patent to an informative reference (the diagrams and description are still
> helpful).*
>
>
>
>
>
> > I find this very strange. Why is this a requirement? I would have
> expected it to be the other way around - use/extend what exists?
>
>
>
> The only protocol that was published as a standard is MADCAP. Making that
> work as a host-based (vs server-based) allocation model was something we
> looked into briefly, but it would be significantly more complicated than a
> protocol designed for host allocation. We left it out of the Excluded
> Solutions section because it was never really a viable option.
>
>
>
> KT> I'll remind you that we are not anymore talking about protocols but
> solutions. This text is not just about MADCAP. Taking a step back and
> thinking about this, is the intention actually the following (please feel
> free to wordsmith to convey the intention)?
>
>
>
> [CONS-2] Standards Compatibility: The solution SHOULD aim to minimize the
> need for changes to existing protocols or standards that affects backwards
> compatibility or deployment in existing networks.
>
>
>
> *[NLK] I’m fine with this wording.*
>
>
>
> > It is not clear if the solution can extend to both host stacks as well
> as network devices.
>
>
>
> We somewhat address that with the Standards Compatibility consideration.
> That is limited to protocols and standards, though that can be extended to
> a desire to minimize *any* change. We can update the document to reflect
> that if you prefer.
>
>
>
> KT> Yes, however, it would be preferable to describe in terms of
> applications, hosts, and routers/switches. When you say "platform", it is
> not clear what exactly that refers to. I suspect this is on the hosts - but
> please clarify.
>
>
>
> *[NLK] Sure, we can clarify that this is referring to host platforms.*
>
>
>
> > Should it also cover MLD snooping
>
>
>
> We can update this to say “IGMP/MLD snooping”
>
>
>
> > Perhaps you would want to clarify why not? Is it because it requires a
> server and is not a decentralized mechanism?
>
>
>
> That’s correct. We rearranged the sentence a bit to make that more
> apparent:
>
>
>
> RFC2730 (MADCAP) describes a method for multicast IP address allocation,
> but its server-based model does not suit a zeroconf environment.
>
>
>
> > Does "Ethernet" here imply the "wired" media or in general for others
> such as wifi and various other link layer technologies?
>
>
>
> Éric Vyncke had a similar comment. We updated the document to be more
> neutral with regards to link layer.
>
>
>
> > I am assuming the "hardware" being referred to here is an L2 switch?
>
>
>
> No, this would be in the Ethernet MAC, for example.
>
>
>
> KT> Could you please clarify and be more precise?
>
>
>
> *[NLK]*
>
> *Sure. We updated this paragraph as follows:*
>
>
>
> *First, many host network interfaces allow filtering of multicast traffic
> directly in hardware. When an application joins a multicast group, the host
> network stack typically programs the hardware to accept only traffic for
> that group. However, if two groups share the same link-layer address, the
> hardware network interface cannot distinguish them. The network stack is
> then forced to process unwanted traffic in software, reducing performance
> and increasing CPU usage.*
>
>
>
> *Does that help?*
>
> *[/NLK]*
>
>
>
> KT2> Yes, it does. Thanks.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
>
>
> > "gracefully" is not very precise
>
>
>
> We left that vague to allow flexibility in protocol design. Still, it
> would be helpful to at least indicate that streams should be migrated to a
> unique address. We updated this accordingly.
>
>
>
> > I am not able to parse the above statement properly. Could you please
> clarify or rephrase
>
>
>
> Sorry, my grammar was terrible there. I updated to say “advertising and
> *discovering* allocated addresses”. This was from Mohamed Boucadair’s
> question about how the allocated addresses would be communicated (see
> https://mailarchive.ietf.org/arch/msg/pim/yvDAR-jVVIuexooqwS9P8FywSNk/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/pim/yvDAR-jVVIuexooqwS9P8FywSNk/__;!!EJc4YC3iFmQ!U6InPKfEEzSRFhS0SwFKiXm1PWzYkxm1AGEWdvmV8SOk3vxx9cQ4mkgwdcwCTfafIxP8oCtnkPYF3WijaaFO6qw$>
> ).
>
>
>
> > The above sentence is not appropriate for this document
>
>
>
> Éric Vyncke had a similar comment. Our concern with removing the reference
> from the IPv6 considerations section is that the reader may get the
> impression that there is no solution to the issues we describe.
>
>
>
> KT> It is not right that a problem statement and requirement document
> references solutions. Please remove this reference. What prevents the WG
> from finding another solution? Do we want this document to be partial to
> one particular solution?
>
>
>
> *[NLK] OK, we will remove it.*
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
> > I find the discussion of excluded solutions in this document to be odd
>
>
>
> I can’t say that the WG spent extensive time discussing these, though that
> might have been because we listed them in our first draft. We moved this to
> an appendix.
>
>
>
> Best Regards,
>
>
>
> Nate
>
>
>
> *From:* Ketan Talaulikar via Datatracker <[email protected]>
> *Sent:* Wednesday, November 19, 2025 08:33
> *To:* The IESG <[email protected]>
> *Cc:* [email protected];
> [email protected]; [email protected]
> *Subject:* [pim] Ketan Talaulikar's Discuss on
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)
>
>
>
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: Discuss When responding,
> please keep the subject line intact and reply to all email addresses
> included in the To and CC lines. (Feel
>
> Ketan Talaulikar has entered the following ballot position for
>
> draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: 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!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDQbI7GChw$ <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!EJc4YC3iFmQ!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDQbI7GChw$>
>
> 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!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDRKAVrmUA$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/__;!!EJc4YC3iFmQ!UjULH0DhVmj7ill_v9jfReZ7yq_cT2H8QJnwK_ItAH83KaVQhMPVVUq-VtkisWQ_PdLPxlq7rDRKAVrmUA$>
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> DISCUSS:
>
> ----------------------------------------------------------------------
>
>
>
> Thanks to the authors and the WG for their work on this document.
>
>
>
> There are several aspects in this document that I would like to discuss with
>
> the authors and the WG.
>
>
>
> There is also an overarching question at the back of my mind on why the WG
>
> wishes to publish this document as an RFC when it has already adopted multiple
>
> documents related to solutions that supposedly address this problem space
>
> (draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id (in IETF LC),
>
> draft-ietf-pim-ipv6-zeroconf-assignment, draft-ietf-pim-gaap (experimental)).
>
> Just curious ... perhaps the WG can just decide not to publish this as an RFC
>
> and instead continue their work-in-progress solutions while keeping this draft
>
> as a guidance?
>
>
>
> Please find below discussion points inline in the idnits o/p of v08 of this
>
> document:
>
>
>
> 29         zeroconf deployment.  This foundation serves as a reference for
>
> 30         developing future multicast address allocation protocols that operate
>
> 31         autonomously within local networks.
>
>
>
> <discuss-1> It is strange for a problem statement and requirements documents to
>
> pre-suppose a solution that requires new/future protocols. I would have expected
>
> the document to remain open to any solution that solves the problem and meets
>
> the requirements. It may be a protocol or a mechanism (e.g., a mapping scheme
>
> for multicast address allocation). It may an extension of an existing protocol
>
> or mechanism or a new one. I do not see the analysis that rules out extending
>
> existing things and makes it a must to define new ones.
>
>
>
> A way to address this is to replace the "new protocol" with a "solution" so this
>
> document is not getting into the specifics of the solution space.
>
>
>
> <discuss-2> Assuming there is indeed the need for something new, I was looking
>
> for some analysis of why we need to build something new for IPv4 and why not
>
> just for IPv6.
>
>
>
> 154        Second, link-layer address collisions reduce the benefit of using
>
> 155        multicast snooping switches on a network.  As described in [RFC4541],
>
> 156        Section 4, many switches forward multicast traffic based solely on
>
> 157        the link-layer address, without considering the network-layer group
>
> 158        (see the results for Q2 and Q3).  In such cases, if two multicast
>
>
>
> <discuss-3> That RFC is almost 20 years old. Is it still relevant?
>
>
>
> 165        Third, the internal design of some switches can also contribute to
>
> 166        collisions.  For example, certain switch implementations
>
> 167        [US6690667B1] use hash tables to store forwarding entries based on
>
> 168        MAC addresses.  If multiple addresses hash to the same location and
>
> 169        the table fills up, additional entries may be dropped or rejected,
>
> 170        resulting in forwarding failures.
>
>
>
> <discuss-4> The reference to a 20+ year old patent (so the idea is even older)
>
> as an example or justification seems very odd to me. I find the argument odd
>
> that we need to design a new protocol in 2026+ to fix this thing ...
>
>
>
> 224        2.  Standards Compatibility: The protocol SHOULD aim to minimize the
>
> 225            need for changes to existing protocols or standards.
>
>
>
> <discuss-5> I find this very strange. Why is this a requirement? I would have
>
> expected it to be the other way around - use/extend what exists?
>
>
>
> 227        3.  Cross-Platform Availability: It SHOULD use capabilities that are
>
> 228            widely available across platforms and operating systems.
>
>
>
> <discuss-6> It is not clear if the solution can extend to both host stacks as
>
> well as network devices or only to the network devices or only to the hosts.
>
> Would it be desirable if the solution only comprises of changes in the hosts
>
> (e.g., a new plugin for socket layer) and does not require any other changes? I
>
> don't find any discussion or analysis on this part.
>
>
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> I would also like to share some comments/suggestions inline in the idnits o/p
>
> of v08 of the document.
>
>
>
> 103        destination MAC addresses.  Instead, each multicast stream is
>
> 104        assigned a unique destination multicast IP address, and IGMP snooping
>
>
>
> <minor> Should it also cover MLD snooping?
>
>
>
> 114        [RFC2730] (MADCAP) describes a method for server-based multicast IP
>
> 115        address allocation, but this does not suit a zeroconf environment.
>
>
>
> <minor> Perhaps you would want to clarify why not? Is it because it requires
>
> a server and is not a decentralized mechanism?
>
>
>
> 146        First, many Ethernet interfaces allow filtering of multicast traffic
>
>
>
> <major> Does "Ethernet" here imply the "wired" media or in general for others
>
> such as wifi and various other link layer technologies?
>
>
>
> 147        directly in hardware.  When an application joins a multicast group,
>
> 148        the network stack typically programs the hardware to accept only
>
>
>
> <major> I am assuming the "hardware" being referred to here is an L2 switch?
>
> And is the "network stack" here IP Routing or L2 bridging? Is it possible to
>
> make this more precise so the target deployment network can be better
>
> understood by those that would build the solutions?
>
>
>
> 212        Note: In rare cases, collisions may arise after a temporary network
>
> 213        partition, when different parts of the network allocate the same
>
> 214        multicast address independently.  Upon reconnection, such collisions
>
> 215        SHALL be detectable and resolved gracefully.
>
>
>
> <major> "gracefully" is not very precise. Is there a time period in mind here?
>
> Is it OK for the multicast service to be disrupted? Any details on what is
>
> expected from the applications, from the host stack, and from the network
>
> devices (switches/routers)?
>
>
>
> 241        7.  Advertisement: The protocol SHOULD describe a mechanism for
>
> 242            advertising and discovery allocated addresses.
>
>
>
> <major> I am not able to parse the above statement properly. Could you please
>
> clarify or rephrase?
>
>
>
> 268        A solution to these issues is presented in
>
> 269        [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].
>
>
>
> <major> The above sentence is not appropriate for this document.
>
>
>
> 295     6.  Excluded Solutions
>
>
>
> <major> I find the discussion of excluded solutions in this document to be odd.
>
> However, if they have been discussed in the WG as part of this work and there is
>
> a need to document them (not as requirements but just as "notes") then perhaps
>
> this can be moved to the Appendix with such a note?
>
>
>
> <EoRv08>
>
>
>
>
>
>
>
> _______________________________________________
>
> pim mailing list -- [email protected]
>
> To unsubscribe send an email to [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.
>
>
> ------------------------------
>
>
> 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.
>
>
> ------------------------------
>
> 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]