Re: Last calling draft-resnick-on-consensus

[Avri Doria]

Hi,

I think this is an excellent draft and have already sent a pointer of it to 
colleagues in other organizations as  stuff to consider.

And although it has been eons since I chaired anything in the IETF, it 
perfectly matches my recollection of what humming  and rough consensus was all 
about.


thanks

avri


On 6 Oct 2013, at 17:03, Jari Arkko wrote:

> The document talks about ways in which consensus processes can be 
> successfully run in the IETF. After the last few rounds of versions, I 
> believe this document is ready to move forward. 
> 
> My goal is to publish it as an Informational RFC. It is an explanation of 
> principles and how they can be applied to productively move IETF discussions 
> forward. While there is no change to IETF processes or any presumption that 
> guidance from this document must be followed, I have found the document very 
> useful. It has been referred to numerous times in IETF and IESG discussions. 
> Consensus is hard and many WG discussions have complex trade-offs and 
> differing opinions. I believe having this document become an RFC would help 
> us apply the useful principles even more widely than we are doing today.  
> 
> The abstract says:
> 
>   The IETF has had a long tradition of doing its technical work through
>   a consensus process, taking into account the different views among
>   IETF participants and coming to (at least rough) consensus on
>   technical matters.  In particular, the IETF is supposed not to be run
>   by a "majority rule" philosophy.  This is why we engage in rituals
>   like "humming" instead of voting.  However, more and more of our
>   actions are now indistinguishable from voting, and quite often we are
>   letting the majority win the day, without consideration of minority
>   concerns.  This document is a collection of thoughts on what rough
>   consensus is, how we have gotten away from it, and the things we can
>   do in order to really achieve rough consensus.
> 
>  Note (to be removed before publication): This document is quite
>  consciously being put forward as Informational.  It does not
>  propose to change any IETF processes and is therefore not a BCP.
>  It is simply a collection of principles, hopefully around which
>  the IETF can come to (at least rough) consensus.
> 
> The draft can be obtained from 
> http://tools.ietf.org/html/draft-resnick-on-consensus
> 
> You should see a last call announcement soon, and both me and Pete look 
> forward to your feedback.
> 
> Jari
> 
> 

Re: Is the IETF aging?

[Avri Doria]

Hi,

It may not be line a hiring manager, but all those who have budget can make it 
a point to make sure some of the younger engineers get to some of the meetings, 
at least the ones that are relatively local to them.  I assume that many of the 
older participants, have the means to influence the travel lists.  For years 
there have been people working on the gender balance perhaps some focus on the 
age balance may become appropriate.

It was good, though to see that the distribution was not too skewed toward the 
older participants.

As for bringing new work in, doesn't that take a plan for introducing the 
subject and showing why it is relevant to the IETF community. Although, knowing 
you, you probably had such a plan.  I think that the technical privacy issues, 
for example, while belonging in the IETF, might still feel strange to some of 
the traditional engineering participants.  So in this case, you may need to 
promote a slight cultural change that accepts privacy as a requirement as well 
as the technical challenge of the issue.

avri



On 2 May 2012, at 15:14, Hannes Tschofenig wrote:

> Hi PHB, 
> 
> the IETF is not like an enterprise where you can decide (as part of the 
> hiring process) what characteristics your employees should have. 
> 
> In a volunteer organization the offered topics drive the participation. Ask 
> yourself: what you as someone who just finished a university education want 
> to hang around in the IETF to standardize yet another IPv4/IPv6 transition 
> mechanism or to participate in the MPLS-TP discussions?
> 
> When people suggest new work to the IETF they often see a strange reaction. I 
> remember when Mozilla came to the IETF and proposed to work on the privacy 
> topic "Do Not Track". I couldn't find support for doing the work in the IETF. 
> I don't exactly know why people didn't like it but the W3C immediately picked 
> it up and had seen lots of new companies (mostly from the advertising 
> industry) joining the W3C. 
> 
> Ciao
> Hannes
> 
> 

Re: Future Handling of Blue Sheets

[Avri Doria]

Hi,

In reading this thread several thoughts have come to mind:

- for several years I have not been able to attend an IETF mtg in person, yet 
always join in some of the sessions remotely. Is our remote attendance recorded 
as well, or its it only in the chat archive?  I have noticed that not all of us 
give our real names when we sign in (I generally do but that is beside the 
point.) This would also apply to those who are at the physical mtg but who time 
share between sessions.

- when I used to come to the physical meetings, I often noticed people who came 
to the mtg who did not sign the blue / pink sheets. And does everyone who comes 
in late actually find the sheet and sign it?

- does everyone sign their real name?  do we know if anyone has ever signed the 
name of someone else? How often has Minnie Mouse attended an IETF WG mtg.

- I thought the comment about taking pictures to record the identities of those 
who read documents was interesting. For those who are recognizable this its 
indeed a good record, but what about for others? Also a statement was made that 
no one could complain about this because of the note well - but that only 
references "written, audio and video records of meetings may be made and may be 
available to the public" - nothing about still photography. Perhaps the video 
feature of the phone should be used in the future.

So it seems that the records are probably partial, and unreliable. They are 
also not verified. Are they really useful?

In thinking about why such records are kept, I sort of understand the various 
IPR reasons, but wonder, whether given the unreliability of the information, it 
really would be accepted as evidence. Has ever ever been a case where these 
blue sheet records were accepted as evidence?

If not, are there other good reasons for the blue sheets? I mean they are a 
quaint historical relic and that has value for any organization, but is there a 
function they reliably serve?



avri


Fernando Gont  wrote:

>On 04/24/2012 03:40 AM, Brian E Carpenter wrote:
>>> * What about the case in which the same person must be in two
>meetings
>>> that overlap? (e.g., I've *presented* at overlapping meeting) What
>>> should they do in that that case? Sign all the corresponding blue
>>> sheets? Sign none?
>> 
>> I think you should sign both; however, your name will be in the
>minutes as
>> a presenter, so your presence is part of the public record.
>
>What about folks that are interested in being present in the discussion
>of documents in overlapping meetings? (e.g., one document being
>rpesented by some folks at the beginning of one meeting, and some other
>doc being presented at the end of some other meeting?).
>
>Thanks,
>-- 
>Fernando Gont
>e-mail: ferna...@gont.com.ar || fg...@si6networks.com
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Future Handling of Blue Sheets

[Avri Doria]

Hi,

In reading this thread several thoughts have come to mind:

- for several years I have not been able to attend an IETF mtg in person, yet 
always join in some of the sessions remotely. Is our remote attendance recorded 
as well, or its it only in the chat archive?  I have noticed that not all of us 
give our real names when we sign in (I generally do but that is beside the 
point.) This would also apply to those who are at the physical mtg but who time 
share between sessions.

- when I used to come to the physical meetings, I often noticed people who came 
to the mtg who did not sign the blue / pink sheets. And does everyone who comes 
in late actually find the sheet and sign it?

- does everyone sign their real name?  do we know if anyone has ever signed the 
name of someone else? How often has Minnie Mouse attended an IETF WG mtg.

- I thought the comment about taking pictures to record the identities of those 
who read documents was interesting. For those who are recognizable this its 
indeed a good record, but what about for others? Also a statement was made that 
no one could complain about this because of the note well - but that only 
references "written, audio and video records of meetings may be made and may be 
available to the public" - nothing about still photography. Perhaps the video 
feature of the phone should be used in the future.

So it seems that the records are probably partial, and unreliable. They are 
also not verified. Are they really useful?

In thinking about why such records are kept, I sort of understand the various 
IPR reasons, but wonder, whether given the unreliability of the information, it 
really would be accepted as evidence. Has ever ever been a case where these 
blue sheet records were accepted as evidence?

If not, are there other good reasons for the blue sheets? I mean they are a 
quaint historical relic and that has value for any organization, but is there a 
function they reliably serve?



avri


Fernando Gont  wrote:

>On 04/24/2012 03:40 AM, Brian E Carpenter wrote:
>>> * What about the case in which the same person must be in two
>meetings
>>> that overlap? (e.g., I've *presented* at overlapping meeting) What
>>> should they do in that that case? Sign all the corresponding blue
>>> sheets? Sign none?
>> 
>> I think you should sign both; however, your name will be in the
>minutes as
>> a presenter, so your presence is part of the public record.
>
>What about folks that are interested in being present in the discussion
>of documents in overlapping meetings? (e.g., one document being
>rpesented by some folks at the beginning of one meeting, and some other
>doc being presented at the end of some other meeting?).
>
>Thanks,
>-- 
>Fernando Gont
>e-mail: ferna...@gont.com.ar || fg...@si6networks.com
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Proposed IESG Statement on the Conclusion of Experiments

[Avri Doria]

Hi,

While I find the idea of actually tracking experimentals rather inviting, I do 
think the overhead of such a process should definitely be part of the 
consideration.  

I find the idea of knowing when an experiment its over, challenging.  For 
example, I am working on an experimental, albeit an IRTF experimental, now. 
While I may have some idea of when any experiments I am part of end, how would 
I know about the other people who might be experimenting? Will there be a 
request for them to register their intent to experiment?  Do people purpose 
tracking that? What does it mean to say the experiment is over?

One thing I would like to see is an expectation that at some point there would 
be a report on the findings of the experiment. Even just an ID on the topic 
might be a good thing.

avri




Dave Crocker  wrote:

>
>
>On 4/20/2012 6:36 AM, Murray S. Kucherawy wrote:
>> What about the idea of requiring new Experimental documents to
>> include text that indicates when the experiment is to be considered
>> completed absent new work on it?  Essentially, the document declares
>> a date by which the experiment is considered concluded,
>...
>> To Eliot's point, work that is resumed much later could always
>> restore document and code point status and declare new drop-dead
>> dates when it becomes interesting again.
>
>
>As Brian notes, "dates" are probably unlikely to be useful while also 
>imposing additional administrative tracking overhead.
>
>On the other hand, objective performance/achievement criteria --
>statements that describe what experiential information is being sought
>-- would be useful to encourage.
>
>d/
>
>-- 
>
>
>-- 
>  Dave Crocker
>  bbiw.net

Re: edu.ietf.org

[Avri Doria]

hi,

Yes, the database was moved to a new system and then broke.   After  
some effort James Seng, who is kind enough to host this site has fixed  
it.  I have tested it somewhat and added the XML tutorial.  I will add  
the rest of the tutorial from IETF70 as soon as I can.


Please let me know if anyone notices any other problems with this site.

thanks for your patience.

a.



On 4 Jan 2008, at 13:41, Stjepan Gros wrote:


Hi!

Does anyone know why is edu.ietf.org inaccesible? I'm constantly  
getting

the following error messages:

Fatal error: Table './ietfedu/sessions' is marked as crashed and  
should

be repaired query: SELECT u.*, s.*, r.name AS role FROM users u INNER
JOIN sessions s ON u.uid = s.uid LEFT JOIN role r ON u.rid = r.rid  
WHERE

s.sid = '37c31323078e0ea9726622aa4a7c821a' AND u.status < 3 LIMIT 0, 1
in /home/jseng/vhost/ietfedu/includes/database.mysql.inc on line 97

SG


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IPv4 Outage Planned for IETF 71 Plenary

[Avri Doria]

On 16 dec 2007, at 15.15, Ole Jacobsen wrote:


I've attended meetings where we had a "closed laptop" policy during
presentations,



i find those authoritarian and repressive.  unless there is complete  
unanimity in the room for such a policy it is a very bad idea.
incidentally, i always feel so bad for the poor I*s up on the dais  
with no laptop to hide behind.


on the other hand i like the ipv6 experiment - time to sink or swim.   
and imagine the press if ipv6 fails so publicly.


too bad the idea of IP co-existence was never able to actually take  
hold in the community.


a.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: edu.ietf.org site problems - fixed

[Avri Doria]

Hi,

the Edu Team web page (edu.ietf.org) has now been fixed and the  
presentations can be found both there and on the Agenda page.


thanks for your patience.

a.

On 18 mar 2007, at 20.17, Avri Doria wrote:


Hi,

As several people have pointed out, we are having problems with the  
Edu site.  I thank everyone who has reported it and wanted to let  
people know two things:


- we are looking into the problem and will get it fixed as soon as  
possible


- as soon as those who gave today's talks give me their slides i am  
posting them in pdf format to the agenda page:


https://datatracker.ietf.org/public/meeting_materials.cgi? 
meeting_num=68


Some of them have already been posted.

Thanks and sorry about difficulties this has caused people.

a.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

edu.ietf.org site problems

[Avri Doria]

Hi,

As several people have pointed out, we are having problems with the  
Edu site.  I thank everyone who has reported it and wanted to let  
people know two things:


- we are looking into the problem and will get it fixed as soon as  
possible


- as soon as those who gave today's talks give me their slides i am  
posting them in pdf format to the agenda page:


https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68

Some of them have already been posted.

Thanks and sorry about difficulties this has caused people.

a.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: nomcom and confidentiality

[Avri Doria]

Hi,

To add a tidbit.  There has long been a notion of an umbrella of  
confidentiality in Nomcom.  Which means that anyone who has, or is  
given access, to any of the confidential information has to agree to  
keep the information confidential.  While I have paid very little  
attention t nomcom over the last few years, I assume this idea is  
still relevant.


I agree with Harald that there is this common assumption of trust  
given to system administrators.  And in fact when as a Nomcom chair,  
i kept info on my system, there was always the possibility that a  
company system administrator could see the info and do something with  
it.  I assume the same is true of every nomcom members who receives  
the email on a work owned computer.  I would assume that in addition  
it being implicit that the tools team folks be trusted to treat  
things confidentially, that it be explicit that members of the tool  
team and other administrators of the systems agree to keep nomcom  
information confidential.  I am not looking for an NDA, but perhaps  
an explicit statement might be useful in assuring people.


a.



On 7 nov 2006, at 05.37, Harald Alvestrand wrote:


I think some of Laksminath's concern is valid.
But I think the solution to the problem is simple:

Make it publicly known who is on the technical staff that supports  
the Nomcom, and make it clear that these people:


1) May learn Nomcom information as a side effect of their technical  
work to support Nomcom
2) Have promised not to reveal that information to others, and have  
promised not to take any other action based on that information  
(apart from fixing technical problems)


This is analogous to the role of an email postmaster: He *can* read  
any mail on the system, if he really wants to, but we trust him to  
not *do* it - or, if he has to during debugging, we trust him to  
"forget" what he's read.


I trust that Henrik thought this was "so obvious it didn't need  
mentioning".


 Harald


--On 7. november 2006 00:39 -0800 Lakshminath Dondeti  
<[EMAIL PROTECTED]> wrote:



Fred,

When I saw a non-nomcom member having access to what I thought was
nomcom-confidential, I was very concerned and now doubt the entire
process.  I was told that it is secure, but it has not been  
verified as
far as I can tell.  At this point, no offense to the tools team, I  
remain

unconvinced.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Now there seems to be lack of communicaiton here...

[Avri Doria]

On 2 sep 2006, at 14.49, John C Klensin wrote:


I assume that everything have been done
with good faith here but, to paraphrase an off-list discussion,
at least some of the community will always have a nagging fear
that the reset was motivated by some members of the community
believing that a second draw would yield a more favorable Nomcom.


I think i agree that it is safe to say that is due to human error,  
though the consultation with someone who is on the list of those to  
be considered for renewal does compound the error and put it all at  
further risk.  but i still think it is an error and not an  
intentional act to subvert the process.



On 2 sep 2006, at 17.42, Theodore Tso wrote:

On Sat, Sep 02, 2006 at 06:59:36AM -0700, Hallam-Baker, Phillip wrote:

The bug here is that the process is insufficiently robust under
operator error.

That is broke.





I think we are in violent agreement that it should be fixed before the
next Nomcom.  There may be a difference of opinion of how exactly to
fix the problem, but I don't think anyone has suggested that we should
leave things the way that they are, at least for the next Nomcom.



i don't think the process is broken, but the implementation was.  and  
i don't believe this is sufficient reason to reopen the nomcom process.


i think the process is clear about what should happen once someone is  
committed to the 3797 process.  what is broken is that the process  
was, perhaps, not well enough  understood and, as is so often the  
case in the IETF and elsewhere, was followed loosely as opposed to  
strictly. i do wonder if the previous nomcom chair was consulted in  
making the decision to redraw - in fact perhaps previous chairs could  
be a useful resource for the new chair faced with such a dilemma as  
opposed to representatives of the bodies to be staffed.


however, in the sprit of accepting broken implementations (i.e.  
conservative in what you send, liberal in what you receive) i suggest  
we wish Andrew luck and let him get on with it.


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Meetings in other regions

[Avri Doria]

Hi,

I think I am somewhat confused by this discussion.

In one place you say:

On 14 jul 2006, at 11.04, Fred Baker wrote:

The IETF should indeed meet where our participants come from. That  
was my initial comment (from the mike) on "are we from Latin  
America, Africa, or Antarctica?" I think that remains to be shown.





and in another:

On 14 jul 2006, at 11.55, Fred Baker wrote:
from the norht american stats. I would encourage you to compare the  
european and asiapac meetings, from the proceedings. My observation  
is that the region/country the meeting happens in tends to be  
exaggerated. Yokohama, for example, was 1977 folks, of which 1/4  
were US and perhaps 40% were Japanese. Seoul was similar.


so does this mean that when the meeting is in NA, then the NA  
population is also exaggerated.


Or rather that a large number of participants will come from whatever  
region the meeting is in
(at least for the NA, EU, or Asiapac regions - we have no evidence on  
LAC or Africa), giving us no objective criteria for weighing one  
region over another.


If this holds, don't we have a parity situation where the meetings  
should alternate equally between these 3 regions with maybe an  
occasional meeting in a developing area, like an easy to get to  
region in Africa or LAC.


a.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Response to the Appeal by JFC Morfin dated 2006-02-17

[Avri Doria]

Hi,

I do not wish to enter the substance of this appeal for i am  
qualified neither by position nor training to adjudicate on the  
justice of an appeal.


But I do want to question one paragraph that has been published on  
behalf of the leadership of this organization.  This questioning is  
not in relation to the appeal itself, but rather to the acceptability  
of the statement in itself.


On 10 jul 2006, at 14.05, IESG Secretary wrote:


Secondly, the IESG believes that the Universal Declaration of
Human Rights does not apply to the IETF's internal rules.
IETF participants are assumed to be aware of IETF process rules
before choosing to participate, and their participation is voluntary.



Without making any personal judgement about the correctness of such a  
hypothetical claim, I could understand an IESG decision that the  
Universal Declaration of Human Rights (UDHR) did not apply in this  
particular case. I do not, however,  understand a categorical  
statement to the effect that the IETF, with its rules, is not subject  
to the UDHR because it is a voluntary association.


While the IETF itself is not a signatory to the UDHR, most, if not  
all, of the nations in which the IESG members live  are signatories  
and the host country of the ISOC corporation, the IETF umbrella, is  
also a signatory.  I believe that in all things we do, we are always  
subject to the UDHR.  And I worry about an organization, especially  
one I believe in, making a categorical claim that human rights, as  
defined by the UDHR, do not apply within this organization.  We may  
be here to do technical work, but we should, in my opinion, never  
leave the responsibilities of humanity at the door.  To claim that  
something so fundamental as human rights do not apply within the  
confines of the IETF is too all encompassing a statement, and one I  
don't feel can be allowed to stand without at least a little protest.


To quote  Eleanor Roosevelt  "The destiny of human rights is in the  
hands of all our citizens in all our communities" .  I think this  
applies to the IETF community as much as it does to any other  
community.  I hope that the IAB, whatever it may decide on the merits  
of the appeal in question, will see fit to repudiate the claim that  
the UDHR does apply to the IETF or its rules.


a.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: My notes from this morning at breakfast

[Avri Doria]

On 11 jul 2006, at 09.07, Spencer Dawkins wrote:


This was NOT intended for general distribution - my apologies...



perhaps, but the timely transparency was refreshing.

thanks for the error.


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: On revising 3777 as in draft-klensin-recall-rev-00

[Avri Doria]

On 15 nov 2005, at 16.43, Dondeti, Lakshminath wrote:Hi Eliot,  The most recent number of nomcom eligible folks is 849, please see https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=446.  20 people out of that isn't all that high.  I think I might easily find 10 like-minded people; but 20 makes the burden of proof a bit harder and that sounds good to me.  even when i was just 1 person needed to start a recall we never had one, though there may have been cause on occasion.  a lot of discussion went on about the number in the nomcom wg.  i suggest people go back to the archives before restarting the whole discussion.Furthermore, there have been (rumors of) cases where IESG/IAB members who were purported to be ineffective have been selected again for their positions.  (As to why that is is a different story, and is closely related to the same reason why only about 10% of the nomcom eligible folks actually volunteer to be on the nomcom: apathy).or perhaps some people secretly really hope to be put on the iab/iesg.  while IETF mythology claims that no one worthy wants the roles, i expect it is not true.  though there is the issue that the work load seems to have increased from being a half time job for the iesg to a full time job, and this may make it difficult for independents or people from small companies to contribute the time.  this may be a good reason for reforming the iesg, but that is a difficult topic and probably belongs to another thread.  it may also be that there is an impression that it is always people from the same core group are selected.  this may also be a myth, but may be enough to dissuade people from getting involved in process they may think somewhat futile.finally, i am not convinced that everyone realizes how vital a role nomcom plays in the IETF process, or the fact that it _really_ is open to those outside the core group of IETF.so i think that apathy about nomcom  or willingness to serve in I* may be only a small part of the story.a.___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Please make sure that you do not run your WLAN in ad hoc mode

[Avri Doria]

On 11 nov 2005, at 13.56, Ole Jacobsen wrote:

In 19 days, this very hotel and meeting rooms will be filled with  
ICANN
attendees, most of whom are not "technical" in our sense of the  
word. That

should be lots of fun :-)


It will be interesting to see if ICANN has as much trouble, or IEEE  
during the intermediate week.


I have heard an interesting bit of anecdotal evidence that indicates  
the situation is worse at IETF meetings then at other meetings.  I  
questioned it, but who knows?


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Faux Pas -- web publication in proprietary formats at ietf.org

[Avri Doria]

On 5 nov 2005, at 02.59, Anthony G. Atkielski wrote:


The advantage of PDF is that it preserves the exact appearance of the
original document, and that it is designed to be a final format, that
is, it is not designed to be editable (and editing PDF is difficult,
deliberately so).  Also, PDF readers of some kind are available for
just about every conceivable platform, and they all work extremely
well.



I used to be a proponent of PDF usage in the IETF, but I have been  
informed that there are no PDF readers for the blind.  This makes it  
less then optimal as a universal vehicle.


Of course I may be wrong - did not do the research myself, or  
technology may change.  Though I think the pictorial nature of PDF is  
a barrier.


a.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: technicalities - apologies - wrong list

[Avri Doria]

sorry.  wrong list in address.

a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: technicalities

[Avri Doria]

On 29 okt 2005, at 23.09, [EMAIL PROTECTED] wrote:


And Saddam had WMD, but he used them all up
on the Kurds.  Darn those Kurds anyway.


were these the left over from the ones the US gave him for the war  
with Iran?


a.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: from the horse's mouth

[Avri Doria]

On 29 okt 2005, at 15.40, Harald Tveit Alvestrand wrote:



Amorality among scientists, engineers, and technologists has  
gotten the
world into a lot of trouble.  I prefer to think about the  
consequences

of what I do.



I think we all do, and I think it's one of the reasons why I felt  
Jefsey's accusations of provinciality and blinkeredness to be  
deeply insulting as well as incoherent.


I am not sure what he did other then send 2 pointers to articles.   
Don't quite understand how this might be insulting.


I do think there are two interesting questions:

- is the IETF community interested in discussions about the social  
implications of the technology we develop


- is the IETF general list the right place for those discussions.

I for one am interested in the topic  and think it is important for  
any tehcnological group to take a view of its social responsibility.  
But i am not sure that this list is the right place - though I don't  
mind since I can skip threads that don't interest (or bother)  me,  
but experience shows that not everyone is able to do so.  and to some  
people the topic is irrelevant.


So perhaps an ISOC list, or a specific IETF social issues list would  
be better.  At least on such a list everyone would be participating  
willingly.


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Venue Selection Criteria

[Avri Doria]

Hi,

I can agree with SHOULD and SHOULD NOT, the only problem i had in  
writing it that way is i could not meet the specification requirement  
for specifying the conditions under which the requirement would not  
apply.  I did not want to careless create loopholes.


My main concern is that these issues be a formal requirement of the  
community's decision in where we meet.  And that they be taken  
seriously.


a.
On 17 okt 2005, at 21.50, Brian E Carpenter wrote:


Sam Hartman wrote:


"Avri" == Avri Doria <[EMAIL PROTECTED]> writes:


Avri> - MUST NOT be held in a country whose visa requirements are
Avri> so stringent as to make it impossible or even extremely
Avri> difficult for some participant to attend.
I think this is too strict.  I think visa criteria are an issue, but
saying that visa criteria prevent one participant from attending  
seems

way too strict.



More generally, any non-trivial set of MUST NOTs is going to be
impossible to satisfy simultaneously. I really don't see how we can
go further than should/should not, in practical reality.

   Brian








___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Venue Selection Criteria

[Avri Doria]

I did not mean to say one participant, i meant some participants  
(though i dropped the 's') and of course accept that that should be a  
number larger then 3.


And I do accept the idea that many of these are subjective and best  
determined by a trusted entity (IAD/IAOC) and vetted by the community.


a.

On 17 okt 2005, at 05.59, Sam Hartman wrote:


"Avri" == Avri Doria <[EMAIL PROTECTED]> writes:



Avri> - MUST NOT be held in a country whose visa requirements are
Avri> so stringent as to make it impossible or even extremely
Avri> difficult for some participant to attend.


I think this is too strict.  I think visa criteria are an issue, but
saying that visa criteria prevent one participant from attending seems
way too strict.






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Venue Selection Criteria

[Avri Doria]

Hi,

It certainly makes sense to reword it for a pattern of difficulty or  
exclusion.


On any of these criteria, since this is the IETF, it might make sense  
to subject them to rough consensus criteria.  I.e a country that is  
being considered for a future meeting could be vetted on the IETF list.


Or they could be rephrased as guidelines to the IAD and IAOC assuming  
that they could use a reasonable participant criteria (similar to the  
reasonable man rule used in jurisprudence) for judging whether sites  
meet these criteria, with the IETF ready to comment once they make  
their recommendations.


a.

On 14 okt 2005, at 15.39, Bill Sommerfeld wrote:


On Fri, 2005-10-14 at 11:58, Avri Doria wrote:


I think there needs to be some mention of requirements such as:

- MUST NOT be held in a country whose visa requirements are so
stringent as to make it impossible or even extremely difficult for
some participant to attend.



An important factor worth stressing, IMHO, is the time required to  
apply
for & issue a visitor visa suitable for a short-term visit.  If the  
time

required isn't predictable in advance and measureable in small numbers
of months, that itself is a barrier to participation.

But I might back off on a hair on the phrasing -- "several
participants"?

Let's be realistic -- we're talking about government bureaucracy here.
Is there any country out there which doesn't occasionally "randomly"
deny or significantly delay granting a visitor visa?  A single  
incident
ought not to preclude us from returning.  A pattern of exclusion,  
on the

other hand, would be a matter of concern.

- Bill

















___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Venue Selection Criteria

[Avri Doria]

On 14 okt 2005, at 13.19, Jari Arkko wrote:


Freedom of expression is another matter, and would be slippery
slope indeed. I think in most cases we would be better off
being open and constructive, and helping more people understand
what our views are than to refuse contact.




I agree, and that is why I tired to include specific issues, though  
admit that part needs greater specificity.  I think the slippery  
slope can be avoided by designating specific acts that make a site  
unacceptable.


One can safely argue that everywhere censures something, however,  
some well known practices are more serious then others.  Blocked  
sites, redirected dns, registration and arrest of bloggers etc
stand out as things that can be stated specifically and not subject  
to much interpretation (ok, as anyone who knows me knows, i believe  
everything is subject to some degree of interpretation).


As for being open and constructive, I agree that in principle this is  
a good goal.  however, i beleive it is a goal that exists on its own  
slippery slope, a slope that ends in appeasement and acquiescence to  
practices we would prefer not to support.  I think a better path to  
openness is to set a good example and to invite all to participate  
and to make it easy for them to participate (ref. the visa rules - i  
also advocate subsidized attendance fees - but that is another issue).


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Venue Selection Criteria

[Avri Doria]

Hi,

I think there needs to be some mention of requirements such as:

- MUST NOT be held in a country whose visa requirements are so  
stringent as to make it impossible or even extremely difficult for  
some participant to attend.


- MUST NOT be held in a country with restrictions on freedom of  
expression, especially if these extend to the blocking of web sites  
or any other censuring of personal communications.


- MUST NOT be held in a country were local participants would be  
under pressure to support national technical policies on threat of  
imprisonment or other punitive actions, for their opinions.


- MUST NOT be held in a country were local participants would need  
government approval to attend.


a.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: On PR-actions, signatures and debate

[Avri Doria]

On 7 okt 2005, at 17.56, Anthony G. Atkielski wrote:





It's just possible that the threshold might be higher for some
than it is for others.



So which threshold is the "right" threshold?





I think that the offense has to be so egregious that invoking such  
draconian rules is truly a rough consensus - i.e. with very few  
dissenting voices and for the dissenting voices to be such that their  
dissent is not well thought out.  and while full consensus is rarely  
possible, it should be as close to full consensus as possible.


the IETF of late seems to me to be moving ever closer to a top  
dominated group where a few voices have control of all decisions and  
where very little disagreement, especially strong disagreement, is  
allowed. i think this is a bad trend.  to allow for easy suppression  
of dissent, which always sounds strident to those in power (whether  
they happen to be in office or not), is, in my opinion a mistake and   
contributes to that trend.  it leads to a behavior mandate of 'be  
careful of what you say and who you disagree with for it may come  
back to bite you'.  and since there is no real appeal mechanism,  
except for the very brave, for those who feel abused by the system,  
the suppression of dissent becomes even more alarming.


On 6 okt 2005, at 16.51, Melinda Shore wrote:


Messages like "I'm for this" or "I'm against this" seem to be taking
the form of a vote, when it seems to me that what's probably more
appropriate would be an attempt at persuasion.


i think that when looking for consensus, it makes sense for multiple  
people to support the statements of someone else.  This is not a  
vote, but rather an indication that something does or does not have  
enough agreement to affect a consensus call.


my normal attitude on this overly active list is to only comment when  
i don't see my viewpoint reflected in someone else's comments - in  
fact that is my attitude vis a vis all IETF lists.  but when a storm  
is gathering and someone must make a consensus evaluation, i think it  
reasonable to send a 'me too' message and to make that message as  
short as possible.


