Re: [MIB-DOCTORS] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07

[Hiroshi Tsunoda <[e-mail]>]

Dear Glenn,

Thank you for your comments. I posted a new revision (-09) as follows.

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

In the new revision, all of your comments are addressed and
the following additional changes are made.

-   Update the definition and description of L2L3VpnMcastProviderTunnelType
    Describe the enumerated values and the corresponding
    tunnel type.
    I added new valule, transportTunnel (8) defined in [RFC7524].

 - Add some description related to transportTunnel (8)
   into the defi L2L3VpnMcastProviderTunnelId

 - Update the description of l2L3VpnMcastPmsiTunnelAttributeFlags
   according to [RFC7902]

 -  Added a new object, l2L3VpnMcastPmsiTunnelAttributeAddlFlags.
    This is defined in [RFC7902]

I also removed some paragraph from 1.1 Terminology section,
because those seem verbose.

Please see some other notes below.

2017-06-05 12:24 GMT+02:00 Glenn Mansfield Keeni <[e-mail]>:
> 1. The explanations for the size of the identifiers for each tunneling
>    technology in TC L2L3VpnMcastProviderTunnelId
>    is nicely done. These are aligned with definitions in rfc6514.
>    In
>            noTunnelId         (0), -- No tunnel information
>    is there a specific reason to name it 'noTunnelId' instead of
>    'noTunnelInfo'.

Fixed.

> 2. The TCs
>        L2L3VpnMcastProviderTunnelPointerType, and
>        L2L3VpnMcastProviderTunnelPointer
>    Are probably not required. The value of the RowPointer [rfc2579]
>    object is ' the name of the instance of the first
>                accessible columnar object in the conceptual row'
>    So the pointer will explicitly contain the name of the table.
>    An auxilliary type object to indicate the table name is not
>    necessary.
>   [This is an oversight on my part. I should have noticed this earlier.]

These TCs were removed and related descriptions in other parts
in the document were updated.

> Other Editorials:
> P-2. Sec-1.
> 1.   para-1 makes tedious reading. Could this be improved?
>
> 2.       "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)"
>      The usage of the '/' here is unclear.

Updated.
In the new revision, BGP/MPLS VPN is explained in para-1, and
multicast support in BGP/MPLS Layer 2 and Layer 3 is explained in para-2
separately.

> 3.       "and L3 VPNs.  Therefore, TCs and MOs defined"
>      The context of the 'Therefore' is not clear.

Fixed. I removed the related sentence because it seemed not
required already.

> 4.       "The are two type"
>      Probably s/The/There/ ?

Fixed. Thank you for pointing it out.

-- tsuno