Re: Éric Vyncke's No Objection on draft-ietf-rtgwg-policy-model-30: (with COMMENT)

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

Yingzhen

Thank you for your reply: we are all set

Regards

-éric

-----Original Message-----
From: Yingzhen Qu <[e-mail]>
Date: Thursday, 12 August 2021 at 06:46
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, rtgwg-chairs <[e-mail]>, routing WG <[e-mail]>, Chris Bowers <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-rtgwg-policy-model-30: (with COMMENT)

    Hi Eric,

    Thank you for your review and comments, please see my answers inline.


    Thanks,
    Yingzhen

    > On Aug 11, 2021, at 6:57 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
    > 
    > Éric Vyncke has entered the following ballot position for
    > draft-ietf-rtgwg-policy-model-30: No Objection
    > 
    > 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/iesg/statement/discuss-criteria.html
    > for more information about DISCUSS and COMMENT positions.
    > 
    > 
    > The document, along with other ballot positions, can be found here:
    > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/
    > 
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document. I really admire the 4 authors
    > managing to reach a consensus even while having different affiliations: IETF at
    > its best!
    > 
    > Please find below some non-blocking COMMENT points (but replies would be
    > appreciated).
    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == COMMENTS ==
    > 
    > -- Section 2 --
    > Having "Policy chain: A policy chain is a sequence of policy definitions
    > (described in Section 4)." in the terminology section does not really help the
    > reader…
    [Yingzhen]: The language here is not clear. It means that policy definitions are descried in Section 4. I’ll remove “(described in Section 4)" in the next version.
    > 
    > -- Section 4.1 --
    > While I am not a YANG expert, I wonder about the "*" (usually meaning 0 or
    > more) for address in the neighbor-set container ? How can a neighbor exist w/o
    > an address ? Why not using the "min-elements' YANG statement ?
    > 
    [Yingzhen]: neighbor-set allows you to define a list of neighbor-set keyed by “name”. In each neighbor-set, besides name, there is a list of address. We didn’t add the “min-elements” statement because this allows to create an “empty” neighbor-set. I understand it’s not really useful when being referenced, but might be convenient during configuration.
    >