Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-mib-iptfs-06: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Don

You were faster than the light ;-)

Indeed, the changes are ok for me and, more important, I do believe that they have improved the document. I also noticed that the tree is not updated, but I will trust you (and your AD) on this point. I will clear my DISCUSS shortly.

Thank you for your reply and your work

Regards

-éric

On 17/10/2022, 19:27, "Don Fedyk" <[e-mail]> wrote:

    Hi Eric 

    Thanks for you Review. We have posted an updated draft 07 to address your comments. 
    Note I Revalidated the MIB with the changes, but I realized I didn’t update the tree in the draft. So, I have one pending change, but I will wait and see if we satisfied your points.    

    See [Don] Below. 

    Thanks
    Don 

    -----Original Message-----
    From: Éric Vyncke via Datatracker <[e-mail]> 


    Éric Vyncke has entered the following ballot position for
    draft-ietf-ipsecme-mib-iptfs-06: Discuss

    When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


    Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
    for more information about how to handle DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/



    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06
    CC @evyncke

    Thank you for the work put into this document (even if I am balloting a
    DISCUSS);

    Please find below one blocking DISCUSS points (easy to address), some
    non-blocking COMMENT points (but replies would be appreciated even if only for
    my own education).

    Special thanks to Tero Kivinen for the shepherd's detailed write-up including
    the WG consensus *but* it lacks the justification of the intended status.

    I hope that this review helps to improve the document,

    Regards,

    -éric

    ## DISCUSS

    As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
    DISCUSS ballot is a request to have a discussion on the following topics:

    ### Inconsistent intended status & use of experimental code point

    This document is standard track, but the OID used in section 4.1 is
    'experimental' and in section 4.2 `experimental 500` per
    https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please request
    IANA to assign an OID from the 1.3.6.1.2.1 tree.

    [Don] This was a holdover from the initial draft.  
    We have updated to be consistent with the IANA requests and your comment. 

    BTW Thank you for helping us clarify where this should be placed. 

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    ## COMMENTS

    ### Section 1

    ```
       Note an IETF MIB model for IPsec was never standardized however the
       structures here could be adapted to existing MIB implementations.
    ```
    [Don] we updated to:
    adapted to existing proprietary MIB
    implementations where SNMP is used to manage networks.

    Perhaps clarify "existing MIB implementations" ? I guess this is about
    proprietary IPsec MIBs, but clarification will be welcome.

    ### Section 4.2

    Should the construct with `<CODE BEGINS>` be used to allow for easy file
    extraction ?

    [Don] OK Roman had requested this comment and I looked for MIB examples and found none. But as I updated the YANG, I found the sourcecode tag and used that for a mib and nothing seem to complain.  We may be the only MIB that ever used this though.

    `mailto:ekinzie.labn.net` is probably wrong ;-)
    [Don] Fixed. 

    `l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 7.1.10
    defines this type as monotically increasing. I understand that there are no
    interger64 in RFC 2578 but why not using a different unit than 'bps' for those
    two items ?

    [Don] We updated this CounterBasedGauge64 - Does this satisfy your point? SNMP has a richer set of types.   

    ### Section 5

    The IANA section should probably follow more closely RFC 8126, notably
    specifying the right registry (e.g., "SMI Network Management MGMT Codes
    Internet-standard MIB")

    [Don] Thanks we updated this an noted. 

    ### Section 8.1

    Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps I-D.ietf-ipsecme-iptfs)
    is a normative reference (i.e., I can implement this I-D MIB without accessing
    the YANG module).
    [Don] We moved the YANG to informative. We left the IP-TFS core draft as normative since it is the source for the attributes.  

    ## NITS

    ## Notes

    This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
    [`ietf-comments` tool][ICT] to automatically convert this review into
    individual GitHub issues.

    [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
    [ICT]: https://github.com/mnot/ietf-comments