Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Erik Wilde
    hello tom. thanks a lot for your response! it was very useful to get a menu of options how to proceed. ... after thinking about these options for a while, i
    Message 1 of 2 , Feb 21, 2013
    • 0 Attachment
      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.

      thanks again and kind regards,

      dret.

      --
      erik wilde | mailto:dret@... - tel:+1-510-2061079 |
      | UC Berkeley - School of Information (ISchool) |
      | http://dret.net/netdret http://twitter.com/dret |
    • Erik Wilde
      hello tom. ... 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). ... the
      Message 2 of 2 , Feb 23, 2013
      • 0 Attachment
        hello tom.

        On 2013-02-21 17:40 , t.petch wrote:
        > 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.

        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).

        > 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.

        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?

        > 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.

        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.

        --
        erik wilde | mailto:dret@... - tel:+1-510-2061079 |
        | UC Berkeley - School of Information (ISchool) |
        | http://dret.net/netdret http://twitter.com/dret |
      Your message has been successfully submitted and would be delivered to recipients shortly.