Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362)

From: t.petch <[email-masked]>
Date: Tue, 2 Oct 2012 10:02:36 +0100

----- Original Message -----
From: "Benoit Claise" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>; "Jernej Tuljak"
<[email-masked]>; "Ladislav Lhotka" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, September 27, 2012 11:20 AM
> Dear all,
> >> I don't have any experience with the errata procedure but I think
the first decision should be whether this qualifies as an erratum,
because indeed it changes the DSDL mapping "protocol", as Martin pointed
out.
> >>
> >> Who is entitled to make this decision?
> >>
> > I have moved this question over to Benoit since I think we need
advice
> > from the ADs here.
>
> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as
> background information...
> - As far as I can tell, we agree that this is a bug in the
> specification. So an errata should be filed.
> - As far as I can tell, we fall into: "Only errors that could cause
> implementation or deployment problems or significant confusion should
be
> Approved."
> - As far as I can tell, we don't fall into: "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"
>
> I'm in favor to keep the process simple, and to verify the errata,
> instead of producing a new RFC.

It is a substantive change to the protocol and would seem to me to be a
change to the consensus when the document was approved, albeit a
necessary change in the light of further understanding; but if an AD
says not, I won't argue.

My greater concern is that I do not believe that  consumers of RFC know
to look for Errata and so would miss it, producing something
incompatible.  I know that I have been caught out, in other contexts, by
failing to look for Errata even though I have been around long enough to
know the procedure well; ie, I would go for a revised RFC, greater cost
to us, but more reliable for everyone else.

Tom Petch

> However, before doing so, we want to be a safe side, basically making
> sure that there are no other implementations for which this bug fix
> (read non-backward compatibility change) would cause a problem.
>
> So let me propose the following:
> - We keep the errata 3362 open for now
> - Since errata 3362 needs to updated (and since we can't update this
> errata without approving/rejecting AFAIK), we create a new errata with
> all the changes, as agreed on the mailing list. Do we have an
agreement
> on what Lada proposed?
> - I send a kind of LC email to the mailing list, with this new errata
> - If no issue during this LC, I reject errata 3362 (pointing to the
new
> errata), and I verify the new one.
>
> Regards, Benoit.
> > /js
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 2 Oct 2012 13:20:21 +0200

> to us, but more reliable for everyone else.

Yes, that's a relevant concern. It would actually be helpful in general if the parts of RFCs that are affected by errata were clearly marked in the RFC text, at least in the HTML rendering.

Lada

--
Ladislav Lhotka
PGP Key ID: E74E8C0C

---

From: t.petch <[email-masked]>
Date: Tue, 2 Oct 2012 14:51:33 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Benoit Claise" <[email-masked]>; "Ladislav Lhotka"
<[email-masked]>; "Jernej Tuljak" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 02, 2012 12:20 PM

> to us, but more reliable for everyone else.

Yes, that's a relevant concern. It would actually be helpful in general
if the parts of RFCs that are affected by errata were clearly marked in
the RFC text, at least in the HTML rendering.

<tp>
Yes, I suggested that on the main IETF list two months ago, but did not
get any traction.  The HTML does say that they are errata but my doubt
is how many people outside academia and IETF standards development know
what the word means - I suggested using 'corrections' instead.

Tom Petch

Lada

--
Ladislav Lhotka
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Oct 2012 16:31:18 +0200

> what the word means - I suggested using 'corrections' instead.

Well, this WG is not going to re-engineer how errata work in the IETF
or how the IETF tools display them. We have to work with what we have.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 05 Oct 2012 16:30:52 +0200

> to us, but more reliable for everyone else.
I understand your concern.
So I discussed this issue with Ron, and the errata is also his preferred 
option.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Oct 2012 16:38:31 +0200

Dear all,

One simplification in the process of this errata.
See in line.
>>> because indeed it changes the DSDL mapping "protocol", as Martin 
>>> pointed out.
>>>
>> I have moved this question over to Benoit since I think we need advice
>> from the ADs here.
>
> be Approved."
> Hold for Document Update or Rejected"
>
> agreement on what Lada proposed?
After speaking to the RFC-editor, I was able to update the errata 3362 
(thanks Lada for helping here).
> new errata), and I verify the new one.
Please review the updated errata 3362 at 
http://www.rfc-editor.org/errata_search.php?eid=3362, and provide 
feedback by October 19th.
At that date, the errata will be "verified"

Regards, Benoit.
>
> Regards, Benoit.
>> /js
>>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 10 Oct 2012 08:36:16 +0200

Dne 9.10.2012 16:38, piše Benoit Claise:
>> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html 
>> as background information...
>> errata without approving/rejecting AFAIK), we create a new errata 
>> with all the changes, as agreed on the mailing list. Do we have an 

There's a typo in the corrected entry of Table of Contents.

       12.16. The<nma:unique Annotation>  ..............................74

Should be

       12.16. The<nma:unique>  Annotation ..............................74

("greater than" moved)

Jernej

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Oct 2012 09:36:05 +0200

Jernej,

Well spot. Corrected

Regards, Benoit.
>>> implementation or deployment problems or significant confusion 
>>> should be Approved."
>>> However, before doing so, we want to be a safe side, basically 
>>> making sure that there are no other implementations for which this 
>>> bug fix (read non-backward compatibility change) would cause a problem.
>>>
>> After speaking to the RFC-editor, I was able to update the errata 
>> 3362 (thanks Lada for helping here).

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Oct 2012 10:34:26 +0200

> Well spot. Corrected

Oops, sorry, mea culpa. Unfortunately, there is now a new typo that wasn't in my text: There should be a space between "The" and the left chevron. That is, the correct ToC entry is:

      12.16. The <nma:unique> Annotation ..............................74

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Oct 2012 10:49:06 +0200

Done.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Oct 2012 18:41:47 -0400

Dear all,

It's now past October 19th, and this errata is now verified.
Thanks to all.

Regards, Benoit