On Tue, 1 Mar 2005 20:06:36 -0500, Bruce Lilly <blilly@xxxxxxxxx> wrote: > It's unclear what the status of the document is intended to be. > I suspect it should probably be a BCP RFC. It's intended to replace http://www.ietf.org/ietf/1id-guidelines.txt . > Sect. 2 mentions "six months" for expiration, whereas the actual > rule appears to be 185 days Indeed, the secretariat's review also caught this error; thanks! > Sect. 2 mentions the "instructions > to RFC Authors" document; that should probably refer (instead or > additionally) to RFC 2223 or its successor (which the named > document is apparently intended to become). The draft says 'This format is specified fully in "instructions to RFC Authors" (see the RFC Editor's Web pages and [I-D.rfc-editor-rfc2223bis]).' - is the reference there not the one you're suggesting? > An error was made in > conversion of "10 inches" -- the text "less than about 250mm" > should be replaced with "no greater than 254.00mm". I did say "about". I didn't think that the 4mm was particularly important; maybe I'm just remembering how stupid I thought it read when a book I was reading said "...about 621.37119 miles" when it was converted from "about 1000 kilometers". > How about > "Internet Draft" rather than the HYPHENATED-SHOUTING > "INTERNET-DRAFT"? I don't mind removing the shouting, but the hyphenation is on purpose. Internet-Draft is meant to be a noun. > There is a discussion about restrictions on > content of the title -- RFC 2223 has text prohibiting a dot in > the title rfc2223bis doesn't have this restriction. However, it's worth including 2223bis's restriction on acronyms. > Section 3 gives some boilerplate text. I believe that some options > should be available to conform that boilerplate to specific > circumstances. I copied the boilerplate in sections 3 and 4 from the lawyer-approved text in RFC 3978. I'm not inclined to change it without advice from the lawyer (which I'm becoming convinced that I should seek - you're not the only one who wants to vary the text.) > 1. I'd like to see a statement that spaces around "(C)" are > optional and that PostScript and PDF versions may use the > copyright symbol in place of a parenthesized C. Do you mean that "Copyright(C)The Internet Society" is acceptable? > 2. Presumably the draft should not literally contain the > characters "(year)" Indeed, that's why the document says 'The "year" in the copyright statement should be replaced with the current year.'. Can you suggest a way to make this more clear? > should the year of publication be > parenthesized or not -- it's not clear. I think the intent is that it is, but again, I'm just interpreting RFC 3978, I didn't write the boilerplate. > In place of "I accept" in some boilerplate, "the author accepts" > or "the authors accept", as appropriate for the draft, should > probably be substituted for consistency with other boilerplate. I agree, but the ipr working group didn't make this change in the updated RFC. I'm still discussing this section with the RFC Editor so these "I accept" options may just go away anyway. > Section 4, paragraph labeled a raises some amusing issues Again, these are RFC 3978 issues. 1id-guidelines is reflecting the ipr policies, not making them. > Section 8 discusses file names and tombstone files. Can we please > add an IANA considerations section directing IANA to provide > working links to draft files (or tombstone files) when registering > some assignment based on a draft (prior to publication as an RFC)? > Currently, IANA has links from their web-based assignments tables > that point to a non-existent file, which leads to an HTTP 404 > error and a lot of work to figure out where exactly the particular > assigned "number" is defined, how it is intended to be used, etc. I don't think 1id-guidelines is the place for this kind of specific instruction to IANA - but it is a reasonable request. I will bring this up during our IETF/IANA coordination lunch on Monday. > What's the deal with "Ignore this partial reference"? It's a draft document and I wasn't focusing on the format of references. > Regarding updating of references, consistent use of BCP numbers > might save such effort in the future, since BCP numbers don't > change. Well, the whole reason for this update to 1id-guidelines is because the content of BCP 78 changed between when it was published as RFC 3667 and RFC 3978, so I'm not sure that stability of reference is good in this context. > There is either a stray "bullet" or some missing text on page 12. A stray bullet - sorry. Bill _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf