Date: Thu, 30 Jun 2005 17:21:10 -0400
From: Sam Hartman <hartmans@xxxxxxx>
Message-ID: <tsl8y0ra6d5.fsf_-_@xxxxxxxxxx>
| The RFc 2780 procedures are a sparse. We'd all be happier if the
| community had given us more advice on what criteria to use when
| evaluating hop-by-hop option requests and on what procedures were
| desirable.
2780 refers to 2434 for its definition of terms, Everything in 2434
is about the amount and type of documentation that is required.
What's more, that is as it should be, this is IANA considerations after
all - what we're doing (what IANA would be doing) is registering
parameters. The point of that registration is to avoid conflicts
(both one name or number used in two different ways, and two different
names/numbers that mean essentially the same thing). That's it.
The IESG has been acting as if it had been asked to approve the protocol
that was going to use the option. That would certainly have required
community review, and deciding not to allocate resources to such a review
may have been a justifiable decision.
But that is not what was requested, the protocol for which the parameter
was requested may be totally hopeless. That isn't going to stop it
being used, if its advocates feel strongly enough about it. Whether
they do in this case I cannot tell for sure. But there will certainly
come a case where they do.
Failing to register whatever parameter they need, because the protocol
proposed is disgusting, even if true, helps absolutely no-one. On
the other hand, if the documentation of what the parameter means, or
how to use it, is inadequate, then refusing registration makes sense.
It is also immediately clear to the applicant what they need to do to
correct the problem - simply fix the quality of their documentation.
| The IESG is under significant pressure to improve the management of
| the IETF. The community believes that the IESG has management
| responsibility for the timeliness ande appropriateness of the output
| of the IETF. If the IESG is going to have this responsibility it
| should be given the tools to act on this responsibility.
I agree with all of that, the IESG should be driving and helping the
working groups produce quality output. They should spend more of
their available resources doing just that, and much less quibbling with
the results of what the community has produced.
| One tool the IESG needs is to be able to set the bar fairly high for
| new work in the IETF that is unlikely to gain consensus.
That's fine. But notice that nothing here was asking the IETF to do
new work. That was something the IESG invented for itself. All that
was requested as assignment of an integer in a particular IANA registry.
I am confident that IANA has both the expertise, and probably the resources,
to preform that task, once told to go ahead and do it.
| This is
| especially true when there is existing conflicting work in the IETF.
| We don't value multiple protocols for doing the same thing for the
| sake of having multiple protocols. Clearly we sometimes do charter
| multiple efforts to do the same thing, but we tend to require a higher
| bar when that is the case. If the IESG does not have this ability,
| then it will be forced to charter work that is more likely to
| ultimately fail, consuming significant resources in the process.
Again, all that is fine, but irrelevant, as no-one was asking the IETF
to do any work, there were no IETF resources to be wasted here. If
the other group are wasting their resources defining a protocol that
untimately doesn't get used, because it is junk, that's their issue,
not the IETF's.
| Committing to review any proposal that comes in from another standards
| organization is not compatible with efficient management of the IETF.
Of course not. They didn't ask you to review it.
| I do not feel comfortable discussing the reasoning that lead to the
| particular management decision not to allocate resources to this work
| item on a public list. There are parts of any discussion of this type
| that do involve politics.
Yes, there's a bad smell of "that is our turf, how dare they step into it"
being at least a part of the reasoning (perhaps unconscious, perhaps
deliberately stated, those not in the meeting will likely never know).
| However I would like to look at what options the community has in
| order to disagree with this decision. First, while the option of
| appeal does exist, it seems like an inefficient option to employ and
| there are better alternatives. Someone could write an internet draft
| allocating the codepoint; if they believe that we should allocate the
| codepoint without technical review of the proposal, then they could
| contain few details on that draft about the proposal but instead
| reference the existing specification.
How exactly would that change anything? The IESG apparently believes that
the protocol is no good, and that that fact (whether true or not, I have
no idea) should govern the assignment of option codes. How can a draft
cause that to alter?
If you mean that the IETF should review the protocol they're proposing,
why? That isn't what they requested. Why would we care? It might
be different if we could expect to be able to prevent the protocol being used
by legislating against it, but we cannot. If they like it, they will use it,
whatever we (the IETF) thinks about it, and whether or not IANA issues
them a code point (recall, that is just a number, it takes no particular
skill to pick a number out of the hat).
| If people believe that the guidelines in RFC 2780 should
| encourage the IESG to assign options whenever the use is sufficiently
| specified and there is likely to be a significant deployment, then
| they could propose revising RFC 2780 with those requirements.
There is no need to do that, that's what it effectively already says.
The problem is that the IESG read he words "IESG approval" and took
that to mean "we can judge however we like". But that's not what rfc2434
is all about, it nowhere suggests that the IANA, or those making decisions
on the IANA's behalf, should be investigating the technical merits of
the proposals.
It is possible for a field to require that, if it requires a standards
action RFC, or slightly less, if it requires IETF consensus. In both
of those cases, the review happens as part of making the required documentation
available, not as a part of doing the IANA allocation of the code point.
For IESG approval, there's no particular documentation required, just
whatever the IESG deems necessary. Once that documentation is available,
the code point should be allocated.
That is the current state of the 2780/2434 combination.
| I would like you to consider one thing with regard to the specific
| proposal. We both seem to believe it is reasonable for the IESG to
| require community review.
In this case, I don't. There was nothing that needed to be reviewed.
The IESG can certainly seek outside assistance in doing its job, that's
not the same thing as community review. This is not a case where there
is anything that needs much reviewing. Either the documentation is
adequate, or it is not. If it isn't, it can certainly be fixed to
make it adequate.
| So far, I'm not hearing requests either from the
| IPV6 or QOS communities for the opportunity to review this proposal.
Which may mean that they don't care (or all kind of other things). If
they don't care, why should anyone else?
| If those communities don't want to support the proposal, it will
| ultimately go nowhere within the IETF.
As a protocol in the IETF, that would be true. But the community who
took this request to the IESG (via IANA) didn't ever say they wanted
IETF approval.
That is, this is most definitely not a case of someone wanting to gain
apparent IETF blessing of their shoddy work by getting an RFC number
assigned to it.
| Why should we be spending
| effort on the proposal without interest from the areas of the IETF
| that would ultimately review it?
You should not. The IESG already spent far too much time on this.
All it should have done was looked through the documents presented, and
determined whether or not they were adequate to document the option.
It could reasonably have asked for more documentation, for clarification of
the current state of the documentation (whether it was likely to change
further) and other issues like that. No-one (here) should be wasting
any time on the actual protocol quality, unless someone asks for that
to be done.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf