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

[Hiroshi Tsunoda <[e-mail]>]

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
>>
>