Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-yang-13: (with DISCUSS and COMMENT)

Alvaro Retana <> Wed, 29 May 2019 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A880B1200B8; Wed, 29 May 2019 06:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pG8Z0YhacffN; Wed, 29 May 2019 06:12:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7FC112006D; Wed, 29 May 2019 06:12:02 -0700 (PDT)
Received: by with SMTP id w33so3683053edb.10; Wed, 29 May 2019 06:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SLvg33MYfJv9ZdDVm9GoEIS0c8mrdoljUJ726UeCWHU=; b=NbcmRDhUkrhVYeLwcVRyoqkzM6rMl5RaJbfQM18DEUgMXXA4zU+TSTzJBZiBu7OqXX V1C7MMDDW85CFPtMtSkeS3Pe0JczKmboRxd9rcz9CoRGnoB4mlSs4Mx7ORAEdNKx+fTl CuzwoRTlcwHKL3QBi13zJ5qIRLMe6fOCKjkQ8JDdOP3OtZNs/iyfoox3hfCAGUD6GJ2C ewjYJsnY8M7eRrkEqsie+CvT1K+qYnD39+X00Y4B3/Uih1Z1SEYWn7wxwmWwz2bzDRnW eTSY+Or8sYJbfcBOm/lPRxACdsXEFKQUVFRToaiU5Y6mSYG/tXs5okzveYZGDA06NL/F 1UNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SLvg33MYfJv9ZdDVm9GoEIS0c8mrdoljUJ726UeCWHU=; b=cp6ChFB7M2reagmFJ1x4zYL3tr97dOrK33vNo2/xrAcMzC37NGDy7gkWePpLOBymJ6 0PlL8jlskHGMcXpCVrTPLB1zfgEJNWy0k+M0GQTzTuYWnITq458zAtfm6pY0/NbdKko2 /QZ0KPUwD7OkjaPV6JLM++fmL5dFjgg9CGwLPO+GynnXwiXnROtb9s+8JWZvQdD6iGnG Chy1lZBoxMXumSU7zMoqTQapXgzNEwOQHcr9lOJkfkCi80n0J1JwDPim7PPpIXZP/DfY uDCEAblb2KkfBOzaw0RI76Y1zhCr3vLLYUQYTBTqkDevqZdX8fs0a14sMk91yA8olAc1 ppfg==
X-Gm-Message-State: APjAAAXn0S5Eiu51Qc5SJNzSvZE04+ZhcjMYYHgsRviek+VcAzeTr7l5 iQdV9+Vsmei1P0e/SZGpcWITYM/hQIpvNQWYoUC9j91H
X-Google-Smtp-Source: APXvYqxEMGl5j3ibi/Er1LfHLR+111aiPsJB9r6Lxr48sCwcP58lHZjlX6ZJAcKBHhcHhSxPRcp5s34Vbnfm3h/Tj9Q=
X-Received: by 2002:a17:906:3385:: with SMTP id v5mr9824984eja.301.1559135521255; Wed, 29 May 2019 06:12:01 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 29 May 2019 09:12:00 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Wed, 29 May 2019 09:12:00 -0400
Message-ID: <>
To: Benjamin Kaduk <>, The IESG <>
Cc:,, Stig Venaas <>,
Content-Type: multipart/alternative; boundary="000000000000e6b6f2058a068656"
Archived-At: <>
Subject: Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-yang-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 May 2019 13:12:06 -0000

On May 26, 2019 at 10:15:05 PM, Benjamin Kaduk via Datatracker ( wrote:




I agree with Mirja that reiterating the privacy considerations of
explicit tracking of group membership (with pointer to the relevant
IGMP/MLD protocol documents) would be worthwhile.
Normally I would leave this as a Comment on the assumption that the
privacy considerations are already documented in the protocol
specification that documents explicit tracking, but I could not find
such a document (with privacy considerations listed) in a quick search;
I found RFC 6636 and draft-ietf-pim-explicit-tracking but probably
missed a few others.

Let's talk about what the current state actually is, and where it's best
to document the privacy considerations (which is not necessarily this
document, a priori).

Let’s first take a step back.  IGMP/MLD have the function of managing
multicast groups, as MLD’s name (Multicast Listener Discovery) suggests,
the protocols already collect information related to which hosts are
interested in which multicast groups.  §3 of rfc6636 has a good description:

   Mobile hosts use IGMP and MLD to make a request to join or leave
   multicast sessions.  When an adjacent upstream router receives the
   IGMP/MLD Report messages, it recognizes the membership status on the
   link.  To update the membership status reliably, the router sends
   IGMP/MLD Query messages periodically, and sends Group-Specific and/or
   Group-and-Source-Specific Queries when a member host reports its
   leave.  An IGMP/MLD Query is therefore necessary to obtain up-to-date
   membership information, but a large number of the reply messages sent
   from all member hosts may cause network congestion or consume network

“Explicit Membership Tracking” is simply the realization of the ability of
the router to remember the membership to save network resources and shorten
group leave time.  Yes, the name is probably not the best, specially if
we’re worried about privacy, but the protocols already expose that
information.  IOW, the ability to know the hosts is not new.

Note that anyone on the link can listen to the Reports…so there’s no need
to get access to the YANG information, or even implement explicit tracking,
to know which host is interested in what.  From that point of view, I think
that any privacy consideration should have been in the IGMP/MLD specs
(rfc3376/rfc3810), but those documents only focus their Security
Considerations on the impact/mitigation of forged messages.

draft-ietf-pim-explicit-tracking had the intent of specifying Explicit
Membership Tracking.  However, a couple of attempts for publication have
resulted in the document being sent back to the WG, first as a result of
the IESG Evaluation…and later my me.  In both cases the reason can be
summarized as there not being enough clarity for it to be in the Standards
Track.  The WG seems to have lost interest…. As described there, there are
"various ways to implement the explicit tracking function…[it] does not
change on-wire behavior, and the function or mechanisms described in this
document do not break the interoperability between the existing
implementations and the implementation based on this specification.”  IOW,
multiple implementations can co-exist...

Having said that, I don’t think the YANG module is the right place to
document the privacy considerations of information that has existed in the
protocols “forever" (IGMPv1 was specified in rfc1112 and MLDv1 in rfc2710).