> Date: 2005-02-19 19:02 > From: Bill Fenner <fenner@xxxxxxxxxxxxxxxx> > Â I'm working on an update for 1id-guidelines.txt so that it > will be ready to reflect the new IPR RFCs (RFC 3907 and 3908) > when they are published. ÂIt's gone through one round of > discussion in the IESG; now I'm looking for more complete > review. > > Â Pieces that could use extra review: > - Section 3 - in particular, are the 4 choices for copyright > Â statements clear enough, and what type of document needs what? > - Section 7 - the section on naming was redone, removing the > Â part about asking the secretariat for a filename, and adding > Â the rules for an I-D filename. > - Section 9 - this was significantly updated to reflect the > Â authors' responsibilities under 3667/3668 (it still said > Â "if you know about IPR, you should consider sending an IPR > Â disclosure") Below are my comments. Aside from some overall questions/comments, they're in the same order as the document. It's unclear what the status of the document is intended to be. I suspect it should probably be a BCP RFC. Sect. 2 mentions "six months" for expiration, whereas the actual rule appears to be 185 days (six months from August 31 would be February 31). And of course, given some of the provisions late in the document, a draft might nor expire then. As I understand the intended procedure, drafts are not deleted as such, they are replaced with a "tombstone" file. 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). An error was made in conversion of "10 inches" -- the text "less than about 250mm" should be replaced with "no greater than 254.00mm". How about "Internet Draft" rather than the HYPHENATED-SHOUTING "INTERNET-DRAFT"? There is a discussion about restrictions on content of the title -- RFC 2223 has text prohibiting a dot in the title (implying that some circumlocution would be required in a title addressing use of 802.11, etc.). Section 3 gives some boilerplate text. I believe that some options should be available to conform that boilerplate to specific circumstances. For example, in the case of a draft written by an individual author, saying "each author represents" is silly; "the author represents" is more sensible. Likewise if a draft has no female authors, it is silly, pointless, and offensive to have multiple repetitions of "he or she" where "he" is accurate and concise. Likewise for use of "she" if the draft has no male authors. Some of the boilerplate has SCREAMING ALL CAPS -- is that really necessary? It looks awful. Same concept as above applies to the screaming "HE/SHE" in that text. In the section 3 and in the later copyright boilerplate: 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. 2. Presumably the draft should not literally contain the characters "(year)"; should the year of publication be parenthesized or not -- it's not clear. 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. Section 4, paragraph labeled a raises some amusing issues: by referring to "languages other than English" there are a couple of possible implications: 1. all drafts MUST be in English; but that is nowhere stated, at least not in the document under review 2. drafts in a language other than English (except for boilerplate) containing such a statement cannot under any circumstances be translated into English! I think that needs some work. Perhaps "languages other than that of the original" solves the second problem w/o addressing the first. There are some references to change control mentioning "IETF"; since the IETF is a large body with ill-defined membership, perhaps change control issues should refer to the IESG (rather than the IETF at large), since it is the IESG that makes such decisions on behalf of the IETF. Section 6 has another "six months" reference which should probably be changed to "185 days". [I'm resisting the urge to comment on the ASCII-only provision; I'll leave that to somebody who is directly affected.] 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. What's the deal with "Ignore this partial reference"? Regarding updating of references, consistent use of BCP numbers might save such effort in the future, since BCP numbers don't change. There is either a stray "bullet" or some missing text on page 12. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf