Dear Glenn, Thank you for your detailed comments. I will revise the draft based on your comments and submit new revision as soon as possible.
-- tsuno 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>: > Dear Tsunoda, >> I think that I have addressed all of Glenn's comments in >> this revision. > Thanks for addressing the comments. The MIB compiles OK and > is looking good. It is shaping up well. > A new set of comments is attached. Please check and do the > > needful. > Glenn > On 2017/02/21 16:50, Hiroshi Tsunoda wrote: >> >> Dear Glenn and BESS WG, >> >> I posted a new revision as follows. >> I think that I have addressed all of Glenn's comments in this revision. >> >> In this revision, I have tried to add more detailed explanation >> throughout the document. >> Please review and let me know if there are any misunderstanding from >> technical view points. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-06.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-06 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-06 >> >> Please see some notes below. >> >>> 1. Introduction >>> >>> 1.1 >>> Would be very nice if a short explanations of MVPN and >>> L2 VPN Multicast were given. With emphasis on the operational >>> aspects. >> >> >> I have updated Introduction. I hope this update fulfills your >> requirements. >> >>> 1.4 .... there are 2 types of PMSIs .. >>> >>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>> >>> >>> please make these explanations more gentle(complete) to the reader. >>> Also, give the references where these terms are defined. >> >> >> More gentle explanation and references were added in Terminology >> section (Sec.1.1). >> >>> 3.2 some more text like the following will be good. >>> L2L3-VPN-MCAST-MIB contains >>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>> an enumeration of the provider tunnel types and, >>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>> composed of multiple attributes that depend on the tunnel type and >>> uniquely identify a tunnel. This table will be used to ... monitor >>> the tunnels supported by the system at a given point of time (?) >>> It may also be used in conjunction with XXXX-mib to obtain the >>> other details of a tunnel by following the row pointer of the >>> corresponding tunnel's row in this table. >>> [ Please treat the above as a template and modify the text as >>> appropriate ..] >> >> >> Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. >> >>> 3.3 Since this will become a standard document, please take care of >>> definitions and notations used in the document. >>> The notation I/S-PMSI is not defined. If you must use a new >>> term/notation, define it before use. >> >> >> The notation I/S-PMSI is defined in Sec.1.1 now. >> >>> 4.8 >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>> MAX-ACCESS not-accessible >>>> STATUS current >>>> DESCRIPTION >>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>> The entries may be referred to by I-PMSI or S-PMSI table >>>> entries defined in other MIBs, e.g. mvpnMIB in >>>> [I-D.ietf-bess-mvpn-mib]." >>> >>> >>> It would seem that each row in this table is an index for a PTA >>> and may contain pointers to rows in tables of other MIB modules >>> which may contain more details for the PTA. Is that correct? >>> Please reword the DESCRIPTION acordingly. >>> Also see comments in 4.15 >> >> >> I have changed DESCRIPTION as follows. >> >> "An entry of this table corresponds with a >> PMSI Tunnel attribute and is created by a PE router >> that advertises and receives the attribute. >> The entry in the table will be referred by other MIB modules >> which are designed for monitoring and/or configuring >> both L2 and L3 VPN that support multicast." >> >> >>> 4.10-3 >>> the phrase UDP-based S-PMSI appears here for the first time. >>> Somewhere earlier it should be made clear that UDP too may be used >>> in signaling. >> >> >> In Introduction, I have explained that BGP and UDP are used in signaling. >> >>> 4.13 >>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>> >>>> DESCRIPTION >>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>> field in PMSI Tunnel Attribute of the corresponding >>>> I/S-PMSI A-D or Leaf A-D route." >>> >>> o Does this description cover all the types? If not, then cover all the >>> types unless there is a good reason to focus only on the above types. >>> o I/S-PMSI: unexplained notation. >> >> >> Fixed. >> >>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>> >>> Please indicate that the first column gives the size >> >> >> I have updated the table as follows. >> >> Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType >> IPv4 IPv6 (tunneling technology) >> -------------------------------------------------- >> 0 0 noTunnelId (No tunnel information present) >> 12 24 rsvpP2mp (RSVP-TE P2MP LSP) >> 17 29 ldpP2mp (mLDP P2MP LSP) >> 8 32 pimSsm (PIM-SSM Tree) >> >>>> 8/32 pimAsm >>>> 8/32 pimSsm >>>> 8/32 pimBidir >>>> 4/16 ingressReplication >>> >>> >>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>> 8 or 32 octets of this attribute are filled with >>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>> Identifier field in PMSI Tunnel Attribute of the >>>> corresponding I/S-PMSI A-D route." >>> >>> >>> A more generous description of the AttributeID would be good. All the >>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>> summary would be very nice. >> >> >> Fixed. I have summarized Section 5 of RFC 6514 here. >> >>> 4.15 >>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>> >>>> SYNTAX RowPointer >>>> DESCRIPTION >>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>> pointer is null." >>> >>> I am having problems understanding this. Will help if you can give >>> a use case of how this will be used. As of now the intent is unclear. >>> A RowPointer cannot be pointing to "some MIB table". It must be >>> pointer to a specific row in a specific table. If this is a pointer to >>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >> >> >> I have changed DESCRIPTION as follows. >> >> "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId >> may be represented as an entry in other table, e.g, >> mplsTunnelTable [RFC3812]. If there is such entry, >> this object will point to the row pertaining to the entry. >> Otherwise, the pointer is null." >> >>> 5.0 >>>> >>>> 5. Security Considerations >>> >>> TBD >> >> >> I have rewritten this part according to the guideline described in >> RFC4181 Sec.3.4. >> >>> 6.0 >>>> >>>> 6. IANA Considerations >>> >>> >>>> IANA is requested to root MIB objects in the MIB module contained in >>>> this document under the mib-2 subtree. >>> >>> >>> Please Note: >>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >>> put the definitions in a separate MIB module. That would mean a >>> separate branch in the mib-2 subtree. Then the maintenance of the >>> TC can be carried out by some entity ( IANA or, some WG or, whoever is >>> responsible for maintaining the TC) independent of other MIB objects. >>> If that is the intent you will need to define 2 mib modules and you >>> will >>> need to request 2 branches in the mib-2 subtree- one for the module >>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> >> Now, this document defines following two MIB modules: >> - the module containing the L2L3VpnMcastProviderTunnelType TC >> - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> -- tsuno >> >> 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>: >>> >>> Dear Tsunoda, >>>> >>>> I will submit the next version within three days. >>>> The next versionbwill address all of remained your >>>> comments. >>> >>> Great! Looking forward to the revised draft. >>> >>> Glenn >>> >>> On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >>>> >>>> >>>> Dear Glenn, >>>> >>>> I am sorry I kept you waiting so long for the revised version, I have >>>> been side tracked by other things. >>>> I will submit the next version within three days. The next version >>>> will address all of remained your comments. >>>> The summary of remained TODOs is shown below. Please wait a little >>>> more >>>> time. >>>> ------------- >>>> 1. Add general explanation about MVPN, multicast in VPLS >>>> Define and explain some technical terms, such as PIM-MVPN, >>>> UDP-based S-PMSI etc. >>>> >>>> 2. Revise summary of the MIB module >>>> >>>> 3. Revise MIB definition >>>> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >>>> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >>>> cover all cases. >>>> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >>>> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >>>> >>>> 4. Split the MIB module into two separate modules. >>>> >>>> 5. Revise security considertations >>>> ------------- >>>> >>>> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >>>> >>>> Best regards, >>>> >>>> -- tsuno >>>> >>>> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>: >>>>> >>>>> >>>>> Hi Tsunoda, >>>>>> >>>>>> >>>>>> I have started to volunteer to help to move this document forward. >>>>> >>>>> >>>>> Great! >>>>>> >>>>>> >>>>>> I posted a new revision and addressed all editorial things in >>>>>> that revision. >>>>> >>>>> >>>>> Got this. Looks good. >>>>>> >>>>>> >>>>>> Please give me some more time for revising other parts, >>>>> >>>>> >>>>> No problems. Will be looking forward to the revised document. >>>>> >>>>> Glenn >>>>> >>>>> >>>>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>>>> >>>>>> >>>>>> >>>>>> Dear Glenn, >>>>>> >>>>>> Thanks for your careful review and detailed comments/suggestions. >>>>>> I have started to volunteer to help to move this document forward. >>>>>> I posted a new revision and addressed all editorial things in that >>>>>> revision. >>>>>> Please give me some more time for revising other parts, >>>>>> in order to be familiar with the context of the original and related >>>>>> documents. >>>>>> >>>>>> URL: >>>>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>> Status: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>> Htmlized: >>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 >>>>>> Diff: >>>>>> >>>>>> >>>>>> >>>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>>> >>>>>> Please see some notes below. >>>>>> >>>>>>> 0. Abstract. >>>>>>> 0.1. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> it describes common managed objects used to configure >>>>>>> >>>>>>> >>>>>>> >>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>> >>>>>>> There are no writable MOs in this MIB. So it does not look >>>>>>> as though this MIB will be used for configuration directly. >>>>>>> The use case scenario for monitoring is not clear, either. >>>>>>> It appears that the MIB module(s) in this document will be >>>>>>> used by other modules which are designed for monitoring and/ >>>>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>>>> wording. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1. Introduction >>>>>>> >>>>>>> 1.1 >>>>>>> Would be very nice if a short explanations of MVPN and >>>>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>>>> aspects. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise. >>>>>> >>>>>>> 1.2 >>>>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1.3 >>>>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 1.4 .... there are 2 types of PMSIs .. >>>>>>> >>>>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> please make these explanations more gentle(complete) to the >>>>>>> reader. >>>>>>> Also, give the references where these terms are defined. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise. >>>>>> >>>>>>> 3. Summary of MIB Module >>>>>>> 3.1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>>>> >>>>>>> >>>>>>> >>>>>>> Typo: I/S-PMSI, (see 3.3 below). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 3.2 some more text like the following will be good. >>>>>>> L2L3-VPN-MCAST-MIB contains >>>>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that >>>>>>> provides >>>>>>> an enumeration of the provider tunnel types and, >>>>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index >>>>>>> is >>>>>>> composed of multiple attributes that depend on the tunnel type >>>>>>> and >>>>>>> uniquely identify a tunnel. This table will be used to ... >>>>>>> monitor >>>>>>> the tunnels supported by the system at a given point of time >>>>>>> (?) >>>>>>> It may also be used in conjunction with XXXX-mib to obtain the >>>>>>> other details of a tunnel by following the row pointer of the >>>>>>> corresponding tunnel's row in this table. >>>>>>> [ Please treat the above as a template and modify the text as >>>>>>> appropriate ..] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 3.3 Since this will become a standard document, please take care of >>>>>>> definitions and notations used in the document. >>>>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>>>> term/notation, define it before use. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 4. Definitions >>>>>>> >>>>>>>> IMPORTS >>>>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>>>> experimental. >>>>>>> It is good practice to keep the draft in the as "close to final >>>>>>> form" >>>>>>> as possible. (See below) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please update this date. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Updated. >>>>>> >>>>>>> 4.3 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "This MIB contains common managed object definitions for >>>>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Would be good if you could rearrange the text. Something like >>>>>>> "This MIB module will be used for managing multicast in Layer 2 >>>>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>>>> Or, even better >>>>>>> "This MIB module will be used by other MIB modules designed for >>>>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>>>> [RFC6513], [RFC6514] >>>>>>> Or, a combination of both, depending on the envisaged use case >>>>>>> scenarios. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Rearranged the text along with your comment. >>>>>> >>>>>>> 4.4 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ::= { experimental 999 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please >>>>>>> o Replace "experimental" by the branch where this mib module >>>>>>> will >>>>>>> be anchored; that is a decision that the WG will take, >>>>>>> probably. >>>>>>> o Import the branch in the IMPORTS statement >>>>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>>>> subtree >>>>>>> is requested. In that case this must be >>>>>>> ::= { mib-2 XXX } >>>>>>> ] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.5 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Please also remove the ", experimental" text from earlier >>>>>>>> -- IMPORTS section. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Remove these instructions. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>> 4.5.2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Texual convention >>>>>>> >>>>>>> >>>>>>> >>>>>>> Typo: -- Textual convention >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.6 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>>> DESCRIPTION >>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>>>> in future RFCs, and those will be allowed as >>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>> >>>>>>> >>>>>>> >>>>>>> The part >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Additional types may be defined >>>>>>>> in future RFCs, and those will be allowed as >>>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>>> >>>>>>> >>>>>>> >>>>>>> may be deleted. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Deleted. >>>>>> >>>>>>> 4.7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Top level components of this MIB. >>>>>>>> -- tables, scalars, conformance information >>>>>>>> >>>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> should be >>>>>>> >>>>>>> -- Top level components of this MIB. >>>>>>> >>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects >>>>>>> 1 >>>>>>> } >>>>>>> >>>>>>> -- tables, scalars, conformance information >>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.8 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>> MAX-ACCESS not-accessible >>>>>>>> STATUS current >>>>>>>> DESCRIPTION >>>>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It would seem that each row in this table is an index for a PTA >>>>>>> and may contain pointers to rows in tables of other MIB modules >>>>>>> which may contain more details for the PTA. Is that correct? >>>>>>> Please reword the DESCRIPTION acordingly. >>>>>>> Also see comments in 4.15 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I need some more time to understand the original context. >>>>>> >>>>>>> 4.9 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>> "An entry in this table corresponds to a PTA >>>>>>>> that is advertised/received on this router. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>>>>>> so "entry in this table" does not fit in well. >>>>>>> A rewording like >>>>>>> "A conceptual row corresponding to a PTA >>>>>>> that is advertised/received on this router. >>>>>>> .... >>>>>>> would be better. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.10 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>> they are just as signaled by BGP. >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>> they're derived from the S-PMSI Join Message. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Note that BGP-based signaling may be used for >>>>>>>> PIM-MVPN as well." >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is the signaling mechanism important here? If it isn't then the >>>>>>> above part of the description is redundant. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed the above part. >>>>>> >>>>>>> 4.10-2 >>>>>>> PIM-MVPN appears for the first time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Defined the notation of PIM-MVPM as follows >>>>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>>>> However, I think that some descriptions may be required for this >>>>>> somewhere in this document. That is TBD. >>>>>> >>>>>>> 4.10-3 >>>>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>>>> Somewhere earlier it should be made clear that UDP too may be used >>>>>>> in signaling. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. >>>>>> >>>>>>> 4.11 >>>>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>>> >>>>>>> >>>>>>> >>>>>>> "this" is unclear. >>>>>>> Something like "the value of this object is 0" will be better. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>>> More bits may be defined in the future and >>>>>>>> they will be registered in IANA Registry xxxx." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This part is probably redundant. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Removed. >>>>>> >>>>>>> 4.12 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>>>> -- and remove this note. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Look at the comments in 6.0 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The above description ("IANA Registry xxxx.") was removed, >>>>>> thus this part was also removed. >>>>>> >>>>>>> 4.13 >>>>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>>>> >>>>>>> >>>>>>> >>>>>>> o Does this description cover all the types? If not, then cover all >>>>>>> the >>>>>>> types unless there is a good reason to focus only on the above >>>>>>> types. >>>>>>> o I/S-PMSI: unexplained notation. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to address this point. >>>>>> >>>>>>> 4.14 >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>>>> included. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please indicate that the first column gives the size >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I made a change as follows. >>>>>> >>>>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>>>> (IPv4/IPv6) >>>>>> -------------------------------------------------- >>>>>> (snip) >>>>>> 8/32 pimAsm >>>>>> (snip) >>>>>> >>>>>> Is this OK? >>>>>> >>>>>>>> 8/32 pimAsm >>>>>>>> 8/32 pimSsm >>>>>>>> 8/32 pimBidir >>>>>>>> 4/16 ingressReplication >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>>>> 8 or 32 octets of this attribute are filled with >>>>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>>>>>> Identifier field in PMSI Tunnel Attribute of the >>>>>>>> corresponding I/S-PMSI A-D route." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A more generous description of the AttributeID would be good. All >>>>>>> the >>>>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A >>>>>>> simple >>>>>>> summary would be very nice. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. Please give me some more time to revise this point. >>>>>> >>>>>>> 4.15 >>>>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> SYNTAX RowPointer >>>>>>>> DESCRIPTION >>>>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>>>> pointer is null." >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am having problems understanding this. Will help if you can give >>>>>>> a use case of how this will be used. As of now the intent is >>>>>>> unclear. >>>>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>>>> pointer to a specific row in a specific table. If this is a pointer >>>>>>> to >>>>>>> a row in the mplsTunnelTable spell it out clearly and >>>>>>> unambiguously. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I will need some more time to understand the original context. >>>>>> >>>>>>> 4.16 >>>>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>> DESCRIPTION >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "If the tunnel has a corresponding interface, this is the >>>>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>>>> >>>>>>> >>>>>>> >>>>>>> This description is better. Would be even better with >>>>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>>>> this object will point to the row pertaining to the entry >>>>>>> ..... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 4.17 >>>>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DESCRIPTION >>>>>>>> "Support of these object is not required." >>>>>>> >>>>>>> >>>>>>> >>>>>>> Support of these objects is not required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> 5.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 5. Security Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> TBD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Still TBD. >>>>>> >>>>>>> 6.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6. IANA Considerations >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> IANA is requested to root MIB objects in the MIB module contained >>>>>>>> in >>>>>>>> this document under the mib-2 subtree. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please Note: >>>>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you >>>>>>> need >>>>>>> to >>>>>>> put the definitions in a separate MIB module. That would mean a >>>>>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>>>>> TC can be carried out by some entity ( IANA or, some WG or, >>>>>>> whoever >>>>>>> is >>>>>>> responsible for maintaining the TC) independent of other MIB >>>>>>> objects. >>>>>>> If that is the intent you will need to define 2 mib modules and >>>>>>> you >>>>>>> will >>>>>>> need to request 2 branches in the mib-2 subtree- one for the >>>>>>> module >>>>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for >>>>>>> the >>>>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TBD. I will address this point in the next revision. >>>>>> >>>>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Jeffrey, >>>>>>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >>>>>>> document. It took me some time to do this review. But now here it >>>>>>> is. A (near complete) review of >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>> is >>>>>>> attached. Hope this helps. >>>>>>> I understand that the Security Considerations section is TBD. >>>>>>> >>>>>>> Glenn >>>>>>> >>>>>>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Glenn, >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Glenn Mansfield Keeni [mailto:gl...@cysols.com] >>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM >>>>>>>>> To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Benoit Claise >>>>>>>>> <bcla...@cisco.com>; EXT - thomas.mo...@orange.com >>>>>>>>> <thomas.mo...@orange.com> >>>>>>>>> Cc: Mach Chen <mach.c...@huawei.com>; ops-...@ietf.org; Martin >>>>>>>>> Vigoureux >>>>>>>>> <martin.vigour...@nokia.com>; bess@ietf.org; mib-doct...@ietf.org >>>>>>>>> Subject: Re: [bess] MIBDoc review of >>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>>>>>>> 02.txt >>>>>>>>> >>>>>>>>> Jeffrey, >>>>>>>>> > Thanks for your comments. I've addressed most of your comments >>>>>>>>> > in the new revision: >>>>>>>>> Thanks for your cooperation. I will need at least one more revision >>>>>>>>> with the following comments/recommendations addressed before I will >>>>>>>>> be able to complete the detailed review. In the following the >>>>>>>>> numbers >>>>>>>>> refer to the issue numbers in the initial review. The issues that >>>>>>>>> are >>>>>>>>> addressed and closed are not listed. For brevity, the issue >>>>>>>>> descriptions have been trimmed. In case of doubts please look at >>>>>>>>> the >>>>>>>>> response mail appended below. >>>>>>>>> Hope this helps. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks for your detailed comments/suggestions. I posted a new >>>>>>>> revision >>>>>>>> with the following issues addressed. >>>>>>>> >>>>>>>> URL: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>>>>>>> Status: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>>>>>>> Htmlized: >>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>> Diff: >>>>>>>> >>>>>>>> >>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>>>>>>> >>>>>>>> Please see some notes below. >>>>>>>> >>>>>>>>> >>>>>>>>> Glenn >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> Comments: >>>>>>>>> >>>>>>>>> 1.1 >>>>>>>>> > I had thought this would be standard/obvious for all MIB >>>>>>>>> objects >>>>>>>>> - >>>>>>>>> We will comeback to this time and again, whereever possible make >>>>>>>>> matters explicit and clear. That will help. >>>>>>>>> > Is it enough to say something similar? For example: >>>>>>>>> > In particular, it describes common managed objects used >>>>>>>>> > to configure and/or monitor both L2 and L3 VPN >>>>>>>>> Multicast. >>>>>>>>> That is better. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I take it that this is already closed in -03 revision. >>>>>>>> >>>>>>>>> >>>>>>>>> 2.2 >>>>>>>>> > Having said that, I'll explain PMSI a bit further. >>>>>>>>> PMSI explanation is good. >>>>>>>>> Please use the same style/format for I-PMSI and S-PMSI. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think -03 revision already use the same style/format for I-PMSI >>>>>>>> and >>>>>>>> S-PMSI? >>>>>>>> >>>>>>>>> >>>>>>>>> 2.3 >>>>>>>>> > No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>> out >>>>>>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs >>>>>>>>> and >>>>>>>>> I >>>>>>>>> > was advised to change it accordingly. Looks like I did not >>>>>>>>> change >>>>>>>>> all >>>>>>>>> > the cases. >>>>>>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>>>>>>> VPN" >>>>>>>>> so >>>>>>>>> > I'll change it back. >>>>>>>>> No problems. just make sure that the same expression/notation is >>>>>>>>> used >>>>>>>>> uniformly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I take it that this is also addressed in -03 already. >>>>>>>> >>>>>>>>> 3. >>>>>>>>> > > > 3. Summary of MIB Module. >>>>>>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>> > > > structure of the MIB, short descriptions of the >>>>>>>>> table(s) >>>>>>>>> > > > including usage of the table(s) for management and/or >>>>>>>>> by >>>>>>>>> > > > other MIB(s). >>>>>>>>> > >>>>>>>>> > I had that, but have added one sentence about the only table. >>>>>>>>> A sentence or two about the textual convention will be good. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Added in -04. >>>>>>>> >>>>>>>>> > > > 4. MIB syntax checking: >>>>>>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>> > >>>>>>>>> > I used simpleweb's validation tool but looks like I did not use >>>>>>>>> the >>>>>>>>> > strictest level of validation. I've now fixed the following >>>>>>>>> issues >>>>>>>>> and >>>>>>>>> > verified. >>>>>>>>> Good. >>>>>>>>> 5. >>>>>>>>> > > > >>>>>>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses >>>>>>>>> liberally. >>>>>>>>> > > > Wherever possible, provide references for objects used >>>>>>>>> in >>>>>>>>> > > > the MIB. The references will point to specific sections/ >>>>>>>>> > > > sub-sections of the RFCs defining the protocol for which >>>>>>>>> the >>>>>>>>> > > > MIB is being designed. It will greatly improve the >>>>>>>>> readability >>>>>>>>> > > > of the document. >>>>>>>>> > >>>>>>>>> > Added. >>>>>>>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>>>>>>> improve on it. >>>>>>>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>>>>>>> clause move it to a separate REFERENCE clause. The addition of the >>>>>>>>> section number is an improvement. It is friendlier to the reader. >>>>>>>>> Note. Same comment for other OBJECTs too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Oh I missed that. All fixed. >>>>>>>> >>>>>>>>> 7.1 >>>>>>>>> > > > 7.1 CONTACT-INFO >>>>>>>>> > > > Following the conventions (including indentation style) >>>>>>>>> will >>>>>>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>> > > > Will be good if it does not overflow into the next >>>>>>>>> page. >>>>>>>>> > >>>>>>>>> > Fixed. >>>>>>>>> The format is OK. The Postal address etc., need not have been >>>>>>>>> deleted. Please put the complete contact information as in the >>>>>>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> 7.3 >>>>>>>>> > I kept "experimental 99" so that I could continue to use mib >>>>>>>>> tools >>>>>>>>> > to validate; but I added notes for the editor to replace them as >>>>>>>>> you >>>>>>>>> > indicated. >>>>>>>>> Use of "experimental 99" is not recommended. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Do you mean 99 is not a good number? What about 9999? As I >>>>>>>> explained, >>>>>>>> I >>>>>>>> kept it so that we can use mib tools to validate, and I've added >>>>>>>> detailed >>>>>>>> notes for the editor. >>>>>>>> >>>>>>>>> 8 >>>>>>>>> > > > 8. Specific MO and TC related comments. >>>>>>>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>> replace >>>>>>>>> > with things like rsvpP2mp. >>>>>>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ok this is closed already then. >>>>>>>> >>>>>>>>> 8.2 >>>>>>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>> > The intent is to simply return the octet value of the flags >>>>>>>>> > field, w/o listing individual bits like "Leaf Information >>>>>>>>> Required". >>>>>>>>> > More bits could be defined in the future but the MIB would not >>>>>>>>> change. >>>>>>>>> > >>>>>>>>> > Is that OK? >>>>>>>>> As far as possible, the meaning of the objects must be made clear. >>>>>>>>> That will help implementors and operators- users of the MIB. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I added the definition for one existing bit and reference to the >>>>>>>> IANA >>>>>>>> registry being created for this flag field. >>>>>>>> >>>>>>>>> >>>>>>>>> 8.3 >>>>>>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>> > Depending on the tunnel type, there could be different sizes. >>>>>>>>> > Future tunnel types could have other sizes that not specified >>>>>>>>> > today. I was thinking to just give a size >>>>>>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>>>>>>>> > Is that ok? >>>>>>>>> I see that you have changed the size upper limit to 50. >>>>>>>>> If the size varies continuously from 0 to 50 the above description >>>>>>>>> is correct. >>>>>>>>> Please confirm, explain and cite appropriate reference. If the size >>>>>>>>> may change in the future that must be stated too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I changed to discrete sizes for currently defined tunnel types. >>>>>>>> >>>>>>>>> >>>>>>>>> 8.4 >>>>>>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>> > > > SYNTAX RowPointer >>>>>>>>> > > > MAX-ACCESS read-only >>>>>>>>> > > > STATUS current >>>>>>>>> > > > DESCRIPTION >>>>>>>>> > > > "If the tunnel has a corresponding interface, >>>>>>>>> > > > this is the row pointer to the ifName table." >>>>>>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>>>>>>> > > > want to say this object points to the corresponding >>>>>>>>> > > > row in the ifTable? >>>>>>>>> > >>>>>>>>> > Yes. Fixed. >>>>>>>>> Not quite. >>>>>>>>> What is ifName table ? ifName is a columnar object in the >>>>>>>>> ifXTable. >>>>>>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row >>>>>>>>> in >>>>>>>>> the >>>>>>>>> ifXTable table ? Please fix accordingly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You're right. Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> 9. >>>>>>>>> > > > 9. The Security Considerations section does not follow >>>>>>>>> > > > the Security Guidelines for IETF MIB Modules >>>>>>>>> > > > >>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>> > > > Please fix. >>>>>>>>> > >>>>>>>>> > I was really hoping that it would not have to be that >>>>>>>>> > tedious. SNMP/MIB secur >>>>>>>>> ity should be no different from the >>>>>>>>> > CLI security - once you secure the infrastructure >>>>>>>>> > then what's more to do? >>>>>>>>> > >>>>>>>>> > I'll need more time to work on this. Let me try to address >>>>>>>>> > the issues in the other mib first and come back to this. >>>>>>>>> >>>>>>>>> Please take your time. Looking at examples will help. And let me >>>>>>>>> know where I can help. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I will need to work on that later. >>>>>>>> >>>>>>>>> >>>>>>>>> 10.1 >>>>>>>>> > > > 10.1 Checking nits according to >>>>>>>>> > > > http://www.ietf.org/id-info/checklist : >>>>>>>>> > Should I break them into different lines or just keep them >>>>>>>>> > as is? Any example of expected indentation if I break the >>>>>>>>> > lines? >>>>>>>>> No problems at all to break lines. >>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>>>>>>> ::= {l2L3VpnMcastConformance 1} >>>>>>>>> Should do. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Done. >>>>>>>> >>>>>>>>> >>>>>>>>> 10.2 >>>>>>>>> > > > 10.2 Checking references for intended status: Proposed >>>>>>>>> Standard >>>>>>>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line >>>>>>>>> 76, >>>>>>>>> > > > but not defined >>>>>>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and >>>>>>>>> other >>>>>>>>> > I hope I understood and fixed it (removing the space in "RFC >>>>>>>>> 7117"). >>>>>>>>> I would recommend that you put it as [RFC6513], [RFC6514], >>>>>>>>> [RFC7117] >>>>>>>>> That is simpler to parse. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I see some other documents do not have comma between multiple >>>>>>>> references >>>>>>>> so I followed that. >>>>>>>> >>>>>>>>> >>>>>>>>> > > > 11. There is another WIP MVPN-MIB in >>>>>>>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>>>>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>>>>>> > > > Is there a good reason for not merging the 2 >>>>>>>>> documents? >>>>>>>>> > > > I have not seen any discussion or explanation on this. >>>>>>>>> > > > I may have missed it. >>>>>>>>> > > > Please clarify or, give some pointers. >>>>>>>>> > >>>>>>>>> > As mentioned in the introduction: >>>>>>>>> > >>>>>>>>> > this memo describes managed objects common to both VPLS >>>>>>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>>>>>>> > in the work and both would reference common >>>>>>>>> >>>>>>>>> > objects defined in this MIB. >>>>>>>>> >>>>>>>>> OK. So you are saying that this MIB contains core objects that >>>>>>>>> will be used to manage implementations of various multicast VPN >>>>>>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>>>>>>> you spell it out at the beginning. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes. I thought I did it already: >>>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> ... and this memo describes managed objects common to both VPLS >>>>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Jeffrey >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Glenn, >>>>>>>>>> >>>>>>>>>> Thanks for your comments. I've addressed most of your comments in >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> new revision: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> URL: >>>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> l2l3-vpn-mcast-mib-03.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Status: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> vpn-mcast-mib/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Htmlized: >>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> mcast-mib-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Diff: >>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> vpn-mcast-mib-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please see below. >>>>>>>>>> >>>>>>>>>>> 1. Abstract: >>>>>>>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>>>>>>> applications for operations, monitoring and management >>>>>>>>>>> would be good. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had thought this would be standard/obvious for all MIB objects - >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> read-write ones are used to control how a device works, and the >>>>>>>>> read-only >>>>>>>>> ones are used for monitoring. Do I really need to say it >>>>>>>>> explicitly? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I see RFC 4382 has the following: >>>>>>>>>> >>>>>>>>>> This memo defines a portion of the Management Information Base >>>>>>>>>> (MIB) >>>>>>>>>> for use with network management protocols in the Internet >>>>>>>>>> community. >>>>>>>>>> In particular, it describes managed objects to configure and/or >>>>>>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>>>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label >>>>>>>>>> Switching >>>>>>>>>> Router (LSR) supporting this feature. >>>>>>>>>> >>>>>>>>>> Is it enough to say something similar? For example: >>>>>>>>>> >>>>>>>>>> In particular, it describes common managed objects used to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> configure >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. Introduction >>>>>>>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>>>>>>> appearing for the first time. (PE, VPLS,..) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>>>>>>> terms that are used, nicely with reference to the protocol >>>>>>>>>>> documents will improve readability. >>>>>>>>>>> e.g. >>>>>>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As the paragraph alluded to, this MIB needs to be understood in >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> general context of L2/L3 multicast VPN and providing good >>>>>>>>> explanation >>>>>>>>> of >>>>>>>>> the terms is not attempted. The references for the terms are the >>>>>>>>> the >>>>>>>>> RFCs >>>>>>>>> for the relevant technologies. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Having said that, I'll explain PMSI a bit further. >>>>>>>>>> >>>>>>>>>>> 2.3 Is there a difference between >>>>>>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>>>>>>> RFC 7117 and RFC 6513/6514" >>>>>>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>>>>>>> and >>>>>>>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>>>>>>> If these are the same, it will be helpful to stick to the >>>>>>>>>>> same expression. If these are not the same, the dictinction >>>>>>>>>>> should be clarified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed >>>>>>>>>> out >>>>>>>>>> that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>>>>>>>> advised to change it accordingly. Looks like I did not change all >>>>>>>>> the >>>>>>>>> cases. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" >>>>>>>>>> so >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll change it back. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3. Summary of MIB Module. >>>>>>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>>>>>>> structure of the MIB, short descriptions of the table(s) >>>>>>>>>>> including usage of the table(s) for management and/or by >>>>>>>>>>> other MIB(s). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had that, but have added one sentence about the only table. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> MIB definitions: >>>>>>>>>>> 4. MIB syntax checking: >>>>>>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>>>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I used simpleweb's validation tool but looks like I did not use >>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> strictest level of validation. I've now fixed the following issues >>>>>>>>> and >>>>>>>>> verified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: >>>>>>>>>>> named >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> See later question/comments below. >>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: >>>>>>>>>>> current >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never >>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is >>>>>>>>> never >>>>>>>>> used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>>>>>>> identifier >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never >>>>>>>>> used >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Removed the above unused imports. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>>>>>>> Wherever possible, provide references for objects used in >>>>>>>>>>> the MIB. The references will point to specific sections/ >>>>>>>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>>>>>>> MIB is being designed. It will greatly improve the readability >>>>>>>>>>> of the document. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Added. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 6. IMPORTS clause >>>>>>>>>>> MIB modules from which items are imported must be cited and >>>>>>>>>>> included in the normative references. >>>>>>>>>>> The conventional style is >>>>>>>>>>> mplsStdMIB >>>>>>>>>>> FROM MPLS-TC-STD-MIB -- >>>>>>>>>>> [RFC3811] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Added. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>>>>>>> errors.) >>>>>>>>>>> 7.1 CONTACT-INFO >>>>>>>>>>> Following the conventions (including indentation style) will >>>>>>>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>>>>>>> Will be good if it does not overflow into the next page. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>>>>>>>> sec 4.5 >>>>>>>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this >>>>>>>>>>> note: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>>>>>>>> sec 4.5 i >>>>>>>>>>> replace >>>>>>>>>>> ::= { experimental 99 } -- number to be assigned >>>>>>>>>>> by >>>>>>>>>>> ::= { <subtree> XXX } >>>>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove >>>>>>>>>>> this >>>>>>>>>>> note >>>>>>>>>>> <subtree> will be the subtree under which the module will be >>>>>>>>>>> registered. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I kept "experimental 99" so that I could continue to use mib tools >>>>>>>>>> to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> validate; but I added notes for the editor to replace them as you >>>>>>>>> indicated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8. Specific MO and TC related comments. >>>>>>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "Types of provider tunnels used for multicast in >>>>>>>>>>> BGP/MPLS L2 or IP VPN." >>>>>>>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>>>>>>> rsvp-p2mp (1), >>>>>>>>>>> ldp-p2mp (2), >>>>>>>>>>> pim-asm (3), >>>>>>>>>>> pim-ssm (4), >>>>>>>>>>> pim-bidir (5), >>>>>>>>>>> ingress-replication (6), >>>>>>>>>>> ldp-mp2mp (7) >>>>>>>>>>> >>>>>>>>>>> o Would be nice to align the enumeration labels with the >>>>>>>>>>> labels in the protocol document RFC 6514 unless there is >>>>>>>>>>> a good reason for not doing so. (You will have to take >>>>>>>>>>> care of the smi compilation errors too; '-' is not allowed >>>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Are spaces allowed? I don't know so I used hyphen. For now I >>>>>>>>>> replace >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> with things like rsvpP2mp. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Or could/should I just remove the definitions, so that if a new >>>>>>>>>> type >>>>>>>>>> is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> defined in the future there is no need to update the MIB? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "An entry in this table corresponds to an PMSI >>>>>>>>>>> attribute >>>>>>>>>>> that is advertised/received on this router. >>>>>>>>>>> For BGP-based signaling (for I-PMSI via >>>>>>>>>>> auto-discovery >>>>>>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>>>>>>> they are just as signaled by BGP (RFC 6514 section >>>>>>>>>>> 5, >>>>>>>>>>> 'PMSI Tunnel attribute'). >>>>>>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>>>>>> they're derived from S-PMSI Join Message >>>>>>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>>>>>>> >>>>>>>>>>> Note that BGP-based signaling may be used for >>>>>>>>>>> PIM-MVPN as well." >>>>>>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>>>>>>> o Please give the reference for this Table. >>>>>>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>>>>>>> both? >>>>>>>>>>> Any other pointers? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this >>>>>>>>>>> is >>>>>>>>>>> 0. >>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>>>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>>>>>> I/S-PMSI A-D route." >>>>>>>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>>>>>>> o Please confirm that the above is a complete enumeration of >>>>>>>>>>> the >>>>>>>>>>> types of signalling. >>>>>>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>>>>>>> "Leaf Information Required". That is useful information. >>>>>>>>>>> Please include in the description. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The intent is to simply return the octet value of the flags field, >>>>>>>>>> w/o >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> listing individual bits like "Leaf Information Required". More bits >>>>>>>>> could >>>>>>>>> be defined in the future but the MIB would not change. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is that OK? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>>>>>>> MAX-ACCESS not-accessible >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the >>>>>>>>>>> first >>>>>>>>>>> four or sixteen octets of this attribute are filled >>>>>>>>>>> with >>>>>>>>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>>>>>>>> For BGP-based I/S-PMSI signaling, this is the >>>>>>>>>>> Tunnel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Identifier >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Field in PMSI Tunnel Attribute of the corresponding >>>>>>>>>>> I/S- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> PMSI >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A-D route." >>>>>>>>>>> o Check the size specifications. The specs above say it can >>>>>>>>>>> be >>>>>>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION >>>>>>>>>>> clause. >>>>>>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Identifiers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress >>>>>>>>>>> Replication,MP2MP. >>>>>>>>>>> It appears that the sizes (range) for each case will be >>>>>>>>>>> different. >>>>>>>>>>> Please clarify that, and if there are discrete sizes, >>>>>>>>>>> specify >>>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Depending on the tunnel type, there could be different sizes. >>>>>>>>>> Future >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> tunnel types could have other sizes that not specified today. I was >>>>>>>>> thinking to just give a size range so that it is flexible. Is that >>>>>>>>> ok? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "If the tunnel exists in some MIB table, this is the >>>>>>>>>>> row pointer to it." >>>>>>>>>>> o "some MIB table" : specify which MIB table. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could >>>>>>>>>> be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> whatever table that a tunnel may be put into. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> o In what case will the tunnel exist and in what case will it >>>>>>>>>>> not? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If a device supports mplsTunnelTable and the tunnel is represented >>>>>>>>>> there, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> then it exists. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> o What will be the behaviour if the above condition is not >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> satisfied? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A null pointer should be given. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>>>>>>> SYNTAX RowPointer >>>>>>>>>>> MAX-ACCESS read-only >>>>>>>>>>> STATUS current >>>>>>>>>>> DESCRIPTION >>>>>>>>>>> "If the tunnel has a corresponding interface, this is >>>>>>>>>>> the >>>>>>>>>>> row pointer to the ifName table." >>>>>>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to >>>>>>>>>>> say >>>>>>>>>>> this object points to the corresponding row in the >>>>>>>>>>> ifTable? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes. Fixed. >>>>>>>>>> >>>>>>>>>>> o In what case does the TunnelIf exist and in what case will >>>>>>>>>>> it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> not? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some tunnels may not have a corresponding interface. >>>>>>>>>> >>>>>>>>>>> o What will be expected if the tunnel does not have a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> corresponding >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> interface? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Null row pointer. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9. The Security Considerations section does not follow the >>>>>>>>>>> Security >>>>>>>>>>> Guidelines for IETF MIB Modules >>>>>>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>>>>>>> Please fix. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I was really hoping that it would not have to be that tedious. >>>>>>>>>> SNMP/MIB >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> security should be no different from the CLI security - once you >>>>>>>>> secure >>>>>>>>> the infrastructure then what's more to do? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll need more time to work on this. Let me try to address the >>>>>>>>>> issues >>>>>>>>>> in >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> the other mib first and come back to this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 10.ID-nits >>>>>>>>>>> 10.1 Checking nits according to >>>>>>>>>>> http://www.ietf.org/id-info/checklist >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** There are 4 instances of too long lines in the document, >>>>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> longest one >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> being 3 characters in excess of 72. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I fixed some but there still three too long lines: >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>>>>>>> L2L3VpnMcastProviderTunnelType, >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= >>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= >>>>>>>>>> {l2L3VpnMcastConformance >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2} >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Should I break them into different lines or just keep them as is? >>>>>>>>>> Any >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> example of expected indentation if I break the lines? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 10.2 Checking references for intended status: Proposed Standard >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, >>>>>>>>>>> but >>>>>>>>>>> not >>>>>>>>>>> defined >>>>>>>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
