[Idr] Éric Vyncke's Discuss on draft-ietf-idr-rfc4360-bis-08: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-rfc4360-bis-08: 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-rfc4360-bis/



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


# Éric Vyncke INT AD comments for draft-ietf-idr-rfc4360-bis-08
CC @evyncke

Thank you for the work put into this document.

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

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 3.1

Why not a "MUST" in `For a non-mappable four-octet Autonomous System number
[RFC6793], the BGP speaker SHOULD fill AS_TRANS [RFC6793] in this field. ` ? A
PS should aim at interoperation and this specification is vague. See also:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 6

Also several BCP 14 "SHOULD", either provide the required guidance or simply
use "should".


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


## COMMENTS (non-blocking)

### Why not obsoleting RFC 5701

It is a huge missed opportunity by the IDR WG and the IETF that this I-D does
not obsolete RFC 5701 by incorporating its very short body text in this I-D.
Once my DISCUSS ballot is cleared, I will therefore ballot ABSTAIN on this
reason.

### Section 1

The text at the end of section 6 about using RFC 5701 for IPv6 should really be
moved to the section 1.