Jefsey,
at most other times, I would not have commented on this at all.
Today, the day before we plan to cut the "final" version of this document,
it seems appropriate to comment on why your "issues" should NOT be
addressed.
Remember always that the cost of text in the document is not about lines of
text - it is about the organizational pain and suffering that comes from
trying to fit actions to a maze of ill-thought-out random restrictions.
That said.....
--On 29. januar 2005 12:43 +0100 "JFC (Jefsey) Morfin" <jefsey(_at_)jefsey(_dot_)com>
wrote:
I would like to rise a few points IRT the IASA effort. Keeping in mind
that Members will have to adopt it and the world to trust it.
1. Transparence is of the essence: I would advise the Transition Team
http://www.alvestrand.no/ietf/adminrest/transteam page to be linked on
the http://ietf.org main page. Important information such as the bios of
the members (including corporate relations and geographical area) are
missing.
If you want to know more about these people, ask, and explain why.
I'm not going to tell the TT members to waste time on writing bios rather
than doing the work that is needed.
The
http://www.ietf.org/internet-drafts/draft-ietf-iasa-bcp-05.txt current
draft should be linked there.
Go one level up. That's the main page.
2. ISOC is an international organization, yet there is no indication
about relations with ISOC local chapters. For organizing local IETF
lists, assisting with IETF meetings, documenting specific local issues
when requested, encouraging regional workshops, meetings, shows,
publications. This should be noted in a short paragraph to acknowledge
national/regional contributions and support and to leave open any further
suggestion/development. Cost: 3lines to be added.
The IETF has never attempted to have an organization along geographical
lines. ISOC has such an organization, but that bears no formal relationship
with the standards process.
This document is not about changing the standards process.
3. Regional representation. Most of the Internet organizations make sure
their BoD is regionally distributed. This is not appropriate for a
technical entity, however IAOC is an administrative body. I would suggest
the Draft Section 4 to include a recommendation (not an obligation) that
all the main parts of the world are represented at the IAOC. Cost: 2
lines to be added.
The IAOC is an administrative body for a technical entity. So "not
appropriate" applies.
4. multilingualism. There is no provision for Secretariat and Editor
translations services, nor for the IAD command of languages. This is
surprising in a 7260 languages world. I do not say the IAD is to speak
many languages nor that publications are to be translated. But I
definitely say that this question must be addressed with a policy
statement. This statement could be that at the present time the
multilingualism issue is not addressed, but should be included in a
further global review of the Internet standard process to support a
Multilingual Internet. Cost: 3 lines to be added.
Not appropriate for this version. This organization is being set up to
support the IETF that exists, not an IETF that might be. If you want to
change the multilingualism policies of the IETF, try that.
5. stability/accountability. As long as decisions by the IAD can be
questioned by anyone else than the IAOC and the IAOC may be accountable
for its decisions one by one rather than for the respect of received
directions, this will be subjective with an important risk of confusion.
I suppose that O'Reilly may start publishing "ORCs" from the Drafts and
the Internet may survive if the IETF is blocked by IASA-DoS? But is that
what we want?
I have no idea what you mean here. Most of the interpretations that come to
mind are meaningless; the rest are covered within the "appeals" debate.
6. The IAD is supposed to be a solitary job. Has anyone considered : "I
am the IAD, let me understand my job and organize my calendar. Even with
48 hours non stop a day, can I carry it all?". I feel there is a few
points which are missing. For example, how can he ask guidance to the
IETF, IAB or IESG? Is the guy entitled to vacations? What if he is sick:
is a replacement to be hired? There are cost of life, salary level,
productivity comparative tables. Did we consider them, when deciding
where the IAD is to seat?
Yes, we assume that the IAD is human. And we assume that the IAD knows
where to find the people of the IESG and IAB, and use the IETF mailing
lists as needed. This is in the category I call "too obvious to state".
7. IANA management. Right now the IANA support is delegated to ICANN by
IETF (RFC 2860) on one hand, and by the USG on another hand,
http://www.icann.org/general/iana-contract-09feb00.htm. This last
contract is questioned by the USGAO
http://www.gao.gov/new.items/og00033r.pdf and by other Govs on the same
grounds. ICANN for some times tries to force another view which is "the
IANA is an ICANN function". This might be a solution, but it should be
worked on and warranties given.
Not relevant to this document. IANA is one of the relationships the IAD has
to care about, but details of these relationships do not belong in this
document.
I guess the rest of your text is just commentary.... it seems to be about
ICANN or about technical work related to the DNS, not about the IASA.
Summary: No change.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf