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 <ietfid@xxxxxxxxxxxxx>
收件人：IETF-Announce <ietf-announce@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;
抄送人：pim-chairs@xxxxxxxx <pim-chairs@xxxxxxxx>;pim@xxxxxxxx <pim@xxxxxxxx>;draft-ietf-pim-msdp-yang@xxxxxxxx <draft-ietf-pim-msdp-yang@xxxxxxxx>;
日 期 ：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
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
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 <ietf-announce-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx>
Sent: 15 January 2020 20:29
To: IETF-Announce
Cc: draft-ietf-pim-msdp-yang@xxxxxxxx; pim-chairs@xxxxxxxx; pim@xxxxxxxx
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
last-call@xxxxxxxx mailing lists by 2020-01-30. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
pim mailing list
pim@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pim
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 <ietf-announce-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx>
Sent: 15 January 2020 20:29
To: IETF-Announce
Cc: draft-ietf-pim-msdp-yang@xxxxxxxx; pim-chairs@xxxxxxxx; pim@xxxxxxxx
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
last-call@xxxxxxxx mailing lists by 2020-01-30. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
pim mailing list
pim@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pim
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
