[Idr] Éric Vyncke's No Objection on draft-ietf-idr-rfc5575bis-23: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-idr-rfc5575bis-23: 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 IESG DISCUSS and COMMENT positions.


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



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

Thank you for the work put into this document. The document is clear, easy to
read (I appreciated the given examples).

After discussion with the responsible AD, Alvaro Retana, and the IDR WG chairs,
I am clearing my DISCUSS (kept below for archival purpose) based on the promise
that the IPv6 companion document will be 'expedite processed' by the WG chairs,
document shepherd, and responsible AD + request for prompt processing by the
RFC Editor. The final goal is to have this document and its IPv6 companion
published roughly at the same time. (I still wonder why making two documents
though ;-) ).

Thanks to all for quickly updating the list of IPv6 implementations, that
opened the gate for publication.

-éric

-- below is no more current as the DISCUSS is cleared --

Why having two different documents ? One for IPv4 (with the core elements of
the protocol) and one for IPv6 (with only the IPv6 specifics)... I am more than
surprized to say the least... hence my DISCUSS...

This blocking DISCUSS can easily be fixed: e.g., with a RFC Editor note to make
a cluster of this document and draft-ietf-idr-flow-spec-v6 so that they are
published together with adjacent RFC numbers. Merging the two documents would
be preferred but I understand that this is more work (albeit a missed
opportunity).

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éricI also second Erik K.'s comment on non-TCP/UDP ports.