Dear Glenn, Thank you for your comments and for waiting for the update. I posted a new revision (-11) as follows.
URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-11.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-11 Please see the responses for your comments in the followings. 2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>: > 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION > 1.1 It will be good to give a reference (RFCNNNN) for > noTunnelInfo (0) : no tunnel information present > That will make it consistent with the other items. > This change will require adding RFCNNNN to the REFERENCE clause. Fixed. > 1.2 pimBidir (5) : BIDIR-PIM Tree [RFC5015] > RFC5015 needs to be added to the Reference section RFC5015 added to the Reference section. > 3. Page-7,8: says > " A L2L3VpnMcastProviderTunnelType object of value > noTunnelInfo(0) indicates that the corresponding > Provider Multicast Service Interface (PMSI) Tunnel > attribute does not have a Tunnel Identifier." > It may be better to align the wording with RFC6514 (Page 11) > ' When the Tunnel Type is set to "No tunnel information > present", the PMSI Tunnel attribute carries no tunnel > information (no Tunnel Identifier).' Fixed. Thank you for your advice. > 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION: > E: Extension flag [RFC7902] > RFC7902 needs to be added to the Reference section Fixed. RFC7902 is now in the Reference section. > 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE > "RFC6514, Section 5 > RFC7902 > " > It will be nice to have a section pointer for RFC7902 too. > (User-friendly and consistency). > Please check the same for all the REFERENCE clause pointers Added a section point for Sec.3 of RFC7902. > 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION > "When UDP-based S-PMSI signaling is used, the value of > this object is zero." > This is actually a 48-bit string. What would be the > representation of "zero" above be? Will it be a string of > length 0, a string containing a single ascii character "0" > 6 ascii "0"s, 48 '0' bits ? > > 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION: > "When UDP-based S-PMSI signaling is used, the value of > this object is zero that indicates the absence of MPLS > Label." > Once again. "zero" above is imprecise. In the current revision, these parts are revised as follows. When the P-tunnel does not have a correspondent PMSI tunnel attribute, the value of this object will be 0. > 8. Compliance: > It would be good to design the compliance module as follows: > l2L3VpnMcastCoreCompliance: > MANDATORY-GROUPS { > l2L3VpnMcastPmsiFieldGroup > } > l2L3VpnMcastFullCompliance: > MANDATORY-GROUPS { > l2L3VpnMcastPmsiFieldGroup > l2L3VpnMcastOptionalGroup > } Fixed along with your comments. Thank you. > General: > 10 Page-2 Section-1 > 10.1 In BGP/MPLS Virtual Private Networks (VPN) > In BGP/MPLS Virtual Private Networks (VPNs) ? Fixed. > 10.2 Throughout this document, we will use the term > "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support > multicast. > > Throughout this document, we will use the term > "L2L3VpnMCast network" to mean a network that comprises of > BGP/MPLS L2 and L3 VPNs and supports multicast. Fixed. Now, the term "L2L3VpnMCast network" is used throughout the document. > 10.3 Page-4 Section-3 bullet 2 > Please review the paragraph for readability. Revised the paragraph in order to improve readability. > 10.4 It will be good to avoid page-breaks within quoted clauses. > example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE Thank you for your comments. I adjusted the page-breaks along with this comment. Thanks again. -- tsuno 2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>: > Dear Tsuno, > > Thanks for the revised draft. I have reviewed the draft. > Some issues remain. These are listed below > Please consider the issues/comments and update the draft. > > Glenn > > +--------------------------------------------------------+ > > 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION > 1.1 It will be good to give a reference (RFCNNNN) for > noTunnelInfo (0) : no tunnel information present > That will make it consistent with the other items. > This change will require adding RFCNNNN to the REFERENCE clause. > 1.2 pimBidir (5) : BIDIR-PIM Tree [RFC5015] > RFC5015 needs to be added to the Reference section > > 2. Page-6: L2L3VpnMcastProviderTunnelType: SYNTAX > The rewritten SYNTAX clause without the repetitions looks better. > Thanks. > > 3. Page-7,8: says > " A L2L3VpnMcastProviderTunnelType object of value > noTunnelInfo(0) indicates that the corresponding > Provider Multicast Service Interface (PMSI) Tunnel > attribute does not have a Tunnel Identifier." > It may be better to align the wording with RFC6514 (Page 11) > ' When the Tunnel Type is set to "No tunnel information > present", the PMSI Tunnel attribute carries no tunnel > information (no Tunnel Identifier).' > > 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION: > E: Extension flag [RFC7902] > RFC7902 needs to be added to the Reference section > > 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE > "RFC6514, Section 5 > RFC7902 > " > It will be nice to have a section pointer for RFC7902 too. > (User-friendly and consistency). > Please check the same for all the REFERENCE clause pointers > 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION > "When UDP-based S-PMSI signaling is used, the value of > this object is zero." > This is actually a 48-bit string. What would be the > representation of "zero" above be? Will it be a string of > length 0, a string containing a single ascii character "0" > 6 ascii "0"s, 48 '0' bits ? > > 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION: > "When UDP-based S-PMSI signaling is used, the value of > this object is zero that indicates the absence of MPLS > Label." > Once again. "zero" above is imprecise. > > 8. Compliance: > It would be good to design the compliance module as follows: > l2L3VpnMcastCoreCompliance: > MANDATORY-GROUPS { > l2L3VpnMcastPmsiFieldGroup > } > l2L3VpnMcastFullCompliance: > MANDATORY-GROUPS { > l2L3VpnMcastPmsiFieldGroup > l2L3VpnMcastOptionalGroup > } > > > General: > 10 Page-2 Section-1 > 10.1 In BGP/MPLS Virtual Private Networks (VPN) > In BGP/MPLS Virtual Private Networks (VPNs) ? > > 10.2 Throughout this document, we will use the term > "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support > multicast. > > Throughout this document, we will use the term > "L2L3VpnMCast network" to mean a network that comprises of > BGP/MPLS L2 and L3 VPNs and supports multicast. > > 10.3 Page-4 Section-3 bullet 2 > Please review the paragraph for readability. > > 10.4 It will be good to avoid page-breaks within quoted clauses. > example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE > > > > > On 2017/08/28 3:27, Hiroshi Tsunoda wrote: >> >> Dear Glenn, >> >> Thank you for your comments and for waiting for the update. >> I posted a new revision (-10) as follows. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-10.txt >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10 >> Htmlized: >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10 >> Diff: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-10 >> >> In the new revision, the following changes are made. >> - Updated the description of following TC and objects >> in order to clarify the role of this MIB and to improve >> the readability >> -- L2L3VpnMcastProviderTunnelId >> -- l2L3VpnMcastPmsiTunnelAttributeTable >> - Removed some redundant expressions >> - Updated compliance statements >> >> Please see the responses for your comments >> in the followings. >> >> 2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>: >>> >>> L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type >>> `L2L3VpnMcastProviderTunnelId' has no format specification >>> This may be avoided by specifying a format in which the >>> L2L3VpnMcastProviderTunnelId should be printed. >>> Is there a preferred format? How will this be printed? >>> One continuous octet string? >> >> >> The size and format of TunnelID depends on Tunnel Type. >> and no preferred format is exist as of now. >> Therefore, I have decided to not give format specification >> to L2L3VpnMcastProviderTunnelId. >> >>> A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the following >>> four MOs as index for its rows >>> l2L3VpnMcastPmsiTunnelAttributeFlags, >>> l2L3VpnMcastPmsiTunnelAttributeType, >>> l2L3VpnMcastPmsiTunnelAttributeLabel, >>> l2L3VpnMcastPmsiTunnelAttributeId >>> The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate? If yes >>> please explain it to me. Or point to the text that contains the >>> explanation. >>> I have been unable to confirm the above from the draft - that is very >>> likely due to my lack of understanding of the l2L3VpnMcast technology. >> >> >> According to Sec. 7.4.1.1 of RFC6513, >> P-tunnel is identified by its type and id. >> Thus, in the latest revision, the following two objects are used as >> index of the table. >> l2L3VpnMcastPmsiTunnelAttributeType, >> l2L3VpnMcastPmsiTunnelAttributeId >> >> Thanks in advance, >> >> -- tsuno >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess