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"
Dear Harald,
If you want the IETF to continue, there will be a judge to this effort: real life. Real life is that IPv6 is still not being deployed. Real life is that people are not excited about two keyboards IDNs. If you accept that the Internet is the adherence to the IETF documents, the first thing is to make sure people trust the IETF and adhere (know and support) to its process.
should NOT be addressed.
Sounds like as if I succeeded in documenting exactly what this document is NOT about! I suggest next time you start discussing something you call on me and ask what I think important (with a substantial part of the world) so you know exactly what you have not to cover. If this may help, you welcome.
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.
Absolutely true. This is not in constraining reality that you will shape it. Your decision.
Now, "ill-tought-out random restrictions" does not exactly describes propositions to permit a further open investigation on world's documented priorities. Or my Franglish is worst than I thought.
That said.....
--On 29. januar 2005 12:43 +0100 "JFC (Jefsey) Morfin" <jefsey@xxxxxxxxxx> 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.
OK. Your decision. But transparency is at this type of cost. I fully understand that IETF is not a PR agency. But it is like everyone else: it needs customers. This reform is going to cost in money and in trust. Every change in life does.
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.
KISS. You are not in an Ivory Tower. You are selling the IETF deliverables.
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.
This document IS obviously to change the standard process. In which way, I do not know, but it will. Simply because life is changing and the world outside has/is/will change. Please reread the RFC 1958 first and single principle.
The standardization process calls for innovation. Innovation calls for projects and brainstorming. This cannot be easily catalyzed in the current structure: experience shows it. Its complexity filters out independent/small corporation searchers and users propositions. This is why different geo areas start fostering local research teams. As they cannot stay local another organization will foster their common effort. Or did you accept IETF will not deal with NGN?
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.
If you say so. Your decision.
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.
1. the world is doing it.
2. I do not want to change it. I only want you do not prevent it to change. When you say "not appropriate for this version" you _exactly_ say what I say.
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.
dear ... is there an international lawyer/politician in the TT?
BTW "appeals" over _what_?
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.
"we"?
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".
I repeat it. Did you try to set your daily time table, would you be the IAD?
Did you compare the costs of life to know where he is to seat? Did you consider the legal limitations imposed to some by some places?
You did not respond about what happens if the guy is ill?
You impose a multinational holding+secretariat function on a single person. How many hours a day is him/she supposed to keep? Do you demand that he works on Thursday/Friday/Saturday?
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 quote your draft "The IETF Administrative Support Activity (IASA) provides the administrative structure required to support the IETF standards process and to support the IETF's technical activities. As of the time at which this document was written, this included the work of IETF working groups, the IESG, the IAB, and the IRTF. Should the IETF standards process at some future date come to include other technical activities, the IASA shall provide administrative support for those activities as well.".
I quote RFC 2860. "its intent is exclusively to define the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force."
IETF technical activities/works are concerned by both documents. The ICANN position changes. The IETF position is rebuilt. The world understanding of the IANA is changing. IANA is challenged.
Harald, I do not want to play Cassandra. But we feel that the document which is under production does not addresses the needs of our real world. This was my last attempt to try to help in order to avoid a confuse transition over the years to come.
Look, if you really trusted the IETF, you would have set-up a WG-Languages.
But after all, may be you are right, the IETF is better to fall asleep.
Summary: No change.
Seems the best comment. RIP in a changing world.
jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf