[Idr] Opsdir early review of draft-ietf-idr-rfc8203bis-04

Dan Romascanu via Datatracker <noreply@ietf.org> Tue, 01 October 2019 14:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B81201EA; Tue, 1 Oct 2019 07:01:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker <noreply@ietf.org>
To: <ops-dir@ietf.org>
Cc: idr@ietf.org, draft-ietf-idr-rfc8203bis.all@ietf.org, ietf@ietf.org, dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.103.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Dan Romascanu <dromasca@gmail.com>
Message-ID: <156993847735.23764.10465895063455957174@ietfa.amsl.com>
Date: Tue, 01 Oct 2019 07:01:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NjBogGu2zGPqCXG-V5GBUxX6ORw>
Subject: [Idr] Opsdir early review of draft-ietf-idr-rfc8203bis-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 14:01:18 -0000

Reviewer: Dan Romascanu
Review result: Has Issues

This document defines an enhancement to the BGP Cease NOTIFICATION message
"Administrative Shutdown" and "Administrative Reset" subcodes for operators to
transmit a short freeform message to describe why a BGP session was shutdown or
reset.  This document updates RFC 4486 and obsoletes RFC 8203 by defining an
Extended BGP Administrative Shutdown Communication to improve communication
using multibyte character sets.

It's clear and rather straightforward, so a full RFC 5706 review would not
apply. However, I have some questions and issues that I would suggest to be
clarified before advancement and approval.

1. The document will obsolete, if approved, [RFC 8203]. The rationale for this
change is currently relegated in Appendix B. I suggest to be moved up forward
in the document, in the introduction section.

2. The 'Changes to RFC 8203' section should include an explicit list of the
changes such as length field and usage of multibyte character sets.

3. I do not know how widely deployed RFC 8203 may be, but we cannot exclude
that some versions do exist out there. I suggest that the Operational
Considerations sections include some information about what caution need to be
taken by the operators when migrating from supporting RFC 8203 to the new RFC.

4. What does 'an invalid length value' mean in 'Error Handling' now? Previously
RFC 8203 had a requirement that 'The length value MUST range from 0 to 128
inclusive.' This does not exist any longer now.