Re: IESG Statement on disruptive posting2006-02-22 20:19:35
At 01:35 23/02/2006, Sam Hartman wrote:
>>>>> "JFC" == JFC (Jefsey) Morfin <jefsey(_at_)jefsey(_dot_)com> writes: JFC> At 23:53 22/02/2006, Sam Hartman wrote: >> >>>>> "JFC" == JFC (Jefsey) Morfin <jefsey(_at_)jefsey(_dot_)com> writes: >> JFC> I think we all are in agreement except on an idea Eudardo JFC> Mendez gave me. I will rephrase it as "if someting tastes as JFC> a WG, smells like a WG, its charter should be approved like JFC> for a WG". The non-WG list is only subject to the approbation JFC> of an AD. This opens the door to too many possible contention JFC> and COI suspicions. Logic and ethic calls for non-WG list JFC> receiving WG authority rights to be subject to WG creation JFC> cycle (obviously far faster). I think it should result from a JFC> simple change in the registration form and page display. It JFC> will say the status of the non-WG list approval and JFC> details. To be on the list an AD approval is enough. To get JFC> full WG priviledges the non-WG list will need to have the JFC> "IAB reviewed", "IESG approved", Area and ADs, etc. >> In principle this sounds fine. My confusion stems from the >> fact that it's actually more restrictions that are applied to >> IETF lists than privileges. >> >> Here is what an IETf list implies to me: * open participation * >> an appeals path * open archive * IETf IPR >> >> What privileges do you see? JFC> I am not sure about what you ask. Their priviledge is to be JFC> an IETF list. This implies constraints (IESG approval, IAB JFC> charter review,...) Their priviledge is reduced JFC> contrainst. AD approval is enough for those not deciding for JFC> the IETF. No Charter, just a few lines describing their JFC> topic. jfc Normally when you want to require an approval process like chartering it is because there is some power or authority being delegated to a list. If the only thing that being an IETF list gets you is additional constraints, why do we need to have a complicated chartering process? Now if you propose that whenever an IETF list is given authority--over a registry, over some approval process etc--it needs a charter and that charter needs community review, I agree with you.
All the lists on the non-WG page are IETF lists covered by the IETF copyrights, etc. These are their basic privilege. Obviously when you just keep alive a WG list, prepare a WG, investigate some testing, etc. you do not need something formal. But when it comes to a registry.
Also, this is something Brian does not seem to want to consider too much, but there may be legal implications to registry management and certainly political ones (ex. names and numbers, languages, etc.). Then you want a mutual formal link - to control/protect.
In the RFC 3066 Bis case, the question raised by Scott irt. the LSR could be IMHO addressed by a separate Draft. It would be a very formal way to describe a permanent organisation (but not more than in the case of names/numbers where there is an MoU with ICANN). The interest is that the Draft I propose would be formally approved by the IESG (under possible appeal to the IAB). It would be much more flexible and could serve as the IETF side in an MoU, if the job was delegated to another organization (I quoted Unicode, ICANN, ISOC, UNESCO,INCOTERM, ITU, etc.). Or accommodate its delegation to an individual like Michael Everson or me or anyone else. Even in the case the job is performed by a 20 people staff at UNESCO, the IETF/IAB/IESG would keep control over that non-WG list.
We see all the difficulties we face and this flexible approach permits to address. In the 3066 Bis case technical appeals are to the IESG and IAB. This means that if an African university disagrees on the way a Chinese scholar think a Eskimo dialect is written in Cyrillic in Peru, the IESG will have to decide. May be of interest to define some kind of advisory committee. IMHO a graduated approach permits this, while keeping authority/delegation consistent. NB. In case names and numbers, appeals have be left with ICANN. Appeals there are with their Ombudsman.
RFC 3066 Bis creates an interesting case. It says that the LSR moderates the list. This is consistent with the fact that the list is a IANA list. This means that the administration (RFC 3934 in the IETF) is with IANA, and that all the fuss made by Michael Everson is meaningless.
_______________________________________________ Ietf mailing list Ietf(_at_)ietf(_dot_)org https://www1.ietf.org/mailman/listinfo/ietf