Re: IESG Statement on disruptive posting

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.
jfc 

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf