Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-11

Hi Tsuno,
    Thanks for addressing the issues in the new draft. It
looks good. I do not have any major issues with the MIB.
But before we give a go-ahead I would like to ask to you
do another editorial check for nits.These are basically
               s/network/networks/
type of fixes.
A minor issue with the MIB on naming related mater-
I would suggest
       s/l2L3VpnMcastPmsiFieldGroup/l2L3VpnMcastCoreGroup/

Glenn

On 2017/10/22 1:14, Hiroshi Tsunoda wrote:
> 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