Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-yang-13: (with DISCUSS and COMMENT)
Xufeng Liu <xufeng.liu.ietf@gmail.com> Tue, 28 May 2019 14:19 UTC
Return-Path: <xufeng.liu.ietf@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629B412017A; Tue, 28 May 2019 07:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHjx-pa5YVqC; Tue, 28 May 2019 07:19:06 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1070312015E; Tue, 28 May 2019 07:19:06 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id g16so15852363iom.9; Tue, 28 May 2019 07:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I2LsZUWdjTYnkdDrx5IYHiMmE4PMV+XV3VHuGYooZbg=; b=Z9rJlDFSSCvZduohLaKax+U5XPn6ktsVSwLY85kg2aMEvwMZTY974OgfPNwEIQ9rw7 hwUOg+Tfr+EUkKk4Na4i9ogtljdA3DQG7KVUag9QMHYkkXEnP02Wn8cHKmuLsgNqVlvk wgtpGMpGCwsdcRU4QC5DaiARisGUdURGKMuUBtl/2/Fgyq+jJJs6oYTa7JDZJ3fCU5yU ZZTFhTokHM4HPrsw2ES5i/7+d74kTWYPYtuEXWwi2YN9j7B9gxg1g2bzYgzLG7OYhv/R I1JU9s8vqbgxScncvRHcBfxbqoRWikw7yYR/AFJpvaiJi6t+jvHwP7F1giZO/1GVKpD6 ScAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I2LsZUWdjTYnkdDrx5IYHiMmE4PMV+XV3VHuGYooZbg=; b=jT3KkQh+Soz3XVd6rgWdH866LBPS3QtHsQ41+HlIKtESg8rmfUDA0TVw3KW1PQ2pQB y3Y5R8mM7Q4/FNsR4wYHEd9GpK5tcupe4vFdBXWm7u4+czLlefrMCQCCeOiHo4Uz8miD xH1sNC+YmMLrKLq+Wn7nfexGS6sESDfqn5zu03TD0q0ZzMNTpsMeD2BigV/QHA7lWIjf XYlPQbWvsv//z9edrTILT9S5M4mm+QQ1Fs3Tfofpr2BE+8b40bNPafPh63NCX7fjmYav LvWiYybJwt1a34vYn0hpPOb97oN7bAz4d4g4RGwBxcDp3m9j++vklL99HPm3rfyLQUoP VGXg==
X-Gm-Message-State: APjAAAVl3KUCJ0dUUo4Pi1tQGAxLwQt70KzpOMUsNjCYt70mAJjw4dLi XS8Tv7MxM3XBJ5t14lX1qp8T42Wk39y4D3pFoAs=
X-Google-Smtp-Source: APXvYqw2yK96Vsv5QxViGu350CTKhZ9GD1E9wZic7WFQtzS8ir9Go7CQqNBNYN7JNkpsU03SfmFcgOjDbJwFH2Fn874=
X-Received: by 2002:a6b:bf01:: with SMTP id p1mr9192012iof.181.1559053145197; Tue, 28 May 2019 07:19:05 -0700 (PDT)
MIME-Version: 1.0
References: <155892330463.6040.689041510063921681.idtracker@ietfa.amsl.com>
In-Reply-To: <155892330463.6040.689041510063921681.idtracker@ietfa.amsl.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Tue, 28 May 2019 10:18:54 -0400
Message-ID: <CAEz6PPQBx3v1ZYPmOA02X08ih95dXHxHnja1wh_z=CHEhCx=Sw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pim-igmp-mld-yang@ietf.org, Stig Venaas <stig@venaas.com>, Alvaro Retana <aretana.ietf@gmail.com>, pim-chairs@ietf.org, pim@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e7cf7e0589f35884"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/7ofzR5j8ELaQhPDLSNYEvkMjjcQ>
Subject: Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-igmp-mld-yang-13: (with DISCUSS and COMMENT)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 14:19:09 -0000
Hi Benjamin, Thanks for the review. A little more on the discussion below. Best regards, - Xufeng On Sun, May 26, 2019 at 10:15 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-pim-igmp-mld-yang-13: 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://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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). > [Xufeng]: Understand the conern about the insufficient decription in RFC6636 and draft-ietf-pim-explicit-tracking. We are ok to add more description in this document, as proposed in the reply to Mirja's comment. Would the change be ok? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Other than my Discuss point, basically all I have is editorial nits -- > thanks for > the well-written document! [Xufeng]: Thanks for these. We will fix them in the new revision, and post the updates soon. > > Section 2.1 > > Even though there is no protocol > specific notifications are defined in this model, the subscription > > nit: s/there is// -- the "are defined in this model" takes care of > the grammatical necessities here. > and push mechanism defined in [I-D.ietf-netconf-subscribed- > notifications] and [I-D.ietf-netconf-yang-push] can be used by the > user to subscribe notifications on the data nodes in this model. > > nit: "subscribe to notifications" > > The model contains all basic configuration parameters to operate the > protocols listed above. Depending on the implementation choices, > > nit: "all the basic" > > Section 4 > > grouping interface-common-config-attributes { > [...] > leaf query-interval { > [...] > description > "The Query Interval is the interval between General Queries > sent by the Querier.In RFC3376, Querier's Query > Interval(QQI) is represented from the Querier's Query > Interval Code in query message as follows: > > nit: one or two (not zero) spaces after the end of the sentence. > nit: "In RFC3376, the Querier's Query Interval (QQI)" > > leaf exclude-lite { > if-feature intf-exclude-lite; > > side-note: I misparsed this (I think) the first few times I read it, > since "exclude lite" can be taken as an imperative command to not use > the lite version. But it seems this is really just an ordinary > feature-enablment tag about whether to use the EXCLUDE filtering that > is available in the lite version of the protocol. I don't know whether > reordering to "lite-exclude" would be a net win or net loss due to > causing some other confusion, though. > [Xufeng]: Understand the confusion. "exlude" has its special meaning (which a type of filter) here, but the leaf name does not show it. Would "lite-exclude-filter" or "exclude-filter-lite" a bitter better? > > grouping interface-state-attributes-igmp { > [...] > list group { > [...] > list source { > [...] > list host { > [...] > leaf host-address { > type inet:ipv4-address; > description > "The IPv6 address of the host."; > > nit: "ipv6-address" > > grouping interface-state-group-attributes-igmp-mld { > > nit: I thought most of the other shared groupings just didn't use a > suffix, as opposed to using the "-igmp-mld" combined suffix. > (Similarly for interface-state-source-attributes-igmp-mld and > interface-state-host-attributes-igmp-mld, which does cause me to wonder > if I'm not perceiving "most" correctly.) > > Section 5 > > igmp-mld:global > > This subtree specifies the configuration for the IGMP attributes > at the global level on an IGMP instance. Modifying the > configuration can cause IGMP membership deleted or reconstructed > on all the interfaces of an IGMP instance. > > nit: "to be deleted or reconstructed" (Similarly for the following > paragraphs.) > > The description of the considerations for unauthorized read access are > fairly generic and do not specify specific potential harms, but I will > not insist on any changes here. > > >
- [pim] Benjamin Kaduk's Discuss on draft-ietf-pim-… Benjamin Kaduk via Datatracker
- Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-… Xufeng Liu
- Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-… Alvaro Retana
- Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-… Xufeng Liu
- Re: [pim] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk