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 E16901201A0; Wed, 29 May 2019 20:40:13 -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 oWi1BL_NdJQa; Wed, 29 May 2019 20:40:10 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 767FE12000F; Wed, 29 May 2019 20:40:10 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id e3so3819628ioc.12; Wed, 29 May 2019 20:40:10 -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=1H8bfku3RbaxUY9uZ4as2OdUKqs2Tuydz3X2mLPwqbU=; b=TcLoz8v9QP2z956gwbtow+dPtizNIQvzkIx83QtKomPswEK0faozbsd74WVKA7PlAs cAM4eT5uadadlLJPd8W3BJ08sTk7hDmH4pzf005PHa1AGruzgpXjZnj3QSyjsmzHLufO h56tNS7IDE8ADN1y1AA7wc2mpp4PkGBBDXzWm2a5htDdhHH6re8wglwwY/LnLVz7kZFY ytbzPK+1n8ftFjz6HvgJerm9gOIC7SmKc5GzRWbwP3PtvfyDFKfhOxp1Ns35ECFqVkS7 U7fLkB9ivi9EC3aaIYCHVimYjcBJJ6V3VEYpXkqhsMZ8LIj+7u6HhU4ITFXkv2A3yJ31 9wNg== 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=1H8bfku3RbaxUY9uZ4as2OdUKqs2Tuydz3X2mLPwqbU=; b=lEcEpCVAoDxy4PoAXo1pehGXmPX+ZIMcvVINvJEslTbpJJMPns9qJrmnYyMxopnhXc bcr8aAX2U05ktFexT0lJ1MC2bkhObmqyCcQeWYd1yewWirI24xm/S2Diq5L3iQfIvmhq 8bOdo2EOfQtMjxZLPesR/dTyiJPV+rMPNv/zzAIiCsgxtT2wbCGzkE+JQapLriHbiYxj rDCVXy+cN/5pJz2rOknsVPXcbMLDmt3fWVNtcMORbkQuKrAtVRVBPFRNg6E1FwJd8Btx XdHpANl/IoBOjqwAoaEmwBOLnPE0VGClFJHMtoMT+kiV8gUcrWAawizEp0ZrXPTcmVgb 093g== X-Gm-Message-State: APjAAAVev0ys6XD5JLjcbTZ7+qfSPakDc96Yhm9WbAVUavCsnP3ljcnp YHVvBWVIHmiVRq9MUI9CJ1NTcV/nO60AlsYRPZs= X-Google-Smtp-Source: APXvYqycn2T6UhgrwxZqHUaaLJ8ppgk9q/WtHlW1JQ3T8MKPkFv9mcdudRNPqQh2HmKtEU/+FMi6P+MOkymv9xWG88E= X-Received: by 2002:a5d:81d5:: with SMTP id t21mr1105996iol.119.1559187609683; Wed, 29 May 2019 20:40:09 -0700 (PDT) MIME-Version: 1.0 References: <155913814501.5477.15583573702686809097.idtracker@ietfa.amsl.com> In-Reply-To: <155913814501.5477.15583573702686809097.idtracker@ietfa.amsl.com> From: Xufeng Liu Date: Wed, 29 May 2019 23:39:58 -0400 Message-ID: To: Roman Danyliw 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="0000000000009d0b32058a12a76e" Archived-At: Subject: Re: [pim] Roman Danyliw's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with 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: Thu, 30 May 2019 03:40:14 -0000 --0000000000009d0b32058a12a76e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks for the review. We have posted an updated revision https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-14, to address these issues. Regards, - Xufeng On Wed, May 29, 2019 at 9:55 AM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-pim-igmp-mld-yang-13: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) I support Ben Kaduk=E2=80=99s DISCUSS about privacy considerations. > > (2) Thanks for Section 1.3. This upfront cross-reference was very helpfu= l! > > (3) Section 2.2. > On the other hand, operational state parameters are not so widely > designated as features, as there are many cases where the defaulting > of an operational state parameter would not cause any harm to the > system, and it is much more likely that an implementation without > native support for a piece of operational state would be able to > derive a suitable value for a state variable that is not natively > supported. > > I struggled to understand this very dense single sentence paragraph. > -- What does it mean for =E2=80=9Coperational state parameters are not so= widely > designated as features=E2=80=9D? [Xufeng]: In the modeling language YANG, an optional section (that can be a group of parameters) may be marked as a YANG =E2=80=9Cfeature=E2=80=9D, mea= ning that this section is =E2=80=9Coptionally=E2=80=9D supported by an implementation. If = an implementation supports this =E2=80=9Cfeature=E2=80=9D, the name and status= of this feature are sent to the client. In the design of this model, we do not use many such =E2=80=9Cfeatures=E2=80=9D for operational states. The result is that = an implementation will have to return the values of the states, without the option of not implementing them. > -- What is a =E2=80=9Cdefaulting of an operational state > parameter=E2=80=9D? [Xufeng]: As mentioned in the previous paragraph, an implementation needs to return many of the states specified in this model without the vendor=E2= =80=99s choice. Usually the states that an implementation would want to opt-out are these states that are not critical for the protocol to operate, and the implementation usually has used a default value. Therefore, the implementation may always return the default value when the client ask for such a state, hence the phrase =E2=80=9Cdefaulting of an operational state parameter=E2=80=9D. If better wording can make this paragraph more comprehensible, please advise. > > (4) Section 3. Does the sentence =E2=80=9CThis model augments the core r= outing > data > model specification in [RFC8349]=E2=80=9D suggest that this draft should = update > [RFC8349]? > [Xufeng]: The suggestion is logically correct, but the current practice for YANG model document is not to update the base model [RFC8349], but to make a reference to it. I think that it is because of the modular and extensible natures of YANG, there could be hundreds of models augmenting a base model, both inside and outside of IETF. > > (5) Reference Nits > ** Section 1. I would have expected a reference to NMDA (i.e., > [RFC8342]). > This is done later in the draft but not the first time it is mentioned > (here). > [Xufeng]: Added. > > ** idnits returned the following valid reference issues: > > =3D=3D Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on = line > 178, but not defined > [Xufeng]: Added. > > =3D=3D Missing Reference: 'RFC 8446' is mentioned on line 1910, but not > defined > [Xufeng]: Added. > > =3D=3D Missing Reference: 'RFC8341' is mentioned on line 1912, but not > defined > [Xufeng]: Added. > > =3D=3D Unused Reference: 'RFC5246' is defined on line 2085, but no expl= icit > reference was found in the text > [Xufeng]: Removed. > > =3D=3D Unused Reference: 'RFC6536' is defined on line 2099, but no expl= icit > reference was found in the text > [Xufeng]: Removed. > > =3D=3D Unused Reference: 'RFC5790' is defined on line 2145, but no expl= icit > reference was found in the text > [Xufeng]: Fixed. > > ** Downref: Normative reference to an Informational RFC: RFC 3569 > [Xufeng]: Fixed as Alvaro suggested. > > ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) > [Xufeng]: Removed > > ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) > [Xufeng]: Removed > > (6) Editorial Nits > > ** Section 2.1. The sentence =E2=80=9CEven though there is no protocol s= pecific > notifications are defined in this model, the subscription and push > mechanism > defined in [I-D.ietf-netconf-subscribed- notifications] and > [I-D.ietf-netconf-yang-push]=E2=80=9D doesn=E2=80=99t parse. Likely remo= ve the =E2=80=9Care=E2=80=9D. > [Xufeng]: Fixed > > ** Section 2.1. Per the sentence =E2=80=9CDepending on the implementatio= n choices, > some systems may not allow some of the advanced parameters configurable= =E2=80=9D, > what is a =E2=80=9Cadvanced parameters configurable=E2=80=9D? I think th= ere is a typo > there. > [Xufeng]: Fixed. > > ** Section 2.3. Per =E2=80=9CThe current document defines =E2=80=A6=E2= =80=9D, shouldn=E2=80=99t this > just be > =E2=80=9CThe document defines =E2=80=A6=E2=80=9D since when published as = an RFC there would be no > notion of versioning as suggested by =E2=80=9Ccurrent=E2=80=9D? > [Xufeng]: Edited. > > ** Section 2.3. s/supports and only supports/only supports/ > [Xufeng]: Fixed. > > ** Section 4. Typo. s/refered/referred/ > [Xufeng]: Fixed. > > ** Section 4. Missing space. /Querier.In RFC3376,/Querier. In RFC3376,/ > [Xufeng]: Fixed. --0000000000009d0b32058a12a76e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

T= hanks for the review. We have posted an updated revision https://tools.ietf.or= g/html/draft-ietf-pim-igmp-mld-yang-14, to address these issues.
<= div>
Regards,
- Xufeng

On Wed, May 29, 201= 9 at 9:55 AM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has entered the following ballot posi= tion for
draft-ietf-pim-igmp-mld-yang-13: No Objection

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/



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

(1) I support Ben Kaduk=E2=80=99s DISCUSS about privacy considerations.

(2) Thanks for Section 1.3.=C2=A0 This upfront cross-reference was very hel= pful!

(3) Section 2.2.
=C2=A0 =C2=A0On the other hand, operational state parameters are not so wid= ely
=C2=A0 =C2=A0designated as features, as there are many cases where the defa= ulting
=C2=A0 =C2=A0of an operational state parameter would not cause any harm to = the
=C2=A0 =C2=A0system, and it is much more likely that an implementation with= out
=C2=A0 =C2=A0native support for a piece of operational state would be able = to
=C2=A0 =C2=A0derive a suitable value for a state variable that is not nativ= ely
=C2=A0 =C2=A0supported.

I struggled to understand this very dense single sentence paragraph.
-- What does it mean for =E2=80=9Coperational state parameters are not so w= idely
designated as features=E2=80=9D?
=09 =09 =09

[Xufeng]: In the modeling language YANG, an optional section (that can be a group of parameters) may be marked as a YANG =E2=80=9Cfeature=E2=80=9D, meaning t= hat this section is =E2=80=9Coptionally=E2=80=9D supported by an implementation= . If an implementation supports this =E2=80=9Cfeature=E2=80=9D, the name and sta= tus of this feature are sent to the client. In the design of this model, we do not use many such =E2=80=9Cfeatures=E2=80=9D for operational states. The result is that an implementation will have to return the values of the states, without the option of not implementing them.

=C2=A0
-- What is a = =E2=80=9Cdefaulting of an operational state
parameter=E2=80=9D?=C2=A0 =09 =09 =09

[Xufeng]: As mentioned in the previous paragraph, an implementation needs to return many of the states specified in this model without the vendor=E2=80=99s choice. Usually the states that an implementation would want to opt-out are these states that are not critical for the protocol to operate, and the implementation usually has used a default value. Therefore, the implementation may always return the default value when the client ask for such a state, hence the phrase =E2=80=9Cdefaulting of an operational state parameter=E2=80=9D.

If better wording can make this paragraph more comprehensible, please advise.


(4) Section 3.=C2=A0 Does the sentence =E2=80=9CThis model augments the cor= e routing data
model specification in [RFC8349]=E2=80=9D suggest that this draft should up= date
[RFC8349]?
=09 =09 =09

[Xufeng]: The suggestion is logically correct, but the current practice for YANG model document is not to update the base model [RFC8349], but to make a reference to it. I think that it is because of the modular and extensible natures of YANG, there could be hundreds of models augmenting a base model, both inside and outside of IETF.


(5) Reference Nits
** Section 1.=C2=A0 I would have expected a reference to NMDA (i.e., [RFC83= 42]).
This is done later in the draft but not the first time it is mentioned (her= e).
=09 =09 =09

