Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

From: S Moonesamy <[email-masked]>
Date: Sat, 29 Feb 2020 05:48:51 -0800

Dear Mr Raszuk,
At 02:36 PM 28-02-2020, Robert Raszuk wrote:
>His information about 6man AD not accepting the Errata: 5933 is 
>correct. Errata must be first accepted by an AD then processed 
>further. Since it was posted on 11th Dec 2019 it was still not 
>accepted at first stage. You are mixing AD acceptance / validation 
>with IESG decision. Those are completely different errata processing phases.

Once an erratum is reported [1], a report is automatically sent to 
the Working Group Chair(s), the author(s) and the Area 
Directors.  The relevant Area Director ensures that there is adequate 
review and the erratum is classified.  There isn't any IESG decision 
for the errata processing phases.

Regards,
S. Moonesamy

1. https://www.rfc-editor.org/errata/eid5646

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Feb 2020 16:17:53 +0100

>   There isn't any IESG decision for the errata processing phases.

Interesting.

When I click on any RFC number in the below errata link there is always
"IESG writeups" section  containing the formal IESG approval. In addition
to that in the recent erratas there is also "IESG evaluation report":

https://datatracker.ietf.org/doc/search/?name=Errata&activedrafts=on&rfcs=on

Maybe just errata containing spelling errors could be approved by an AD
alone, but to fundamentally change the meaning of the specification IMHO it
would be pretty bad for IETF process to allow such shortcut.

Many thx,
R.

---

From: "Pete Resnick" <[email-masked]>
Date: Sat, 29 Feb 2020 12:36:50 -0600

On 29 Feb 2020, at 9:17, Robert Raszuk wrote:

> Maybe just errata containing spelling errors could be approved by an 
> AD alone, but to fundamentally change the meaning of the 
> specification IMHO it would be pretty bad for IETF process to allow 
> such shortcut. 

You might want to have a peek at 
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

Errors that the AD determines "could cause implementation or deployment 
problems or significant confusion" are marked as Verified, but "changes 
that modify the working of a protocol to something that might be 
different from the intended consensus when the document was approved 
should be either Hold for Document Update or Rejected." It is up to the 
AD to determine whether the text aligns with the intention of the WG 
that produced the document. There is no further processing of errata 
beyond this.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: John C Klensin <[email-masked]>
Date: Sat, 29 Feb 2020 13:50:10 -0500

--On Saturday, February 29, 2020 05:48 -0800 S Moonesamy
<[email-masked]> wrote:

>> His information about 6man AD not accepting the Errata: 5933
>> is  correct. Errata must be first accepted by an AD then
>> processed  further. Since it was posted on 11th Dec 2019 it
>> was still not  accepted at first stage. You are mixing AD
>> acceptance / validation  with IESG decision. Those are
>> completely different errata processing phases.
> 
> Once an erratum is reported [1], a report is automatically
> sent to the Working Group Chair(s), the author(s) and the Area
> Directors.  The relevant Area Director ensures that there is
> adequate review and the erratum is classified.  There isn't
> any IESG decision for the errata processing phases.
> 
> Regards,
> S. Moonesamy
> 

More important, even having the erratum marked "verified" does
not change the substantive content of the a standard.  That
would require a new document, IETF Last Call, and IESG review
and signoff, presumably followed by RFC publication.