[Idr] Paul Wouters' Discuss on draft-ietf-idr-long-lived-gr-06: (with DISCUSS)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-idr-long-lived-gr-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-idr-long-lived-gr/



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

These two DISCUSSes should be easy to resolve :)


        The following text in Section 4.2 of the GR specification [RFC4724] no longer applies:
        [...]
        and the following procedures are specified instead:
        [...]

Shouldn't this be indicated with an Updates: 4724 clause ?



The well-known BGP community "LLGR_STALE" and "NO_LLGR" used by this document
are listed in the IANA registry as defined by draft-uttaro-idr-bgp-persistence
which expired in 2019.  If this is an early allocation, this value might vanish
from the registry ? I'm not sure what the exact process would be to ensure those
values remain in the registry and that these can be safely used by this document.

Then in the IANA Considerations, it claims _this_ document is adding these entries
to the IANA Registry?
        This document introduces a new BGP well-known community
        "LLGR_STALE" for marking long-lived stale routes, and another
        well-known community "NO_LLGR" to mark routes that should not
        be retained if stale.

So I guess that removes my concern by these entries expiring. I am assuming that this
document taking over these entries is okay, I just wanted to confirm that with the
responsible AD, the IETF Secretariat and IANA :-)