[RTG-DIR] Rtgdir early review of draft-ietf-mpls-mna-requirements-12

Susan Hares via Datatracker <noreply@ietf.org> Sun, 21 April 2024 12:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6037C14CEE3; Sun, 21 Apr 2024 05:02:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Susan Hares via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-mpls-mna-requirements.all@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171370097593.34977.18348102734454699963@ietfa.amsl.com>
Reply-To: Susan Hares <shares@ndzh.com>
Date: Sun, 21 Apr 2024 05:02:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ZRvf4I4k81sZcsOUSaN20ddzf90>
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-mpls-mna-requirements-12
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2024 12:02:56 -0000

Reviewer: Susan Hares
Review result: Has Nits

Status: Ready with NITS

Summary: No Technical issues were found when examined with:
- draft-ietf-mpls-mna-usecases-04
- draft-ietf-mpls-mna-fwk-07

One technical suggestion:
I think more of the MNA framework security consideration should be pulled into
this document to cover: - current network boundaries using filters that form a
trust boundary, - differences with new boundaries that impact that trust
boundary.

By reference of draft-ietf-mpls-mna-fwk, one can find the technical material.
However, a bit more in the text would help the reader.

MPLS-chairs,
Thank you for your patience in waiting for this early review.
Sue

=====================
NITS
1. Requirement #33
Why: Grammar and sentence clarity
Old text:/
   33.  NAIs MUST only be inserted at LSRs that push a label onto the
        stack, e.g. head end LSRs and points of local repair (PLR), but
        can be processed by LSRs along the path of the LSP./

comment: The text
"/, the use of ".e.g. head end LSR and points of local report (PLR), /

is confusing and difficult to read.  Consider rewriting the sentence.

#2 Requirement #39.
Why: Grammar and sentence clarity - the "i.e." detracts from clarity without
adding value. Text:/
   39.  A network action solution specification MUST state where the
        NAIs are to be placed in the packet i.e. in-stack or post-stack.
     /
Suggested New text:/
   39.  A network action solution specification MUST state where the
        NAIs are to be placed in the packet i.e. in-stack or post-stack.
     /

#3 Requirement #47
Why: Grammar and sentence clarity. "inserting" and "that"
Current text:/
   47.  An MNA solution MUST allow an LER inserting ancillary data to
        determine that each node that needs to process the ancillary
        data can read the required distance into the packet at that node
        (compare with the mechanism in [RFC9088])./
Suggested text:/
   47.  An MNA solution MUST allow an LER that inserts ancillary data to
        determine whether each node that needs to process the ancillary
        data can read the required distance into the packet at that node
        (compare with the mechanism in [RFC9088])./

#4: Section 5, paragraph 2, second sentence
Why: Grammar - Commas in sentence make it difficult to read, "labelled"
(spelling ?).

Current text:/
   Furthermore, an LSR may insert information into the
   labelled packet such that the forwarding behavior is no longer purely
   a function of the top label, or other label with forwarding context,
   but instead is the result of a more complex heuristic./

Perhaps consider a rewrite.
New text:/
   An LSR may insert information into a label packet such that the
   forwarding behavior is no longer a function of either the top label or
   another label within the forwarding context, but a result
   complex heuristic. /

Thank you for your patience in receiving this early