On Tue, 1 Mar 2005 20:06:36 -0500, Bruce Lilly <blilly(_at_)erols(_dot_)com>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf