Dear Glenn, Thank you very much for your thorough review. I have greatly appreciated it.
I am going to check and update the draft taking into account your comments. I try to submit the updated draft by the end of next week. Best regards, -- tsuno 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni <[email protected]>: > Dear Tsuno/Zhang > Thanks for waiting. The review of > draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. > > Glenn > > C1. Abstract: > The draft now defines 2 MIB modules. Please revise the abstract > and probably the title of the document too. > > C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. > (Three {type-unref} warnings are there, may be ignored.) > > C3. Page 4: > s/3. Summary of MIB Module/ > 3. Summary of MIB Modules/ > > C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION > s/"Denotes a pointer to the row pertaining to a table entry/ > /"This textual convention represents a pointer to a row in > the table represented by the following object of type > L2L3VpnMcastProviderTunnelPointerType./ > > C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION > The explanation in the last paragraph seems out of place. > It may be removed. > > C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION > it is unclear when the value 'null(0)' will be used. > Is this allowed only when the corresponding object of type > L2L3VpnMcastProviderTunnelPointer has a value that is a > zero-length string ? If yes, please make that clear. > > C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION > s/created by a PE router/maintained by a PE router/ > > C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId > Do you really want to keep this object in L2L3-VPN-MCAST-MIB. > It will change every time a new "tunnel type" is added to > L2L3VpnMcastProviderTunnelType. That will defeat the purpose > of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB > It may be a good idea to define a textual convention like > L2L3VpnMcastPmsiTunnelAttributeId > in the L2L3-VPN-MCAST-TC-MIB and use that textual convention > in the L2L3-VPN-MCAST-MIB > > C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION > A. s/Thus, the size of this object is 16 octets in IPv4/ > Thus, the size of this object is 8 octets in IPv4/ > B. The last 2 paragraphs do not tie up well with the previous > paragraphs in the DESCRIPTION. > C. In the last paragraph > "this object is a pair of source and group IP addresses" > is unlcear. Please clarify. > > C10. Page 15: Security Considerations > I would think that any field that reveals information about > a Multicast VPN and/or its members is sensitive. > Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal > information about the participating members? If yes, it must > be marked as sensitive. > > C11. Editorial: > > A. This does not pertain to the MIBs as such, > but I am uncomfortable with the several variations > of the phrase > "Layer 2 and Layer 3 Virtual Private Networks (VPN) > that support multicast" > that appears in the text. I do not have a solution > on hand but it would be perhaps be more readable to > define and use a simple name/notation the beast for > which the MIB is being designed (e.g. "L2L3VPNMCast"). > > B. Same with the phrase > "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private > Network) > it would be probably be easier on the reader if an > abbreviation like L2L3VPNs was used where ever > applicable. > > C12. P2:Para4: s/within MIB module specifications//; > > C13. General: > A. The DESCRIPTION clauses could do would some more > packing. (Too much space at the end of lines) > B. Please check the articles a/an/the once again. Some > usages do not seem right to me. > > > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
