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

[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
>>>>>>>>>> documents
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> tha...'
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I hope I understood and fixed it (removing the space in "RFC 7117").
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Jeffrey
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: BESS [mailto:[e-mail]] On Behalf Of Glenn
>>>>>>>>>> Mansfield
>>>>>>>>>> Keeni
>>>>>>>>>> Sent: Tuesday, April 12, 2016 2:28 AM
>>>>>>>>>> To: Benoit Claise <[e-mail]>; EXT -
>>>>>>>>>> [e-mail]
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> Cc: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail];
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Vigoureux <[e-mail]>; [e-mail]; Mach Chen
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> Subject: [bess] MIBDoc review of
>>>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 02.txt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> I have been asked to do a MIB Doctors review of
>>>>>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt.
>>>>>>>>>> My knowledge of L2L3VPN Multicast is limited to the reading
>>>>>>>>>> of this document and browsing through the documents referred
>>>>>>>>>> to in the draft and bess-wg mailing list archives.( read
>>>>>>>>>> "shallow").
>>>>>>>>>> So some of the doubts and questions may sound trivial or
>>>>>>>>>> strange. Please bear with me and help me help you make
>>>>>>>>>> this into a better document :-)
>>>>>>>>>>
>>>>>>>>>> The comments are attached.
>>>>>>>>>>
>>>>>>>>>> Glenn
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> BESS mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> BESS mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> BESS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>