[Xufeng]: Added.


** idnits returned the following valid reference issues:

=C2=A0 =3D=3D Missing Reference: 'I-D.ietf-netconf-yang-push' is me= ntioned on line
=C2=A0 =C2=A0 =C2=A0178, but not defined
=09 =09 =09

[Xufeng]: Added.

=C2=A0

=C2=A0 =3D=3D Missing Reference: 'RFC 8446' is mentioned on line 19= 10, but not defined
=09 =09 =09

[Xufeng]: Added.

=C2=A0

=C2=A0 =3D=3D Missing Reference: 'RFC8341' is mentioned on line 191= 2, but not defined
=09 =09 =09

[Xufeng]: Added.

=C2=A0

=C2=A0 =3D=3D Unused Reference: 'RFC5246' is defined on line 2085, = but no explicit
=C2=A0 =C2=A0 =C2=A0reference was found in the text
=09 =09 =09

[Xufeng]: Removed.

=C2=A0

=C2=A0 =3D=3D Unused Reference: 'RFC6536' is defined on line 2099, = but no explicit
=C2=A0 =C2=A0 =C2=A0reference was found in the text
=09 =09 =09

[Xufeng]: Removed.

=C2=A0

=C2=A0 =3D=3D Unused Reference: 'RFC5790' is defined on line 2145, = but no explicit
=C2=A0 =C2=A0 =C2=A0reference was found in the text
=09 =09 =09

[Xufeng]: Fixed.

=C2=A0

=C2=A0 ** Downref: Normative reference to an Informational RFC: RFC 3569
=09 =09 =09

[Xufeng]: Fixed as Alvaro suggested.

=C2=A0

=C2=A0 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
=09 =09 =09

[Xufeng]: Removed

=C2=A0

=C2=A0 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
=09 =09 =09

[Xufeng]: Removed

=C2=A0

(6) Editorial Nits

** Section 2.1.=C2=A0 The sentence =E2=80=9CEven though there is no protoco= l specific
notifications are defined in this model, the subscription and push mechanis= m
defined in [I-D.ietf-netconf-subscribed-=C2=A0 =C2=A0notifications] and
[I-D.ietf-netconf-yang-push]=E2=80=9D doesn=E2=80=99t parse.=C2=A0 Likely r= emove the =E2=80=9Care=E2=80=9D.
=09 =09 =09

[Xufeng]: Fixed

=C2=A0

** Section 2.1.=C2=A0 Per the sentence =E2=80=9CDepending on the implementa= tion choices,
some systems may not allow some of the advanced parameters=C2=A0 =C2=A0conf= igurable=E2=80=9D,
what is a =E2=80=9Cadvanced parameters configurable=E2=80=9D?=C2=A0 I think= there is a typo there.
=09 =09 =09

[Xufeng]: Fixed.

=C2=A0

**=C2=A0 Section 2.3.=C2=A0 Per =E2=80=9CThe current document defines =E2= =80=A6=E2=80=9D, shouldn=E2=80=99t this just be
=E2=80=9CThe document defines =E2=80=A6=E2=80=9D since when published as an= RFC there would be no
notion of versioning as suggested by =E2=80=9Ccurrent=E2=80=9D?
=09 =09 =09

[Xufeng]: Edited.

=C2=A0

** Section 2.3.=C2=A0 s/supports and only supports/only supports/
=09 =09 =09

[Xufeng]: Fixed.

=C2=A0

** Section 4.=C2=A0 Typo.=C2=A0 s/refered/referred/
=09 =09 =09

[Xufeng]: Fixed.

=C2=A0

** Section 4. Missing space.=C2=A0 /Querier.In RFC3376,/Querier. In RFC3376= ,/
=09 =09 =09

[Xufeng]: Fixed.

=C2=A0
--0000000000009d0b32058a12a76e--