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.
>
>
>