[MIB-DOCTORS] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-11

Dear Glenn,

Thank you for your comments and for waiting for the update.
I posted a new revision (-11) as follows.

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

Please see the responses for your comments in the followings.

2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>:
> 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION
> 1.1   It will be good to give a reference (RFCNNNN) for
>          noTunnelInfo       (0) : no tunnel information present
>       That will make it consistent with the other items.
>       This change will require adding RFCNNNN to the REFERENCE clause.

Fixed.

> 1.2      pimBidir           (5) : BIDIR-PIM Tree      [RFC5015]
>       RFC5015 needs to be added to the Reference section

RFC5015 added to the Reference section.

> 3. Page-7,8: says
>        " A L2L3VpnMcastProviderTunnelType object of value
>          noTunnelInfo(0) indicates that the corresponding
>          Provider Multicast Service Interface (PMSI) Tunnel
>          attribute does not have a Tunnel Identifier."
>    It may be better to align the wording with RFC6514 (Page 11)
>        ' When the Tunnel Type is set to "No tunnel information
>          present", the PMSI Tunnel attribute carries no tunnel
>          information (no Tunnel Identifier).'

Fixed. Thank you for your advice.

> 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION:
>          E: Extension flag [RFC7902]
>       RFC7902 needs to be added to the Reference section

Fixed. RFC7902 is now in the Reference section.

> 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE
>           "RFC6514, Section 5
>            RFC7902
>           "
>       It will be nice to have a section pointer for RFC7902 too.
>       (User-friendly and consistency).
>       Please check the same for all the REFERENCE clause pointers

Added a section point for Sec.3 of RFC7902.

> 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION
>           "When UDP-based S-PMSI signaling is used, the value of
>           this object is zero."
>        This is actually a 48-bit string. What would be the
>        representation of "zero" above be? Will it be a string of
>        length 0, a string containing a single ascii character "0"
>        6 ascii "0"s, 48 '0' bits ?
>
> 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION:
>           "When UDP-based S-PMSI signaling is used, the value of
>           this object is zero that indicates the absence of MPLS
>           Label."
>        Once again.  "zero" above is imprecise.

In the current revision, these parts are revised as follows.
  When the P-tunnel does not have a correspondent PMSI tunnel
  attribute, the value of this object will be 0.

> 8. Compliance:
>    It would be good to design the compliance module as follows:
>       l2L3VpnMcastCoreCompliance:
>           MANDATORY-GROUPS {
>                l2L3VpnMcastPmsiFieldGroup
>           }
>       l2L3VpnMcastFullCompliance:
>           MANDATORY-GROUPS {
>                l2L3VpnMcastPmsiFieldGroup
>                l2L3VpnMcastOptionalGroup
>           }

Fixed along with your comments. Thank you.

> General:
> 10    Page-2 Section-1
> 10.1    In BGP/MPLS Virtual Private Networks (VPN)
>         In BGP/MPLS Virtual Private Networks (VPNs) ?

Fixed.

> 10.2    Throughout this document, we will use the term
>         "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support
>         multicast.
>
>         Throughout this document, we will use the term
>         "L2L3VpnMCast network" to mean a network that comprises of
>         BGP/MPLS L2 and L3 VPNs and supports multicast.

Fixed. Now, the term "L2L3VpnMCast network" is used throughout the document.

> 10.3  Page-4 Section-3 bullet 2
>       Please review the paragraph for readability.

Revised the paragraph in order to improve readability.

> 10.4  It will be good to avoid page-breaks within quoted clauses.
>       example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE

Thank you for your comments. I adjusted the page-breaks along with this comment.

Thanks again.

-- tsuno

