Return-Path: 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 Date: Tue, 28 May 2019 10:18:54 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-pim-igmp-mld-yang@ietf.org, Stig Venaas , Alvaro Retana , pim-chairs@ietf.org, pim@ietf.org Content-Type: multipart/alternative; boundary="000000000000e7cf7e0589f35884" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 14:19:09 -0000 --000000000000e7cf7e0589f35884 Content-Type: text/plain; charset="UTF-8" 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. > > > --000000000000e7cf7e0589f35884 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 Datat= racker <noreply@ietf.org> wro= te:
Benjamin Kad= uk 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/s= tatement/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).
=09 =09 =09

[Xufeng]: Understand the conern about the insufficient decription in= RFC6636 and draft-ietf-pim-explicit-tracking. We are ok to add more descri= ption in this document, as proposed in the reply to Mirja's comment. Wo= uld the change be ok?

=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Other than my Discuss point, basically all I have is editorial nits -- than= ks 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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Even though there is no= protocol
=C2=A0 =C2=A0specific notifications are defined in this model, the subscrip= tion

nit: s/there is// -- the "are defined in this model" takes care o= f
the grammatical necessities here.
=C2=A0 =C2=A0and push mechanism defined in [I-D.ietf-netconf-subscribed- =C2=A0 =C2=A0notifications] and [I-D.ietf-netconf-yang-push] can be used by= the
=C2=A0 =C2=A0user to subscribe notifications on the data nodes in this mode= l.

nit: "subscribe to notifications"

=C2=A0 =C2=A0The model contains all basic configuration parameters to opera= te the
=C2=A0 =C2=A0protocols listed above. Depending on the implementation choice= s,

nit: "all the basic"

Section 4

=C2=A0 =C2=A0 =C2=A0grouping interface-common-config-attributes {
=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf query-interval {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The Query Interval is the in= terval between General Queries
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent by the Querier.In RFC3376, Q= uerier's Query
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interval(QQI) is represented from= the Querier's Query
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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)"

=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf exclude-lite {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-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.=C2=A0 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.=C2=A0 I don't know wh= ether
reordering to "lite-exclude" would be a net win or net loss due t= o
causing some other confusion, though.
[Xufeng]: Understand the confusion. &quo= t;exlude" has its special meaning (which a type of filter) here, but t= he leaf name does not show it. Would "lite-exclude-filter" or &qu= ot;exclude-filter-lite&q= uot; a bitter better?

=C2=A0 =C2=A0 =C2=A0grouping interface-state-attributes-igmp {
=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0list group {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list source {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list host {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf host-address {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-addre= ss;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The IPv= 6 address of the host.";

nit: "ipv6-address"

=C2=A0 =C2=A0 =C2=A0grouping 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

=C2=A0 =C2=A0igmp-mld:global

=C2=A0 =C2=A0 =C2=A0This subtree specifies the configuration for the IGMP a= ttributes
=C2=A0 =C2=A0 =C2=A0at the global level on an IGMP instance.=C2=A0 Modifyin= g the
=C2=A0 =C2=A0 =C2=A0configuration can cause IGMP membership deleted or reco= nstructed
=C2=A0 =C2=A0 =C2=A0on all the interfaces of an IGMP instance.

nit: "to be deleted or reconstructed"=C2=A0 (Similarly for the fo= llowing
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.


--000000000000e7cf7e0589f35884--