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

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

Dear Tsuno/Zhang,
  > Thank you for your comments. I posted a new revision (-09)
This draft looks good. Thank you very much.

L2L3-VPN-MCAST-TC-MIB is almost OK.
smilint gives warnings
   L2L3-VPN-MCAST-TC-MIB:63: [5] {type-unref} warning: current type
   `L2L3VpnMcastProviderTunnelType' is not referenced in this module
   L2L3-VPN-MCAST-TC-MIB:112: [5] {type-unref} warning: current type
   `L2L3VpnMcastProviderTunnelId' is not referenced in this module
These may be ignored.
   L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type
   `L2L3VpnMcastProviderTunnelId' has no format specification
This may be avoided by specifying a format in which the
L2L3VpnMcastProviderTunnelId should be printed.
Is there a preferred format? How will this be printed?
One continuous octet string?

L2L3-VPN-MCAST-MIB is also syntactically OK.

But before we go on to the next stage could you please confirm that
A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the following
    four MOs as index for its rows
              l2L3VpnMcastPmsiTunnelAttributeFlags,
              l2L3VpnMcastPmsiTunnelAttributeType,
              l2L3VpnMcastPmsiTunnelAttributeLabel,
              l2L3VpnMcastPmsiTunnelAttributeId
    The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate? If yes
    please explain it to me. Or point to the text that contains the
    explanation.
I have been unable to confirm the above from the draft - that is very
likely due to my lack of understanding of the l2L3VpnMcast technology.

Glenn

On 2017/06/22 2:35, Hiroshi Tsunoda wrote:
> 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
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>