so in this case i was agreeing that i saw no just cause for a PR  
action.  but if i had seen casue, i would probably have argued for  
mutual cause given the provocation and counter provocation of the two  
parties.  however, as i argue above, i don't think this rises to the  
level of requiring application of a draconian response to limit  
expression.


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Anyone not in favor of a PR-Action against Jefsey Morfin

[Avri Doria]

well said.  neither am i.

a.

On 6 okt 2005, at 13.42, Bill Manning wrote:



i for one, am not in favor of a PR action against anyone.

--bill



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF Chair, General Area, process and complexity

[avri doria]

Hi,

in John's formulation, the process work of the general area withers 
away - or at least moves to a different corner of the world.


so what happens to the general area?

one suggestion is to axe it.
my suggestion would be for that role to be staffed by a generalist who 
is comfortable with complexity in its many network manifestations.  
this area could then house those groups that need to deal with complex 
issues that now often get force fit into the more specific areas.


a.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

publishing names (Re: Complaining (Re: Voting (again))

[avri]

there have been cases where names were published by the iab or iesg, 
e,g, in selecting for the iaoc and the isoc bot.

while i know it is probably impossible to know how many people refused 
to be considered because of the publication (don't remember if there 
was a opt-out of publication opportunity - if so it would be 
interesting to know how many chose it), what i would be interested in 
knowing is whether the I* received many comments from a wide cross 
section of the ietf community on those occasions.

thanks
a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: text suggested by ADs

[avri]

On 7 maj 2005, at 21.32, Dave Crocker wrote:
Let me try the simplest summary possible:
   If someone has the authority to block the long-term work of a group 
of IETF
participants, they have an *obligation* to take their concerns 
directly to
those participants and engage in a direct process to resolve it.

Authority always comes with responsibility.  In this case it should 
simply be
that the authority to block a group has a responsibility to interact 
with that
group.

Directly.


Seems eminently reasonable to me.
Even seems practical not to mention good professional etiquette.
I find it hard to understand why an AD would not behave this way 
(though I know it is not the common practice).

I have always felt that authority entailed obligations and 
responsibility.  And the more power a position has the more constrained 
the holder of that position should be in his or her behavior.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: french crypto regulations relating to personal encryption usage by visitors?

[avri]

On 3 apr 2005, at 04.39, Eric Rescorla wrote:
I'm not sure what you think the misunderstanding is. That people
are often self-interested and prefer to minimize travel time?
I doubt that's a misunderstanding at all.

I don't agree with this assessment.  I think that if the decision where 
to continue the North American meeting allocation, just requiring them 
all to be in Canada, most of the complaints would come from people in 
the US and not from Europeans even though the US travel time would 
still be optimized.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Correction to EDU Schedule for Sunday

[avri]

To IETF meeting participants,
The HTML schedule for the Working Group Leadership class on the IETF 
website is mistaken, whereas the Text version is correct.  The class is 
a two hour session, not a 4 hour session. This will give people the 
chance to also attend either of the 1500-1700 sessions should they 
desire.

The Schedule for EDU sessions is as follows:
SUNDAY, March 6, 2005
1300-1400 Newcomer's Training  - Salon E
  An introduction to the IETF for new or recent IETF attendees.
  Covers the IETF document processes, the structure of the IETF,
  and tips for new attendees to be successful in the IETF 
environment.

1300-1500 Introduction to Working Group Leadership - Salon F
  This session is designed to help current and future
  Working Group/BOF chairs, and current and future Working
  Group document editors, understand the IETF process and
  what is expected from them. Both the formal requirements
  and the informal lessons learned from previous Working Group
  experience are covered. Part of the session is also
  devoted to how chairs and document authors can work together
  well to aid the entire process.
1500-1700 Routing, Bridging and Switching: A Tutorial - Salon G
  This session demystifies the conceptual issues in moving
  data across multiple hops. We give an overview of, and
  contrast the functionality of these technologies, including
  an overview of link state routing (used in OSPF and IS-IS),
  spanning tree (used in bridging and switching), distance 
vector
  (used in RIP), and path vector (used in BGP).

1500-1700 How to Write an RFC - Salon E
 This tutorial will provide an introduction for newcomers to the
 RFC series as well as a refresher for experienced RFC authors.
 It will review the most important editorial policies and 
formatting
 rules for RFCs. It will also provide a set of helpful hints to 
authors
 about content and format; following these hints will often 
improve
 the timeliness of RFC publication and the quality of the 
resulting
 documents. It will include a brief overview of the procedures 
for
 review and approval of RFCs, both IETF submissions and RFC 
Editor
 submissions, and there will be an opportunity to ask questions 
of
 RFC Editor staff.

thanks
Avri
Coordinator EDU team

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Proposed consensus text: #725 Appealing decisions

[avri]

I would also prefer that the last paragragh stay in.
a.
On 28 jan 2005, at 14.13, Sam Hartman wrote:
I support this text.  I prefer the last paragraph be present but this
is not a strong preference.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Suggested resolution - #826: Section 4 - Removal of the IAOC Chair

[avri]

I don't think it is a showstopper and don't think that removing the 
IAOC char should require a super majority.  If the chair serves at the 
pleasure of the IAOC then the chair should be easily replaceable by the 
IAOC.  I do agree, however, that it should take a majority of the 
members and not a majority of those present at a meeting to remove the 
chair.

a.
On 28 jan 2005, at 04.10, Harald Tveit Alvestrand wrote:
Russ raised the issue that 2/3 majority to remove an IAOC chair seems 
a bit excessive, considering that this requires 6 votes out of 8, with 
the chair being one of the 8. So the chair + 2 others could hold on to 
the chair position.

Scott mentioned that removing a chair is serious, so we should make 
sure we don't get into the "decision at a meeting with few people 
present" problem, and talked about email voting.

Suggested change:
Old text (from section 4):
  The Chair serves at the pleasure of the IAOC, and may be removed from
  that position at any time by a two thirds vote of the voting
  membership of the IAOC.
New text:
  The Chair serves at the pleasure of the IAOC, and may be removed from
  that position at any time by a vote of five of the IAOC voting 
members.

If people disagree with Russ, and think that we SHOULD require six 
votes, that's easily accomplished:

  The Chair serves at the pleasure of the IAOC, and may be removed from
  that position at any time by a vote of six of the IAOC voting 
members.

I don't think that this is a show-stopper issue no matter what the 
resolution is, but it's nice to have it nailed.

Harald

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Mud. Clear as. Re: Rough consensus? #425 3.5

[avri]

I am happy with both as well.
thanks
a.
On 27 jan 2005, at 20.30, Margaret Wasserman wrote:
Hi Leslie,
I like this formulation.
A couple of suggested tweaks, inline:
...and I like your tweaks :-).
They make the text much clearer.  Thanks.
Margaret
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Mud. Clear as. Re: Rough consensus? #425 3.5

[avri]

This set of principles works for me.
a.
On 26 jan 2005, at 20.40, Eric Rescorla wrote:
With that in mind, I would like to suggest the following principles:
1. The IETF community should have input on the internal rules
   set by the IASA and the IASA should be required to respond
   to comments by the community on said rules.
2. While the IASA's behavior should be constrained by BCPs (as it will
   be constrained by the first one) we should in general refrain from
   enacting specific internal IASA rules changes by BCP. If it is 
believed
   that the IAOC is making bad decisions we have a mechanism for 
unseating
   them.

3. Decisions of the IAOC should be appealable (following the
   usual 2026 appeal chain) on the sole grounds that the IASA's
   processes were not followed. Those decisions should NOT be
   appealable on the grounds that the decisions were simply bad ones.
I recognize that point (3) above is somewhat controversial, so
I'll attempt to justify it a bit. The simple fact is that the
IASA (both IAD and IAOC) will be constantly making business decisions
and if we are to keep the job manageable (and in the case of IAD
keep the costs down) they have to know that they will not be
constantly second-guessed by the community on what kind of cookies
they purchased. If the community feels very strongly that the
wrong kind of cookies were purchased then they can ask for a
rule demanding chocolate chip, and in the worst case pass
a chocolate chip cookie RFC.
There's a parallel here in the RFC 2026 appeals process. While
the IAB and IESG can review a decision both for process violations
AND for technical merit, the ISOC BOT is extremely constrained in
that it can only provide limited procedural review (S 6.5.3)
   Further recourse is available only in cases in which the procedures
   themselves (i.e., the procedures described in this document) are
   claimed to be inadequate or insufficient to the protection of the
   rights of all parties in a fair and open Internet Standards Process.
   Claims on this basis may be made to the Internet Society Board of
   Trustees.  The President of the Internet Society shall acknowledge
   such an appeal within two weeks, and shall at the time of
   acknowledgment advise the petitioner of the expected duration of the
   Trustees' review of the appeal.  The Trustees shall review the
   situation in a manner of its own choosing and report to the IETF on
   the outcome of its review.
   The Trustees' decision upon completion of their review shall be 
final
   with respect to all aspects of the dispute.

It seems to me that this is a good model to follow for IASA.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #425: Review versus appeal?

[avri]

Hi Spencer,
On 26 jan 2005, at 08.25, Spencer Dawkins wrote:
- And last: Even if there is an appeals chain, I don't think the IESG 
and the IAB should be in it. We are supposed to be selected for the 
wrong sort of competence.

  Harald
I'm really not trying to muddy the waters here, but
- I agree with Harald on this point, for exactly the reason stated, and
- this statement seems to be pretty disconnected from the "don't have 
to respond to community appeals, have to respond to IESG/IAB appeals" 
discussion (also in this thread), so I think we're confused on 
consensus...

I am afraid this confuses me.  But perhaps it is becasue I think the 
two subjects of appeal and accountability for review are, and should 
be, linked.

I have difficulty understanding how the IESG and IAB can be responsible 
for 'enforcing' a review request (Leslie's formulation as I understand 
it) yet, not have a role in handling appeals.

Thinking further this seems to create the following paths
- individual request for IAOC review
  - If no response
 then make request to IAB or IESG for enforced review
(and i am not clear if this a request to
 either IAB or IESG or to some sort of joint entity.
 and if it is to either
 does one just pick the one they are more comfortable with?)
 - If IAB/IESG refuses to enforce the review request
then make a 2026 appeal of the decision of the IAB/IESG
  -  if the appeal is successful
 then the IAB/IESG makes enforced review request
  - If the IAOC response is unsatisfactory
 then what?  appeal decision directly to ISOC BoT?
do they accept such a responsibility?
 and who makes the appeal on an enforced review?
   does the original complainant have the right/responsibility
   or only the body that required the enforced review.
As I indicated above, separating the concept of review request from 
that of an appeal, an appeal with the possibility of revising a 
decision, seems to make things more complicated.  Unless, of course, 
the object of the separation is to replace appeals with reviews.  And 
my problem with eliminating appeals, as I have said too often now, is 
that it makes recall or non renewal the only recourse to correct a 
problem.  This bother me for several reasons:

 - It is too course a method.  90% of what an IAOC may do could be very 
satisfactory to the IETf at large with only a few decisions being 
problematic.  But if one must recall the committee to fix a bad 
decision (I assume that any IAOC can revise the decisions of a prior 
IAOC) one either sacrifices the good for the bad, or is forced to 
accept the bad as a price for the good.  A finer instrument of 
correction seems important.

- Getting reappointed to a position, or even the absence of recall,  
becomes 'approval' for all prior decisions, i.e. there is just one 
undifferentiated "moment of accountability" for all decisions.

- I strongly believe that one of the strengths of the IETF is the 
direct accountability all of the leadership has to the appeals of the 
participants.  I.e I believe that 2026 accountability is an important 
part of the IETF and should be maintained for all new organizational 
structures.

Note: If i am alone in my reasoning, I will not stand in the way of the 
draft going forward (as if i could).  So I will probably wait until 
others of a similar persuasion to mine, if there are any, comment on 
the issue before making any further comment - unless of course a 
question is directed at me specifically.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Mud. Clear as. Re: Rough consensus? #425 3.5

[avri]

Hi Harald,
On 26 jan 2005, at 02.23, Harald Tveit Alvestrand wrote:
Avri,
--On tirsdag, januar 25, 2005 23:44:09 -0500 [EMAIL PROTECTED] wrote:
Hi Leslie,
This formulation is still of the form that does not give the IETF
community a direct voice in the review and appeal mechanisms for the 
IAOC.
I do not understand what you mean by "direct voice". Could you explain?
As I understand Leslie's formulation, the IAOC has no requirement to 
process a review from a normal member of the IETF Community unless that 
request comes from the IAB or IESG.  To my mind, this means that the 
IAOC is answerable to the IAB or IESG and not directly answerable to 
the IETF Community.

When an individual IETF participant makes a review request, it may be 
ignored.
If someone is unhappy at being ignored they may make a request to the 
IAB or IESG for recognition.  This request may be also ignored, with 
the only recourse to that being an appeal of the IAB or IESG decision 
to ignore their request.

That is, it is only if someone interests the IAB or IESG in their issue 
that it forces a review.  Also the only decision that can really be 
appealed is the IAB or IESG handling of the request for a review not 
the decision of the IAOC. I am defining that this as not having direct 
voice.


If what you mean is that the community should have representatives 
involved in the consideration of the issues, and do not think that the 
nomcom-selected members, the IESG-selected members and the 
IAB-selected members of the IAOC are appropriate community 
representation, I do not see any mechanism short of the way we 
constitute recall committees that will give you what you want.
My issue is not with how the members are appointed to the IAOC.  I am 
fine with that.  My issue is whether they are accountable to the 
community or the community's representatives.  As written they are 
accountable only to the the community's representatives and are thus 
one step removed from direct accountability to the community.

If you think that the community should have the right of complaint, 
then I think you need to accept some limitation by human judgment on 
how much effort each complaint can cause.
I have not seen any argument that convinces me that those limits should 
be any different then the limits to judgment that currently exist to 
complaints, i.e. appeals, against the IAB or IESG.  I am basically 
using the 'running code' argument and asking that the appeal process we 
currently have be extended to this new IETF management group.


If that judgment is to lie outside of the IAOC, it has to be invoked 
for all complaints to the IAOC (making the system more formalistic); 
if it is inside the IAOC, it seems reasonable to have some means of 
overriding it.

I, personally see not reason why the IAOC is not directly addressable 
by
the community and does not have a direct obligation to the IETF
community.  While I am comfortable with the IESG and IAB being the 
appeal
path for the IAOC, I am not comfortable with them being a firewall for
the IAOC.
I do have a problem with seeing the words that Leslie proposed as 
fitting your description. As described, it isn't a firewall - it's an 
override of a safeguard.
A firewall protects.  As written the IESG or IAB protects the IAOC from 
the IETF community, which to some extent is being assumed to be a 
sometimes malicious DOS'ing environment that the IAOC needs to be 
isolated from.


I think this is a fundamental question that differentiates Margaret's
formulation from yours.  I also think it is a fundamental question 
that
goes back to issues in the problem statement about the current 
leadership
model:  too much influence is focused in one leadership group.  One
benefit of the creation of the IAOC is that it spreads the task of
running of the IETF to another group of people.  As such, I think the
IAOC must be required to respond directly to the community.
I don't quite see the logic here - we take tasks that are currently 
performed in an undocumented and unaccountable fashion and move them 
into a body that has oversight over them, is selected by the 
community, is removable by the community, and is (as I see it) 
normally expected to respond to the community.
To some extent those tasks were performed in an unaccountable fashion, 
and to some extent the Chair's of the IAB and IESG (and maybe the 
groups themselves) have been the only ones who had any visibility, for 
some degree of visibility, into them.

But that is not really the point.  If as you say this is oversight that 
never occurred before, then I see this formulation as adding more 
responsibilities to the IAB/IESG, i.e. acting as the oversight body and 
as the arbiter of the community's voice.  And to refer back to the 
Problem process this is adding responsibility to a group that is 
already overloaded and which has a scope of responsibility that some 
feel is already ov

Re: Mud. Clear as. Re: Rough consensus? #425 3.5

[avri]

Hi Leslie,
This formulation is still of the form that does not give the IETF 
community a direct voice in the review and appeal mechanisms for the 
IAOC.

I, personally see not reason why the IAOC is not directly addressable 
by the community and does not have a direct obligation to the IETF 
community.  While I am comfortable with the IESG and IAB being the 
appeal path for the IAOC, I am not comfortable with them being a 
firewall for the IAOC.

I think this is a fundamental question that differentiates Margaret's 
formulation from yours.  I also think it is a fundamental question that 
goes back to issues in the problem statement about the current 
leadership model:  too much influence is focused in one leadership 
group.  One benefit of the creation of the IAOC is that it spreads the 
task of running of the IETF to another group of people.  As such, I 
think the IAOC must be required to respond directly to the community.

a.
On 25 jan 2005, at 21.15, Leslie Daigle wrote:

3.5  Business Decisions
Decisions made by the IAD in the course of carrying out IASA business
activities are subject to review by the IAOC.
The decisions of the IAOC must be publicly documented for each formal
action.
3.6  Responsiveness of IASA to the IETF
The IAOC is directly accountable to the IETF  community for the
performance of the IASA.  In order to achieve this, the
IAOC and IAD will ensure that guidelines are developed
for regular operation decision making.  Where appropriate, these
guidelines should be developed with public input.  In all
cases, they must be made public.
Additionally, the IASA should ensure there are reported objective
performance metrics for all IETF process supporting activities.
In the case where someone questions that an action of the IAD or the
IAOC has been undertaken in accordance with this document
or those operational guidelines (including the creation of an
appropriate set of such guidelines), he or she may ask for a formal
review of the action.
The request for review is addressed to the person or body that took
the action. It is up to that body to decide to make a response,
and on the form of a response.
The IAD is required to respond to requests for a review from the
IAOC, and the IAOC is required to respond to requests for a review
of a decision from the IAB or from the IESG.
If members of the community feel that they are unjustly denied a
response to a request for review, they may ask the IAB or the IESG
to make the request on their behalf.
Answered requests for review and their responses are made public.
Reviews of the IAD's actions will be considered at his or her following
performance review.  Reviews of the IAOC's actions may be considered
when IAOC members are subsequently being seated.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Rough consensus? #425 3.5

[avri]

On 25 jan 2005, at 08.33, Margaret Wasserman wrote:
At 7:54 AM -0500 1/25/05, [EMAIL PROTECTED] wrote:
in (2) I think that the review request need to be addressed to the 
chair of the respective body.  I think the language of 2026 can be 
adapted as to contents.
Yes, I agree.  That is what I included in my proposed wording (lo 
these many moons ago), but would also accept other alternatives, as 
long as it is clear when someone would send a review request and it is 
clear who is responsible for making sure that it is considered.
I think that the Chair is always ultimately responsible for seeing to 
it that the work of the IAOC, or the IAB or IESG for that matter, gets 
done.


in (5), I think the appeals should have the full chain of appeals. I 
know 'at least one level' does include the chain, but I think it is 
important to be able to appeal all the way to the ISOC BoT.
Why do you think so?  If it is the ISOC BoT that you want in the loop 
specifically, I suppose that the first level could go there...   It 
seems to me that multi-level appeals in the IETF have not worked very 
well...
I think the multi level escalation works by making sure that the 
correct level of the organizational layering gets to handle the review. 
 It would be impossible, or at least very complex to say, reviews for 
topic X go to the IAB while reviews for y go to the the IESG and for Z 
to the ISOC BoT.  And while I think that the ISOC BoT is the reviewer 
of last resort (as they are today for process issues), I don't believe 
they necessarily need to be the reviewer of first resort.

If multi-level reviews are not working well, I think this is a 
different problem to be explored separately, but my view is that the 
IAOC should be slipped into the processes in as compatible a method as 
possible, and I think that following the same escalation procedures as 
are currently in existence is an appropriate approach.


in (6), I agree that decisions that involve contractual obligations 
mustn't be overturned, but I have a problem with saying that there 
are no decisions that can be overturned.
So, how would you make the distinction?  One of the reasons why I'd 
rather see no decisions subject to being overturned is that I don't 
want the IAOC to have an incentive to hide their contract or hiring 
plans from us until after they are signed (and can't be overturned).
I think it is relatively easy to distinguish a contractual obligation 
from a decision that is not contractual, there is a contract.

Now you bring up a good point, what if the IAC uses that as a loophole, 
and make a decision to not be transparent about contractual plans so 
that their decisions cannot be altered.  This would certainly, to my 
mind, qualify as a decision where a successful appeal would force a 
change.  I can imagine many other decision that they could make that 
might also be subject to revision.

My problem with making all decisions unchangeable is that it makes 
appeals toothless, they never can have any real effect.  And I believe 
that this is almost, but not quite, as bad as not having an appeals 
process as it leave no recourse other then recall or public discontent.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Rough consensus? #425 3.5

[avri]

hi,
I generally agree with these principles with some comments:
in (2) I think that the review request need to be addressed to the 
chair of the respective body.  I think the language of 2026 can be 
adapted as to contents.

in (5), I think the appeals should have the full chain of appeals.  I 
know 'at least one level' does include the chain, but I think it is 
important to be able to appeal all the way to the ISOC BoT.

in (6), I agree that decisions that involve contractual obligations 
mustn't be overturned, but I have a problem with saying that there are 
no decisions that can be overturned.

a.
On 25 jan 2005, at 07.29, Margaret Wasserman wrote:
So, I'll take a shot at a few things attributes that I think would be 
good in a review process:

(1) I agree with you that we do not want a review process (whether 
invoked by an individual or by the IAB and IESG) that can overturn a 
contract award or hiring decision after that decision is made.  The 
current proposed text (I think that the latest was from Leslie) makes 
the community impotent, without properly restricting the review 
requests from the IAB/IESG, IMO.

[N.B.  I do hope that the IAOC will run an open RFP process for most 
(or all?) contracts, and that the process will include a public 
comment stage after the IAOC chooses a potential winner, so that there 
will be an opportunity for the community to raise concerns (if any) 
before it is too late.  Given recent posts, I don't think that the 
IASA-TT/IAOC is likely to take us in this direction within the next 
year, but I do hope that we get there eventually.]

(2) I think that the review process should be well-enough specified 
that a person who is not  a (past or present) member of the I* could 
use it.  This means that it needs to say where you send a review 
request, how you unambiguously identify a formal review request and 
what a review request should contain.  This should be at least at the 
level of detail of the RFC 2026 appeals process (or even a bit more 
detailed, as folks seem to find that process confusing enough that 
they don't often get it right).

(3) I think that review requests should be limited to situations where 
the IAOC violates written procedures (their own or the IASA BCP) 
and/or makes a decision that is against the best interests of the 
IETF.  The request for review should be specific about what procedure 
was violated and/or how a specific decision runs against the IETF's 
interests.

(4) Personally, I think that any member of the community (and yes, I 
understand that means the general public) should be able to make a 
formal review request and expect to get a response from the IAOC 
within a reasonable time period (~90 days).  I do not think the 
response needs to be a lengthy hearing, or a complex legal document. 
But, I think that we should have a review process, open to everyone, 
where a response is mandated.  The response could be:  "We looked into 
this decision, and we didn't find anything irregular about the 
decision or about how it was reached".

(5) I think that there should be at least one level of escalation 
possible if the person requesting a review does not receive a 
satisfactory response from the IAOC (I had suggested that this would 
go to the IESG).  I don't think that the person should have to 
persuade the IAB or IESG to act on his/her behalf (which is another 
way in which the current process is really only open to political 
insiders), I think that the IESG (or whoever we use as the next level 
lf escalation) should be required to consider the IAOC's response and 
respond to the escalated review within a reasonable timeframe.

(6) I do not think that we want the IAB or IESG (or anyone else) to be 
able to overturn a decision of the IAOC, only to advise the IAOC that 
they believe that an incorrect decision was made.

Do folks agree with these thoughts?  Are there other basic ideas that 
should be included?

Margaret

At 11:48 AM +0100 1/25/05, Brian E Carpenter wrote:
Sam Hartman wrote:
"Brian" == Brian E Carpenter <[EMAIL PROTECTED]> writes:
 Brian> Reviewing procedures is fine. Reviewing specific awards
 Brian> isn't, IMHO, which is all I intended my words to exclude.
 Attempting to undo a specific award once things are signed (or
 delaying signing) is generally unacceptable.  Reviewing a specific
 award to come to conclusions like "we failed to follow our
 procedures," is definitely problematic but IMHO sometimes necessary.
 Such reviews need to be handled with great care: some of the data 
used
 to make the decision may not be available to the reviewing body and
 much of the data must not become public.  Also, if you conclude that
 you did follow the wrong procedures in a specific incident but are
 stuck with the contract because it is already signed, that creates 
all
 sorts of bad feelings and potential liability.
Exactly. And we need to be sure that the "appeals" text allows for
review of procedures, including the kind of 

Re: A little more feedback? #818 Hiring and firing the IAD

[avri]

I also favor the second wording.
a.
On 24 jan 2005, at 12.26, Harald Tveit Alvestrand wrote:
NEW(2)
Although the IAD is an ISOC employee, he or she works under the
direction of the IAOC. A committee of the IAOC is responsible for
hiring and firing of the IAD, for reviewing the performance and for
setting the compensation of the IAD. The members of this committee are 
appointed by the IAOC, and consist at minimum of the ISOC President, 
the IETF Chair and one IAOC member that has been selected by the 
Nomcom.

I don't see any world-shaking difference between these, but I slightly 
prefer the last one (with nomcom-selected member).

I'd like this one, too, nailed before -05 rolls

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Rough consensus? #425 3.5

[avri]

I suppose that I am one of those at the other end of the scale, looking 
for a solution that allows full and direct IETF community 
review/appeal.

On 23 jan 2005, at 21.35, Spencer Dawkins wrote:
I agree with the idea that there are extremes when we talk about our 
ideas on "review", but please don't assume that JohnK and Michael are 
the only people at that end of the pool...

I had assumed that the IETF would let IASA run things with periodic 
general feedback and rare specific feedback (only in situations when 
the feedback begins "we can't imagine why you ..."). The further we 
move from that end of the spectrum, the less I understand why we need 
an IASA in the first place.
My main reason for supporting the creation of the IAOC specifically, is 
to offload most of the administrative effort from the IESG/IAB.  That 
is also, incidentally one of my reasons for not wanting the IESg/IAB to 
be involved in every review/appeal, but only in those that get 
escalated.  The other reason is that it is the IAOC that will be the 
IETF community's representatives in administration and therefore they 
should be directly responsible to that community.

I agree with the role of IAD becaue I think that job needs to focused 
in one person.  But that does not mean that the person should not be 
accountable to the community.  I know it is harder to do a job with 
accountability and transparency, but I see any other solution as being 
problematic for reasons that have outlined earlier.

I remain in favor of Margaret's formulation as the compromise position 
from what I would truly prefer which is for all IAD/IAOC actions and 
decisions being reviewable in the same manner that the actions and 
decisions of the ADs, IESG and IAB are currently appealable.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Rough consensus? #425 3.5

[avri]

Hi,
The IAD is required to respond to requests for a review from the
IAOC, and the IAOC is required to respond to requests for a review
of a decision from the IAB or from the IESG.
If members of the community feel that they are unjustly denied a
response to a request for review, they may ask the IAB or the IESG
to make the request on their behalf.
I still find the lack of direct accountability to the IETF community 
problematic, though I do realize that this does leave two options open 
to the community in the case that the IAB or IESG does not decide to 
honor someone's request for a review:

- Protest on the IETF list and at plenary and review in the court of 
public opinion; i.e resort to public confrontation.
- Appeal of a decision by the IESG to not ask the IAOC for a review.

I am also assuming that since these appeals would always be procedural 
they would always be appealable through to the ISOC BoT.  So while a 
bit contorted, there is a path for accountability for the public.

The request for review is addressed to the person or body that made
the decision. It is up to that body to decide to make a response,
and on the form of a response.
I do not understand what happens if the IESG/IAB do ask for a review 
and the IAOC gives what they consider an inadequate response.  Is the 
only recourse at that point to initiate a recall? Or to ask the ISOC 
BoT to fire the IAD?
I am troubled that at the end of the day recall is the only way to 
redress an error that those in office may commit.  Since this is such a 
large hammer to use, I expect that it will leave the IAOC and IAD free 
to act with relative impunity.

I know we will be reviewing the procedures over the years, but 
initiating the restructuring without proper mechanisms for 
accountability seem, to me, to be a mistake.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Rough consensus? #425 3.5

[avri]

Hi,
In general I am happy with this formulation.  Some comments below.
On 19 jan 2005, at 09.38, Margaret Wasserman wrote:
--
3.5 Decision review
In the case where someone believes that a decision of the IAD or the 
IAOC
either need an extra phrase here or need to change 'believes that' to 
something like
'objects to'

or add the phrase: 'runs counter to the provisions of RFC ..." or "... 
provisions of this BCP ..."

or maybe: 'is not in the best interests of the IETF'
he or she may ask for a formal review of the decision by sending e-mail
to the IAOC chair.  The request for review is addressed to the IAOC, 
and
should include details of the decision that is being reviewed, an 
explanation
of why the decision should be reviewed, and a suggestion for what 
action
should be taken to rectify the situation.  All requests for review 
will be
published publicly on the IAOC web site.

It is up to the IAOC to determine what level of formal review is 
required
based on the specifics of the request for review.  However, the IAOC is
expected to make some public response to a request for review within
90 days of the request, indicating the findings of the review.

If the IAOC finds that an incorrect or unfair decision was made, it 
will be
up to  the IAOC to decide what type of action, if any, makes sense as a
result.  In many cases, it may not be possible or practical to change 
the
decision (due to signed contracts or business implications), but the 
IAOC
may choose to make changes to its policies or practices to avoid 
similar
mistakes in the future or may simply wish to acknowledge that  a 
mistake
was made and learn from the error.

If a person believes that his or her request for review was not handled
properly or fairly by the IAOC, he or she may escalate the request to 
the
IESG by sending mail to the IETF chair.  The IESG will consider the 
IAOC's
response and may take one of three actions:  (1) indicate that the 
decision
was properly reviewed and the IAOC's response was fair, (2) state why
the review was improper or unfair and offer advice to the IAOC
regarding what type of response or action would be justified, or (3)
determine that there is a problem with the rules governing the IAOC and
propose changes to this document (or other BCPs) to the IETF
community.
In this formulation, I would like to see one further possible step
or (4) refer the issue to the ISOC BoT for further review.
In no case, may the IESG reverse or change a decision of
the IAOC or make a direct change to the IAOC's operating policies.
a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Firing the IAOC (Re: Consensus search: #725 3.4b Appealing decisions)

[avri]

i strongly agree with Carl on this, people serve as individuals.
a.
On 18 jan 2005, at 10.53, Carl Malamud wrote:
Hi -
Just so we're clear, I think a mass execution procedure is a bad idea.
Serial executions are much better: these people got seated one by one,
and if you don't like them, each one should get their own trial and
sentence.
Changing 3777 to allow group trials seems like a task well beyond the
current exercise, which should be focused on how to get the IAOC on
board and functioning.  I fully expect that our founding fodders on
the IAOC will do a great job and that we should focus on building this
particular bridge instead of establishing procedures for burning it 
down.

Regards,
Carl

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Consensus search: #725 3.4b Appealing decisions

[avri]

Hi,
Thanks for the response.
I don't know whether I am in a severe minority on this particular 
position, and hope that my arguments do not come across as a DOS 
attack.  At a certain point I will accept that rough consensus has 
passed this concern by.

To start, I must admit I have trouble equating an individual or 
community's disagreement with a decision to a DOS attack, though I do 
know how disconcerting and distracting an insistent complaint can be.  
I just don't see equating people's concerns with maliciously motivated 
attacks, no matter how persistent or obnoxious.

I also have no problem believing that the better option in any such 
disagreement would be to respond early and with due diligence with a 
public response (accountable and transparent) as opposed to just 
deleting it because it appears frivolous.  I think we need to be very 
careful in defining an objection as frivolous before having given it 
due diligence.  But once having reviewed an issue and publishing a 
response, then there would be no reason to re-review, thus avoiding an 
effect similar to that from a DOS attack.  I think this differs from 
the case of a discussion in a WG since that is an intentional and 
ongoing exchange of ideas, and traction is often difficult to gauge on 
a WG list where the majority remains silent.

I also think that history has shown us that appeals are relatively rare 
and generally not frivolous.  It is for this reason that I advocate 
extending the current model of appeal, with the caveats about not 
voiding contracts etc, to the IAD and IAOC.  I think creating the 
procedure to avoid so called 'DOS attacks' is, in effect, fighting a 
problem we do not have.

a.
On 13 jan 2005, at 13.19, John C Klensin wrote:

--On Thursday, 13 January, 2005 12:06 -0500 [EMAIL PROTECTED] wrote:
Hi,
Either I don't understand it or I don't agree.  I allow that I
don't understand it.
Since the model is partially my fault, let me try to explain.
In the first paragraph it seem like anyone can ask for a
decision to be reviewed.
And a sensible IAOC will initiate reviews after any
well-reasoned and sensible request, especially one that contains
information they didn't consider and should have.   If they
regularly don't, they should be fired.
In subsequent paragraphs it appears that anyone is limited to
IAOC, IAB and IESG members because no one is required to
review the questions of anyone other then those in an I*. And
while someone can ask for help from the IAB/IESG when their
question is ignored, I don't understand why the level of
indirection.  I think that anyone in the community should be
able to go to the IAOC with an issue.
I, Scott, and probably others are very concerned about denial of
service attacks on the IAOC.  We have all seen instances (even
on the IETF and IPR list in the last few weeks) in which
determined people will post small variations on the same
complaints over and over again, never noticing that they aren't
getting any traction in the community.  If the IAOC is required
to respond to every similar note with a formal review, it can
almost be guaranteed that they will get nothing else done.
One way to deal with the problem would be to say "no one gets to
talk to the IAOC other than the IAB or IESG".  That impresses me
as fairly bad news for several reasons.  So I tried to strike a
compromise that says:
(1)  The IAB and IESG get to initiate requests for
review and insist that the IAOC respond.

(2) Any member of the community can initiate a request
for review.  The IAOC gets to decide whether to respond
or to hit "delete".  It isn't explicit in the document,
and I don't think it should be, but an IAOC that blows
off all such requests without any good reason should be
headed for retirement.

(3) If the community member doesn't get the expected
review, he or she gets to mount a mini-appeal to see if
the IESG or IAB can be convinced to endorse the question
and demand a review.  If the IESG or IAB blows off those
requests unreasonably, _they_ ought to be headed for
retirement, using normal mechanisms.
The text seems consistent with that.  If you can suggest better
text, I'm sure the editors would be interested.
I also think it is a work overload issue. In a sense the IAOC
is being created to offload the administrative issues from the
IAB/IESG.  So why buffer them from the public's problems?
I would suggest that if "the public" has a legitimate problem
that the IAOC refuses to address after input and a request from
"the public", then the IETF has a problem and the IAB and IESG
should be aware of it.
I think the IAOC should be required to respond to a request
for review from the IETf community without requiring IAB or
IESG intervention.
As I said, the concern is about denial of service attacks.  One
could, of course, eliminate or reduce that problem by setting up
some procedure requ

Re: Consensus search: #725 3.4b Appealing decisions

[avri]

Hi,
Either I don't understand it or I don't agree.  I allow that I don't 
understand it.

In the first paragraph it seem like anyone can ask for a decision to be 
reviewed.

In subsequent paragraphs it appears that anyone is limited to IAOC, IAB 
and IESG members because no one is required to review the questions of 
anyone other then those in an I*. And while someone can ask for help 
from the IAB/IESG when their question is ignored, I don't understand 
why the level of indirection.  I think that anyone in the community 
should be able to go to the IAOC with an issue.

I also think it is a work overload issue. In a sense the IAOC is being 
created to offload the administrative issues from the IAB/IESG.  So why 
buffer them from the public's problems?

I think the IAOC should be required to respond to a request for review 
from the IETf community without requiring IAB or IESG intervention.

a.
On 13 jan 2005, at 07.27, Harald Tveit Alvestrand wrote:
3.5 Decision review
  In the case where someone questions a decision of the IAD or the
  IAOC, he or she may ask for a formal review of the decision.
  The request for review is addressed to the person or body that made
  the decision. It is up to that body to decide to make a response,
  and on the form of a response.
  The IAD is required to respond to requests for a review from the
  IAOC, and the IAOC is required to respond to requests for a review
  of a decision from the IAB or from the IESG.
  If members of the community feel that they are unjustly denied a
  response to a request for review, they may ask the IAB or the IESG
  to make the request on their behalf.
  Answered requests for review and their responses are made public.
I think that should be enough - the IAD and IAOC can route all 
frivolous requests to /dev/null; the decision of the IESG to not ask 
the IAOC for a review is an IESG action that can be handled in the 
usual way; there is no formal "I can overturn your decision" involved; 
if the IAOC shows a pattern of replying "go away" when a review is 
requested, that becomes a matter of public record, and can be used at 
nomcom time.

Does this seem like a reasonable point on the various scales of 
concern?


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[avri]

On 23 dec 2004, at 20.07, John Leslie wrote:
I'm not so much worried about IESG actually _appealing_ the
decision on where to get bagels as I am about language which seems
to encourage anyone who doesn't like the bagels to _ask_ the IESG
to appeal it.
I don't understand why it is that the IESG would make the appeals (I 
know this was the suggestion).  I think that appeals should continue to 
work as they do now.  First you appeal to the one who made the decision 
you don't like, then you escalate it.  So if I want to appeal the IAD's 
decision, i go to the IAD.  If I am not satisfied with the answer i go 
to the IAOC and then up the food chain (staying with the bagel motif) 
from there.

a.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IASA BCP Conflict of Interest Clause?

[avri]

I think this is sufficient as well.
a.
On 22 dec 2004, at 15.22, Harald Tveit Alvestrand wrote:
"The IAOC will establish and publish rules to handle conflict of 
interest situations".

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Consensus? #746 Section 3.4 - IAOC decision making

[avri]

In general I like this formulation with the following comments:
editorial:  'non-conflicted' bothers me as a term.   I recommend 
something like

  ... a majority of the IAOC who are available and who do not need to 
recuse themselves from the vote.  IAOC votes can be taken in person, by 
teleconference, or by email.

As for the  I would recommend using a quorum rule. e.g. a 
majority of members.

a.
On 22 dec 2004, at 15.19, John C Klensin wrote:
 IAOC decisions are taken by a majority of the
non-conflicted IAOC members who are available to vote in
person, by teleconference, or by email.  However, except
in an emergency situation, no decision may be taken with
less than  of the IAOC available to vote.
Declaration of an emergency requires a 2/3 majority of
the IAOC members available to vote after all members
have been notified of the possibility of that action.
Of course, the "emergency" provision, and the assumption that
people who had conflicts with the substantive matter would not
need to recuse themselves in a vote to declare an emergency,
could be abused.  But abuse of that variety would, I hope, be a
more than sufficient condition for a speedy recall action.
"" could be as simple as "three" or as complicated as
some requirement that at least one person appointed by the IETF
be included on the majority side.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: #720 and #725 - Appeals and IAD autonomy

[avri]

Mostly ok with me.
On 22 dec 2004, at 10.21, Harald Tveit Alvestrand wrote:
Suggested resolution:
1) Make a separate section for the appeals stuff in 3.4 (for clarity), 
so that this becomes section 3.5

2) Change the section to read:
  If someone believes that the IAOC has made a decision that is clearly
  not in the IETF's best interest, he or she can ask the IETF 
leadership
  to investigate the
  matter, using the same procedure as is used for appeals of procedural
  issues in the IETF, starting with the IESG.
Well, if we follow the current process, they should be able to appeal 
directly to the IAOC and then escalate it as normal.

  In cases where appeals concern
  legally-binding actions of the IAOC (hiring, signed contracts, etc.),
  the bodies handling the appeal may advise the IAOC, but are not
  authorized to make or unmake any legally binding agreements on the
  part of IASA.
  In cases where no legally-binding actions are at stake, the bodies
  handling the appeal may nullify the IAOC decision and ask IAOC to 
restart
  its decision process.
Is it necessary to restart the process.  I can imagine cases where it 
would be sufficient to reconsider something that it had failed to 
consider.  I would suggest substituting reconsider for restart.

(mostly suggestion from Margaret)
3) Add the following to the IAOC's role in 3.2:
  The IAOC will hear and respond to concerns from the community about
  the activities of the IASA.
Even though it is slightly redundant, I would like to see it 
specifically include a final clause

 activities of the IASA, including actions by the IAD.
Does this make sense, or are we leaning too far in the "too many 
appeals" direction?
I think it makes sense and that we are not leaning in the 'too many 
appeals' direction.  I believe that the history of appeals, and recalls 
for that matter, show that they are relatively few, especially when 
things are running well.  The process is new, and there may be a flurry 
of initial concerns, and these must be handled well for the community 
to gain confidence in the IASA.

The wording 'hear and respond to' should allow for a light weight but 
due diligence procedure.  We will only enter the domain of appeals, in 
the formal sense of the word, if the community believe that the IAOC is 
not handling this properly.

a.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: No change needed? #717 Open archives of correspondence

[avri]

ah, back to openness issues.  i was wondering when we would get back 
here.

i am fine with this one.
a.
On 22 dec 2004, at 08.20, Harald Tveit Alvestrand wrote:
(note - there are several tickets on openness in general. I am trying 
to close off this one, because it seems to have been debated 
"enough")

Margaret said:
Should the same web site also include a record of all written/legal
correspondence received by or sent by the IAOC (with sections removed
if absolutely necessary for confidentiality)?
A long thread resulted (see tracker), in which Leslie quoted from the 
document:

Transparency: The IETF community shall have complete visibility into
the financial
and legal structure of the ISOC standards activity. In particular, a
detailed budget for the entire standards activity, quarterly financial
reports, and audited annual financial reports shall all be available 
to
the IETF community. In addition, key contract material and MOUs shall
also be publicly available. The IAD and IAOC are responsible for
providing regular overviews of the state of the IASA to the IETF
community.
I think that the consensus on the thread was that the particular 
requirement being proposed was not warranted; I therefore suggest that 
we close this ticket with no change to the document.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: bcp-02: Section 3.4

[avri]

Hi,
On 12 dec 2004, at 15.06, Wijnen, Bert (Bert) wrote:
I guess I am of the "less formal" type of person.
Well, in terms of type of person, I am rather informal myself.  but in 
this case I think we are talking about a process that can serve the 
IETF community and I believe it needs a certain formality.

We can send omcplaints/concerns ot IAOC.
And I just look for a statement under their duties that says they 
receive and act on these complaints/concerns.

We ssume IAOC will handle/act on it
I don't think it is safe to assume.  If assumptions of people doing the 
right thing were always sufficient, we would not need most of the text 
in this BCP.

If they do not, we can start the recall process on them
I would prefer to not have to rely on that big a hammer.
Maybe I am just too simple minded.
Somehow, I doubt that.
a.
Bert
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 12, 2004 15:17
To: Wijnen, Bert (Bert)
Cc: [EMAIL PROTECTED]; Sam Hartman
Subject: Re: bcp-02: Section 3.4
Well,
A letter of complaint requires no response unless there is something
that formalizes the requirement of response.
And if there is no procedure indicating that the IAOC needs to pay
attention to a letter of complain, that decision, i.e the one
to ignore
letters of complain, cannot be appealed.
So, as I see it, without a formalized process of complaint/appeal of
IAD actions we are left with no avenue to deal with problems
other then
by the yearly nomcom process and the IETF list.
On 11 dec 2004, at 22.18, Wijnen, Bert (Bert) wrote:
Avri writes:
Unless I am missing something in the document, there is no
way for a
member of the IETf community to formally ask the IAOC to review the
decisions of the IAD.
Since when would you not be allowed to send an email/complaint to
the IAOC ??
I guess you meant to say that there is not "formal way" to do so,
yeah, that is what i explicitly said.
but we're all adults and we CAN communicate, can we not?
what does being an adult have to do with it?
I don't understand.  The issue is that there is no way to
make the IAOC
take notice of the communication.
I.e. I do not see why we would need to make a formal procedure for
this.
Because the lack of formalization leaves the IETF community without a
means to appeal decisions.  And this decreases the level of
accountability.
And of the things I thought that were driving the entire AdminRest
process was the need for transparency and accountability.  And as I
understand accountability in the IETF, it involves handling appeals
from the IETF community.
a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Draft version of the IAD job announcement from the IASA TT

[avri]

On 16 dec 2004, at 04.18, Kurt Erik Lindqvist wrote:
-BEGIN PGP SIGNED MESSAGE-
  The IETF Administrative Entity
Isn't it the transition team that is seeking the IAD at this point?
is seeking a highly capable individual
  to serve as Administrative Director. You will report to the
  Internet Administrative Oversight Committee (IAOC) be accountable
  to the IETF community. This is a highly visible and very demanding
  job.
Shouldn't we state explicitly that the IAD will be an employee of ISOC?
You will be expected to:
  o Working with the IAOC to document and cater for the administrative
requirements of the IETF, IESG, IAB and IRTF.
cater is a difficult word that ussually refers to food.  I would 
recommend 'provide for'

  o Establish the IASA/IETF annual budgets, and the financial
administration and reporting of IASA/IETF.
These should be established in cooperation with ISOC and IASA.  This 
will not be done in isolation.

   o Work with ISOC and various service providers to establish
appropriate
 agreed budgets and related financial and performance reporting.
  o Contract negotiations with service providers, and establish
procedures for meassuring the performance of these providers.
  o Eventual mangagement of support staff and contractors.
  o Serve as the day-to-day chief operating officer of the IETF,
managing a number of contractors and working with a number of
volunteers.
Have we gone so far as to call this job the COO of the IETF?
Not only is the IETF not an organization that is structured to have a 
COO, but i think giving this position the COO designation may be 
misleading.

  o Work with our liaison organizations, such as the RFC Editor and
the IANA.
liaison?
  o Serve as the primary staff resource for the governing body of the
administrative entity for the IETF.

What does this mean?
  o Work with your contractors and members of the IETF community to
provide adequate support and planning for 3 IETF meetings
annually, and for frequent meetings and teleconferences of the
IAB, IESG, and other bodies that support the IETF.
  The following characteristics are necessary for this job:
  o This job is public service. You should be able to work
successfully with large numbers of people. This requires a high
clock rate, a large stack,
Well, i understand how you would measure these thing in a robot, but I 
am not sure how to determine these capabilities in a human.  I think, 
it might be better to refer to  these attributes in human terms; 
something like the ability to handle a multitude of simultaneous tasks.

and the ability to listen carefully.

  o This is an operations job. IETF meetings are large and complex,
and the day-to-day activities of the standards-making process is
demanding. You should be adept at getting real results and
helping large groups work together towards common goals and
deadlines.
should we mention that the nature of working together is consensus 
based?

  o This is a public job. You will be required to present the
results and achievements of the IASA in front of the community
as well as dealing with questions from individual members of the
community. The goal of IASA is to achieve as much transparency
and accountability?
as possible so good communication skills, and previous similar
experiences are valued.
  o This job requires a financially astute individual. The IETF is a
$2-$3 million/year operation. IETF funds are tight and we expect
you to take leadership in establishing our budgetary procedures,
our procurement standards, and understanding our revenue sources.
  In-depth familiarity with the IETF prior to assuming this position is
  not required, but you must be able to quickly get up to speed and
  learn the unique culture and requirements of the organization.
Should we require experience in running a similar type of operation?
  Likewise, long-term technical experience is not required, but you
  must be a quick learner and adept at using the Internet effectively.
  The Internet Society is based in Reston, Virginia and the job will
  require a high level of travel for IETF meetings and preparation and
  related meetings.
  You may work out of a home office as a telecommuter, or use the
  Internet Society facilities in Virginia. In either case, you should
  be prepared to travel to Virginia, IETF meetings, and the locations
  where the IETF has contractors.
  Salary levels commensurate with experience and qualifications.
you might want to ask applicants to state salary requirements
  You must be fluent in spoken and written english.
  Applicants should forward a resume, references,
should ask for a certain number of references
and any other
  relevant materials, with a cover letter explaining why they feel they
  are the right person for this position written in text or PDF, in an
  email sent to [EMAIL PROTECTED]
  Applications will be evaluated starting January 

Re: Assuring ISOC commitment to AdminRest

[avri]

On 12 dec 2004, at 22.40, Dave Crocker wrote:
This is probably not what either one of them is thinking about, but I 
class their exchange as being concerned with the following question:

		Is the IETF making itself a wholly-owned subsidiary of ISOC, or is 
the IETF contracting with ISOC to do some services for the IETF.
Since I think it is neither of those, I suggest a third possibility
are the IETF and ISOC agreeing on a partnership in the administration 
of the IETF?

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: bcp-02: Section 3.4

[avri]

Well,
A letter of complaint requires no response unless there is something 
that formalizes the requirement of response.

And if there is no procedure indicating that the IAOC needs to pay 
attention to a letter of complain, that decision, i.e the one to ignore 
letters of complain, cannot be appealed.

So, as I see it, without a formalized process of complaint/appeal of 
IAD actions we are left with no avenue to deal with problems other then 
by the yearly nomcom process and the IETF list.

On 11 dec 2004, at 22.18, Wijnen, Bert (Bert) wrote:
Avri writes:
Unless I am missing something in the document, there is no way for a
member of the IETf community to formally ask the IAOC to review the
decisions of the IAD.
Since when would you not be allowed to send an email/complaint to
the IAOC ??
I guess you meant to say that there is not "formal way" to do so,
yeah, that is what i explicitly said.
but we're all adults and we CAN communicate, can we not?
what does being an adult have to do with it?
I don't understand.  The issue is that there is no way to make the IAOC 
take notice of the communication.

I.e. I do not see why we would need to make a formal procedure for
this.
Because the lack of formalization leaves the IETF community without a 
means to appeal decisions.  And this decreases the level of 
accountability.

And of the things I thought that were driving the entire AdminRest 
process was the need for transparency and accountability.  And as I 
understand accountability in the IETF, it involves handling appeals 
from the IETF community.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: bcp-02: Section 3.4

[avri]

I tend to agree. As I mentioned in another note, I too am uncomfortable 
with the appeal procedures.

In my case, I am not so much concerned about the ability to overturn 
decisions, such as contracts that are signed, as I have accepted that 
allowing this might make the job impossible.  But I am concerned about 
the inability for the IETF community to invoke censure against an IAD 
who persists in making contractual arrangements that the IETF community 
finds unacceptable.

Unless I am missing something in the document, there is no way for a 
member of the IETf community to formally ask the IAOC to review the 
decisions of the IAD.  And while it is possible to lodge an appeal 
against the IAOC for not supervising the IAD properly, I think this may 
be a bit too roundabout.

a.
On 10 dec 2004, at 10.55, Sam Hartman wrote:
I'm not very comfortable with the appeal text in section 3.4.  There
isn't a way to overturn decisions and there is no way to appeal
decisions because the wrong decision was made.
I understand why the current text is there.  I understand there are
significant concerns about having either of the things I'd like to see
in an appeal system.
I will try and think of constructive ways of getting better
appealability without destroying the IASA's ability to do its job.
I'm also not sure how uncomfortable I am with the current text.  I
know I don't like it, but it's hard to tell how strong that feeling
is.
--Sam
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Procedural question on iasa-bcp-02 Last Call (was: Re: Consensus? Separate bank account)

[avri]

Hi,
I agree it does seem procedurally a little skewed.
But in thinking about it, I feel that this may not end up a problem as 
long as one thing happens.  That is, if -03 (the 02-bis you refer to) 
is different in any substantive manner, i.e. other then editorial, it 
will need to go through a second call before the IESG can decide on it. 
 I.e,, as you said, as soon as an -03 that is substantially different 
comes out, the LC clock restarts.

I think getting this into wider community review, i.e. due to LC, is a 
good thing to do at this point, even while some of us, myself included, 
continue to argue on particular points we are uncomfortable with.

a.
On 11 dec 2004, at 00.26, John C Klensin wrote:
Harald,
This is purely a procedural question, but my interpretation of
the note below and the general support your suggestion has
gotten is that the document that is actually being last-called
is not draft-ietf-iasa-bcp-02.txt, as identified in the Last
Call posted yesterday afternoon, but a hypothetical document,
draft-ietf-iasa-bcp-02-bis.txt, which consists of the I-D as
modified by assorted comments and agreements on the IETF mailing
list or perhaps elsewhere.
Is that your intent?
If so, I am at least mildly concerned: normally, we have Last
Call reviews against stable documents, not documents that are
still actively changing, much less virtual documents in which
significant  changes are being made out of band and in a way
that is very hard for someone casually participating in the IETF
to track.  Do you have a better suggestion?  Can  we expect a
-03 for final review halfway through the Last Call window, with
the window being restarted if the changes are significant enough?
 john

--On Wednesday, 08 December, 2004 23:11 +0100 Harald Tveit
Alvestrand <[EMAIL PROTECTED]> wrote:
After all this threading, it seems clear that it would be bad
to send out the Last Call today as planned without settling
this issue.
(Not to mention that the secretariat still hasn't posted
version -02)
So - scanning back - I find that we have Bert's suggestion for
"principle" that seems to have met with no strong disfavour:
   Once funds or in-kind donations have been credited to the
IETF accounts,
   they shall be irrevocably allocated to the support of the
IETF.
(Scott preferred my variant:
Donations to the IETF shall be irrevocably committed to
the support of
the IETF
but I don't - this does not cover meeting fees)
So I propose the following consensus text - relative to
bcp-02, which is visible on
:
a) Add under "Principles", section 2.2, between item 4 and 5:
   Once funds or in-kind donations have been credited to the
IETF accounts,
   they shall be irrevocably allocated to the support of the
IETF.
b) Note, but DO NOT CHANGE, the following statements from
section 5.
I believe they address the suggestions Margaret has made for a
more detailed specification of money moving into and out of
the accounts.
5.2 IETF Meeting Revenues
Meeting revenues are an important source of funds for IETF
functions. The IAD, in consultation with the IAOC, sets the
meeting fees as part of the budgeting process. All meeting
revenues shall be credited to the appropriate IASA account.
5.3 Designated Donations, Monetary and In-Kind
.
ISOC shall create appropriate administrative structures to
coordinate such donations with the IASA. In-kind resources are
owned by the ISOC on behalf of the IETF and shall be reported
and accounted for in a manner that identifies them as such.
Designated monetary donations shall be credited to the
appropriate IASA account.
5.4 Other ISOC Support
Other ISOC support shall be based on the budget process as
specified in Section 6. ISOC shall credit the appropriate IASA
accounts at least quarterly.

5.5 IASA Expenses
The IASA exists to support the IETF. Therefore, only expenses
related to supporting the IETF may be debited from the IASA
account.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: iasa-bcp-01 - Open Issues - Separate bank accounts

[avri]

On 8 dec 2004, at 10.20, Harald Tveit Alvestrand wrote:
"Donations to the IETF shall be irrevocably committed to the support 
of the IETF".
I am not sure I understand what it means.  i.e. are you trying to say 
that

 donations to the IETF are to be allocated to the IETF's budget and may 
not be reallocated to another budget?

or is there some other content?
a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

iasa-bcp-02 - Issues with IAD autonomy

[avri]

Hi,
For the most part I am happy with the way the document is turning out.  
In reading through -02, though, I am still somewhat uncomfortable with 
the autonomy of the IAD

While there is a method to appeal procedural lapses by the IAOC, and I 
am fine with that, there does not seem to be a way for a member of the 
community to question, i.e. appeal, the actions of the IAD. I.e. 3.4 
does not contain method to appeal the actions of the IAD for procedural 
issues or suspected malfeasance.

I think there should be an explicit responsibility on the IAOC to 
review any complaints members of the community bring up against the 
IAD.  I have no problem with them throwing out the frivolous ones or 
the ones that say 'he or she picked my competitor,' but it should be 
possible for members of the community, or of the leadership, to have 
grievances heard.  And then, if the community is not satisfied with the 
procedure the IAOC followed in handling the complain, they have 
recourse to section 3.4.

possible wording:
- To review and act on complaints regarding the IAD's performance from 
the IETF community.

I know this gives the community the right to complain about anything, 
but it also empowers the IAOC to act on it - including dispose of 
spurious claims.

On this list there has been some conversation that we don't want the 
powers that be to be overburdened by having to handle many complaints 
against the IAD for contracts someone might not agree with.  While I 
mostly agree with this position, it should be possible for someone who 
knows a contract was given in return for a kickback, or just for the 
love of a family member, to file a complaint with some entity who will 
review it impartially and act on it.

Additionally:
 To review the IAD's plans and contracts to  ensure that they will 
meet the  administrative needs of the IETF.
Can this be amended to '... ensure they meet the procedural 
requirements and the administrative ...'

And from section 3.2 3rd paragrapgh.
 The IAOC's role is to direct and review,
At the very least, I think this should be '"direct, review and approve"
thanks
a.
ps. editorial questions from the same section:

 To select the IAD and provide high-level  review and direction for 
his or her work.  This task should be handled by a  sub-committee, as 
described in Section 3.
is this a proper self-reference?  should the reference be more specific?

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Consensus? IPR rights and all that

[avri]

I understand that there may be conflicting claims on the current IPR, 
but isn't the document about the future and about the conditions under 
which new sw, tools and data would be contracted.  I don't understand 
why a discussion of past IPR, or the claims on its ownership, would be 
a subject for this BCP.

Or, is the suggestion, to put a statement in somewhere that the IASA is 
responsible for negotiating to obtain the same rights on all relevant 
IPR created in the past that it requires for all future IPR.

a.
On 7 dec 2004, at 03.41, Bob Kahn wrote:
Harald,
I am enroute back to Washington at the moment, but did want to comment 
on IP matters.

I think it fair to state in the document what the IETF thinks 
appropriate for it to manage its own affairs going forward, but one of 
the matters we will have to work out is the fact that there is 
considerable IP generated over the past almost twenty years. At 
present, CNRI owns most of this IP, but the US Government may have 
certain continuing rights in the data as well.

As you know, I have committed publicly to working with the IETF on the 
administrative restructuring issues. Over the coming year, I hope we 
can work out how best to handle matters such these, but at best the 
document ought to recognize this fact of life and that it will be 
necessary to address these matters in due course going forward.

bob
At 04:29 AM 12/6/2004, Harald Tveit Alvestrand wrote:
Hi folks,
it seems that we are drawing close to a consensus here:
- Access to data that the IETF has created and needs to function is a 
paramount basic principle. Not to be compromised. So it needs to go 
VERY plainly into section 2.2 "principles".

- Access to software is a very-nice-to-have, but it's only critical 
if not having it limits our ability to effectively access the data. 
And open-source is a quite-nice-to-have; we see a number of 
advantages in doing things that way, but there may be cases where 
other considerations apply. So this belongs in the document, but 
under "advice", not "principles".

So - I'd like to propose a specific text change to address that:
Replace the current section from 2.2 that says:
  6.  The right to use any intellectual property rights created by any
  IASA-related or IETF activity may not be withheld or limited in
  any way by ISOC from the IETF.
with the following:
  6.  The IASA, on behalf of the IETF, shall have an irrevocable,
  permanent right of access and later use to all data created
  in support of the IETF's activities, including
  the right to disclose it to other parties of its choosing.
And in section 3.1 "IAD Responsibilities", add after paragraph 4 
("The IAD negotiates service contracts"):

 The IAD is responsible for ensuring that all contracts give the IASA
 and the IETF the rights in data that is needed to satisfy the 
principle
 of data access.
 This is needed to make sure the IETF
 has access to the data it needs at all times, and that the IASA can
 change contractors when needed without disrupting IETF work.
 If software is developed under an IASA contract, the software should
 remain usable by the IETF beyond the terms of the contract; this may
 be accomplished by IASA ownership or an open source license; an open
 source license is preferable. The IAD will decide how the interest of
 the IETF is best served when making such contracts.

Note: I have tried to write the sentences above without using any of 
the legal terms "copyright", "ownership" or "work for hire" - these 
are all terms of art that I know I don't fully understand, and I 
believe it's possible to state the principles without using those 
terms.

Reasonable?
Harald

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: section 3.5b (appealability)

[avri]

OK, I am open to the idea.  And I suppose that the current appeal 
mechanisms would allow it.

But in that case I do have a problem with making the barrier higher for 
appeals originating from a non IOAC member.  While I can see arguments 
for not removing an IAOC's member's right of appeal, I don't see any 
arguments that should give them any greater right of appeal.  I.e. I 
would have difficulty supporting a mechanism that weighed 1 IAOC member 
versus 10 non members as suggested in your original message.

Allow appeals to be made but set some bar for an appeal; perhaps
   appeals from IAOC members are always accepted, but appeals from the
   community require say 10 signatures.

a.
On 3 dec 2004, at 22.44, Sam Hartman wrote:
"avri" == avri  <[EMAIL PROTECTED]> writes:
avri> And I don't think we want to get into a situation where we
avri> have one member of the IAOC appealing the actions of the
avri> IAOC.
I do.  Or rather in cases where that happens, I'd treat the appeal
very seriously.  Being reasonable is one of the criteria we use for
selecting our leadership.  If that leadership still feels a decision
is worth appealing even knowing the consequences and pain of such an
appeal, then I'm very interested in what they have to say.


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: created IPR

[avri]

While I support the use of open source software whenever possible, it 
seems too restrictive to mandate it in the BCP on the IASA operation.   
I am not even sure that this level of detail belongs in this doc at 
all, though it may belong in a set of recommendations to the IAOC.

a.
On 3 dec 2004, at 16.37, Henrik Levkowetz wrote:

   restriction by the contractor.  Software should be open source 
and
"should be open source" ??
It does leave open that it is not mandatory. But it still sounds as
a very strong statement. If a contractor develops specific software
for us, I'd be OK if we can get it at any time for IETF use, but I am
not sure we should require it to be or become open source should we?
There are two issues here, one practical and one philosophical.
Practically, if we can use it, but don't have the source code, we
cannot take it to someone else and ask them to add new functionality.
Asking someone else to provide an enhanced version of the tool would
mean starting implementation from scratch.  But this doesn't mean
that the source needs to be open, it means that the IETF needs to
have ownership of the source.
Philosophically, I would suggest that it might be more in line with
the spirit of the IETF to go for open source, and (a different point)
I would personally find it desirable.  Having IETF-developed
software as open source also neatly bypasses any future controversy
about ownership, stewardship and whatnot, which I find appealing.
I'm not sure I see any strong reasons for us not going this route.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: section 3.5b (appealability)

[avri]

On 3 dec 2004, at 16.28, Sam Hartman wrote:
2) Allow appeals to be made but set some bar for an appeal; perhaps
   appeals from IAOC members are always accepted, but appeals from the
   community require say 10 signatures.
Since the IAOC is the oversight body, why would they need to appeal the 
actions of the IAD?  Don't they just have the right of adjudication of 
any process failure by IAD ?

And I don't think we want to get into a situation where we have one 
member of the IAOC appealing the actions of the IAOC.

BTW, I was just rereading the formulation sent by Harald.  the one I 
said I was comfortable with:

If someone believes that the IAOC has violated the IAOC rules and 
procedures, he or she can ask the IETF leadership to investigate the 
matter, using the same procedure as is used for appeals of procedural 
issues in the IETF, starting with the IESG.

If the IESG, IAB or the ISOC BoT find that procedures are violated, 
they may advise the IAOC, but does not have authority to overturn or 
change a decision.
while it makes sense for the IAOC, it does not cover someone, not from 
the IAOC, appealing a procedural issue of the IAD.  I think there needs 
to be a way for someone to initiate an appeal with the IAOC against the 
IAD.

a.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: section 3.4

[avri]

this formulation works for me.
thanks.
a.
On 3 dec 2004, at 11.16, Wijnen, Bert (Bert) wrote:
   3.4  Relationship of the IAOC to Existing IETF Leadership
   The IAOC is directly accountable to the IETF community for the
   performance of the IASA.  However, the nature of the IAOC's work
   involves treating the IESG and IAB as major internal customers
   of the administrative support.  The IAOC and the IAD should not
   consider their work successful unless the IESG and IAB are also
   satisfied with the administrative support that the IETF is
   receiving.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: section 3.5b (appealability)

[avri]

Seems like a reasonable way to approach it.
a.
On 3 dec 2004, at 09.19, Harald Tveit Alvestrand wrote:
In some other argument in some alternate universe, I said about the 
appeals issue:

I see three alternatives:
- Individual decisions of the IAOC cannot be appealed/reviewed by 
anyone
- We invent an entirely new process from scratch just for IAOC matters
- We funnel appeals against IAOC into the existing appeals process

I dislike the first and second choices (the first because it raises 
the
risk that one will have to resort to the recall "control"; the second
because inventing new process mechanism is *hard*), so by Hobson's
choice, I like the third.
A theory
if "decisions of the IAOC can be appealed" rather reads:
--
If someone believes that the IAOC has violated the IAOC rules and 
procedures, he or she can ask the IETF leadership to investigate the 
matter, using the same procedure as is used for appeals of procedural 
issues in the IETF, starting with the IESG.

If the IESG, IAB or the ISOC BoT find that procedures are violated, 
they may advise the IAOC, but does not have authority to overturn or 
change a decision.
--

I remember that 2026 rather carefully circumscribed the power of the 
appeals process - the IAB can nullify an IESG decision, but cannot 
make the IESG make a different one. In this case, I think that maybe 
the process should be even more circumscribed - if the decision is 
"hire an IAD", and the appeal is something like "you made the right 
choice, but did not file proper paperwork", nullifying the hire would 
make the situation for the newly hired IAD quite confusing.

Does this make some kind of sense?
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: iasa-bcp-01 - Open Issues - Startup Phase

[avri]

On 2 dec 2004, at 23.00, Scott Bradner wrote:
This leaves any minuted decision in limbo for another
meeting interval.
I do not understand - in all boards I've been a part of the
decision is the decision, the minutes just report the decision - it
does not matter when the minutes get approved, the decision was
made when teh decision was made (e.g. when teh board voted)
Yes, and no.  It is true that the decision is the decision.  But in the 
Boards I have been involved in, until the minutes are approved at the 
next meeting, they are not official and thus anything can be disputed 
and one can (and perhaps not in the ISOC's history but within my 
experience) argue that a decision the previous meeting was not made 
properly or not recorded properly.

It is a small thing, but on something this important, I would like to 
see a formal statement of acceptance and not rely on minutes.  I do not 
understand why asking for a response document committing the ISOC BOT 
to the BCP is a problem?

BTW, are the ISOC minutes all public?  And how long do they take to 
show up.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

iasa-bcp-01 - Open Issues - Pre-nuptials

[avri]

I tend to think that we should go into this arrangement with an 
attitude of trust.  Certainly we should try to get the document as 
specific and accurate as possible, and should leave open the process 
for future updates to the BCP, but I do not think we need explosive 
bolts or any other prearranged separation model.

Having chosen Scenario 0, we have opted for the simplest of the 
solutions.  Any escape clause, other then a statement that the 
agreement can be amended upon consensus of the IETF and agreement of 
the ISOC BoT (the current situation for any process BCP) would reopen 
much of the complexity we decided to avoid in selecting this Scenario.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

iasa-bcp-01 - Open Issues - Startup Phase

[avri]

Not sure if this refers to what I said in an earlier not about 
indicating when the process goes into effect.

Harald indicated that process BCP approval is indicated by an 
indication in the ISOC BoT minutes that the BCP was acceptable.

I have a slight problem with minutes as the criteria.  In boards I have 
served on, minutes are not formal records until they are approved at a 
later meeting.  This leaves any minuted decision in limbo for another 
meeting interval.  For most decisions this is not a big deal.  In this 
case, I think it is somewhat more significant.

Additionally, while the ISOC BoT approves process BCPs, normally they 
do not place any conditions on ISOC actions.  In this case, the IASA 
BCP does require specific actions  from the ISOC BoT.

In this case, I think a ISOC BOT approved document, or official 
resolution, that calls out this BCP and indicates in clear language its 
agreement with the terms and conditions of the BCP would be helpful.

I would suggest a section at the front that says something like:.
--
#. Effective date for commencement of IASA
The procedures in this document will become operational immediately 
after this document has been approved by the process defined in BCP 9 
and has been affirmed by a Resolution of agreement by the ISOC board of 
Trustees.
--

(alternatively 'immediately after' can be replaced by 'the first day of 
the following month' or whatever legal/accounting starting point makes 
sense.)

As I said in a previous email, I trust the ISOC to do the right thing, 
but I prefer to put our trust in the hands of someone who explicitly 
accepts the terms under which we grant that trust.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

iasa-bcp-01 - Open Issues - Separate bank accounts

[avri]

In thinking about this, I think about the fungibility of funds.
By having a common account, cash flow issues that might be an issue at 
various points of the year can be dealt with more easily.  For example 
if funds are earmarked for meeting fees, but collections have not come 
in time for the year's first meeting, it is simpler to deal with when 
the funds come from a common account.

On the other hand, transparency requires the ability to inspect the 
accounts that are pertinent to the IETF, its budget vs it projected 
expenditure vs its actual expenditures.  This can, I believe, be 
adequately handled by so-called 'divisional accounting'.

a.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: section 3.5b (appealability)

[avri]

I tend to feel that both the decisions of the IAD and of the IAOC 
should be appealable.

My thinking tends toward thinking that anyone should be able to appeal 
the decision, or any practice including the accounting practices, of 
the IAD.  I believe we are defining high standards of transparency, as 
I think we should, but transparency without recourse can be 
problematic.

I think anyone, or perhaps any group of people, should be able to 
appeal IAD actions to the IAOC.

the chain of appeal could be either:
a. the normal iaoc-iesg-iab-isoc bot
b. iaoc - a joint iab/iesg appeals committee (that excluded iaoc 
members) set up to hear the appeal - isoc bot
c. an abbreviated chain iaoc-isoc bot

As for the IAOC, I believe their actions should be appealable as well 
and should use the same chain as an IAD appeal.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: IASA BCP: Separability

[avri]

On 1 dec 2004, at 22.35, Sam Hartman wrote:
I had sort of assumed this BCP would be the MOU to the extent that one
existed.
I think that there has to be an equivalent document on the ISOC side as 
indicated by Geoff, i.e. a document indicating acceptance of the BCP as 
governing the relationship.  And these documents should take effect at 
essentially the same time.

Since, ISOC, under current rules, if I understand them correctly, needs 
to approve BCP's that change IETF processes, it should be easy for the 
two documents to be approved, and thus put into effect, simultaneously.

Perhaps there should be wording in this document indicating how and 
when it takes effect.

a.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: AdminRest: IASA BCP: Executive Director

[avri]

seems reasonable to me as well.  including the recommended change.
a.
On 29 nov 2004, at 15.07, scott bradner wrote:
Harald suggests:
   The IAOC, in consultation with the IAB and the IESG,
   will designate the person(s) to carry out the tasks that
   other IETF process documents say are carried out by the
   IETF Executive Director.
makes sense to me (I would remove the word "other" on the 3rd line 
though)

Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Reminder: Poll about restructuring options

[avri]

Hi,
While I agree that the poll should have provided more options, such as:
  - neither 0 nor c
  - indifferent
  - need more info/discussion
The fact that it does include a box for comments mitigates the absence 
somewhat.  Especially if in reporting the results, the comments are 
included as well (without attribution).

But yes, a poll needs better design for full validity.
a.
On 28 sep 2004, at 12.41, Dave Crocker wrote:
It is very unlikely that there is any language on this planet
that would equate ""No, I do not wish to state an opinion" with
"I wish to state an opinion but you have no provided a category
that covers my opinion".
What is normal for surveys that wish to represent the responses
of those who are not represented by the provided categories is
"none of the above".  And there is no language on this planet
that would equate "none of the above" with "No, I do not wish to
state an opinion".
More generally, you should review John Klensin's brief comments
on this thread.  Your response to him suggests that you did not
understand his point.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Poll: Restructuring questions

[avri]

On 24 sep 2004, at 11.20, Harald Tveit Alvestrand wrote:
So please - take a look, and tell us that you're listening.


I think the poll was a good idea, I hope lots of people take it.  I 
know I had been reading and generally agreeing with some of the folks 
and the poll is a good forcing function for response.

Since my comments are slightly longer then short:
I agree with those who are arguing for Scenario 0 and agree with most 
of the arguments, about complexity and timing.  I also believe that a 
version of C remains a possibility in the future should scenario 0 not 
work.  Though I think it could.

I also agree with those who argue that we need an accurate job 
description for the IAD, and need it soon.  I think the startup process 
seems reasonable.  the timing is challenging, but I believe it could be 
done with lots of hard work and lots of good will.

I also agree that 2 IAOC members should be selected by Nomcom - I have 
argued before why I consider then qualified to chose.  I would have 
argued for more, since I believe that 1/2 of the IAOC should be nomcom 
selected.  However, since I agree with those who argue that the IETF 
chair and the IAB chair should be voting members of the IAOC,  that 
would mean that 4 of the participants were chosen by a Nomcom process, 
and that seems a good enough balance.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Administrative Reorganization: What was that problem anyway?

[avri]

On 14 sep 2004, at 17.12, John C Klensin wrote:
(ii) Nomcom appointments to IETF volunteer technical/
standards process leadership positions are not expected to
require that candidates have significant administrative
or financial skills, nor are candidates expected to acquire
those skills on appointment.

I want to take exception to this criteria.
I think I may have more faith in the ability of the nomcom process to 
chose leaders with the required skills for supervising the 
administrative and financial function.

It is probably true that the Nomcom has not included the significant 
administrative or financial oversight skills in the requirements it 
used for selecting the leadership.  But, that is largely because it has 
not been asked to.

In my experience with various Nomcom groups, when an issue was made of 
the ability of IESG candidates to function as second level managers, 
i.e. to manage the WG chairs without needing manage the working groups 
themselves, the Nomcom did include deliberation of these abilities in 
its decision making. Reasonable people can certainly disagree on how 
successful they have been, but that is the case in any search or 
employment committee process.

The rules for Nomcom include the requirement that the IAB and IESG 
supply the Nomcom with a list of capabilities that they expected in 
each role being discussed.  It is certainly reasonable that this list 
of capabilities for the IESG chair include the ability to oversee the 
administrative and financial functions.  And while the Nomcom does not 
pick the IAB chair, it has, in my experience, discussed the 
requirements for an IAB chair and has made sure that one, or more, 
candidates had the expected qualities - though of course they could not 
guarantee the selection of that person by the IAB.

Another point has been made that this is an engineering group and that 
we don't have these skills within the community.  I think that looking 
at the outside world education and experience of people in the IETF 
community should dispel that notion.  Among the technical contributors, 
using HA's broad definitions of technical contributor, are people 
trained as lawyers, accountants as well as MBAs (not to mentions the 
economists, ethicists, sociologists, psychologists and ...).  Among the 
community of contributors one also finds those whose resumes include 
jobs such senior manager (including CEO), administrators, and analysts 
(financial as well as technical).  And finally, in other organizations 
I have been involved with one does find engineers appointed to jobs 
like President, Secretary and Treasurer who acquired the necessary 
skills upon appointment and who did an admirable job in their 
positions.

A final point on the ability of nomcom to consider the necessary 
qualities for administrative and financial oversight has to do with the 
role of the liaisons to the Nomcom.  While these folks, in my 
interpretation, are not supposed to influence the selection itself, 
they are certainly able to help in understanding requirements.  The 
addition of the ISOC liaison will help widen the requirements that are 
understood.  And it does not take too much of a stretch to imagine the 
Nomcom inviting a liaison from the Administrative entity for further 
broadening its understanding of requirements when selecting people 
capable of administrative and financial oversight.

To respond to a related comment made by Brian Carpenter:
Secondly, I would add three other people with both IETF experience
and some degree of management and business experience. I'm worried
about loading the RFC 3777 NomCom with this since they already have
a big, and rather different, job. So I'd be inclined to give
this selection job to the IAB, but using a Nomcom-like procedure.
While I agree that the Nomcom job is big and this would make it bigger, 
I don't believe it is beyond their ability, my experience with Nomcom 
convinces me of that.  One should also note that while the Nomcom works 
hard for about 3 months, it does very little the rest of its term. If 
the assignments were staggered so that the timing for selecting members 
of the BoD was offset by 6 months, they would have the time.  One could 
ask whether this would discourage volunteers, but I suspect it would 
not.

As for it being a different job, I don't agree.  The requirements and 
qualifications may be different, but I believe the job of making a 
selection is similar and I believe the Nomcom is up to the task.  And 
given that the Nomcom is the community's vehicle for participation in 
the selection of its leadership, I believe it should be used for this 
segment of the leadership as well.

Of course I do agree in one respect that RFC3777 would need an annex (I 
would recommend a separate RFC that amended/added as opposed to 
reopening RFC3777 at this point) to cover this process and a method by 
which the BoD selections would be approved.  In this case, my f

Re: What we need done (Re: first steps (was The other parts of the report...))

[avri]

On 12 sep 2004, at 16.39, Harald Tveit Alvestrand wrote:
The things that we need done in the "clerk's office" aren't actually 
that novel. It's basic workplan management and document management, 
for the most part. Scale and the responsiveness of participants may be 
different from other organizations - but not THAT different.

I tend to agree with this.  Having worked in other organizations, while 
some of the details may be different the overall scope of 
administrative work appears very similar.  sure, someone would have to 
adapt to the IETF culture, but that is what they get paid for.

Having said that, I am concerned about the amount of time left in 2004 
for finding a new group to do the secretariat work by 2005.  I think we 
need to do a proper search, assuming one hasn't already been done in 
parallel, receive bids, evaluate them, discuss contracts and have a 
transition period.  I do agree with those who have argued that some 
aspects of the administrative function might be RFP'ed out separately 
in the very near future, but think that attempting to RFP the core 
services in time for 2005 continuity is a risk.  I guess this means I 
support strategy 3.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Functional differentiation and administrative restructuring

[avri]

Hi John,
No problem, my skin is not that thin.  As i have tried to explain on 
the IETF list, i think we need to understand all options including 
these two extremes - the ones not specifically covered in the mud 
document.  I find the models expressed in the document somewhat 
incomplete and slightly disingenuous in that they don't discuss the 
implications of the end of the road - as far as i can tell they hand 
wave about 'extraneous' results.  And while I have never managed to get 
invovled in the policy part of IETF+ISOC, it is something i care about 
quite a bit.

So if my notes provoke the discussion, even in the form of 'rants', i 
am satisfied.

And thanks for the apology.
a.
ps. i don't have the negative connotations to absorbtion that you do.  
I see that as another term for merger, though, since ISOC is the real 
entity from a corporate point of view, it would constitute an 
absortion.  It is the conditions, as in by-law changes and perhaps 
MOUs, that determine whether this is beneficial or destructive.

On 8 sep 2004, at 09.41, John C Klensin wrote:

--On Wednesday, 08 September, 2004 08:53 -0400 [EMAIL PROTECTED]
wrote:
Hi John,
Thanks for you analysis.  It was something I felt lacking and
has helping me in my wavering between the absorption into ISOC
model and the independent corporate model.
I look forward to your analysis of the absorption model.
Avri, I want to apologize in advance for using your note as the
excuse for the rant below.   You are certainly not the first
person to do this and probably won't be the last; your note just
arrived at a convenient time.

I think we need to be very careful about slapping labels of
convenience on options and then getting distracted by what those
labels "mean".  Doing so can really distract from a productive
discussion in which information is exchanged.There has been
a lot of that sort of distraction, and the associated confusion,
going on, since even before San Diego.
"Absorption" is a loaded term.  If we are asked "how would you
like to be absorbed into foo", the answer has got to be "no".
For me, at least, the recurring image is some rather unpleasant
(for the food) digestion process.  But, to my knowledge, no one
has seriously proposed anything of the sort.   Certainly the
standards process has not been "absorbed".   I doubt that the
RFC Editor staff would consider themselves "absorbed".  There
are unincorporated organizations in addition than the IETF which
have worked closely with ISOC for years and haven't been
"absorbed" either.
And "independent corporate model", while less loaded
semantically (at least for me), is almost equally bad: to the
best of my knowledge, no one has really seriously proposed that
either, since "independent" would imply "own fundraising" and
presumably untangling the standards model which is now seriously
intertwined with ISOC.   As long as critical pieces of those
things remain in ISOC's hands, we aren't "independent" in any of
the normal senses of that term.

john



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Functional differentiation and administrative restructuring

[avri]

Hi John,
Thanks for you analysis.  It was something I felt lacking and has 
helping me in my wavering between the absorption into ISOC model and 
the independent corporate model.

I look forward to your analysis of the absorption model.
a.
On 8 sep 2004, at 01.28, John C Klensin wrote:
But,
from a risk analysis standpoint, even the abbreviated list above
is a pretty long list.  If any one of those assumptions (or any
of several of those not listed) is not met and things go
seriously wrong, the odds of the standards process grinding to a
complete halt -- think "no meetings", "no IESG phone calls",
and/or "even less functional mailing lists and archives" as
examples-- are non-trivial.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Options for IETF administrative restructuring

[avri]

On 7 sep 2004, at 02.13, Brian E Carpenter wrote:
[EMAIL PROTECTED] wrote:

I'm very puzzled. I though those two extremes were exactly described
by scenarios A and D.
Perhaps I misread, but while I saw that A and D are the extremes of the 
scenarios represented to date, I was suggesting is that the extremes 
not yet discussed are:

- full integration into ISOC with the rework of the by-law that 
accommodates the standard's function. Scenario A tends toward this but 
does, seem to me, to go all the way.

- Creation of a parallel non profit incorporated Standards organization 
with its own by-laws  that is partnered though MOU's with ISOC.  
Scenario D might evoke this, but since the explanation of this Scenario 
is so brief, I have trouble understanding its implications.

In both I have trouble understanding the full implications in terms of 
items not within the administrative domain.

If A really does equal full integration and D really does equal full 
independence, then I will stand corrected, though I will remain 
confused about some of the implications.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Options for IETF administrative restructuring

[avri]

On 6 sep 2004, at 07.31, [EMAIL PROTECTED] wrote:
2.  I think that we shouldn't broaden the discussion at this time ( as
Avri suggested ), on the grounds of keeping things simple.
I understand the desire to keep thing simple and that Carl is 
attempting a simple fix to a single problem.  However, I think that any 
of the decisions made on a simple fix have possible repercussions for 
the entire relationship and for the IETF's ability to function as a 
standards body.  It is these that I think need to be understood.

This is why I think the full scope of the possible effects should be 
discussed and understood for all options, including both the 4 
compromise solution proposed (A-D) and the more extreme positions of a 
full merger into ISOC or the establishment of an independent Standards 
non profit corporate counterpart/companion to ISOC.

Currently I think A-D are all in some respect ambiguous relationships 
that open many questions.  I tend to prefer one of the more extreme 
positions mentioned above, though I can't yet say which of the two i 
would argue for since I don't fully understand the repercussions of 
each.

That being said, i would also find it reasonable to establish a 
direction and pick an intermediate route that gave immediate solution 
to the 'simple' problem problem involved in gaining control of the 
administrative functions.  Whether that intermediate is A or C, would 
in many ways depend on where we wanted to end up in the end.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: What to incorporate (Re: Options for IETF administrative restructuring)

[avri]

On 2 sep 2004, at 07.11, Brian E Carpenter wrote:
Yes that would be helpful.
Well, I don't agree. I think it would defocus the discussion (which
is about putting the IETF's administration onto a business-like
basis). IMHO the only case in which we should discuss the wider
option is if the newtrk WG proposes changes in the standards process
that would make such a thing necessary.
I guess I don't understand this comment.
As I see it, one reason for another option would have to do with the 
independence of the IETF to change its processes, should it want to.  
Not necessarily because it has a plan today to do so.

One of the concerns I have over the ISOC dependent mechanisms, which I 
guess is all of the presented options, is the link between budgeting 
and process.  If a process change requires a different form of 
budgeting support, would the IETF need the approval of ISOC to make 
that change?  Often what seems like a purely technical decision has 
policy and budgetary implications.  Assuming that we don't want to have 
reconsider the organizational relationship again in the near future, I 
believe we need to take such possibilities into account.

I think another consideration in making these administrative decisions 
has to do with the IETF's voice in the general standards and Internet 
governance arena.  Will ISOC, as a 'parent' organization - my 
interpretation of the options that are offered, be the responsible 
party for such activities?  E.g. currently for a liaison to the ITU, it 
is ISOC that is the liaison association.  Should ISOC disagree with the 
IETF position on a liaison matter who has the final say?  Likewise with 
the ongoing governance debate in the international arena, will ISOC or 
the IETF be the negotiating body?  And before we decide that this is 
just policy and does not relate to protocol issues, we should not 
ignore the intimate link between policy and technical - while it is not 
always direct, there generally is a technical implication in policy 
decisions and, generally,  also a policy impact in technical decisions. 
Basically I am concerned about the real independence of the IETF as a 
technical standards body when ISOC, which the IETF does not control, 
has the governing policy and financial voice.

I would be interested in seeing an analysis of an option which has the 
IETF as a independent nonprofit corporate entity.  This could be either 
as a wholly owned subsidiary of ISOC, thus keeping the fiduciary 
relationship, or as completely independent organization.

a.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Jabber at ietf60

[avri]

Are folks using it?
a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Has anybody heard back from the Hotel in Seoul?

[avri]

Hi,

Just as another check point.  I sent mine in by email.  And on not 
receiving a confirmation by email, even after a second request, I 
decided to call them and confirm.  They had indeed received it and were 
able to give me the confirmation number over the phone.  Now, since I 
currently live in Korea, this was a relatively local phone call, so I 
am not necessarily recommending that everyone call them.  But this is 
an indicator that they are processing the email reservations.

a.

Sunday training classes at IETF58

[Avri Doria]

In addition to the Newcomer's training and the security tutorial, the 
IETF sunday training schedule for Minneapolis will include two new 
sessions.

The first covers the editor's role in working with the WG and in 
producing RFCs.  This is a completely new course.  The session is open 
to both current editors and folks who think they may be interested in 
taking on an editorship, or co-editorship, at some point in the future.

The second is the WG chairs training course.  This is an extension of 
the course that has been given during  lunch sessions for WG chairs.  
This session is open to both current WG chairs and to anyone who thinks 
they may be interested in  chairing a WG.

The schedule for the courses is listed below.  There is no need to 
pre-register, just show up.

Thanks
a.
Sunday, November 10, 2003
=
1330-1430  Newcomers Training -- Salon B  (Scott Bradner)

An introduction to the IETF for anyone who wants to know
more about the IETF, specifically recommended for all new
or recent IETF attendees. The session covers the IETF
history, structure, and standards process. It also
provides tips for success in the IETF environment.
1330-1500  Editor's Training -- Conrad C  (Avri Doria)

Training for current or aspiring IETF document
editors.  Covers the roles and responsibilities
of a document editor, and includes advice on
producing a high-quality IETF specification.
1330-1500  Intro WG Chairs Training -- Conrad B  (Margaret Wasserman)

Introductory training for new or aspiring WG chairs.
Covers the role and responsibilities of the WG chair,
and includes advice on how to run a WG that is fair,
open and productive.
1500-1700  Security Tutorial -- Salon B  (Radia Perlman)

All IETF attendees need to be aware of the security
implications of our design choices.  This session
offers a basic primer in protocol security, as well
as advice on how to write the Security Considerations
sections required for all IETF documents.

Re: IETF Sub-IP area: request for input (fwd)

[avri doria]

2/ establish a long-term area: decide that the SUB-IP
area will be a long-term one, clearly define its charter, and ask the
nomcom to select one or two people to be Area Directors




I spoke on this at the Sub-IP area meeting.  I beleive that the Area
provides focus for a class of problem that is not going to go away.  In
fact, as the versions of IP are adapted to more underlying structures,
including the optical sub-strucutre today and wireless sub-structures
tomorrow, there will alwasy be a class of problem that is best
categorized as the sub-ip problem.  In fact throughout the history of
the IETF there have been such issues, e.g. PPP, it is just that they
were easily hosted in other areas due to their relative simplicity.  As
this class of issue grows, however, I think it would benefit from the
focus only obtainable its own area.  It may even be reasonable to go
through the working groups in some other areas and see if some don't fit
better into a generic sub-IP area.


One further point:

Should the WGs be parcelled out to various groups, GSMP should be
considered as a candidate for the O&M area. Though GSMP was originally
in the Routing area this was becasue the MPLS area was there.  As it is
a management protocol for sub-ip entities I think the best alternate
placement for it is the management area.  I obviously support it
remaining in the permanent Sub-IP area should that be an option.

a.
--
Avri Doria
http://www.sm.luth.se/~avri/

Amended NomCom Volunteer Pool

[avri . doria]

Hi,

As previously announced on the IETF announcement list, the NomCom is to 
chosen from a list of qualified volunteers.  This list was initially
published Friday on the IETF announcement list and has been augmented by 2 
names tacked onto the end of the list:

- 1 whose initial mail did not arrive, but who notified me of the
  discrepancy before any of the seeds where set.
- 1 whose  statement was received in time but whose name I inadvertently

  left off the list.

The following is the final list of qualified volunteers which will be used 
in the drawing.  Qualification was based upon verified attendance at 2 of 
the last 3 IETF meetings (43-Orlando, 44-Minneapolis, 45-Oslo). 

(Note: The added names (71,72) have not yet been yet been verified by the 
Secretariat.  Should either of them be selected but not be qualified, the
selection process will be run an additional step to select an alternate. The

effect of this would be the same as having a selected volunteer decline 
after the selection process.
I am sending this out on the IETF discussion list now so that the final 
headcount can be known before the final seed is set. )

#Name   #   Name
1.  Alec Brusilovsky2.  Allyn Romanow
3.  Amal Maalouf4.  Andrew G. Malis
5.  An-Ni Huynh 6.  Basavaraj Patil
7.  Bernard Aboba   8.  Bernhard Petri
9.  Bilel Jamoussi  10. Bill Manning
11. Bill Sommerfeld 12. Bob (Robert L.) Fink
13. Bob Hinden  14. Bruce Northcote
15. Charlie Kaufman 16. Cheng-Yin Lee
17. Chris Burke 18. Claudio Allocchio 
19. Cynthia Martin  20. Dan Romascanu
21. Danielle Deibler22. Dave Crocker
23. David T. Perkins24. Dorian Kim
25. Doug.Royer  26. Edward Lewis
27. Elwyn Davies28. Erik Guttman
29. Fiffi Hellstrand30. Frank Dawson
31. Graham Travers  32. Greg Minshall
33. Helmut Schink   34. Howard C. Berkowitz
35. Hui-Lan Lu  36. Ian King
37. Igor Faynberg   38. Jeffrey Dunn
39. Jim Luciani 40. Joerg Ottensmeyer
41. John Tavs   42. Josh Cohen
43. Kathleen Nichols44. Kim Hubbard 
45. Larry Gabuzda   46. Lixia Zhang
47. Mark Allman 48. Mark Townsley
49. Marshall Rose   50. Martha Zimet
51. Matt Squire 52. Maximilian Riegel
53. Michael Mealling54. Michael W. Condry
55. Nancy M. Greene 56. Pat Egen
57. Patrice Calhoun 58. Paul Ferguson
59. Paul Hoffman60. Pete Resnick
61. Sally Floyd 62. Scott Brim
63. Spencer Dawkins 64. Steve Hanna
65. Steve Waldbusser66. Thomas Hardjono 
67. Tony J. Genovese68. Walter Weiss
69. William B. Norton   70. Yakov Rekhter
  71. Glenn Zorn72. Rodney Thayer 


Chair, NomCom
---
avri doria
+1 617 678 9402