[Bier] Robert Wilton's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Wed, 25 August 2021 13:50 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bier@ietf.org
Delivered-To: bier@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C36913A0AA4; Wed, 25 Aug 2021 06:50:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bier-te-arch@ietf.org, bier-chairs@ietf.org, bier@ietf.org, Xuesong Geng <gengxuesong@huawei.com>, aretana.ietf@gmail.com, gengxuesong@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <162989945476.29713.12937356180696657837@ietfa.amsl.com>
Date: Wed, 25 Aug 2021 06:50:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/tzde7S8m5AZbkO8j2LDo5hOKPcM>
Subject: [Bier] Robert Wilton's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2021 13:50:55 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-bier-te-arch-10: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



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

Hi,

I would like to please double check with the authors, responsible AD, and IESG
that publishing this as standards track is the right choice (as opposed to
experimental).

>From the first line of the introduction:
"BIER-TE is based on architecture, terminology and packet formats with
   BIER as described in [RFC8279] and [RFC8296].

Both RFC 8279 and RFC 8296 are experimental RFCs, hence (1) I wanted to check
that by publishing this draft as Std Track, that this draft isn't being built
on an unstable footing.

This draft has a normative reference to RFC 8279, but only an informative
reference to RFC 8296.

Hence, I further wanted to check:
(2) Should RFC 8296 really be a normative reference?
(3) The IETF LC announcement didn't seem to flag the downref to RFC 8279.  RFC
8067 says that is not strictly required, but in this case I think that would
have been useful.

I can see from the document history that the WG has flip-flopped on whether
this document should be experimental or stds track, but I couldn't quickly find
this discussion, and it wasn't covered in shepherds writeup.  If it is possible
for someone to provide a quick summary as to why it is okay and right to
publish this as standards track that would be appreciated.


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

Thanks for your work on this document.

I'm not an expert on the BIER technology, and I didn't have the time to
properly read the core references before reviewing this document.  However, I
didn't spot any obvious issues on the text, beyond the question on the document
status.  But I also appreciated the detailed section on the operational
considerations related to managing the bit position assignments, which I
interpret not as a strict requirement of this specification, but likely to be
very helpful to controller implementations and operators.

Regards,
Rob