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

[Hiroshi Tsunoda <[e-mail]>]

Dear Glenn,

I posted a new revision taking into account your latest comments.
In the new revision, the following two new textual conventions are
added to L2L3-VPN-MCAST-TC-MIB.
   - L2L3VpnMcastProviderTunnelPointer
   - L2L3VpnMcastProviderTunnelPointerType

This change is to provide a mean to specify the table type referred
by the object in L2L3-VPN-MCAST-MIB.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-07.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-07
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-07

Please see some notes below.

> A.  Sec 1.1 Terminology.
> 1.  The scope of the MIB is  "Layer 2 and Layer 3 Virtual Private
>     Networks (VPN) that support multicast". This phrase appears
>     multiple times in the text.
>     It would be better to coin a term (eg L2/L3-VPN-MCast) for the
>     above in Sec 1.1 Terminology and use it in the text.

Hmm,  that phrase appears in Abstract, Sec.3, and MIB definition.
In my humble opinion, that current style seems better because
the MIB definition part may be read separately from this document.
Thus, I keep the current style.

> B.  TC-MIB
> 1   L2L3VpnMcastProviderTunnelType enumeration order:
>     Is there any rationale behind the difference in ordering in
>     Sec 1.1 Terminology and the enumeration in the textual convention?
>     Could these be aligned?

The enumeration order in the textual convention is based on
Section 5 of [RFC6514].
In Sec.1.1, I would like to categorize tunnel setup techniques
based on the protocol.

Thus, there is the difference in ordering in those sections.

> C.  L2L3-VPN-MCAST-MIB
> 1.  DESCRIPTION
>     The description states
>     "This MIB module will be used by other MIB modules designed for
>      managing multicast in Layer 2 (L2) VPNs [RFC7117] and
>      Layer 3 (L3) VPNs [RFC6513], [RFC6514]"
>
>     The statement differs from that in the abstract:
>     "designed for monitoring and/or configuring both
>     Layer 2 and Layer 3 Virtual Private Networks (VPN) that support
>     multicast."
>
>     Please align the descriptions.
>     [The description in the abstract appears more appropriate.]

Thank you. I fixed the description according to your recommendation.

> 2.  OID tree structure:
>     Is there any particular reason to have the l2L3VpnMcastStates subtree?
>     If no, then l2L3VpnMcastPmsiTunnelAttributeTable can come directly
>     under l2L3VpnMcastObjects

Fixed. Now l2L3VpnMcastPmsiTunnelAttributeTable is directy under
l2L3VpnMcastObjects.

> 3.  l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE
>        DESCRIPTION
>            "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId
>             may be represented as an entry in other table, e.g,
>             mplsTunnelTable [RFC3812].
>     There must be some means to specify which "other table" table this
>     RowPointer points too unless it points to a single prespecified
>     Table (mplsTunnelTable).

I defined a new object, l2L3VpnMcastPmsiTunnelPointerType, in
L2L3-VPN-MCAST-MIB.
This usage of this object is to specify the type of
l2L3VpnMcastPmsiTunnelPointer.
Its syntax is L2L3VpnMcastProviderTunnelPointerType which is defined
in L2L3-VPN-MCAST-TC-MIB.

I hope this fulfills your requirement.

> D.  Other issues:
>
> 1.  It is stated that this MIB will be used by other MIBs
>     "designed for monitoring and/or configuring both
>     Layer 2 and Layer 3 Virtual Private Networks (VPN) that support
>     multicast."
>
>    Is there a use case for this MIB? That would make it easier to
>    understand and review the applicability.

MCAST-VPN-MIB, defined in other document, use this MIB
to get the information of BGP PMSI attribute.
MCAST-VPN-MIB has several tables for monitoring and configuring
several types of PMSI (I-PMSI, S-PMSI, etc).
Each table is required to have the attribute information and has
the pointer to a row in l2L3VpnMcastPmsiTunnelAttributeTable.

I hope this answers your question.

> 2.  You are sure that notifications are not required ?

I think no notifications are required.
I and Jeffery do not find any useful notifications regarding this MIB
for operators/administrators.

> 3.  You are sure that read-write and/or read-create operations are not
>     required for rows in l2L3VpnMcastPmsiTunnelAttributeTable?
>
>     Then the purpose of this MIB will be limited to
>          o provide a pointer to tables like ifXTable for further attributes
>          o provide a list of tunnels
>    only?

The content of the table comes only from signaling.
Therefore, I think read-write and read-create operations are not required.

> E.  Editorial issues
>     A complete editorial review is TBD.
>
> 1.  line 99: Typo?
>     < BPG auto-discovery (A-D) routes.
>     > BPG auto-discovery (A-D) routes.
> 2.  line 102: Typo
>     < This document defines a textual conventions (TC)
>     > This document defines a textual convention (TC)
> 3.  line 134: nit
>     < A PE uses to send
>     > A PE uses it to send

Fixed. Thank you very much for pointing these out.

Thanks.

-- tsuno

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

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