Thanks for the comment, But do we mark the update to base RFC if some reserved bit is being used? Because it does not change any base procedure of RFC 7307.
Mankamana
From:
Roni Even via Datatracker <noreply@xxxxxxxx>
Date: Thursday, May 2, 2024 at 11:20 PM
To: gen-art@xxxxxxxx <gen-art@xxxxxxxx>
Cc: draft-ietf-mpls-mldp-multi-topology.all@xxxxxxxx <draft-ietf-mpls-mldp-multi-topology.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, mpls@xxxxxxxx <mpls@xxxxxxxx>
Subject: Genart last call review of draft-ietf-mpls-mldp-multi-topology-05
Reviewer: Roni Even
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-mpls-mldp-multi-topology-??
Reviewer: Roni Even
Review Date: 2024-05-02
IETF LC End Date: 2024-05-02
IESG Telechat date: 2024-05-16
Summary:
The document is ready for publication as a standard track rfc with nits
Major issues:
Minor issues:
Nits/editorial comments:
1. This document is using the few types from iana fed type name space registry.
I think that the Iana section should ask to update the registry pointing to
this document and verify that all fields in the relevant entries are not
changed 2. The document is using 8 bits from the MT IP address for the IPA
field. Should this document title say that it updates RFC7307 or specify how to
prevent different use of these reserved bits?
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
