Subject: [Iasa20] Errata

From: Alissa Cooper <[email-masked]>
Date: Wed, 31 Oct 2018 10:01:52 -0400

I’ve heard from the RFC Editor that processing document updates of the sort this WG is chartered to work on as errata is not in line with how they typically interpret <https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/>. That is, they don’t consider things like changing the title of “IETF Executive Director” to be bug fixes. So for the docs where the plan is to file errata or where errata have already been filed, the WG may want to revisit those plans.

Thanks,
Alissa

---

From: Bob Hinden <[email-masked]>
Date: Wed, 31 Oct 2018 08:07:14 -0700

Alissa,

> On Oct 31, 2018, at 7:01 AM, Alissa Cooper <[email-masked]> wrote:
> 

I assume that would also apply to s/IAOC/LLC/ and similar items in an errata.

Thanks,
Bob

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2018 15:25:48 -0000

In article <[email-masked]>,
Bob Hinden  <[email-masked]> wrote:
>> I’ve heard from the RFC Editor that processing document updates of the sort this WG is chartered to
>work on as errata is not in line with how they typically interpret
><https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/>. That is, they don’t consider
>things like changing the title of “IETF Executive Director” to be bug fixes. So for the docs where
>the plan is to file errata or where errata have already been filed, the WG may want to revisit those
>plans.
>

If we can't do it as errata, I hope we can agree to put all of the
non-errata into one (1) I-D that makes all the updates to all of the documents
that need tiny changes.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Oct 2018 09:26:38 -0600

On 10/31/18 9:25 AM, John Levine wrote:
>>> Iâ€™ve heard from the RFC Editor that processing document updates of the sort this WG is chartered to
>> <https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/>. That is, they donâ€™t consider
>> things like changing the title of â€œIETF Executive Directorâ€ to be bug fixes. So for the docs where

+1

Peter

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Oct 2018 09:34:46 -0700

On Wed, Oct 31, 2018 at 7:02 AM Alissa Cooper <[email-masked]> wrote:

> I’ve heard from the RFC Editor that processing document updates of the
> sort this WG is chartered to work on as errata is not in line with how they
> typically interpret <
> https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/>. That
> is, they don’t consider things like changing the title of “IETF Executive
> Director” to be bug fixes. So for the docs where the plan is to file errata
> or where errata have already been filed, the WG may want to revisit those
> plans.
>
>
While I don't wish to push back too hard on this, I think this reading is a
little narrow.  In all of these cases we have identified a bug in the
spec:  it was tailored to an implementation rather than to the function,
giving a specific name rather than describing the job being done.  That was
a useful shorthand when we had a single implementation, but this situation
has shown us it was a bug and should be fixed.

That means that we can't just s/IAOC/LLC/, because that just shifts the bug
to the new implementation.  We have to update the language to actually
allow for the kind of evolution of implementation that we now have evidence
occurs.  To my way of thinking, that means an erratum is a correct first
step--it notes the error, notes the community acceptance that it is an
error, and marks it "hold for update".

Of course, we have to then actually run the update process then.  But
because of the other things that have changed, that's a larger process and
likely one that has to go elsewhere than this group.

Just my two cents as an individual,

Ted

> Thanks,
> Alissa
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 31 Oct 2018 12:51:22 -0700

Ted,

> On Oct 31, 2018, at 9:34 AM, Ted Hardie <[email-masked]> wrote:
> 
> While I don't wish to push back too hard on this, I think this reading is a little narrow.  In all of these cases we have identified a bug in the spec:  it was tailored to an implementation rather than to the function, giving a specific name rather than describing the job being done.  That was a useful shorthand when we had a single implementation, but this situation has shown us it was a bug and should be fixed.

For some documents, in hindsight, it should have only talked about the IASA, not the IAOC.

However, for other documents, for example one that describes how people are appointed to the IAOC, the this is not an error.  These documents do need to be updated.

In the first case (simple change s/IAOC/LLC/), I don’t think this is an errata.  The original RFC was correct when written an approved, there is no bug.   What changed would elsewhere.   The thing that changed, has the responsibility to be specifying other things that need to change.   In this case, this falls to the IASA 2.0 w.g. to do these updates (either BIS or Updating documents).

Bob

> 
> That means that we can't just s/IAOC/LLC/, because that just shifts the bug to the new implementation.  We have to update the language to actually allow for the kind of evolution of implementation that we now have evidence occurs.  To my way of thinking, that means an erratum is a correct first step--it notes the error, notes the community acceptance that it is an error, and marks it "hold for update".
> 
> Of course, we have to then actually run the update process then.  But because of the other things that have changed, that's a larger process and likely one that has to go elsewhere than this group.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 31 Oct 2018 15:27:51 -0700

On Wed, Oct 31, 2018 at 12:51 PM Bob Hinden <[email-masked]> wrote:

> Ted,
>
> > While I don't wish to push back too hard on this, I think this reading
> is a little narrow.  In all of these cases we have identified a bug in the
Sorry, I meant "all the cases where the plan was to file an erratum", not
every document in front of the group for revision.  My apologies for the
lack of clarity.

Ted

> However, for other documents, for example one that describes how people
> are appointed to the IAOC, the this is not an error.  These documents do
> need to be updated.
>
> In the first case (simple change s/IAOC/LLC/), I don’t think this is an
> errata.  The original RFC was correct when written an approved, there is no
> bug.   What changed would elsewhere.   The thing that changed, has the
> responsibility to be specifying other things that need to change.   In this
> case, this falls to the IASA 2.0 w.g. to do these updates (either BIS or
> Updating documents).
>
> Bob
>
>
> >
> > That means that we can't just s/IAOC/LLC/, because that just shifts the
> bug to the new implementation.  We have to update the language to actually