> It is the requirement that Internet Drafts always contain IANA
> considerations sections that has to go.
Ned, you have not produced any argument for this position, and since
the absence of such a section does not imply the absence of IANA
considerations, your logic continues to esc
; Simple: The requirement that an IANA considerations section be
included in RFC
> not containing any IANA actions needs to be dropped. I have been
extremely
> clear ahout this.
It's good, because this is already the case. Even if you're required
to add a "null"
from my very humble perspective, it is actually useful to test a -00
draft. The more revisions a draft goes through, the more reticent and
author becomes to change it. Getting the test done early makes that job
easier.
On Jun 10, 2005, at 7:25 AM, Bill Fenner wrote:
On 6/9/05, Bruce Lilly <
The requirement that an IANA considerations section be included in
RFC
> not containing any IANA actions needs to be dropped. I have been extremely
> clear ahout this.
It's good, because this is already the case. Even if you're required
to add a "null" IANA considerations se
t their reputations (at least).
And that is what has been missing from the picture. It is
trivial to check whether an IANA Considerations section (or a
Security Considerations section, or an Internationalization
Considerations one, or any of the other things that have been
asked for) is presen
On Fri, 10 Jun 2005, Ned Freed wrote:
What exactly is it that you
think should be done (in addition to careful reviews) that would help
reduce the odds that the careful review find issues with the IANA
instructions (or lack thereof)?
Simple: The requirement that an IANA considerations section
g I found that worked.
> I agree careful reviews are necessary. What I find surprising is your
> logic, which seems to say:
> IANA considerations sections in IDs are not sufficient, therefore
> they are useless (or worse).
I have never said or even implied that.
> Is that really
ee careful reviews are necessary. What I find surprising is your
logic, which seems to say:
IANA considerations sections in IDs are not sufficient, therefore
they are useless (or worse).
Is that really what you are advocating? What exactly is it that you
think should be done (in addition
On 6/9/05, Bruce Lilly <[EMAIL PROTECTED]> wrote:
> Conversely, if the IESG does regard the matter as important, it could:
> 1. direct the IETF Secretariat to enforce the rule
Bruce,
ID-Checklist is only for I-Ds that are submitted to the IESG for
publication. It's not the cost of checking tha
It's a matter of taste whether http://www.ietf.org/ID-Checklist.html
is obscure or not, but it is quite explicit and cites RFC 2434
which is BCP 26.
BCP 26 says, among other things:
All future RFCs that either explicitly or implicitly rely on the IANA
to register or otherwise manage assign
http://www.iana.org site is not the best
documentation site I saw. It said two things:
1. a IANA related obligations registry. Where obligations to IANA,
authors, users, etc. would be registered and easily displayed.
2. in the IANA considerations to explicit the way IANA overload will be
fought
Ned Freed wrote:
...
And in fact there has already been at least one example of this happening. The
document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's
queue. It's IANA considerations section says "no IANA actions". Alas, the
document defines any
a new document saying "think about X,
Y, and Z".
>Even worse, the presence of a section that says "these are all the IANA
>considerations" or "there are no IANA considerations here" is likely to cause
>reviewers to assume that someone has already checked for
possible.
Even worse, the presence of a section that says "these are all the IANA
considerations" or "there are no IANA considerations here" is likely to cause
reviewers to assume that someone has already checked for IANA actions. This
will lead to more omissions, not less.
And in f
> > the ID-Checklist clearly states:
[IANA Considerations section is REQUIRED]
> That's most unfortunate. What do we need to do to get this silly and
> counterproductive requirement removed?
(pessimist hat on)
Nothing. Just ignore it; everybody does. The rule, such as it is
obligations registry. Where obligations to IANA, authors,
users, etc. would be registered and easily displayed.
2. in the IANA considerations to explicit the way IANA overload will be
fought. This last point (with XML registries) is a point under
consideration and of concern for those having to
In message <[EMAIL PROTECTED]>, John C Klensin writes:
>Brian,
>
>We agree about the desirability of making sure than some things
>are explicitly documented and explicitly part of what gets
>reviewed. But I continue to believe, as I have believed for
>years, that adding more and more mandatory mat
ely can't argue against it being used for its intended
> purpose.
>
>>> I believe the requirements exist to ensure that draft
>>> authors give due consideration to IANA Considerations and
>>> that IANA can readily determine if some action is or is not
>
Please see RFC 2434 = BCP 26
Brian
JFC (Jefsey) Morfin wrote:
Dear Bruce,
you know what? I think it would be great to write a IANA obligations
RFC. It would say that the IANA MUST maintain a list of all the
obligations RFC authors should respect when writting the IANA
considerations
Dear Bruce,
you know what? I think it would be great to write a IANA obligations RFC.
It would say that the IANA MUST maintain a list of all the obligations RFC
authors should respect when writting the IANA considerations, and to
document whatever additional information IANA may need (for
rgue about what should or shouldn't be in the checklist, but
you surely can't argue against it being used for its intended
purpose.
I believe the requirements exist to ensure that draft authors give due
consideration to IANA Considerations and that IANA can readily determine
if some actio
bmission process
considerably; it would also interfere with the IETF process.
True... but something like "has an IANA Considerations section" is easy
to check, and easy for the author to implement, even if it's just
starting with an I-D template that says "to be determined&
> > Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> > Date: 2005-06-08 10:50
> > From: Ned Freed <[EMAIL PROTECTED]>
> > > .. RFC2119, when used, must be a normative reference. Likewise,
> > > you'll need to ad
On Wednesday, June 08, 2005 01:59:19 PM -0400 Bruce Lilly
<[EMAIL PROTECTED]> wrote:
Evidently (and unfortunately) the
IETF Secretariat apparently doesn't enforce that part of the ID-Checklist
rules.
Aside from making sure the proper boilerplate is included in documents it
publishes (which
> Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> Date: 2005-06-08 10:50
> From: Ned Freed <[EMAIL PROTECTED]>
> > .. RFC2119, when used, must be a normative reference. Likewise,
> > you'll need to add a "null" IANA
The idea what we can ever proceed without a Last Call strikes me as a
fundamental anathema for the IETF.
agree entirely
Keith
Harald,
Tuesday, February 18, 2003, 7:30:51 AM, you wrote:
HTA> Given that a large portion of the IETF does not in fact subscribe to the
HTA> ietf-announce list, and that in some cases the IETF consensus is pretty
HTA> obvious (for instance when the decision is just paperwork following up on
HTA>
Date:Tue, 18 Feb 2003 14:30:51 +0100
From:Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Given that a large portion of the IETF does not in fact subscribe to the
| ietf-announce list,
That's irrelevant, anyone who cares can subscrib
--On tirsdag, februar 11, 2003 19:45:04 +0700 Robert Elz
<[EMAIL PROTECTED]> wrote:
IETF Consensus is the IETF's way of agreeing to some action. The IETF
makes that decision, the IESG (currently anyway) is tasked with
determining whether or not the IETF has actually made a decision. IETF
Co
Date:Thu, 30 Jan 2003 15:45:13 -0500
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
I had been avoiding reading this set of messages, because I couldn't
really see discussions of what was required to get IANA to assign a
number in some (irreleva
> Absolutely. Otherwise, this discussion wouldn't be worth the
> trouble. But, if you are going to define "IETF Consensus" as
> "Publication as an RFC" then
Since I don't seem to be able to make this clear enough, once again, I
do not and have never intended "IETF Consensus", in the literal se
Hi Thomas,
On Thu, 30 Jan 2003, Thomas Narten wrote:
> In practice, "IETF Consensus" (as defined in 2434) means that
> procedurally the IESG has to sign off on a document before IANA
> assigns code points for it.
RFC 2434 has (among others) these two definitions:
IESG Approval - New assig
--On Thursday, 30 January, 2003 15:53 -0500 Thomas Narten
<[EMAIL PROTECTED]> wrote:
If 2434 doesn't modify them, then we are, for better
or worse, back into the situation we were in with 2119 --
documents could either use it or could not refer to it but,
instead, make up their own defintions.
ntext of most of the
> discussion on this thread, folks seem to be applying their
> own definition of what "IETF Consensus" means when in fact
> the 2434 definition is what should be used, as is cited in
> the relevant IANA considerations section.
>
> I don't know w
John,
> > and they meant the current 2434 definition
> Except, perhaps, for the documents that were written before 2434
> with a rather specific definition --discussed with the IESG at
> the time-- in mind. If 2434 modifies them, then 2434 can be
> updated and the update can update all of the
the context of most of the
> > discussion on this thread, folks seem to be applying their own
> > definition of what "IETF Consensus" means when in fact the
> > 2434 definition is what should be used, as is cited in the
> > relevant IANA considerations section.
>
art is that there are many
many RFCs that use the "IETF Consensus" terminology in their
IANA considerations
and they meant the current 2434 definition
Except, perhaps, for the documents that were written before 2434
with a rather specific definition --discussed with the IESG at
th
> > and they meant the current 2434 definition
>
> or they misread 2434 (or did not read 2434) and thought they knew
> what "IETF consensus" means
which means that it's not simply a matter of revising text, but
of asking again what was intended, and perhaps reopening the debate.
so perhaps we s
> and they meant the current 2434 definition
or they misread 2434 (or did not read 2434) and thought they knew
what "IETF consensus" means
Scott
> > I don't know what can be done a this point to change the terminology
> > in 2434. It's been in use for some 4 years now...
>
> It would seem quite simple for you to take the text of RFC-2434,
> edit the text appropriately to pick a more clear and accurate
> term, then run it past the community
t;IETF Consensus" terminology in their IANA considerations
and they meant the current 2434 definition
uot; terminology in their IANA considerations
(e.g., the documents that sparked the original thread). I suspect that
the confusion will remain as long as folks read those RFCs and just
assume they know what the term is supposed to mean. But I agree it
makes sense to update the document for future usage.
Thomas
On Wednesday, Jan 29, 2003, at 20:20 America/Montreal, Thomas Narten
wrote:
I don't know what can be done a this point to change the terminology
in 2434. It's been in use for some 4 years now...
It would seem quite simple for you to take the text of RFC-2434,
edit the text appropriately to pick
--On Wednesday, 29 January, 2003 20:20 -0500 Thomas Narten
<[EMAIL PROTECTED]> wrote:
...
As one of the authors of RFC 2434 "Guidelines for Writing an
IANA Considerations Section in RFCs", I have long regretted
defining the term "IETF Consensus" as it is i
the ietf-problems mailing list, IMHO.
As one of the authors of RFC 2434 "Guidelines for Writing an IANA
Considerations Section in RFCs", I have long regretted defining the term
"IETF Consensus" as it is in that document. 2434 says:
> IETF Consensus - New values are
At 06:37 AM 9/28/2001, Thomas Narten wrote:
>usages). This again argues for having the IANA Considerations section
>be complete during IETF Last Call, so the community as as whole can
>also review it.
(excellent summary, Thomas. many thanks it. in fact, it probably should
be includ
ensure that
> the TBD value is replaced with an appropriate value.
In the case of draft-aboba-dhc-domsearch-06.txt, it contains an IANA
considerations section that calls attention to the need for IANA to
assign an option code. During Last Calls, IANA scans documents,
looking for an IANA Considerat
101 - 147 of 147 matches
Mail list logo
