Hi Alfred, See inline.
|-----Original Message----- |From: [email protected] [mailto:[email protected]] |Sent: Tuesday, March 23, 2010 2:48 PM |To: Acee Lindem |Cc: [email protected]; [email protected]; |[email protected]; [email protected] |Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry | |Acee Lindem wrote: |> My take is that RFC 5329 should have stated that it updates RFC 3630. |> RFC 5728 is not dependent on RFC 5329. | |(I guess you mean RFC 5786, not RFC-to-be 5728.) | |The definition of the "Updates" metadata relation in the RFC |Editor's "Instructions to RFC Authors" (instructions2authors.txt) is: | || Updates || || Specifies an earlier document whose contents are modified or || augmented by the new document. The new document cannot be || used alone, it can only be used in conjunction with the || earlier document. | |RFC 5786 applies to the OSPFv3 TE Extensions as well and as |such, IMHO readers can expect the RFC metadata to point from |RFC 5329 to RFC 5786 as well. I do not understand how you can |implement RFC 5786 for OSPFv3 without reading/implementing RFC |5329 as well. |So doesn't RFC 5786 "augment" RFC 5329 as well? |Where's the difference to the dependency on RFC 3630 for OSFPv2 ? RFC 5786 actually "updates" RFC 3630 with a new top level TE TLV. RFC 5329 is listed a reference for those reading/implementing RFC 5786. I don't think it is mandatory that it update RFC 5329 and certainly am not going to spend any more time on this now that the RFC is published (at least not mine :^). | |Sometimes there are 'political' issues or hidden reasons (that |better should have been explained in the memo) to not provide |the expected metadata service to the readers. Since that was |unclear in this case, I have asked by email. No politics here - just the editorial discretion of the authors. | | |> As for the errata, I don't disagree that the suggested |changes improve |> the text. However, given I don't see them as warranting an errata. |> Afterall, we in the IETF are an international organization |and I don't |> see the benefit of wordsmithing the English here. Comments such as |> these should be made before the RFC is published. |> |> Thanks, |> Acee | |Acee, |which percentage of RFCs do _you_ read before publication as well? 100% of those for which I intend to provide editorial comments. Please take a look at http://www.ietf.org/id/draft-ietf-ospf-af-alt-10.txt Since it is on the RFC Editor queue. | |I read, comment, and cross-annotate them on paper after |publication (and file Errata if appropriate), and I read and |comment many (sometimes long) before publication. |"RFC" still expands to "Request for Comment", and the RFC |Errata process serves to channelize many of these comments for |the benefit of other readers and users of the material for |derived work. | |The definition of Editorial Errata at | <http://www.RFC-Editor.ORG/status_type_desc.html> |(or see <http://www.RFC-Editor.ORG/how_to_report.html> as well) |is: | "a spelling, grammar, punctuation, or syntax error that | does not affect the technical meaning" | |Given the recent discussions on IANA terms "assigned", |"allocated", "reserved", and "available for assignment" in |various instances, the use of "reserved" in place of |"assigned", which is the core issue addressed by Errata ID |2085, arguably would even have deserved a Technical Errata |Note. This does not seem to be a question of "wordsmithing" |or style; it's precision in terminology. |The other details addressed in the Errata Note "en passant" |are related to "grammar" / "syntax" of the language and hence |the proper subject of an Editorial Erratum, per the above |definition. Since all details are contained in close nearby |text, I have saved errata IDs and mails and efforts in |consolidating all into a single Errata Note. As I stated before, I don't disagree that your suggestions improve the text or that "assigned" is more appropriate than "reserved". It is unfortunate that there is not a classification of errata to categorize those which are substantive and those that are purely editorial. Again, I'm not going to spend any more time debating this. Thanks, Acee | |Kind regards, | Alfred. | |-- | |+------------------------+--------------------------------------------+ || TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | || Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | || D-71254 Ditzingen | E-Mail: [email protected] | |+------------------------+--------------------------------------------+ | | |> |-----Original Message----- |> |From: [email protected] On Behalf Of RFC Editor |> |To: Alfred HÎnes |> |Cc: [email protected]; [email protected]; RFC Editor; |> |[email protected] |> |Sent: Monday, March 22, 2010 2:36 PM |> |Subject: Re: [OSPF] RFC 5786 metadata, references, and IANA registry |> | |> |Hi Alfred, |> | |> |We don't determine which references should be included as normative |> |or informative. We might make suggestions about this if someting |> |seems odd to us, but whether references appear as normative or |> |inforamtive is usually decided at the working group level (I |> |believe). You may want to discuss this with the authors |and working |> |group chairs, as we are unable to provide you with any additional |> |information about why RFC 3630 was a normative reference while RFC |> |5329 was listed as an informative reference. |> | |> |Thanks, |> |Sandy |> | |> | |> |On Sun, Mar 21, 2010 at 07:15:51PM +0100, Alfred HÎnes wrote: |> |> Hello, |> |> as an additional remark to the Errata Note I have filed for RFC |> |> 5786 |> |> (eid=2085): |> |> |> |> I do not understand why: |> |> |> |> - Ref. [RFC5329] is Informative and [RFC3630] is Normative |> |> (both RFCs are mentioned in a comparable manner, e.g. in |> |> Section 1.1 (3rd para) and Section 5), and |> |> - the RFC only "Updates: 3630" (and not also 5329). |> |> |> |> Further, -- that's perhaps more a deficiency of the IANA |> |> Considerations of RFC 5329 but could be corrected by |directives to |> |> IANA -- I would appreciate if the OSPF TE parameters |registry would |> |> more clearly indicate its applicability to OSPFv3, e.g. by giving |> |> an additional ref. to RFC 5329 at the top level. |> |> |> |> |> |> Kind regards, |> |> Alfred HÎnes. | | _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
