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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 25 Aug 2021 06:50:54 -0700

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

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 25 Aug 2021 08:43:37 -0700

On August 25, 2021 at 9:50:55 AM, Robert Wilton wrote:

Rob:

Hi!

Both RFC8279 and RFC8296 are in fact Standard Track documents.  The
bier WG was originally chartered to produce experimental work, right
as those documents were published (as Experimental), the WG was
rechartered and the status of the documents was changed to Standards
Track:

https://datatracker.ietf.org/doc/status-change-bier-core-to-proposed-standard/

FWIW, the datatracker shows the correct status even if the document
doesn't.  Yes, that is confusing. :-(

Thanks!

Alvaro.

> 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.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 25 Aug 2021 16:08:28 +0000

Hi Alvaro,

Thanks for the clarification.  I will clear my Discuss.

When I pulled up these docs, and both in tools and datatracker the document boilerplate has them as experimental.  Do you know if this is a generic issue, or specific to these docs for some reason?  I would say that having different status in different places is highly confusing.

Thanks,
Rob

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: 25 August 2021 16:44
To: Robert Wilton via Datatracker <[email-masked]>; The IESG <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; Xuesong Geng <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Robert Wilton's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)

Rob:

Hi!

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 25 Aug 2021 11:19:57 -0700

On August 25, 2021 at 12:08:31 PM, Rob Wilton wrote:

Rob:

> When I pulled up these docs, and both in tools and datatracker the document
> boilerplate has them as experimental. Do you know if this is a generic issue,
> or specific to these docs for some reason? I would say that having different
> status in different places is highly confusing.

Yes, it is confusing.  The problem is that the boilerplate is part of
the RFC, so it's immutable.

Alvaro.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Aug 2021 15:15:19 -0400

Can someone ELI5 why we don't just republish documents when the status
changes?

It seems like it would be trivial to take RFC8296, and run `sed /Category:
Experimental/Category: Proposed Standard/`, add "Obsoletes: RFC8296", and
slap a new number on it...

It is already clear that we will soon need 5 digit RFC numbers, so it's not
like these are a limited resource...

W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Aug 2021 00:20:51 -0700

Since I almost DISCUSSed the same thing:

On Wed, Aug 25, 2021 at 12:16 PM Warren Kumari <[email-masked]> wrote:

> It is already clear that we will soon need 5 digit RFC numbers, so it's
> not like these are a limited resource...
>

I'd settle for a notation at the top in some attention-getting color, akin
to "Errata Exist", something like "Status Change Exists" and a link to the
status change action, or the new status, or something.

-MSK