Subject: Re: [Last-Call] Last Call: <draft-ietf-pim-msdp-yang-08.txt> (A YANG Data Model for Multicast Source Discovery Protocol (MSDP)) to Proposed Standard

From: tom petch <[email-masked]>
Date: Wed, 22 Jan 2020 16:20:41 +0000

RFC8349 says that a new identity MUST be defined for a new control plane protocol - I see no such definition here

RFC8349 says that augments should be to control-plane-protocols/control-plane-protocol as is seen in the OSPF and the other LSR YANG modules; here I see an augment to control-plane-protocols which seems wrong to me

many features but no idea where to look them up - I think every YANG feature needs a YANG reference to an I-D/RFC

I find a list of features and references in the body of an I-D valuable

YANG modules must be plain text; [3618] in the module description does not look like plain text. Other references e.g. RFC8177 look ok although some have a space in them and some do not

leaf tcp-connection-source says that ipv4 must be enabled but the when statement does not test for enabled, just for configured

rpc clear peer clears everything if there is no address - this is fail danger, a specific value for clear all would IMHO be better engineering

XXXX is likely to mean this I-D/RFC but I always like to see a specific direction to the RFC Editor to that effect, just the once, somewhere near the front.

In the same vein, a direction to replace the dates with date of publication  would not go amiss

Tom Petch
________________________________________
From: IETF-Announce <[email-masked]> on behalf of The IESG <[email-masked]>
Sent: 15 January 2020 20:29
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Last Call: <draft-ietf-pim-msdp-yang-08.txt> (A YANG Data Model for Multicast Source Discovery Protocol (MSDP)) to Proposed Standard

The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'A YANG Data Model for Multicast Source
Discovery Protocol (MSDP)'
  <draft-ietf-pim-msdp-yang-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-01-30. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document defines a YANG data model for the configuration and
   management of Multicast Source Discovery Protocol (MSDP) Protocol.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-msdp-yang/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pim-msdp-yang/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: <[email-masked]>
Date: Thu, 23 Jan 2020 16:00:19 +0800 (CST)

Hi Tom,

Thank you very much for your review!

I updated the draft to 11 version. 

About the RFC number, I'll update the draft when I get the number. :-)

Thanks,

Sandy

原始邮件

发件人：tompetch <[email-masked]>
收件人：IETF-Announce <[email-masked]>;[email-masked] <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年01月23日 00:21
主 题 ：Re: [pim] Last Call: <draft-ietf-pim-msdp-yang-08.txt> (A YANG DataModel for Multicast Source Discovery Protocol (MSDP)) to Proposed Standard

Tom Petch

Abstract

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: <[email-masked]>
Date: Fri, 24 Jan 2020 09:27:27 +0800 (CST)

Hi Tom,

Please review the newest 12 version.

Thank you very much! :-)

Best regards,

Sandy

原始邮件

Tom Petch

Abstract

---

From: tom petch <[email-masked]>
Date: Tue, 28 Jan 2020 11:19:14 +0000

> Please review the newest 12 version.

You do not seem to have responded to some of my comments.

Yes, the augment is now in the right place but ..
the description says that it is only valid MSDP but there is no 'when' 
statement to enforce this.

On the other hand, identity now appears but is conditional; this would 
seem to me to make it of limited value - I do not see that conditional 
in other YANG modules.

Features need YANG reference clauses IMHO and I like a list in the body 
of the I-D as well

The RFC number is not something you insert.  The RFC Editor allocates 
and inserts it.  Although it is the convention to use XXXX as a 
placeholder, I think it helpful to include a note up front asking them 
to replace XXXX with the assigned number (many I-Ds have references to 
more than one I-D so it is helpful to be explicit about what is XXXX and 
what is YYYY although that is not an issue here)

tcp-connection-source is still testing for IPv4 configured, not as the 
description says enabled

I note too that you have six authors; the limit is normally five unless 
this has been agreed by the AD.

Tom Petch

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 28 Jan 2020 10:01:45 -0500

Tom:

Hi!

Just responding to the authors list:  yes, that has been discussed and I’m
ok with moving forward with 6.

Thank you for your detailed review!

Alvaro.

On January 28, 2020 at 6:31:01 AM, tom petch ([email-masked]) wrote: