Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni <[e-mail]>]

Hi Tsunoda,
Got this. Thanks for the good work.
I hope to review this draft and get
back to you by the end of next week.

Cheers
Glenn
On 2017/04/13 18:41, Hiroshi Tsunoda wrote:
> Dear Glenn,
>
> I posted a new revision taking into account your latest comments.
> In the new revision, the following two new textual conventions are
> added to L2L3-VPN-MCAST-TC-MIB.
>    - L2L3VpnMcastProviderTunnelPointer
>    - L2L3VpnMcastProviderTunnelPointerType
>
> This change is to provide a mean to specify the table type referred
> by the object in L2L3-VPN-MCAST-MIB.
>
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-07.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-07
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-07
>
> Please see some notes below.
>
>> A.  Sec 1.1 Terminology.
>> 1.  The scope of the MIB is  "Layer 2 and Layer 3 Virtual Private
>>     Networks (VPN) that support multicast". This phrase appears
>>     multiple times in the text.
>>     It would be better to coin a term (eg L2/L3-VPN-MCast) for the
>>     above in Sec 1.1 Terminology and use it in the text.
>
> Hmm,  that phrase appears in Abstract, Sec.3, and MIB definition.
> In my humble opinion, that current style seems better because
> the MIB definition part may be read separately from this document.
> Thus, I keep the current style.
>
>> B.  TC-MIB
>> 1   L2L3VpnMcastProviderTunnelType enumeration order:
>>     Is there any rationale behind the difference in ordering in
>>     Sec 1.1 Terminology and the enumeration in the textual convention?
>>     Could these be aligned?
>
> The enumeration order in the textual convention is based on
> Section 5 of [RFC6514].
> In Sec.1.1, I would like to categorize tunnel setup techniques
> based on the protocol.
>
> Thus, there is the difference in ordering in those sections.
>
>> C.  L2L3-VPN-MCAST-MIB
>> 1.  DESCRIPTION
>>     The description states
>>     "This MIB module will be used by other MIB modules designed for
>>      managing multicast in Layer 2 (L2) VPNs [RFC7117] and
>>      Layer 3 (L3) VPNs [RFC6513], [RFC6514]"
>>
>>     The statement differs from that in the abstract:
>>     "designed for monitoring and/or configuring both
>>     Layer 2 and Layer 3 Virtual Private Networks (VPN) that support
>>     multicast."
>>
>>     Please align the descriptions.
>>     [The description in the abstract appears more appropriate.]
>
> Thank you. I fixed the description according to your recommendation.
>
>> 2.  OID tree structure:
>>     Is there any particular reason to have the l2L3VpnMcastStates subtree?
>>     If no, then l2L3VpnMcastPmsiTunnelAttributeTable can come directly
>>     under l2L3VpnMcastObjects
>
> Fixed. Now l2L3VpnMcastPmsiTunnelAttributeTable is directy under
> l2L3VpnMcastObjects.
>
>> 3.  l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE
>>        DESCRIPTION
>>            "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId
>>             may be represented as an entry in other table, e.g,
>>             mplsTunnelTable [RFC3812].
>>     There must be some means to specify which "other table" table this
>>     RowPointer points too unless it points to a single prespecified
>>     Table (mplsTunnelTable).
>
> I defined a new object, l2L3VpnMcastPmsiTunnelPointerType, in
> L2L3-VPN-MCAST-MIB.
> This usage of this object is to specify the type of
> l2L3VpnMcastPmsiTunnelPointer.
> Its syntax is L2L3VpnMcastProviderTunnelPointerType which is defined
> in L2L3-VPN-MCAST-TC-MIB.
>
> I hope this fulfills your requirement.
>
>> D.  Other issues:
>>
>> 1.  It is stated that this MIB will be used by other MIBs
>>     "designed for monitoring and/or configuring both
>>     Layer 2 and Layer 3 Virtual Private Networks (VPN) that support
>>     multicast."
>>
>>    Is there a use case for this MIB? That would make it easier to
>>    understand and review the applicability.
>
> MCAST-VPN-MIB, defined in other document, use this MIB
> to get the information of BGP PMSI attribute.
> MCAST-VPN-MIB has several tables for monitoring and configuring
> several types of PMSI (I-PMSI, S-PMSI, etc).
> Each table is required to have the attribute information and has
> the pointer to a row in l2L3VpnMcastPmsiTunnelAttributeTable.
>
> I hope this answers your question.
>
>> 2.  You are sure that notifications are not required ?
>
> I think no notifications are required.
> I and Jeffery do not find any useful notifications regarding this MIB
> for operators/administrators.
>
>> 3.  You are sure that read-write and/or read-create operations are not
>>     required for rows in l2L3VpnMcastPmsiTunnelAttributeTable?
>>
>>     Then the purpose of this MIB will be limited to
>>          o provide a pointer to tables like ifXTable for further attributes
>>          o provide a list of tunnels
>>    only?
>
> The content of the table comes only from signaling.
> Therefore, I think read-write and read-create operations are not required.
>
>> E.  Editorial issues
>>     A complete editorial review is TBD.
>>
>> 1.  line 99: Typo?
>>     < BPG auto-discovery (A-D) routes.
>>     > BPG auto-discovery (A-D) routes.
>> 2.  line 102: Typo
>>     < This document defines a textual conventions (TC)
>>     > This document defines a textual convention (TC)
>> 3.  line 134: nit
>>     < A PE uses to send
>>     > A PE uses it to send
>
> Fixed. Thank you very much for pointing these out.
>
> Thanks.
>
> -- tsuno
>
> 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni <[e-mail]>:
>> 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 <[e-mail]>:
>>>>
>>>> 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 <[e-mail]>:
>>>>>>
>>>>>>
>>>>>> 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 <[e-mail]>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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:[e-mail]]
>>>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM
>>>>>>>>>> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Benoit Claise
>>>>>>>>>> <[e-mail]>; EXT - [e-mail]
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> Cc: Mach Chen <[e-mail]>; [e-mail]; Martin
>>>>>>>>>> Vigoureux
>>>>>>>>>> <[e-mail]>; [e-mail]; [e-mail]
>>>>>>>>>> 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
>
> 2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni <[e-mail]>:
>> 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 <[e-mail]>:
>>>>
>>>> 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 <[e-mail]>:
>>>>>>
>>>>>>
>>>>>> 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 <[e-mail]>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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:[e-mail]]
>>>>>>>>>> Sent: Sunday, May 08, 2016 11:02 AM
>>>>>>>>>> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Benoit Claise
>>>>>>>>>> <[e-mail]>; EXT - [e-mail]
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> Cc: Mach Chen <[e-mail]>; [e-mail]; Martin
>>>>>>>>>> Vigoureux
>>>>>>>>>> <[e-mail]>; [e-mail]; [e-mail]
>>>>>>>>>> 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}
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> S
>>
>> ...
>>
>> [クリップしたメッセージ]
>