2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>:
> Dear Tsuno,
>
> Thanks for the revised draft. I have reviewed the draft.
> Some issues remain. These are listed below
> Please consider the issues/comments and update the draft.
>
> Glenn
>
> +--------------------------------------------------------+
>
> 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION
> 1.1   It will be good to give a reference (RFCNNNN) for
>          noTunnelInfo       (0) : no tunnel information present
>       That will make it consistent with the other items.
>       This change will require adding RFCNNNN to the REFERENCE clause.
> 1.2      pimBidir           (5) : BIDIR-PIM Tree      [RFC5015]
>       RFC5015 needs to be added to the Reference section
>
> 2. Page-6: L2L3VpnMcastProviderTunnelType: SYNTAX
>       The rewritten SYNTAX clause without the repetitions looks better.
>       Thanks.
>
> 3. Page-7,8: says
>        " A L2L3VpnMcastProviderTunnelType object of value
>          noTunnelInfo(0) indicates that the corresponding
>          Provider Multicast Service Interface (PMSI) Tunnel
>          attribute does not have a Tunnel Identifier."
>    It may be better to align the wording with RFC6514 (Page 11)
>        ' When the Tunnel Type is set to "No tunnel information
>          present", the PMSI Tunnel attribute carries no tunnel
>          information (no Tunnel Identifier).'
>
> 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION:
>          E: Extension flag [RFC7902]
>       RFC7902 needs to be added to the Reference section
>
> 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE
>           "RFC6514, Section 5
>            RFC7902
>           "
>       It will be nice to have a section pointer for RFC7902 too.
>       (User-friendly and consistency).
>       Please check the same for all the REFERENCE clause pointers
> 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION
>           "When UDP-based S-PMSI signaling is used, the value of
>           this object is zero."
>        This is actually a 48-bit string. What would be the
>        representation of "zero" above be? Will it be a string of
>        length 0, a string containing a single ascii character "0"
>        6 ascii "0"s, 48 '0' bits ?
>
> 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION:
>           "When UDP-based S-PMSI signaling is used, the value of
>           this object is zero that indicates the absence of MPLS
>           Label."
>        Once again.  "zero" above is imprecise.
>
> 8. Compliance:
>    It would be good to design the compliance module as follows:
>       l2L3VpnMcastCoreCompliance:
>           MANDATORY-GROUPS {
>                l2L3VpnMcastPmsiFieldGroup
>           }
>       l2L3VpnMcastFullCompliance:
>           MANDATORY-GROUPS {
>                l2L3VpnMcastPmsiFieldGroup
>                l2L3VpnMcastOptionalGroup
>           }
>
>
> General:
> 10    Page-2 Section-1
> 10.1    In BGP/MPLS Virtual Private Networks (VPN)
>         In BGP/MPLS Virtual Private Networks (VPNs) ?
>
> 10.2    Throughout this document, we will use the term
>         "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support
>         multicast.
>
>         Throughout this document, we will use the term
>         "L2L3VpnMCast network" to mean a network that comprises of
>         BGP/MPLS L2 and L3 VPNs and supports multicast.
>
> 10.3  Page-4 Section-3 bullet 2
>       Please review the paragraph for readability.
>
> 10.4  It will be good to avoid page-breaks within quoted clauses.
>       example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE
>
>
>
>
> On 2017/08/28 3:27, Hiroshi Tsunoda wrote:
>>
>> Dear Glenn,
>>
>> Thank you for your comments and for waiting for the update.
>> I posted a new revision (-10) as follows.
>>
>> URL:
>>
>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-10.txt
>> Htmlized:
>>         https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10
>> Htmlized:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10
>> Diff:
>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-10
>>
>> In the new revision, the following changes are made.
>>   - Updated the description of following TC and objects
>>     in order to clarify the role of this MIB and to improve
>>     the readability
>>      -- L2L3VpnMcastProviderTunnelId
>>      -- l2L3VpnMcastPmsiTunnelAttributeTable
>>   - Removed some redundant expressions
>>   - Updated compliance statements
>>
>> Please see the responses for your comments
>> in the followings.
>>
>> 2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni <glenn@cysols.com>:
>>>
>>>    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?
>>
>>
>> The size and format of TunnelID depends on Tunnel Type.
>> and no preferred format is exist as of now.
>> Therefore, I have decided to not give format specification
>> to L2L3VpnMcastProviderTunnelId.
>>
>>> 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.
>>
>>
>> According to Sec. 7.4.1.1 of RFC6513,
>> P-tunnel is identified by its type and id.
>> Thus, in the latest revision, the following two objects are used as
>> index of the table.
>>         l2L3VpnMcastPmsiTunnelAttributeType,
>>         l2L3VpnMcastPmsiTunnelAttributeId
>>
>> Thanks in advance,
>>
>> -- tsuno
>>
>> _______________________________________________
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess