A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping
draft-ietf-pim-igmp-mld-snooping-yang-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
20 | Gunter Van de Velde | Request closed, assignment withdrawn: Joe Clarke Last Call OPSDIR review |
2024-01-26
|
20 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-01-31
|
20 | (System) | Received changes through RFC Editor sync (created alias RFC 9166, changed title to 'A YANG Data Model for Internet Group Management Protocol (IGMP) and … Received changes through RFC Editor sync (created alias RFC 9166, changed title to 'A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping', changed abstract to 'This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping devices. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).', changed pages to 37, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-02-01, changed IESG state to RFC Published) |
2022-01-27
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-12-21
|
20 | (System) | RFC Editor state changed to AUTH48 |
2021-10-25
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-10-11
|
20 | (System) | RFC Editor state changed to EDIT from IESG |
2021-10-08
|
20 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-20.txt |
2021-10-08
|
20 | (System) | New version approved |
2021-10-08
|
20 | (System) | Request for posting confirmation emailed to previous authors: Anish Peter , Hongji Zhao , Mahesh Sivakumar , Xufeng Liu , Yisong Liu |
2021-10-08
|
20 | Hongji Zhao | Uploaded new revision |
2021-09-29
|
19 | Reshad Rahman | Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Reshad Rahman. Sent review to list. |
2021-09-17
|
19 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Reshad Rahman |
2021-09-17
|
19 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Reshad Rahman |
2021-09-16
|
19 | Alvaro Retana | Requested Last Call review by YANGDOCTORS |
2021-08-24
|
19 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-19.txt |
2021-08-24
|
19 | (System) | New version approved |
2021-08-24
|
19 | (System) | Request for posting confirmation emailed to previous authors: Anish Peter , Hongji Zhao , Mahesh Sivakumar , Xufeng Liu , Yisong Liu |
2021-08-24
|
19 | Hongji Zhao | Uploaded new revision |
2021-08-20
|
18 | (System) | RFC Editor state changed to IESG from MISSREF |
2020-09-01
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-09-01
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-09-01
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-08-26
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-08-25
|
18 | (System) | RFC Editor state changed to MISSREF |
2020-08-25
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-08-25
|
18 | (System) | Announcement was received by RFC Editor |
2020-08-25
|
18 | (System) | IANA Action state changed to In Progress |
2020-08-25
|
18 | Amy Vezza | Downref to RFC 6636 approved by Last Call for draft-ietf-pim-igmp-mld-snooping-yang-18 |
2020-08-25
|
18 | Amy Vezza | Downref to RFC 4541 approved by Last Call for draft-ietf-pim-igmp-mld-snooping-yang-18 |
2020-08-25
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-08-25
|
18 | Amy Vezza | IESG has approved the document |
2020-08-25
|
18 | Amy Vezza | Closed "Approve" ballot |
2020-08-25
|
18 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-08-25
|
18 | Alvaro Retana | Ballot approval text was generated |
2020-08-21
|
18 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss (and Comment!) points! |
2020-08-21
|
18 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-08-14
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-08-14
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-08-14
|
18 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-18.txt |
2020-08-14
|
18 | (System) | New version approved |
2020-08-14
|
18 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Hongji Zhao , Yisong Liu |
2020-08-14
|
18 | Hongji Zhao | Uploaded new revision |
2020-07-21
|
17 | Alvaro Retana | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2020-07-21
|
17 | Robert Wilton | [Ballot comment] Discussed cleared. Previous discuss comment: Hi, I appreciate that this YANG model has already passed a YANG doctor review, but this discuss is … [Ballot comment] Discussed cleared. Previous discuss comment: Hi, I appreciate that this YANG model has already passed a YANG doctor review, but this discuss is to understand the reasoning as to why both IGMP snooping and MLD snooping are in the same YANG module, yet have top level features to separate their functionality. 4. IGMP and MLD Snooping YANG Module feature igmp-snooping { description "Support IGMP snooping."; reference "RFC 4541"; } feature mld-snooping { description "Support MLD snooping."; reference "RFC 4541"; } It seems strange to me to have the entire YANG Model split under two separate feature statements. I believe that it would have been better to split this into two separate YANG models, both following the same structure. Possibly, a common YANG module could have been used to share groupings and definitions, but even then duplicating the contents of the model so that the description statements could be correct/accurate would be more helpful. Thank you for your work on this document and YANG model. I also have a few minor comments/suggestions that may improve the document and YANG module: 2. Design of Data Model An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and sets up forwarding tables for multicast traffic. If a switch does not run IGMP/MLD snooping, multicast traffic will be flooded in the broadcast domain. If a switch runs IGMP/MLD snooping, multicast traffic will be forwarded based on the forwarding tables to avoid wasting bandwidth. The IGMP/MLD snooping switch does not need to run any of the IGMP/MLD protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD protocols, the data model defined in this document does not augment, or even require, the IGMP/MLD data model defined in [RFC8652]. The model covers considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches [RFC4541]. It wasn't clear to me what the final sentence was trying to say. Perhaps it should be merged with the penultimate sentence in the paragraph? The YANG module includes IGMP and MLD Snooping instance definition, using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN [draft- ietf-bess-l2vpn-yang]. The module also includes actions for clearing IGMP and MLD Snooping group tables. I find the use of the terminology of "scenario of " to be somewhat strange. I would probably have referred to these a "L2 forwarding pradigms" or "L2 forwarding instances". If this terminology is changed then it would need to be fixed elsewhere in this document and the YANG model. 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. With NMDA, the server also has the option of not returning a value for a given item of operational data (RFC 8342, section 5,3, paragraph 4). Although this doesn't conform to the data model, the semantics are well defined - i.e. the client cannot infer anything about the value that has not been returned. 2.3. Position of Address Family in Hierarchy IGMP Snooping only supports IPv4, while MLD Snooping only supports IPv6. The data model defined in this document can be used for both IPv4 and IPv6 address families. This document defines IGMP Snooping and MLD Snooping as separate schema branches in the structure. The benefits are: * The model can support IGMP Snooping (IPv4), MLD Snooping (IPv6), or both optionally and independently. Such flexibility cannot be achieved cleanly with a combined branch. * The separate branches for IGMP Snooping and MLD Snooping can accommodate their differences better and cleaner. The two branches can better support different features and node types. I would suggest rewording this first sentence to something like: "Having separate branches for IGMP Snooping and MLD Snooping allows minor differences in their behavior to be modelled more simply and cleanly". 3. Module Structure A configuration data node is marked as mandatory only when its value must be provided by the user. Where nodes are not essential to protocol operation, they are marked as optional. Some other nodes are essential but have a default specified, so that they are also optional and need not be configured explicitly. This paragraph seems to just describe standard YANG modelling and can be removed. 3.1. IGMP Snooping Instances The value of scenario in igmp-snooping-instance is bridge or l2vpn. When it is bridge, igmp-snooping-instance will be used in the BRIDGE As per previous comments, this first sentence does not read well for me. The values of bridge-mrouter-interface, l2vpn-mrouter-interface-ac, l2vpn-mrouter-interface-pw are filled by the snooping device dynamically. They are different from static-bridge-mrouter-interface, static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-interface-pw which are configured Ideally, these static nodes would not have been necessary, instead relying on the NMDA split between configuration and state, but that would probably require the default model to always allow them to be statically configured. In NMDA, features can be implemented per-datastore but it is not clear how well that would work here. units one-tenth-second; Perhaps "units deciseconds" would be better? grouping igmp-snooping-statistics { description "The statistics attributes for IGMP snooping."; leaf num-query { type yang:counter64; description "The number of Membership Query messages."; reference "RFC 2236"; } For these counters, rather than "num-XXX", I think that they would be better as "XXX-count", or if these relate to the number of packets "XXX-pkts" (as per RFC 8343). container statistics { description "The interface statistics for IGMP snooping"; container received { description "Statistics of received IGMP snooping packets."; uses igmp-snooping-statistics; } container sent { description "Statistics of sent IGMP snooping packets."; uses igmp-snooping-statistics; } } Should the descriptions for received and sent be for "snooped IGMP packets"? The equivalent MLD structure probably also needs a similar fix. |
2020-07-21
|
17 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2020-07-09
|
17 | Benjamin Kaduk | [Ballot comment] Is a gauge type better than an int for the various 'count' fields? Do we want to put in explicit "discontinuity-time" elements for … [Ballot comment] Is a gauge type better than an int for the various 'count' fields? Do we want to put in explicit "discontinuity-time" elements for when the counters last reset? (I see at least one "up-time" leaf but it's not entirely clear that the semantics match up.) Section 3.2 The mld-snooping-instance is the same as IGMP snooping except changing IPv4 addresses to IPv6 addresses. One mld-snooping-instance could be The diff also shows some mechanical changes, like replacing "igmp-version" with "mld-version", and the name of statistics leafs that are tied to protocol version/elements. There doesn't seem to be a clear need to call out every such difference, though. Section 4 feature exclude-lite { description "Support configuration of per instance exclude-lite."; reference "RFC 5790"; RFC 5790 does not use the keyword "EXCLUDE-lite" (or actually, "lite" at all), so a little bit more description of which functionality this refers to could be helpful. leaf-list bridge-mrouter-interface { when 'derived-from-or-self(../scenario,"ims:bridge")'; type if:interface-ref; config false; description "The mrouter interface in BRIDGE forwarding. When switch receives IGMP/MLD queries from multicast router on an interface, this interface will become mrouter interface for IGMP/MLD snooping."; nit: the grammar in this description should be revisited; maybe just missing articles. Similarly for the next few entries. leaf last-reporter { type inet:ipv4-address; description "Address of the last host which has sent report to join the multicast group."; I guess I'm not entirely sure what this is used for; it doesn't seem like it would provide a way to reliably get a stream of all hosts that sent a report to join (the "list host" with feature explicit-tracking would be needed for that, right?), and could be stale at any time, but I'm probably just missing something. (Similarly for the MLD case.) container interfaces { config false; description "Interfaces associated with the IGMP snooping instance"; list interface { key "name"; description "Interfaces associated with the IGMP snooping instance"; Should we consider non-verbatim-equivalent descriptions for the container and the list? (Likewise for MLD.) Section 5 It's probably worth a brief note in the "readable data nodes" section about any privacy considerations of exposing multicast group membership (e.g., if IP addresses are associated with users, and multicast groups associated with certain types of content, then there is transitively an association between the user and the content, which could be privacy sensitive). Section 7.1 It's not entirely clear that RFC 8407 needs to be normative. It is, however, pretty clear that RFC 8652 does not need to be normative, since we reference it basically to say "we don't need to pull this in". Section 7.2 RFC 6636 is referenced from the YANG module; doesn't that make it normative? Appendix A [Just noting that I did not carefully review the examples.] |
2020-07-09
|
17 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-07-09
|
17 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2020-07-09
|
17 | Benjamin Kaduk | [Ballot discuss] Let's discuss whether we need to be a bit more clear about what behavior should be expected when the exclude-lite leaf has value … [Ballot discuss] Let's discuss whether we need to be a bit more clear about what behavior should be expected when the exclude-lite leaf has value true vs. false -- the apparent inconsistency between "exclude" in the leaf name and the positive verb "track" in the description left me confused. |
2020-07-09
|
17 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-07-09
|
17 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-07-09
|
17 | Robert Wilton | [Ballot discuss] Hi, I appreciate that this YANG model has already passed a YANG doctor review, but this discuss is to understand the reasoning as … [Ballot discuss] Hi, I appreciate that this YANG model has already passed a YANG doctor review, but this discuss is to understand the reasoning as to why both IGMP snooping and MLD snooping are in the same YANG module, yet have top level features to separate their functionality. 4. IGMP and MLD Snooping YANG Module feature igmp-snooping { description "Support IGMP snooping."; reference "RFC 4541"; } feature mld-snooping { description "Support MLD snooping."; reference "RFC 4541"; } It seems strange to me to have the entire YANG Model split under two separate feature statements. I believe that it would have been better to split this into two separate YANG models, both following the same structure. Possibly, a common YANG module could have been used to share groupings and definitions, but even then duplicating the contents of the model so that the description statements could be correct/accurate would be more helpful. |
2020-07-09
|
17 | Robert Wilton | [Ballot comment] Thank you for your work on this document and YANG model. I also have a few minor comments/suggestions that may improve the document … [Ballot comment] Thank you for your work on this document and YANG model. I also have a few minor comments/suggestions that may improve the document and YANG module: 2. Design of Data Model An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and sets up forwarding tables for multicast traffic. If a switch does not run IGMP/MLD snooping, multicast traffic will be flooded in the broadcast domain. If a switch runs IGMP/MLD snooping, multicast traffic will be forwarded based on the forwarding tables to avoid wasting bandwidth. The IGMP/MLD snooping switch does not need to run any of the IGMP/MLD protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD protocols, the data model defined in this document does not augment, or even require, the IGMP/MLD data model defined in [RFC8652]. The model covers considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches [RFC4541]. It wasn't clear to me what the final sentence was trying to say. Perhaps it should be merged with the penultimate sentence in the paragraph? The YANG module includes IGMP and MLD Snooping instance definition, using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN [draft- ietf-bess-l2vpn-yang]. The module also includes actions for clearing IGMP and MLD Snooping group tables. I find the use of the terminology of "scenario of " to be somewhat strange. I would probably have referred to these a "L2 forwarding pradigms" or "L2 forwarding instances". If this terminology is changed then it would need to be fixed elsewhere in this document and the YANG model. 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. With NMDA, the server also has the option of not returning a value for a given item of operational data (RFC 8342, section 5,3, paragraph 4). Although this doesn't conform to the data model, the semantics are well defined - i.e. the client cannot infer anything about the value that has not been returned. 2.3. Position of Address Family in Hierarchy IGMP Snooping only supports IPv4, while MLD Snooping only supports IPv6. The data model defined in this document can be used for both IPv4 and IPv6 address families. This document defines IGMP Snooping and MLD Snooping as separate schema branches in the structure. The benefits are: * The model can support IGMP Snooping (IPv4), MLD Snooping (IPv6), or both optionally and independently. Such flexibility cannot be achieved cleanly with a combined branch. * The separate branches for IGMP Snooping and MLD Snooping can accommodate their differences better and cleaner. The two branches can better support different features and node types. I would suggest rewording this first sentence to something like: "Having separate branches for IGMP Snooping and MLD Snooping allows minor differences in their behavior to be modelled more simply and cleanly". 3. Module Structure A configuration data node is marked as mandatory only when its value must be provided by the user. Where nodes are not essential to protocol operation, they are marked as optional. Some other nodes are essential but have a default specified, so that they are also optional and need not be configured explicitly. This paragraph seems to just describe standard YANG modelling and can be removed. 3.1. IGMP Snooping Instances The value of scenario in igmp-snooping-instance is bridge or l2vpn. When it is bridge, igmp-snooping-instance will be used in the BRIDGE As per previous comments, this first sentence does not read well for me. The values of bridge-mrouter-interface, l2vpn-mrouter-interface-ac, l2vpn-mrouter-interface-pw are filled by the snooping device dynamically. They are different from static-bridge-mrouter-interface, static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-interface-pw which are configured Ideally, these static nodes would not have been necessary, instead relying on the NMDA split between configuration and state, but that would probably require the default model to always allow them to be statically configured. In NMDA, features can be implemented per-datastore but it is not clear how well that would work here. units one-tenth-second; Perhaps "units deciseconds" would be better? grouping igmp-snooping-statistics { description "The statistics attributes for IGMP snooping."; leaf num-query { type yang:counter64; description "The number of Membership Query messages."; reference "RFC 2236"; } For these counters, rather than "num-XXX", I think that they would be better as "XXX-count", or if these relate to the number of packets "XXX-pkts" (as per RFC 8343). container statistics { description "The interface statistics for IGMP snooping"; container received { description "Statistics of received IGMP snooping packets."; uses igmp-snooping-statistics; } container sent { description "Statistics of sent IGMP snooping packets."; uses igmp-snooping-statistics; } } Should the descriptions for received and sent be for "snooped IGMP packets"? The equivalent MLD structure probably also needs a similar fix. |
2020-07-09
|
17 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2020-07-09
|
17 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. On an editorial note, I found sometimes the text difficult to read (I am … [Ballot comment] Thank you for the work put into this document. On an editorial note, I found sometimes the text difficult to read (I am not an English-native speaker) due to very long sentences: e.g., the first 2 paragraphs of section 2.2. Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs). I hope that this helps to improve the document, Regards, -éric == COMMENTS == I am not a big expert in MLD or WiFi, but, it seems to me that this YANG module covers only the important use case of switches. But, if not mistaken, some WiFi access points also do a similar job and translates L2 mcast addresses into a series of L2 unicast addresses. Was it considered in this model ? -- Section 1.1 -- English is not my native language, but, I have hard time to parse "mrouter: multicast router, which means nodes attached to a switch have multicast routing enabled" is a switch or a router ? -- Section 2.3 -- No need to reply on this one, but, I really do not like separating the IPv4 and IPv6 branches of the trees. It looks to me like doubling the operational cost but not sharing common properties; hence, diminishing the usefulness of this document. I made the same comment for RFC 8652 and there is really no need to repeat what I consider as mistakes. -- Section 4 -- The description parts of the YANG module are quite short so I may have overlooked some parts of it... so bear with my two COMMENTs below: 1) for a MLD group, why having the mac-address leaf ? AFAIK, the mac-address is derived from the group IPv6 mcast address. Storing related information twice in a model looks bad to me (I am a big fan of the SQL normal forms...) 2) some switches does not snoop MLD for link-local groups (sollicited node mcast for example). Is this feature listed in the list of features ? |
2020-07-09
|
17 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-07-08
|
17 | Éric Vyncke | Request closed, assignment withdrawn: Joe Abley Telechat INTDIR review |
2020-07-08
|
17 | Éric Vyncke | Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still … Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still welcome by the authors probably). |
2020-07-08
|
17 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-07-08
|
17 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-07-08
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-07-08
|
17 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-07-08
|
17 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-17.txt |
2020-07-08
|
17 | (System) | New version approved |
2020-07-08
|
16 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-07-08
|
17 | (System) | Request for posting confirmation emailed to previous authors: Xufeng Liu , Anish Peter , Mahesh Sivakumar , Hongji Zhao , Yisong Liu |
2020-07-08
|
17 | Hongji Zhao | Uploaded new revision |
2020-07-08
|
16 | Murray Kucherawy | [Ballot comment] I'm almost hitting the "DISCUSS" button here over the fact that the shepherd writeup warned in several places that the YANG in this … [Ballot comment] I'm almost hitting the "DISCUSS" button here over the fact that the shepherd writeup warned in several places that the YANG in this document had issues. Were these resolved? > There was an early YANG doctor review that found some issues. I believe the should be resolved. There are some errors compiling the model though. > Early YANG doctor review was done. It would be good to get another check to see if everything is fine now. > There are some minor nits as found by the tool, and YANG validation has a few issues. > The early YANG doctor review only found minor issues, which should be addressed in version 08. [We're at -16 now; was this never updated?] Section 3: * "The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]." -- This text also appears in Section 2. Section 5: * I concur with Roman's suggestion to refer here to RFC 4541. Section 6: * I suggest this be split into two subsections, which in my experience is more conventional (but not required). Other: There's a bug in whatever rendering engine was used here. The footer for page 1 says the document expires January 2021, but all others say 2020. |
2020-07-08
|
16 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record |
2020-07-08
|
16 | Murray Kucherawy | [Ballot comment] I'm almost hitting the "DISCUSS" button here over the fact that the shepherd writeup called out in five places the fact that the … [Ballot comment] I'm almost hitting the "DISCUSS" button here over the fact that the shepherd writeup called out in five places the fact that the YANG in this document had issues. Were these resolved? > There was an early YANG doctor review that found some issues. I believe the should be resolved. There are some errors compiling the model though. > Early YANG doctor review was done. It would be good to get another check to see if everything is fine now. > There are some minor nits as found by the tool, and YANG validation has a few issues. > The early YANG doctor review only found minor issues, which should be addressed in version 08. [We're at -16 now; was this never updated?] |
2020-07-08
|
16 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2020-07-07
|
16 | Erik Kline | [Ballot comment] [ questions ] * What's the origin for using rt-types:timer-value-seconds16 for the group and source expire value? I spent some time with … [Ballot comment] [ questions ] * What's the origin for using rt-types:timer-value-seconds16 for the group and source expire value? I spent some time with 2710 and 3810 looking for where this might have come from, but perhaps I missed something. |
2020-07-07
|
16 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-07-07
|
16 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-16.txt |
2020-07-07
|
16 | (System) | New version approved |
2020-07-07
|
16 | (System) | Request for posting confirmation emailed to previous authors: Hongji Zhao , Anish Peter , Mahesh Sivakumar , Xufeng Liu , Yisong Liu |
2020-07-07
|
16 | Hongji Zhao | Uploaded new revision |
2020-07-06
|
15 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-07-06
|
15 | Roman Danyliw | [Ballot comment] ** It caught me by surprise for a standards track document not to use RFC2119 words in a normative way ** Section 2.2. … [Ballot comment] ** It caught me by surprise for a standards track document not to use RFC2119 words in a normative way ** Section 2.2. Per “On the other hand, operational state parameters are not so widely designated as features …”, I didn’t follow the intent of this paragraph. I’m not sure what it means to designate a operational state parameter. ** Section 5. It would be worth noting that devices that use this YANG model should heed the Security Considerations in Section 6 of RFC4541. ** Section 5. Per “If unauthorized action is invoked, the IGMP and MLD Snooping group tables will be cleared unexpectedly”, could the impact of this table flush please be explicitly stated. ** Editorial -- Section 2. Editorial. s/to avoid bandwidth waste/to avoid wasting bandwidth/ -- Section 5. Editorial. The sentence “Some of the actions in this YANG module may be considered sensitive or vulnerable in some network environments. “ appears to be included twice. It’s only needed once. |
2020-07-06
|
15 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-07-06
|
15 | Stephen Farrell | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Stephen Farrell. Sent review to list. |
2020-06-29
|
15 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-15.txt |
2020-06-29
|
15 | (System) | New version approved |
2020-06-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: Hongji Zhao , Xufeng Liu , Anish Peter , Mahesh Sivakumar , Yisong Liu |
2020-06-29
|
15 | Hongji Zhao | Uploaded new revision |
2020-06-23
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-23
|
14 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-14.txt |
2020-06-23
|
14 | (System) | New version approved |
2020-06-23
|
14 | (System) | Request for posting confirmation emailed to previous authors: Hongji Zhao , Yisong Liu , Anish Peter , Xufeng Liu , Mahesh Sivakumar |
2020-06-23
|
14 | Hongji Zhao | Uploaded new revision |
2020-06-22
|
13 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Joe Abley |
2020-06-22
|
13 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Joe Abley |
2020-06-22
|
13 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-06-19
|
13 | Himanshu Shah | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Himanshu Shah. Sent review to list. |
2020-06-19
|
13 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-19
|
13 | Cindy Morgan | Placed on agenda for telechat - 2020-07-09 |
2020-06-19
|
13 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2020-06-19
|
13 | Alvaro Retana | Ballot has been issued |
2020-06-19
|
13 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2020-06-19
|
13 | Alvaro Retana | Created "Approve" ballot |
2020-06-19
|
13 | Alvaro Retana | Ballot writeup was changed |
2020-06-18
|
13 | Reshad Rahman | Request for Last Call review by YANGDOCTORS Completed: Ready with Nits. Reviewer: Reshad Rahman. Sent review to list. |
2020-06-17
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-17
|
13 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-13.txt |
2020-06-17
|
13 | (System) | New version approved |
2020-06-17
|
13 | (System) | Request for posting confirmation emailed to previous authors: Anish Peter , Mahesh Sivakumar , Xufeng Liu , Yisong Liu , Hongji Zhao |
2020-06-17
|
13 | Hongji Zhao | Uploaded new revision |
2020-06-15
|
12 | Alvaro Retana | Waiting: YANGDOCTORS Last Call Review - due: 2020-06-21 |
2020-06-15
|
12 | Alvaro Retana | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2020-06-15
|
12 | Alvaro Retana | Ballot writeup was changed |
2020-06-15
|
12 | Alvaro Retana | Ballot writeup was changed |
2020-06-15
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-06-12
|
12 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2020-06-12
|
12 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-06-12
|
12 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2020-06-12
|
12 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-06-12
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pim-igmp-mld-snooping-yang-12. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pim-igmp-mld-snooping-yang-12. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new namespace will be registered as follows: ID: yang:ietf-igmp-mld-snooping URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ a single, new YANG module will be registered as follows: Name: ietf-igmp-mld-snooping File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping Prefix: ims Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-06-06
|
12 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list. |
2020-06-05
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2020-06-05
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2020-06-04
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2020-06-04
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2020-06-03
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2020-06-03
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2020-06-01
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-06-01
|
12 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-06-15): From: The IESG To: IETF-Announce CC: Stig Venaas , pim-chairs@ietf.org, stig@venaas.com, aretana.ietf@gmail.com, … The following Last Call announcement was sent out (ends 2020-06-15): From: The IESG To: IETF-Announce CC: Stig Venaas , pim-chairs@ietf.org, stig@venaas.com, aretana.ietf@gmail.com, pim@ietf.org, draft-ietf-pim-igmp-mld-snooping-yang@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A Yang Data Model for IGMP and MLD Snooping) 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 IGMP and MLD Snooping' 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@ietf.org mailing lists by 2020-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-snooping-yang/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches (Informational - IETF stream) |
2020-06-01
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-06-01
|
12 | Cindy Morgan | Last call announcement was generated |
2020-05-31
|
12 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-12.txt |
2020-05-31
|
12 | (System) | New version approved |
2020-05-31
|
12 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2020-05-31
|
12 | Hongji Zhao | Uploaded new revision |
2020-05-31
|
11 | Min Ye | Request for Last Call review by RTGDIR is assigned to Himanshu Shah |
2020-05-31
|
11 | Min Ye | Request for Last Call review by RTGDIR is assigned to Himanshu Shah |
2020-05-30
|
11 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Reshad Rahman |
2020-05-30
|
11 | Mehmet Ersue | Request for Last Call review by YANGDOCTORS is assigned to Reshad Rahman |
2020-05-30
|
11 | Alvaro Retana | Requested Last Call review by RTGDIR |
2020-05-30
|
11 | Alvaro Retana | Requested Last Call review by YANGDOCTORS |
2020-05-30
|
11 | Alvaro Retana | Last call was requested |
2020-05-30
|
11 | Alvaro Retana | Ballot approval text was generated |
2020-05-30
|
11 | Alvaro Retana | Ballot writeup was generated |
2020-05-30
|
11 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-05-30
|
11 | Alvaro Retana | Last call announcement was changed |
2020-05-30
|
11 | Alvaro Retana | Last call announcement was generated |
2020-05-30
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-05-30
|
11 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-11.txt |
2020-05-30
|
11 | (System) | New version approved |
2020-05-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: Yisong Liu , Mahesh Sivakumar , Anish Peter , Xufeng Liu , Hongji Zhao |
2020-05-30
|
11 | Hongji Zhao | Uploaded new revision |
2020-05-11
|
10 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2020-05-02
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-05-02
|
10 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-10.txt |
2020-05-02
|
10 | (System) | New version approved |
2020-05-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: Hongji Zhao , Mahesh Sivakumar , Yisong Liu , Anish Peter , Xufeng Liu |
2020-05-02
|
10 | Hongji Zhao | Uploaded new revision |
2020-01-17
|
09 | Alvaro Retana | === AD Review of draft-ietf-pim-igmp-mld-snooping-yang-09 === https://mailarchive.ietf.org/arch/msg/pim/1t_cL9ky6Xbhw-oBVkuYBGAX3XA |
2020-01-17
|
09 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-01-09
|
09 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2020-01-09
|
09 | Alvaro Retana | Notification list changed to Stig Venaas <stig@venaas.com>, aretana.ietf@gmail.com from Stig Venaas <stig@venaas.com> |
2020-01-09
|
09 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-09.txt |
2020-01-09
|
09 | (System) | New version approved |
2020-01-09
|
09 | (System) | Request for posting confirmation emailed to previous authors: Anish Peter , Xufeng Liu , Yisong Liu , pim-chairs@ietf.org, Mahesh Sivakumar , Hongji Zhao |
2020-01-09
|
09 | Hongji Zhao | Uploaded new revision |
2019-08-20
|
08 | Stig Venaas | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track. It should be reasonable for a YANG model to be a standard, unless it is an experiment. IGMP and MLD snooping is well understood and should not be an experiment. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). Working Group Summary The WG has a YANG model design team. 5 member of the team (from a handful of vendors) have worked on this. It is based on implementations from these and other vendors. This indicates good vendor support. Aside from this, only 4 people supported the document for the WGLC, but none have raised any issues during the WGLC or in the WG otherwise. Document Quality A handful of vendors have worked on this and may be implementing it. At least 2 members of the WG have done a careful review, and a YANG doctor early review was also done. Personnel Stig Venaas is the shepherd, Alvaro Retana is the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd believes the document is in good shape, although the shepherd has limited YANG knowledge. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There was an early YANG doctor review that found some issues. I believe the should be resolved. There are some errors compiling the model though. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Early YANG doctor review was done. It would be good to get another check to see if everything is fine now. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, all authors have stated that they are not aware of any IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? At least 9 people are in support (5 of them authors), none are against. Wide range of vendors involved. While we would have liked more people to review it, it is hard to get much responses to YANG models. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are some minor nits as found by the tool, and YANG validation has a few issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The early YANG doctor review only found minor issues, which should be addressed in version 08. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there are many normative references to YANG related documents. These will hopefully be published soon. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes, there is a reference to the informational RFC 4541. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The IANA considerations are clear and they are inline with other YANG models. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Checked idnits and YANG compilation in the tracker. |
2019-08-20
|
08 | Stig Venaas | Responsible AD changed to Alvaro Retana |
2019-08-20
|
08 | Stig Venaas | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-08-20
|
08 | Stig Venaas | IESG state changed to Publication Requested from I-D Exists |
2019-08-20
|
08 | Stig Venaas | IESG process started in state Publication Requested |
2019-08-20
|
08 | Stig Venaas | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track. It should be reasonable for a YANG model to be a standard, unless it is an experiment. IGMP and MLD snooping is well understood and should not be an experiment. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). Working Group Summary The WG has a YANG model design team. 5 member of the team (from a handful of vendors) have worked on this. It is based on implementations from these and other vendors. This indicates good vendor support. Aside from this, only 4 people supported the document for the WGLC, but none have raised any issues during the WGLC or in the WG otherwise. Document Quality A handful of vendors have worked on this and may be implementing it. At least 2 members of the WG have done a careful review, and a YANG doctor early review was also done. Personnel Stig Venaas is the shepherd, Alvaro Retana is the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd believes the document is in good shape, although the shepherd has limited YANG knowledge. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There was an early YANG doctor review that found some issues. I believe the should be resolved. There are some errors compiling the model though. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Early YANG doctor review was done. It would be good to get another check to see if everything is fine now. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, all authors have stated that they are not aware of any IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? At least 9 people are in support (5 of them authors), none are against. Wide range of vendors involved. While we would have liked more people to review it, it is hard to get much responses to YANG models. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are some minor nits as found by the tool, and YANG validation has a few issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The early YANG doctor review only found minor issues, which should be addressed in version 08. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there are many normative references to YANG related documents. These will hopefully be published soon. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes, there is a reference to the informational RFC 4541. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The IANA considerations are clear and they are inline with other YANG models. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Checked idnits and YANG compilation in the tracker. |
2019-08-20
|
08 | Stig Venaas | Notification list changed to Stig Venaas <stig@venaas.com> |
2019-08-20
|
08 | Stig Venaas | Document shepherd changed to Stig Venaas |
2019-08-20
|
08 | Stig Venaas | Changed consensus to Yes from Unknown |
2019-08-20
|
08 | Stig Venaas | Intended Status changed to Proposed Standard from None |
2019-06-10
|
08 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-08.txt |
2019-06-10
|
08 | (System) | New version approved |
2019-06-10
|
08 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2019-06-10
|
08 | Hongji Zhao | Uploaded new revision |
2019-03-25
|
07 | Stig Venaas | Added to session: IETF-104: pim Thu-1350 |
2019-01-07
|
07 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-07.txt |
2019-01-07
|
07 | (System) | New version approved |
2019-01-07
|
07 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2019-01-07
|
07 | Hongji Zhao | Uploaded new revision |
2018-12-10
|
06 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-06.txt |
2018-12-10
|
06 | (System) | New version approved |
2018-12-10
|
06 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2018-12-10
|
06 | Hongji Zhao | Uploaded new revision |
2018-11-04
|
05 | Stig Venaas | Added to session: IETF-103: pim Tue-1350 |
2018-10-17
|
05 | Reshad Rahman | Request for Early review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Reshad Rahman. |
2018-10-11
|
05 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-05.txt |
2018-10-11
|
05 | (System) | New version approved |
2018-10-11
|
05 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2018-10-11
|
05 | Hongji Zhao | Uploaded new revision |
2018-08-06
|
04 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-04.txt |
2018-08-06
|
04 | (System) | New version approved |
2018-08-06
|
04 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2018-08-06
|
04 | Hongji Zhao | Uploaded new revision |
2018-07-13
|
03 | Stig Venaas | Added to session: IETF-102: pim Tue-1550 |
2018-06-11
|
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Reshad Rahman |
2018-06-11
|
03 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Reshad Rahman |
2018-06-11
|
03 | Stig Venaas | Requested Early review by YANGDOCTORS |
2018-05-28
|
03 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-03.txt |
2018-05-28
|
03 | (System) | New version approved |
2018-05-28
|
03 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2018-05-28
|
03 | Hongji Zhao | Uploaded new revision |
2018-05-14
|
02 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-02.txt |
2018-05-14
|
02 | (System) | New version approved |
2018-05-14
|
02 | (System) | Request for posting confirmation emailed to previous authors: Anish Peter , Yisong Liu , Xufeng Liu , pim-chairs@ietf.org, Hongji Zhao , Mahesh Sivakumar |
2018-05-14
|
02 | Hongji Zhao | Uploaded new revision |
2018-03-18
|
01 | Stig Venaas | Added to session: IETF-101: pim Tue-0930 |
2018-02-26
|
01 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-01.txt |
2018-02-26
|
01 | (System) | New version approved |
2018-02-26
|
01 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2018-02-26
|
01 | Hongji Zhao | Uploaded new revision |
2018-02-25
|
01 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Sivakumar , Anish Peter , Xufeng Liu , Yisong Liu , Hongji Zhao |
2018-02-25
|
01 | Hongji Zhao | Uploaded new revision |
2018-02-07
|
00 | Mike McBride | This document now replaces draft-zhao-pim-igmp-mld-snooping-yang instead of None |
2018-02-07
|
00 | Hongji Zhao | New version available: draft-ietf-pim-igmp-mld-snooping-yang-00.txt |
2018-02-07
|
00 | (System) | WG -00 approved |
2018-02-07
|
00 | Hongji Zhao | Set submitter to "Hongji Zhao ", replaces to draft-zhao-pim-igmp-mld-snooping-yang and sent approval email to group chairs: pim-chairs@ietf.org |
2018-02-07
|
00 | Hongji Zhao | Uploaded new revision |