I'm hesitant to relaunch this thread, but there are a number of points
that incite me to comment. Since there's been a fair amount of
repetition, may I ask people only to chime in with new thoughts?
Paul Hoffman wrote:
At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote:
RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does
discuss
them, and we will need to form consensus about whether the RFC Editor is
required to retain them, as we discuss RFC2434bis.
I don't see any discussion of the RFC Editor retaining null IANA
sections in RFC2434bis, which is good. It is a completely silly idea. An
RFC should contain useful, long-lasting information. The fact that a
particular document didn't require IANA action is not useful unless it
is surprising, and if it is surprising, the section should not be null.
I respectfully disagree. I think that someone implementing or deploying a
given specification may well wonder whether any IANA-assigned values
are relevant, and the absence of a null section in an RFC doesn't help
with that.
C. M. Heard wrote:
...
>>RFC2434bis does discuss them, and we will need to form consensus
>>about whether the RFC Editor is required to retain them, as we
>>discuss RFC2434bis. Which we need to do fairly soon.
>
>
> In what venue will this discussion take place?
I think it has to be this list, absent a relevant WG.
Joe Touch wrote:
...
[re a mandatory section in all drafts]
> The goal of putting it in the template is to encourage it be addressed,
> rather than forgotten altogether.
>
> However, I'm not at all in favor of requirements to IDs that are added
> ad-hoc; until this actually makes it into an RFC as a formal
> requirement, it won't be in the word template I manage.
I don't agree that all operational requirements need to be in process
RFCs as formal requirements. We need to give the IESG of the day some
freedom to adapt requirements to current conditions. I felt that the
requirement for IANA Considerations was a fine idea when it was
introduced, and certainly nothing that needed to be BCPized.
Ned Freed wrote:
...
> I also predicted that two things would happen: (1) A draft containing IANA
> considerations and an empty IANA considertions section would be approved and
> (2) That this section would take on the status of boilerplate in some draft
> templates. Both predictions have now come to pass.
If true, (1) means that a mistake was made by several successive layers
of review. (2) is beside the point. But...
Bruce Lilly wrote:
...
> You can make it three: mine says:
>
> This memo adds no new IANA considerations. The presence of this
> template text indicates that the author/editor has not actually
> reviewed IANA considerations.
Yes. Great idea. I updated my own XML template similarly.
Ned Freed wrote:
...
>>As I expect you know, the IANA checks all documents at Last Call time,
>>and the RFC Editor checks them before publication, for missing missed
>>IANA actions. However, redundancy does not seem to me to be a bad
>>idea.
>
>
> Of course I know this. But the tendency will be for the text to be believed
> and for the review to be less thorough.
Ditto if it becomes known that the *next* reviewer's check list includes
"check for overlooked IANA issues: Y/N"
> You're fighting human nature here, and you're gonna lose.
Always. The question is, what's the least bad compromise?
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf