Re: process and editing questions: RFC errata

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

> hello tom.
>
> thanks a lot for your response! it was very useful to get a menu of
> options how to proceed.
>
> On 2013-02-21 12:04 , t.petch wrote:
> >> - 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.
> >
> > 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.
>
> 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.

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

> thanks again and kind regards,
>
> dret.
>
> --
> erik wilde | mailto:[email protected]  -  tel:+1-510-2061079 |
>             | UC Berkeley  -  School of Information (ISchool) |
>             | http://dret.net/netdret http://twitter.com/dret |