On Thu, 7 Jul 2005, Brian E Carpenter wrote:
> RFC 2434 doesn't discuss null IANA sections at all.
Right. The requirement for null IANA Considerations sections first
appeared in the May 2004 version of http://www.ietf.org/ID-Checklist.html,
without prior notice to the community.
> RFC2434bis doe
On Thu, 7 Jul 2005, Robert Elze wrote:
> The question is what the words in 2434 (to which 2780 refers)
> actually mean.
>
> To me, and apparently to some others, it is clear that 2434 is
> all about what amount of documentation is required to get IANA
> to register an option, and who gets to judge
Bruce Lilly wrote:
> BCP 18 (RFC 2277, Frank) recommends an internationalization
> considerations section
Oh, that beast, a MUST UTF-8, not less. Didn't make it into
RfC 3912, can I declare it "broken by design" and return to
RfC 954, please ? It took me hours to find RfC 1032 for RFCI.
While
Commenting only on the idnits specific issue here:
On 2005-07-07 22:08 Bruce Lilly said the following:
> On Thu July 7 2005 15:32, Ned Freed wrote:
[...]
>> > Which would presumably mean that the idnits
>> > check against that requirement would be dropped,
>>
>> On the contrary, it is important
On Thu July 7 2005 15:32, Ned Freed wrote:
> I have never suggested that the requirment for an IANA considerations section
> in documents that contain IANA considerations be dropped.
The specific requirement is for the presence of a section in an I-D
presented for publication as an RFC even in th
> On Thu July 7 2005 15:32, Ned Freed wrote:
> > I have never suggested that the requirment for an IANA considerations
> > section
> > in documents that contain IANA considerations be dropped.
> The specific requirement is for the presence of a section in an I-D
> presented for publication as an
On Wed, 29 Jun 2005, Sam Hartman wrote:
Please add an applicability statement discussing the performance
advantages of RC4 against the known security weaknesses. You may end
up reusing text from your security considerations text. Your
applicability statement needs to suggest to the reader that
> > > I suppose. That said, if IANA considerations was *not* built into the
> > > boilerplate, it would have a high likelihood of being omitted.
> >
> > Which would then be noted on checklist review, causing a fairly careful
> > check
> > to be made to see if there really aren't any considerations
Date:Tue, 05 Jul 2005 11:32:12 +0200
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| > Also remember that "no consensus" in an issue like this, really needs to
| > mean "no authority" - if you cannot get at least most of the community t
Date:Wed, 06 Jul 2005 17:28:28 +0200
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Well, that is not how I read the text in RFC 2460. It's pretty clear
| to me that there are only 32 option codes and that the other three bits
| don'
Brian E Carpenter wrote:
> Joe,
...
>> Re-reviewing 2026, in all places the IESG is noted as being largely
>> reactive to the community and guiding process.
>>
>> Only sec 6.1.2 notes the application of technical judgement, but only
>> regarding maturity of the document and the standards level be
Joe,
Joe Touch wrote:
Keith Moore wrote:
Keith,
The IESG can still exercise their best engineering judgment as
individuals, as the rest of us do.
The IESG role itself need not incorporate a privileged position from
which to wield that judgement. There's plenty left to do.
Joe,
The IESG
> Date: 2005-07-06 14:43
> From: Ned Freed <[EMAIL PROTECTED]>
> > > This opens the door to the author forgetting to check and the various
> > > reviewers assuming the prsence of the sections means a check was done.
I can't speak for others, but
1. if a draft has no IANA considerations section,
John C Klensin wrote:
--On Tuesday, 05 July, 2005 15:09 -0400 Theodore Ts'o
<[EMAIL PROTECTED]> wrote:
...
People seem to be forgetting that the 'E' in IETF standards
"Engineering", and that infinitely expandable registries in
order to obviate the need for responsible registration of code
poi
> Date: 2005-07-06 21:12
> From: Bill Strahm <[EMAIL PROTECTED]>
> I actually would prefer
> IANA Considerations
> This section left intentionally blank
That contains at least one certain inaccuracy: it's there, which
contradicts "left ... blank".
Unless you have a bulletproof way of ascer
John Klensin wrote:
> That said, I think we should be paying careful attention to
> Bruce's implied suggestion about how template
> boilerplate-generators should be constructed.
Some clarification:
1. In the specific case of the troff/nroff rfc macros and template,
Ned's characterization of th
(front posting for quicker reading)
I don't recall this being discussed in the IPv6 WG for a long
time, but if clarification of intent is needed, that's where
it should happen. RFC 2780 explicitly doesn't leave this in
IANA's hands. I agree that it affects the exact level of
prudence needed in pr
17 matches
Mail list logo
