Subject: [apps-discuss] process and editing questions: RFC errata

From: Erik Wilde <[email-masked]>
Date: Wed, 20 Feb 2013 15:09:32 +0100

hello.

i have two process and editing questions: 
http://tools.ietf.org/html/draft-wilde-xml-patch-03#section-6 
specifically links to errata i have filed regarding RFC 5261. it seems 
to me that these errata are legitimate, and that they simply weren't 
caught earlier. draft-wilde-xml-patch is almost complete, and i am 
wondering about the following things:

- how to best sync draft development, and the submitted errata. there 
seems to be no way to predict when and how errata are processed, in 
particular for RFC 5261 because the author seems to be unreachable.

- if the errata are accepted, how to reference them in the draft. it 
would be important that people following references to RFC 5261 from the 
draft do not just read the RFC, but also take the errata into account 
when implementing the spec.

thanks a lot and cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: t.petch <[email-masked]>
Date: Thu, 21 Feb 2013 11:04:28 +0000

----- Original Message -----
From: "Erik Wilde" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 20, 2013 2:09 PM

> particular for RFC 5261 because the author seems to be unreachable.

Indeed!  Bear in mind that the text of an RFC is available for further
processing within the IETF so while it is desirable that the original
author is involved in any updates thereto, that is not a requirement
thereof so if you cannot get any response from them, then submitting an
RFC5261-bis yourself is quite in order; but quite a lot of work.

A simpler approach is to include the relevant changes in
draft-wilde-xml-patch
and state that this is an update to the relevant sections of  RFC5261.
These should give more context than the errata do but need not be much
longer.

Or you can include sections that clarify the issues you have identified
in RFC5261 and state in your I-D that your I-D is based on this
interpretation ie you are not updating RFC5261 for the world at large
but are modifiying the content thereof for the purposes of your I-D.

Or you can make normative references to errata by URL once they are
approved.  I think this the most fraught approach and so the least
desirable.

Tom Petch

>             | http://dret.net/netdret http://twitter.com/dret |>

---

From: Erik Wilde <[email-masked]>
Date: Thu, 21 Feb 2013 15:59:00 +0100

hello tom.

thanks a lot for your response! it was very useful to get a menu of 
options how to proceed.

> approved.  I think this the most fraught approach and so the least

after thinking about these options for a while, i decided to go with the 
second option. http://tools.ietf.org/html/draft-wilde-xml-patch-04 is 
the updated draft and now officially updates RFC 5261. 
http://tools.ietf.org/html/draft-wilde-xml-patch-04#appendix-A lists all 
the changes to that RFC, and i have based this appendix mostly on the 
errata i had filed before. this approach seems to be much less work than 
republishing RFC 5261, and since the changes are rather small, the 
updates aren't that hard to read and apply, when you have to read them 
in addition to RFC 5261.

thanks again and kind regards,

dret.

---

From: t.petch <[email-masked]>
Date: Thu, 21 Feb 2013 16:40:18 +0000

----- Original Message -----
From: "Erik Wilde" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: "REST Discuss" <[email-masked]>
Sent: Thursday, February 21, 2013 2:59 PM

> updates aren't that hard to read and apply, when you have to read them

Yup, that is what I would have done.

In passing, some lines of formal definition exceed the permitted length
for an RFC line so a little reorganising will be needed, probably best
sooner rather than later as they will need validating before the I-D can
advance and reorganising can introduce syntax errors.

I may have missed the errata but I cannot recall a reference to them on
the apps-discuss list.  If they are modified and then approved, which
usually happens, then your I-D should follow suit so the sooner they are
processed the better.  Which might mean you requesting the AD to set the
wheels in motion, explaining why timeliness matters.

And, out of curiosity, do you expect people to use XPath 1.0 or 2.0?  I
ask because in Netconf, I was keen to specify 2.0 and not 1.0, the
handling of namespaces in 2.0 seemed superior, but was told we could not
because there were no implementations for people to use, that 2.0 was a
great idea that had not happened (mmm IPv6?).  The Normative reference
for Yang remains the 1999 version.

Tom Petch

---

From: Erik Wilde <[email-masked]>
Date: Sat, 23 Feb 2013 17:24:00 +0100

hello tom.

> advance and reorganising can introduce syntax errors.

thanks for noting, 
https://raw.github.com/dret/I-D/master/xml-patch/draft-wilde-xml-patch-05.txt 
should look better (not yet submitted).

> wheels in motion, explaining why timeliness matters.

the errata are still just in the "reported" state, 
http://www.rfc-editor.org/errata_search.php?rfc=5261 lists the 4 i have 
submitted. 3 of those now are actually part of the updates to RFC 5261 
in the draft, so i am wondering whether these errata are needed anymore? 
ideally, my draft would update RFC 5261, and then the errata would be 
redundant, right?

> for Yang remains the 1999 version.

2.0 is a vast improvement over 1.0, but it also is much more complex to 
implement. when 1.0 was released, XML was all the rage and there were a 
lot of people implementing specs. when 2.0 was released, the XML hyper 
curve already trended downward, plus it's just harder to implement. as a 
result it's true that it's surprisingly hard to find implementations of 
2.0. so while personally, i always use 2.0 because you can write better 
code, it's true that in specs, if you can get away with 1.0, it may be a 
good idea to stick to it.

cheers,

dret.

---

From: t.petch <[email-masked]>
Date: Tue, 26 Feb 2013 15:16:57 +0000

----- Original Message -----
From: "Erik Wilde" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "REST Discuss"
<[email-masked]>
Sent: Saturday, February 23, 2013 4:24 PM
> > advance and reorganising can introduce syntax errors.
https://raw.github.com/dret/I-D/master/xml-patch/draft-wilde-xml-patch-0
5.txt
> ideally, my draft would update RFC 5261, and then the errata would be

Yes, the errata would be redundant but my instinct would still be to go
forward with them.  They are simple, tightly defined, and so easier to
discuss than a whole I-D (even if yours is pleasantly short).  You would
get a clearer outcome from a discussion of an erratum than from an I-D.

Tom Petch

---

From: Erik Wilde <[email-masked]>
Date: Wed, 27 Feb 2013 15:17:24 +0100

hello tom.

> get a clearer outcome from a discussion of an erratum than from an I-D.

the issue with the errata is that there doesn't seem to be a process 
around them. i have submitted them, and now they are just sitting there 
in "reported" state. i'd rather encourage people to look at 
http://tools.ietf.org/html/draft-wilde-xml-patch#appendix-A and then we 
can have a discussion and maybe updated versions of the draft. this way 
there's a process for how to fix the most pressing issues with RFC 5261. 
but one way or the other, feedback so far has been minimal.

thanks and cheers,

dret.

---

From: t.petch <[email-masked]>
Date: Thu, 28 Feb 2013 15:33:40 +0000

Erik

Errata have a process and it works:-)

You posted errata against RFC5261, an RFC which was produced by simple.
Therefore notification of the errata went to the simple WG mailing list
which was shut down two days ago so your good work has found a very
effective black hole.

How about forwarding the messages that the RFC-Editor produced to the
apps-discuss list, for further discussion?

Normally, the AD picks up an erratum and runs with it but since the WG
has shut down, doubtless the ADs have as well, so you will need to find
a friendly AD elsewhere, or you might want to start with a friendly WG
chair.  As you are doubtless aware, there will soon be an IETF meeting
in Orlando, so chairs and ADs are rather busy right now.  If you plan to
be there, you could even ask the chairs for a slot on the agenda.

Tom Petch

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Feb 2013 10:51:00 -0500

> which was shut down two days ago so your good work has found a very
...
> a friendly AD elsewhere

This is nonsensical.

Errata are associated with the area that the document was produced
in.[1]  Even if the RFC came from an individual submission (no WG) or
from a WG that has closed (recently, or years ago), the ADs for the
area the report is assigned to will see it, and will eventually deal
with it.  The IESG has been putting more emphasis, over the past
couple of years, on handling errata and keeping the number left at
"Reported" to an absolute minimum.

The RAI ADs will deal with this one, I'm sure.

Barry

[1] Errata against very old RFCs can get into a sort of "black hole"
situation if they are not assigned to an area.  That's not an issue in
this case.