Re: Mail lost yesterday

[Bob Hinden]

SM,

The place to report IETF operational problems is .  I 
forwarded your email.

Bob

On Aug 29, 2013, at 3:50 PM, SM  wrote:

> Hello,
> 
> Could whoever from the IETF "leadership" who is responsible for the matter 
> please comment about the mail loss incident?
> 
> I previously commented about the visibility of IETF services.  That aspect of 
> the IETF lacks transparency [1] and leaves it to the user to guess what is 
> wrong at his/her end.
> 
> Regards,
> -sm
> 
> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg68755.html
> 

Re: I-D Action: draft-sweet-uri-zoneid-00.txt

[Bob Hinden]

On Aug 27, 2013, at 12:48 PM, Brian E Carpenter  
wrote:

> I am *not* an author of this draft, which Michael Sweet
> produced on his own. I have not read the draft and have no
> idea whether I agree with it.
> 
> (I believe this was an honest mistake on his part but I don't
> want there to be any misunderstanding.)

I am in the same situation and like Brian I do not know if I support this or 
not.  

Bob


> 
> Regards
>   Brian Carpenter
> 
> On 28/08/2013 03:55, internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> 
>> 
>>  Title   : Representing IPv6 Zone Identifiers in Address 
>> Literals and Uniform Resource Identifiers
>>  Author(s)   : Michael Sweet
>>  Brian Carpenter
>>  Stuart Cheshire
>>  Robert M. Hinden
>>  Filename: draft-sweet-uri-zoneid-00.txt
>>  Pages   : 11
>>  Date: 2013-08-27
>> 
>> Abstract:
>>   This document describes how the zone identifier of an IPv6 scoped
>>   address, defined as  in the IPv6 Scoped Address Architecture
>>   (RFC 4007), can be represented in a literal IPv6 address and in a
>>   Uniform Resource Identifier that includes such a literal address.  It
>>   updates the URI Generic Syntax specification (RFC 3986) accordingly.
>> 
>>   [ Editor's note: This draft adds the IPvFuture format used by CUPS
>>   since 2005, addresses some misconceptions of how zoneid's are not
>>   useful to HTTP servers, and is intended to replace RFC 6874. ]
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-sweet-uri-zoneid
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-sweet-uri-zoneid-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 

Re: Sunday IAOC Overview Session at the Berlin IETF

[Bob Hinden]

AB,

> 
> IMO the questions/comments that may be ok to see added to discuss are:
> 
> 1) Venue selection and operation of the IETF meetings
> 
> - Selection of the current venue and was there difficulties until
> getting to this meeting session time. From the managing meeting
> (providing services) and the community use of the meeting. (10 minute
> discuss if needed).

I don't understand your question, please clarify.

Note that the IAOC selects the venue, provides the network, contracts with the 
hotel, etc., it is the IESG who is responsible for the agenda for the meeting, 
agenda planning, etc.

> 
> - Is there an alternative venue if the venue was closed for any
> emergency reason at any time? or only one plan so if the plan changes
> there can be problems with the communities expected plan because they
> were not aware of the needed information per time.

No, there is not an alternative venue under contract.  It isn't practical to 
have two venues under contract, build two networks, etc.  It is technically 
feasable, but would cause the registration fee to go up significantly to cover 
the extra costs.  

If there was, for example, a fire at a venue months before the the meeting we 
would look for an alternate, but what happens would depend on availability of 
alternative venues.  We have good relationships with the hotel chains we use 
and they would work very hard to find an alternative venue, as would the 
effected venue.

> 
> - Is there an historic/informational RFC issued by IAOC of
> difficulties or important comments in past of venues attended?


No.  There is an extensive record of comments about venue on the attendees list 
for individual meetings and the IAOC reports to the community.  Also, meeting 
surveys with community feedback: http://iaoc.ietf.org/surveys.html

> 
> - Regarding advice within emergency situations (in or out the meeting
> venue), is it considered within chosing the managing meeting
> plan/venue, and is the emergency solution an available information for
> attended participants and who will attend within a meeting day.

Assuming you mean while the meeting is taking place, the secretariat and venue 
have emergency plans in place.  The secretariat discuses safety and emergency 
medial procedures with the venue to be prepared if anything should happen.


> 
> - Someone may like to know if is going to attend at a meeting, how is
> the meeting venue managed per time slots, is there a way of quick
> feedback/communication of registered-community for meetings (you may
> say IETF list but are they connected). The information availability
> can be used for others not attended and whom may attend at any time.
> (the venue ran out of coffee/water, so I may buy one while going to
> venue, or any other issue which can happen out of expected/plan).

The IETF meeting agenda is managed by the IESG.  

Problems with the meeting venue can be reported to the Meeting Trouble Desk at 
m...@ietf.org.  Problems with the network can be reported to the NOC at 
n...@ietf.org.


> 
> 2) Other issue:
> +
> -Is there a future work plan milestones discussed? can be added to [*]


Not sure what your are asking about, but future meetings are posted on the IETF 
web site and the process and timeline for meeting planning is part of the IAOC 
overview presentation.



> -I am not sure if was discussed before and answered (I am sorry if
> repeated), where do I go to find important past/current Q&A for IAOC
> (to avoid efforts to be wasted, and unite best answers)? if not
> available it can be good to find it at [*].

Recent plenaries reports and the last IAOC overview session have been recored 
by Meetecho.  The last IAOC overview is on the main page at 
http://iaoc.ietf.org.  Also, plenary proceedings and jabber logs in the usual 
places, for example http://iaoc.ietf.org/plenary-reports.html

Bob


> 
> [*] http://iaoc.ietf.org/
> 
> AB

Re: Sunday IAOC Overview Session at the Berlin IETF

[Bob Hinden]

Wes,

On Jul 15, 2013, at 5:13 AM, "George, Wes"  wrote:

>> The IETF Administrative Oversight Committee (IAOC) will hold a session
>> from 1500-1650 in
>> Potsdam 1 at the Berlin IETF on Sunday July 28, 2013.  The purpose is to
>> provide an
>> overview of the IAOC to allow the community to better understand what
>> the IAOC does, how
>> the finances work, venue selection, and provide the IAOC feedback on the
>> job they are
>> doing.
> 
> [WEG] After Orlando, there was feedback from multiple folks (myself included) 
> requesting that this session *NOT* be scheduled opposite the Newcomers' meet 
> and greet, since that means that most of the folks who might want to see this 
> but have leadership/mentorship duties must leave the session early. Could 
> this be moved to the earlier time slot? If not, can you at least do the 
> content in the reverse order from the Orlando session so that between the 
> two, those who have to leave after an hour have a mostly complete view 
> between this session and the previous one?
> 

We checked and it appears to be possible to move it to 1pm.  This will conflict 
with the 1pm sessions (Newcomers Orientation and Tools for ID), but would avoid 
the Newcomers' meet and greet.  There isn't a perfect solution, unless there 
are objections we will move it.

Thanks,
Bob

Re: Final Announcement of Qualified Volunteers

[Bob Hinden]

Lloyd,

On Jul 9, 2013, at 5:23 PM, l.w...@surrey.ac.uk wrote:

> I do recall a case where both chairs of a WG belonged to a Major Organization.
> 
> World domination was thwarted, however, because the chairs couldn't actually
> agree on anything; the organization was big enough that competing views
> were widespread within it.
> 
> Much to the frustration of other members of the Major Organization.
> And the members of the working group.

I can think of one company who uses to IETF to have internal arguments.  But at 
the same time, I can think of another company who is very aligned in how they 
participate in the IETF.  Many others are somewhere in between.  There isn't a 
single model here.

Bob

Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats

[Bob Hinden]

Lloyd,



On Jul 2, 2013, at 4:37 PM, l.w...@surrey.ac.uk wrote:

> Do we have any statistics on how many appeals to the IESG fail and how many 
> succeed?

Appeals are listed at:

   https://www.ietf.org/iesg/appeal.html

Bob

> 
> If I knew that 97% of appeals get rejected, I wouldn't even bother writing 
> one...
> 
> (On the other hand, that might simply be because 97% of the appeals are 
> written by loons. Statistics can't tell us everything.)
> 
> Lloyd Wood
> http://sat-net.com/L.Wood/
> 

Re: documenting feedback of meeting venues

[Bob Hinden]

AB,

Thanks for the reminder.

We have starting putting the post meeting survey results online.  See:

  http://iaoc.ietf.org/surveys.html

IETF 70, 68, 65, 64 are there now.  The IAD will add IETF 80 through 86 later 
this week this week and earlier meetings after that.

Bob


On Jun 23, 2013, at 1:12 PM, Abdussalam Baryun  
wrote:

> Hi Bob Hinden, and IETF management
> 
> I attended a presentation of IAOC in IETF last-meeting. I have send
> you the below message which you did not reply so far (was waiting for
> three months). Please note that this is my last reminder (will wait
> only two weeks). I was remotely attending your talk in the last IETF
> meeting, and I asked a question but you or someone refered me to post
> on the list and that I will get reply. Please note I still did not get
> a reply and that I think was ignored by the presenters of such work. I
> don't think the community can be ignored.
> 
> AB
> I usually give a communication delay tolerance time for about three
> months because people may be busy, but don't forget my requests :-)
> 
> On 3/10/13, Abdussalam Baryun  wrote:
>> To: Bob Hinden, (presented at IAOC overview)
>> 
>> My question to Bob; why not document the feedback (of meeting venues) of
>> community of past for the future?
>> 
>> I recommend to change the IAOC procedure, to allow documentation?
>> 
>> AB
>> 

Re: Content-free Last Call comments

[Bob Hinden]

Pete,

On Jun 10, 2013, at 1:37 PM, Pete Resnick  wrote:

> Russ, our IAB chair and former IETF chair, just sent a message to the IETF 
> list regarding a Last Call on draft-ietf-pkix-est. Here is the entire 
> contents of his message, save quoting the whole Last Call request:
> 
> On 6/10/13 1:45 PM, Russ Housley wrote:
>> I have read the document, I a support publication on the standards track.
>> 
>> Russ
> 
> A month ago, we had another very senior member of the community post just 
> such a message (in that case directly to the IESG) in response to a different 
> Last Call. I took that senior member of the community to task for it. But 
> apparently Russ either disagrees with my complaint or didn't notice that 
> discussion on the IESG list, so I think it's worth airing here in public:
> 
> A statement such as the above is almost entirely useless to me as an IESG 
> member trying to determine consensus. It is content-free.

Please describe the context of your email.  Are you speaking for the IESG, 
yourself as an AD, or an individual?  Is this something the IESG has discussed? 
 Are you (or the IESG) creating rules for the community, that is, "thou should 
not send one sentence responses to IETF last calls"?  Same question when you 
"took that senior member of the community to task".  

I read your email that you are trying to control how people respond to IETF 
last calls and if they don't respond to your liking you can take them to task.  
Especially the "Russ either disagrees with my complaint…" text.

This may not have been your intent, but your original email and responses can 
be read that way.  

Bob

Re: Weekly posting summary for ietf@ietf.org

[Bob Hinden]

Thomas,

> From my perspective, the intention/usefulness of the weekly posting is
> to give folk a high-level view of who is posting and how often. It is
> not uncommon to see certain individuals stand out. In some cases, that
> makes perfect sense -- and the signal level is high. In other cases,
> it shows (IMO) people who are too quick to post and who (too often)
> say predictable things if you've read previous threads on the same
> general topic. YMMV.

I agree with your conclusion.  

I also wish that the signal level was higher.  The IETF list is important 
because we need to have a place where IETF wide issues can be discussed.  That 
doesn't work if many people unsubscribe due to the the low signal to noise 
level.  I hope that that people who consistently show up at the top of the 
posting summary will moderate their behavior.

Bob

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

[Bob Hinden]

Loa,

On Apr 5, 2013, at 1:47 AM, Loa Andersson  wrote:

> Bob,
> 
> thinking about this and assuming that the FTL Communication are deployed
> in a not too far distant future, wouldn't we have started to receive
> packets that was sent in the future already now?

See Section 5.  It may be already be happening...

Bob

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

[Bob Hinden]

AB,

On Apr 1, 2013, at 5:45 PM, Abdussalam Baryun  
wrote:

> RFC6921>It is well known that as we approach the speed of light, time
> slows down.
> AB> I know that time slows for something when it is in speed of light,
> but communication is not something moving. If the packet is in speed
> of light we may reduce the comm-delay but never less than zero. The
> communication times don't change if at least one communicator is not
> moving in light speed.
> 
> My comment is that I think this RFC is not logical, and I don't
> understand its recommendations. There is no way that a packet can be
> received before send, packet-time never changes communicators-time
> while the positions of both Tx and Rx are semi-fixed (change is
> relative to communicators' times not their signal). I think the
> communication-times may change when the communicators are at/above
> speed of light not the signal/packet. Is my physics correct?

Only time will tell.

Bob

Re: Less Corporate Diversity

[Bob Hinden]

To raise this discussion up a bit, I can think two other related reasons why 
there may be less corporate diversity in the IETF.  

The first is that it's possible to build applications and businesses that take 
advantage of the Internet without having to come to the IETF to standardize 
anything.  The work of the IETF (and related organizations like W3C, IEEE, 
etc.) have made this possible.  A success problem so to speak.

The second is that it's very hard to make changes at the IP and transport 
layers and have them be deployed in scale given middle boxes.  Many 
organizations have stopped trying and focus on making things work on top of 
http.  This also doesn't require coming to the IETF.

My point in this, is that things have changed and it's not just about how the 
IETF works, makes decisions, takes on new work, cost of registration, travel, 
etc.  Also, I am not making a value judgement here, only trying to acknowledge 
reality.

Bob

Re: Nomcom off in the wilderness: Transport AD

[Bob Hinden]

Eric,

On Mar 6, 2013, at 12:59 PM, Eric Gray wrote:

> Bob,
> 
>   This confuses me.  Are you saying that you would be more able to give 
> feedback on someone
> you don't know if you knew what they might have to say about themselves?
> 
>   I would think that - if you don't know somebody - you can't give 
> feedback on them (and that is
> precisely as it should be).

If I don't recognize them by name (and we don't publish their pictures), I 
might remember something they did in a working group/plenary/etc. by reading 
their summary.  

Also, if they make statements about the future of the IETF that I agree with or 
don't agree with, I can provide feedback on that.

Bob

Re: Nomcom off in the wilderness: Transport AD

[Bob Hinden]

Hi,

> Just to be clear:  I am not suggesting public discussion.  I'm suggesting 
> that candidates make their responses available to the community, so the 
> community can have additional information for providing feedback to the 
> Nomcom.

I agree with Dave on this.  

I try to give feedback on the NomCom lists of candidates.  For people I know, I 
can do this, for people I don't know well it's difficult.  It would help me if 
I could read some of the material they submitted with their acceptance of the 
nomination to see why they want the job, and their qualifications and 
experience.

The IETF has grown a lot over the years to the point where most people don't 
know all of the candidates.

Bob

Re: The RFC Acknowledgement

[Bob Hinden]

AB,

On Feb 11, 2013, at 3:32 PM, Abdussalam Baryun wrote:

> On 2/12/13, joel jaeggli  wrote:
>>> Do you mean that IETF is producing what it does not own, or IETF has
>>> no right to edit/amend a document that it is publishing? I
>>> misunderstand your point,
>>> 
>> Once an RFC number is issued  and the document published, the content of
>> that RFC never changes.
>> 
>> See RFC 2200 section 2
>> 
> I agree, but still IETF can update or obsolete any document,
> 
> The question ment to be:
> Do you mean that IETF is producing what it does not own, or IETF has
> no right to edit/amend a document that will be published?

The IETF has the right to make derivative works.  That is, use the contents of 
an RFC to publish a new one.

We can also file errata, declare an RFC historic, etc.

Bob

Re: Remote Participation Services

[Bob Hinden]

Keith,

On Feb 11, 2013, at 5:17 PM, Keith Moore wrote:

> On 02/05/2013 11:04 AM, IETF Chair wrote:
>> 3.4. Slide Sharing
>> 
>>Slides are often sent by email in advance of the meeting.
>>WebEx allows the slides and desktop applications to be viewed by the
>>remote participants.  These are controlled by the presenter.  The
>>presenter can be shifted from participant to participant as needed.
>> 
> 
> Can we *please* discourage the habit of treating IETF WG meetings as one 
> series of PowerPoint presentations after another?   This makes the meetings 
> much less productive.
> 
> The notion that there are supposed to be slides for each presentation, is 
> IMO, a huge error.

I disagree.  The slides are a great help for non-native english speakers.

Bob

Re: Simplifying our processes: Conference Calls

[Bob Hinden]

Hannes,

On Dec 3, 2012, at 11:37 AM, Hannes Tschofenig wrote:

> 
> On Dec 3, 2012, at 8:01 PM, SM wrote:
> 
>> There are people contributing to a working group who are not subscribed to 
>> the mailing list.  There are probably people who are not actively following 
>> a working group who might attend a conference call.
> 
> Any data that supports your argument? Are there people subscribed to the IETF 
> announce list who just wait for conference calls they can join. 
> With the same argument we should just forward every "interesting" mail from 
> the working group just in case that someone on the IETF announcement list 
> cares about it. 
> 
> If you do not follow the mailing list how likely is it that you will 
> understand the discussions during the conference call? 


If the announcement is sent to IETF announce, then people who are not 
subscribed to the mailing list can decide to participate by subscribing to the 
mailing list, reading the archive, read the drafts, and participate in the 
call.  If they never see the announcement, then this can't happen.

I don't see this as a worthwhile simplification to our process.

Thanks,
Bob

Re: Barely literate minutes

[Bob Hinden]

On Nov 28, 2012, at 3:07 PM, Randy Bush wrote:

>> It is a fact of life that some WGs only make progress face-to-face. I
>> think that's often a sign of a problem, but it's a fact.
> 
> i am not so sure it's a problem.  email is a great miscommunication
> mechanism.  so mailing lists go disfunctional far more easily than face
> to face.

+1

It's much easier to reach a consensus face to face, than on a mailing list.  I 
think we have all seen this.

Bob

> 
> we're funny monkeys and seem to need physical presence.  we'll see how
> we do with remote participation if we ever untangle that charlie
> foxtrot.
> 
> randy

Re: Newcomers [Was: Evolutionizing the IETF]

[Bob Hinden]

Arturo,

On Nov 10, 2012, at 13:31, Arturo Servin  wrote:

> Bob,
> 
>Nice to hear that.
> 
>I will send off-list to the IAOC some venues, possible hosts and people
> that could help in finding a good place. 

Thanks,
Bob


> 
> Regards
> as
> 
> On 10/11/2012 13:26, Bob Hinden wrote:
>> The IAOC site team is planning to visit several potential venues early next 
>> year in Latin America / South America.  We are open to suggestions for 
>> potential venues to evaluate.
>> 
>> Thanks,
>> Bob
>> 
>> On Nov 10, 2012, at 9:54 AM, Randy Bush wrote:
>> 
>>>> about your suggestion, it is my todo list.
>>> 
>>> if i can be of help, holler
>>> 
>>> randy

Re: Newcomers [Was: Evolutionizing the IETF]

[Bob Hinden]

The IAOC site team is planning to visit several potential venues early next 
year in Latin America / South America.  We are open to suggestions for 
potential venues to evaluate.

Thanks,
Bob

On Nov 10, 2012, at 9:54 AM, Randy Bush wrote:

>> about your suggestion, it is my todo list.
> 
> if i can be of help, holler
> 
> randy

Re: Recall petition for Mr. Marshall Eubanks

[Bob Hinden]

On Nov 3, 2012, at 5:39 AM, Scott O Bradner wrote:

> 
> I have not "signed" the petition because I did not think it was proper to do 
> so (as a IAOC member - see Russ's message and RFC 3777)
> 
> but, that aside, I do support the petition - I feel that the IAOC has given 
> Marshal
> the full opportunity to start participating again or to resign and he has 
> done neither -
> it is time to move

+1

Bob


> 
> Scott
> 
> On Nov 1, 2012, at 10:22 PM, Michael StJohns  wrote:
> 
>> At 06:01 PM 11/1/2012, Bob Hinden wrote:
>> 
>> 
>>> While the IAOC has not discussed this formally, I agree with you.  The 
>>> situation did change when we were able to talk with Marshall.
>> 
>> 
>> 
>> 
>> I assume at this point the IAOC would like to pursue the recall option?  If 
>> not, please be very clear about it to the list as I haven't actually seen a 
>> request from the IAOC for that process to proceed as far as I can tell.
>> 
>> If you'd rather just wait from him to resign, if in fact he does, then 
>> please indicate that.  I believe neither you nor Dave Crocker nor Scott 
>> Bradner (the only IOAC members that I think have commented on this issue on 
>> list so far) have actually specifically asked for or signed the recall on 
>> the list. 
>> 
>> Mike
>> 
>> 
>> 
>> 
>> 
>>> I too hope he will resign.
>>> 
>>> Bob
>> 
>> 
> 

Re: I* Member Removal Process

[Bob Hinden]

On Nov 1, 2012, at 9:52 PM, Russ Housley wrote:

> Mike:
> 
>> Yup.  But I'd say their wishes would have a great deal of influence on 
>> whether or not this would go forward.  And I'd still like to get at least 
>> some indication that this is their desired outcome at this point.  I think, 
>> if nothing else, this needs to be part of whatever record considered by a 
>> recall committee.  If I heard that only 1 or 2 members were indicating 
>> support for removal, I probably would withdraw my name from the petition 
>> signature.
> 
> The IAOC was unanimous (minus Marshall, of course) in asking the community to 
> declare the seat vacant.  A vote was taken, and the minutes will confirm what 
> I have stated here when they are published.

The results of the E-Vote taking this action are included below.  As stated 
these will be included in the minutes of the 25 October 2012 IAOC call.

Bob


> 
> From: Bob Hinden 
> Subject: Results of IAOC E-Vote to Approve sending an email about the IAOC 
> Vacancy to IETF Announce
> Date: October 22, 2012 8:08:27 AM PDT
> To: i...@ietf.org
> Cc: Bob Hinden 
> 
> The results of the E-Vote to Approve sending an email about the IAOC Vacancy 
> to IETF Announce mailing list are:
> 
> Ole Jacobsen   [YES]   October 17, 2012 11:30:31 PM GMT+02:00
> Scott Bradner  [YES]   October 17, 2012 11:46:31 PM GMT+02:00
> Russ Housley   [YES]   October 18, 2012 12:02:00 AM GMT+02:00
> Bob Hinden [YES]   October 18, 2012 6:18:34 AM GMT+02:00
> Bernard Aboba  [YES]   October 18, 2012 7:22:48 PM GMT+02:00
> Dave Crocker   [YES]   October 18, 2012 7:24:17 PM GMT+02:00
> Lynn St. Amour [YES]   October 19, 2012 6:55:06 PM EDT
> Marshall Eubanks   [   ]
> 
> The E-Vote passes.  The results of the e-vote will be recorded in the minutes 
> of the IAOC call being scheduled for 25 October 2012.
> 
> The IOAC chair is authorized to send the attached email to the IETF announce 
> list on Monday October 22, 2012.
> 
> Bob Hinden
> IAOC Chair 
> 
> 
> On Oct 17, 2012, at 11:24 PM, Bob Hinden wrote:
> 
>> IAOC,
>> 
>> This is an official IAOC E-Vote, to close on Monday 22 October 2012 at 10am 
>> EST.  A minimum of a 3/4 majority of the IAOC voting Yes is required for the 
>> motion to pass.
>> 
>> RESOLUTION
>> 
>>  The IAOC approves send a message to the IETF-Announce list asking the 
>> community to
>>  declare Marshall Eubanks position on the IAOC vacant.  A draft of the email 
>> is
>>  attached to this E-Vote.
>> 
>> Please let me know your vote by responding to this message to the full IAOC 
>> list.
>> 
>> You may vote Yes (in favor approving the resolution), No (opposed), or you 
>> may formally abstain.  
>> 
>> Passing the resolution requires both a quorum and a 3/4 majority of the IAOC 
>> voting Yes.  The motion will pass if this is reached on or before the 
>> closing date.  The results of the E-Vote will be recorded into the minutes 
>> of the next IAOC meeting.
>> 
>> Regards,
>> 
>> Bob Hinden
>> IAOC Chair
>> 
>> 
>> Bernard Aboba  [ ]
>> Lynn St. Amour [ ]
>> Scott Bradner  [ ]
>> Dave Crocker   [ ]
>> Marshall Eubanks   [ ]
>> Bob Hinden [ ]
>> Russ Housley   [ ]
>> Ole Jacobsen   [ ]
>> 
>> 
>> --
>> 
> 

Re: Recall petition for Mr. Marshall Eubanks

[Bob Hinden]

Sam,

On Nov 1, 2012, at 2:45 PM, Sam Hartman wrote:

> I offer my signature to the recall petition. I am nomcom eligible.
> 
> At this point, I believe the recall process is the correct process to
> follow unless there is an approved BCP update.
> In a case where there's been no contact and there's an argument we've
> found a gap in the procedures I can see the argument for creativity.
> However, according to Bob's note, Marshall has been contacted and rather
> than resigning, said he would consider resigning.
> I hope he does.
> Until he does, though, by considering resigning rather than resigning,
> he has implied that there might be a reason not to resign.
> In my mind that moves us out of a situation where creative
> interpretations of vacancy are appropriate.
> I think we're now in a position where there's a legitimate disagreement
> between Marshall and some members of the community about whether
> Marshall ought to be in his position.
> I believe the recall process is the only existing tool we have for
> resolving such a disagreement; I think permitting the IAOC to invent a
> process for resolving such a disagreement without an approved BCP is
> entirely inappropriate.
> 
> Again, I hope this can all be side stepped by a resignation.


While the IAOC has not discussed this formally, I agree with you.  The 
situation did change when we were able to talk with Marshall.

I too hope he will resign.

Bob

Re: IAOC Request for community feedback

[Bob Hinden]

Géza,

On Nov 1, 2012, at 10:58 AM, Turchanyi Geza wrote:

> Olaf and all,
> 
> 
> First: I cannot help to think there is a personal tragedy behind all this. I 
> hope Marshall makes it back to this community because I will miss him.
> 

Same here.

> 
> 
> Exactly. This is why I hope that some of his best freinds will try to contact 
> him personally, or at least figure out when it would be possible to contact 
> him personally.
> 
> Should not we help Marshall to come back? Unfortunately, I can not, however, 
> there are no others?


Russ Housley and Ray Pelletier were able to visit Marshall at his home last 
Friday.  They discussed the situation with Marshall including describing the 
discussion on the IETF list.  He confirmed he had not been reading his email 
since early August and said he would consider resigning.  

We have not received any communication from him since then.

Bob

Re: IAOC Request for community feedback

[Bob Hinden]

Dale,

On Nov 1, 2012, at 9:38 AM, Dale R. Worley wrote:

> There seems to me to be a "constitutional" issue that has not been
> addressed, and may well bedevil us in the future:  In any collective
> body, there is a concept of a quorum, which is set high enough to
> ensure that the actions of any meeting represent the opinions of the
> body as a whole, and which is set low enough that the expected level
> of absences will not prevent business from being done.
> 
> The current crisis is (apparently) due to the chronic absence of *one*
> member causing *chronic* failures of the IAOC to achieve a quorum.
> This suggests to me that the quorum of the IAOC is too high to allow
> it to reliably conduct business -- after all, any of a thousand
> accidents can cause one member to be absent for a long period of time.
> 
> What are the quorum rules of the IAOC?  Should they be revised?

The rules for a quorum are defined in the IAOC administrative procedures.  They 
can be found in Section 3 at:

  http://iaoc.ietf.org/docs/IAOC-Administrative-Procedures-9-16-2010.pdf

The issue with a quorum is not if a single member can not attend a meeting, it 
is what happens if there are also a few members who for reasons like travel can 
not attend.  This has happened once since the last IETF meeting.  Having one 
person missing over a long period of time makes it harder to obtain a quorum, 
it doesn't make it impossible.  It would be a bigger problem if another member 
could not make a number of meetings (for whatever reason).

There are a number of other reasons why a missing member is a problem.  They 
may have specific responsibilities they are not performing (in this case, IAOC 
liaison to the NomCom and IETF Trust chair), membership on subcommittees, and, 
of course, one less voice in discussions in the IAOC and IETF trust.  Having 
fewer people increases the work load on everyone else and creates less 
diversity in views and expertise.

Bob Hinden
IAOC Chair





> 
> Dale

[RFC 3777 Update for Vacancies]

[Bob Hinden]

The draft that proposes changes to the RFC3777/BCP10 to deal with vacancies is 
now available.

  http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00

Bob



From: internet-dra...@ietf.org 
To: i-d-annou...@ietf.org 
Reply-to: internet-dra...@ietf.org 
Subject: I-D ACTION:draft-ietf-genarea-bcp10upd-00.txt 
X-C5I-RSN: 1/0/935/46939/50333 
 
A new Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : RFC 3777 Update for Vacancies 
Author(s) : D. Crocker, et al 
Filename : draft-ietf-genarea-bcp10upd 
Pages : 4  
Date : Oct. 24, 2012  
 
BCP 10 (RFC 3777) specifies IETF processes for selection, 
confirmation and recall of appointees to IETF positions. It also 
refers to the mechanism of resignation as part of a sequence that 
moves a sitting member to a new IETF position. However it does not 
more generally deal with vacancies created by resignation, death or 
uncontested, sustained absence from participation. This update to 
BCP 10 specifies procedures for handling vacancies. 
 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-genarea-bcp10upd-00.txt 
 
Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/ 
 

Re: IAOC Request for community feedback

[Bob Hinden]

Since a few people are asking questions that were answered in the original 
email, here is a link to the mail that was sent to ietf-announce on October 22, 
2012:

   
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11277&tid=1351092666

I thought this would be helpful since it was only sent to ietf-announce, not to 
the IETF list.

Bob

Re: IAOC Request for community feedback

[Bob Hinden]

Responding to some of the discussion, I would like to raise a few points.

I don't see how the IAOC has bypassed any rules.  We are asking the community 
if it is OK to declare Marshall's position vacant.  Bypassing the rules would 
be true if the IAOC had gone ahead unilaterally and asked the NomCom to fill 
the reminder of Marshall's term.  The community consensus will determine the 
answer to the query.  

We think the current procedures were not meant for this case and are not clear 
on the situation when to declare a position vacant.

BCP101 says:

  Any appointed IAOC member, including any appointed
  by the IAB, IESG, or ISOC Board of Trustees, may be recalled using
  the recall procedure defined in RFC 3777.

The use of "may" usually means do this unless there is good reason to do 
otherwise.  I think that is the case in this situation.

The IAOC has operational responsibilities.  Having one voting member not 
attending many meetings makes it harder obtaining a consensus.  Without a 
consensus the IAOC can not approve contracts, RFPs, etc.  

Lastly, and I think most important, the IAOC proposed this approach because we 
think it would cause the least amount of embarrassment to Marshall.  Marshall 
has been active in the IETF for many years and has made many important 
contributions.  We proposed this course of action in respect to Marshall.  We 
think it's better to not subject him to the formal RFC3777 recall process.  
Having his position declared vacant is milder than having him be formally 
recalled.

Bob

Re: IAOC Request for community feedback

[Bob Hinden]

Noel,

> 
>> From: Tobias Gondrom 
> 
>> And maybe we can get a 3 minute time piece from him (or someone
>> authorised to speak on his behalf). If he would resign due to the fact
>> that he has no time at the moment and for the foreseeable future,
>> everything would be settled without trouble.
> 
> Now, that's by some distance the best suggestion I've heard yet.
> 
> Can Ray (or whomever) contact that person they are in touch with, and pass in
> a message asking him if he wouldn't mind just formally quitting, so we don't
> have to waste inordinate amounts of time and energy either i) doing the
> recall thing, or ii) debating whether we need to do the full-blown recall or
> not?

We have been trying to do that for the past month.  No one we have talked to 
has been able to talk to him.  For example, Marshall was active in Lift Port 
(http://liftport.com) where Marshall is listed as their CTO.  I contacted them 
and they have not been able to reach him.

Bob

Re: New mailing list for DNS-SD/mDNS Extensions

[Bob Hinden]

Stuart,

Looks very interesting.  I will try to attend the BOF.

Bob

On Oct 10, 2012, at 3:53 PM, Stuart Cheshire wrote:

> A new IETF mailing list has been created for discussions regarding 
> DNS-SD/mDNS Extensions:
> 
> 
> 
> This is in response to recent events in the industry and marketplace.
> 
> In August, EDUCAUSE delivered a petition to Apple asking for improvements to 
> Bonjour (aka DNS-SD/mDNS) to allow discovery of services beyond the local 
> link.
> 
> 
> 
> 
> 
> In principle DNS-SD can already be used in conjunction with conventional 
> unicast DNS to enable wide-area service discovery, but in practice this 
> capability is not widely used. This disconnect between customer needs and 
> current practice suggests that we need to revisit how to solve this problem.
> 
> In response to this customer demand, Aerohive, Aruba, Cisco, and Xirrus have 
> all recently announced "Bonjour gateway" products which allow service 
> discovery beyond the local link. However, these were brought to market 
> rapidly, and it's unclear whether they represent a desirable long-term 
> direction for service discovery protocol development. Other companies are 
> also reported to be developing their own "Bonjour gateway" products, not yet 
> announced.
> 
> It would be beneficial for the end users, network operators, these vendors, 
> and for the long-term health of the Internet to bring this work into the IETF 
> where all interested parties can collaborate on it.
> 
> Proposed Scope of Work:
> 
> The MDNSEXT mailing list discussions will focus on service discovery 
> solutions suitable for:
> 
> 1. Enterprise networks
> 2. Academic/Educational/University networks
> 3. Multi-link home networks, such as that envisaged by HOMENET*
> 4. Mesh networks, such as SE2.0/ZigBee/6lowpan-style networks
> 
> * It is hoped that MDNSEXT can develop a solution that is suitable for all 
> four network environments, including the HOMENET case. Of course the HOMENET 
> WG is free to evalulate for itself whether it wishes to adopt the MDNSEXT 
> solution, or develop something different.
> 
> Proposed Goals:
> 
> 1. Enable discovery of services across multiple links.
> 
> 2. Zero configuration operation possible, but not mandatory.
>   - i.e. Zero configuration operation is supported by the protocols,
>   but administrative control is also available on networks where that
>   is desired.
> 
> 3. Scalability, in terms of:
>   - Network traffic
>   - CPU and memory requirements on network entities
>   - User interface (huge flat list is not user friendly)
>   - Having a smooth continuum of operation from local link to site to
> global, rather than wildly different incompatible modes of
> operation at different network scales
>   - Granularity of services available on a server (extend the notion of 
> service?)
> 
> 4. Suitable for both local (zero-config) and global (configured) use
>   - i.e. Suitable out-of-the box defaults should enable zero-
> configuration use on many small- to medium-sized networks, while still
> allowing for administrative control in networks where that's desired.
> 
> 5. Incremental deployability
>   - Identify what changes to existing network elements will be
> required, and attempt to minimize those changes.
>   - Don't break existing DNS-SD/mDNS functionality and devices
> 
> A BoF session is tentatively planned for 1520-1650 Tuesday 6th November 2012, 
> subject there being enough interest to warrant moving ahead to that stage.
> 
> Stuart Cheshire
> 

Re: Steven Bellovin appointed FTC CTO

[Bob Hinden]

Steve,

Congratulations!!!

Bob

On Sep 11, 2012, at 9:33 PM, Steven Bellovin wrote:

> 
> On Sep 11, 2012, at 11:37 AM, Phillip Hallam-Baker  wrote:
> 
>> Some happy news about an IETF-er for a change:
>> 
>> http://idealab.talkingpointsmemo.com/2012/09/ftcs-new-chief-technologist-deterrence-isnt-perfect.php?ref=fpb
>>  
>> 
>> Congrats Steve.
> 
> Thanks! 
> 
> Yes, for the next year I'll be at the Federal Trade Commission,
> advising on security, privacy, and other technical issues.  Because
> I'm still doing technology and not just policy, I will not have to
> put the technical part of my brain into storage while I'm here.
> 
>   --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 

Re: Some thoughts about draft-leiba-3777upd-eligibility-02.txt

[Bob Hinden]

Barry,

On Aug 21, 2012, at 2:27 PM, Barry Leiba wrote:

>> I assume the intent is exclude people who are paid by the IETF to do
>> work in the IETF.  For example, the IAD.
> 
> Correct.
> 

Thanks.

>> In these cases it difficult to tell if an individual is working for the
>> IETF "long-term full-time work".
> 
> Indeed; it's difficult in many cases.
> 
>> If this text is to remain, it needs to be clearer as to what it means.
> 
> Which may say that it should not remain.
> 
> The specific exclusions that are in the real "rules" part are for the
> IETF Secretariat and the RFC Editor.  I would be just as happy to
> remove those.  We can question whether we want to leave the RSE in,
> specifically, but there's probably no real need to exclude the paid
> RFC Editor function employees.  I'll note that the IAD is already
> excluded by the "ex-officio" clause (he's an ex-officio IAOC member).

Right, but he is one of our two paid employees (via ISOC).

> The current IAD has told me that he thinks it would be inappropriate
> for the IAD to volunteer in any case, whether or not he's allowed to.

I agree.

> 
> Margaret has commented that this stuff should come out.  Others, in
> early conversations and discussions about all of this, thought it
> should be in.  Further comments appreciated.

I would be OK if it called out the IAD and the RSE as being ineligible.  It's 
simpler than trying to generalize it.
> 
> In particular: should bullet 15,2 (and its supporting text elsewhere)
> be removed?

15,2 should probably say "People employed in the IETF Secretariat….".  

I would leave it in.  My thinking is that the IESG, IAB, and IAOC have 
oversight roles over the Secretariat and RFC Editor.  Having people employed by 
these organizations be directly involved in the selection of the IESG, IAB, and 
IAOC would be odd.

Bob


> 
> Barry

Re: Some thoughts about draft-leiba-3777upd-eligibility-02.txt

[Bob Hinden]

On Aug 21, 2012, at 3:10 AM, Adrian Farrel wrote:

> This document also excludes certain individuals who are directly
> paid for their work with the IETF...
>   I think you can leave it at that.

While on this topic, we might as well get it right.  The text in the draft is:

   This document also excludes certain individuals who are directly paid
   for their work with the IETF, and who, therefore, have a direct
   personal financial incentive in the selection of the leadership
   boards.  We limit this exclusion to a few people who are paid for
   long-term full-time work.  In practice, they are unlikely to
   volunteer for the NomCom anyway, so this addition makes little
   practical change.

I assume the intent is exclude people who are paid by the IETF to do work in 
the IETF.  For example, the IAD.  The problem is that no one is paid by the 
IETF.  The IETF has several people who do work at it's direction.  This is done 
as direct employees of ISOC or as contractors who have their contracts with 
ISOC.  We also hire (via ISOC) companies that provide services to the IETF.  
This ranges from the secretariat services, NOC services, tools development, 
program management services, and tools specification development.  In these 
cases it difficult to tell if an individual is working for the IETF "long-term 
full-time work".  

Further, the text as written could be interpreted to exclude people who's 
employers pay they to participate in the IETF.  For example, that would include 
me because it is part of my job to participate in the IETF.  I don't think that 
is the intent of the text in the draft, but it would be easy to interpret it 
that way.  OK, maybe I don't do it full time, but all of the IESG position 
require full time support.  

If this text is to remain, it needs to be clearer as to what it means.  

Bob


Bob

Re: New Version Notification for draft-leiba-3777upd-eligibility-01.txt

[Bob Hinden]

SM,

On Aug 17, 2012, at 1:44 PM, S Moonesamy wrote:

> Hi Bob,
> At 13:24 17-08-2012, Bob Hinden wrote:
>> Given what started as a simple change has turned into many changes (14 
>> changed paragraphs by my count), I am starting to think that doing a RFC3777 
>> update document would be a better approach.  Then it would be easy to look 
>> at a diff from RFC3777 and see all of the changes.
> 
> I thought about the update when I posted a related draft as minor changes 
> look extensive due to the IAOC addition in various parts of the text.  I can 
> post a draft which incorporates the changes from 
> draft-leiba-3777upd-eligibility-01 to make the diff easier.
> 
> Would that help?


Yes, it would help for reviewing this draft, but it will still make it 
complicated for future noncom's to understand the rules.  A single document 
would be easier to understand.

I suppose an alternative would be to file an errata on RFC3777 that says 
something like add "IAOC" to everywhere in the document it says IESG, IAB, and 
ISOC Board of Trustees, and leave the specific changes as an excise to the 
reader.  :-)  

Bob

Re: New Version Notification for draft-leiba-3777upd-eligibility-01.txt

[Bob Hinden]

Barry, SM,

Given what started as a simple change has turned into many changes (14 changed 
paragraphs by my count), I am starting to think that doing a RFC3777 update 
document would be a better approach.  Then it would be easy to look at a diff 
from RFC3777 and see all of the changes.

Bob

On Aug 16, 2012, at 2:29 PM, Barry Leiba wrote:

> SM and I have merged our 3777 update proposals, and we have posted the
> merged version.  This is BCCed to the NomCom discussion list; please
> take discussion of this to the main IETF discussion list now.
> 
> Reminder: the primary purpose of this is to add the IAOC to some of
> the points in RFC 3777, since 3777 pre-dates the formation of the
> IAOC.  Some of the IAOC-related processed are described in RFC 4333,
> so this doesn't cover everything -- but it adds the IAOC to what we
> think is appropriate.  It also incorporates the one Verified erratum
> against 3777, and clarifies that a few other people should not be
> eligible to volunteer for the NomCom -- in practical matters, it has
> little effect, because most of them would not be volunteering anyway.
> 
> We aim to ask Russ to AD-sponsor this soon.  Further discussion is open.
> 
> Barry (and SM)
> 
>> A new version of I-D, draft-leiba-3777upd-eligibility-01.txt
>> has been successfully submitted by Barry Leiba and posted to the
>> IETF repository.
>> 
>> Filename:draft-leiba-3777upd-eligibility
>> Revision:01
>> Title:   Update to RFC 3777 to Clarify Nominating Committee 
>> Eligibility of IETF Leadership
>> Creation date:   2012-08-16
>> WG ID:   Individual Submission
>> Number of pages: 7
>> URL: 
>> http://www.ietf.org/internet-drafts/draft-leiba-3777upd-eligibility-01.txt
>> Status:  
>> http://datatracker.ietf.org/doc/draft-leiba-3777upd-eligibility
>> Htmlized:
>> http://tools.ietf.org/html/draft-leiba-3777upd-eligibility-01
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-leiba-3777upd-eligibility-01
>> 
>> Abstract:
>>   RFC 3777 specifies that "sitting members" of the IAB and IESG "may
>>   not volunteer to serve on the nominating commitee".  Since that
>>   document was written the IAOC was formed, and that body is not
>>   covered by RFC 3777.  There is also uncertainty about whether ex-
>>   officio members and liaisons are included as "sitting members".  This
>>   document clarifies those situations.

Re: IETF 92 in Dallas!

[Bob Hinden]

Arturo,

[Reducing the cc: list to just the IETF and IAOC lists]

The IAOC seriously investigated a venue in South America for IETF92, but based 
on the data we collected it did not meet the criteria for IETF meetings.  We 
are continuing to talk with the group that suggested the venue and are also 
looking at other venues in that region for future meetings.  

We have open meeting slots in 2015-2017.

Bob
IAOC Chair


On Aug 15, 2012, at 8:37 PM, Arturo Servin wrote:

> 
>   So "Americas" was actually "North America".
> 
>   Well, it went the possibility to have one in central or south america, 
> what at shame. At least until IETF 98 in March 2017 no IETF down the south of 
> Rio Grande.
> 
>   May I ask the IAOC, what are the impediments to have one IETF in Latin 
> America?
> 
> Regards,
> as
> 
> On 15 Aug 2012, at 14:04, IETF Administrative Director wrote:
> 
>> The IAOC is pleased to announce Dallas, TX, USA as the site for IETF 92 from 
>> March 22-27, 
>> 2015.  The IETF was last in Dallas for IETF 65 in 2006.  IETF 92 will be at 
>> a different venue in 
>> the Dallas Arts District.
>> 

Re: Last Call: Modern Global Standards Paradigm

[Bob Hinden]

I support the IETF and IAB chairs signing document.

Bob

On Aug 10, 2012, at 8:19 AM, IETF Chair wrote:

> 
> The IETF Chair and the IAB Chair intend to sign the Affirmation
> of the Modern Global Standards Paradigm, which can be found
> here:
> 
> http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf
> 
> An earlier version was discussed in plenary, and the IAB Chair called
> for comments on the IETF mail list.  This version includes changes
> that address those comments.
> 
> Th IETF 84 Administrative plenary minutes have been posted, so that
> discussion can be reviewed if desired.  The minutes are here:
> 
> http://www.ietf.org/proceedings/84/minutes/minutes-84-iesg-opsplenary
> 
> On 8 August 2012, the IEEE Standards Association Board of Governors
> approved this version of the document.  The approval process is
> underway at the W3C as well.
> 
> The IETF Chair and the IAB Chair intend to sign the Affirmation in the
> next few weeks. Please send strong objections to the i...@iab.org
> and the ietf@ietf.org mailing lists by 2012-08-24.
> 
> Thank you,
>  Russ Housley
>  IETF Chair

Re: [IAOC] Feedback Requested on Draft Fees Policy

[Bob Hinden]

Richard,

On Jul 20, 2012, at 9:40 AM, Richard L. Barnes wrote:

> 
> On Jul 20, 2012, at 11:56 AM, Dave Crocker wrote:
> 
>> On 7/20/2012 7:25 AM, Richard L. Barnes wrote:
>>> We have the technology.  Surely a CMS signed object (or even just an HTTPS 
>>> download) would provide adequate authentication that it came from the IETF. 
>>>  And it doesn't seem like we would have a problem providing authenticated 
>>> documents to the world.
>> 
>> 
>> Do you know that these are acceptable to most/all courts?
>> 
>> d/
> 
> 
> IANAL, so no.  But what else are we going to provide that's better?
> 

We are doing things like signing internet-drafts and RFCs to make this 
possible, but it will be a long while before the courts catch up.  They are not 
exactly early adopters of things like this :-)

Bob

Re: Proposed Update to Note Well

[Bob Hinden]

Russ,

I like that it is shorter, but I think it might be a little too short.  That 
is, I think it needs to be clearer what is a contribution and then mention 
patents.  For example:

  If you write, say, or discuss anything in the IETF, formally or informally,
  that is considered "a contribution" to the IETF.  If you believe this is 
covered by a patent
  or patent application you or your employer own, one of you must disclose
  that.

Thanks,
Bob


On Jun 21, 2012, at 3:10 PM, IETF Chair wrote:

> The IESG has heard many complaints that the Note Well is too complex.  After 
> some discussion with counsel, we propose the following updated Note Well for 
> your comment and review.  The below summary would be followed with a pointer 
> to or text of more details, which will depend upon whether it's a meeting 
> slide, on the web site, on the registration page, or on a mailing-list 
> greeting.
> 
> On behalf of the IESG,
>  Russ Housley
>  IETF Chair
> 
> --
> 
> NOTE WELL
> 
> In summary:
> 
>   By participating with the IETF, you agree to follow IETF processes.
> 
>   If you write, say, or discuss anything in the IETF, formally or informally,
>   (all of which we call "a contribution") that you know is covered by a patent
>   or patent application you or your employer own, one of you must disclose
>   that.
> 
>   You understand that meetings might be recorded and broadcast.
> 
> This would be followed with a pointer to or text of more details,
> which will depend upon whether it's a meeting slide, on the web site,
> on the registration page, or on a mailing-list greeting.
> 

Re: Inconsistent behavior of IETF meeting registration page

[Bob Hinden]

Please sent it to .

Bob

On May 24, 2012, at 10:58 AM, Vinayak Hegde wrote:

> Hi,
> 
> I was trying to register for IETF 84 and tried the link
> http://www.ietf.org/meeting/register.html from the main site.
> Sometimes it takes me to the IETF 80 page (registration over) and
> sometimes it takes me to the right note well page.
> 
> Trying to replicate the issue, I am seeing that it works well on IE
> and Safari on Windows but not on Firefox on Linux/Windows. Further
> attempts to replicate this problem on Firefox on Windows did not work.
> 
> Posting this here as I am not sure what is the right place to post
> such issues. Please point me there. Also hoping that I would get more
> datapoints of this problem from other people on this list (which
> probably will help pinpoint the problem). Looks like a cache-expiry or
> an improper redirection issue.
> 
> Either ways the workaround is to change the number of the IETF meeting
> in the link as this
> (https://www.ietf.org/registration/ietf84/ietfreg.py) works.
> 
> -- Vinayak

Re: a favor from the list about Jon Postel

[Bob Hinden]

Joe,

On May 8, 2012, at 7:19 PM, Joe Touch wrote:

> Hi, all,
> 
> My apologies for contacting this list with a non-IETF issue, but since this 
> community knew Jon well, I'm asking for its help (among others).
> 
> ---
> 
> There is a Facebook page that falsely implies being owned by Jon Postel:
> 
> https://www.facebook.com/jon.postel

I just tried going to this page and it says it doesn't exist.  Has the problem 
been fixed?

Bob

> 
> Facebook has declined requests from Jon's family to have this page removed.
> 
> To everyone on this list:
> 
> PLEASE do not "LIKE" or interact with this page. Jon passed in 1998, as you 
> know, 5 years before Facebook ever existed. He never had a page on this or 
> any other social networking site, and whomever is running this should stop 
> misrepresenting themselves.
> 
> If anyone here can help, please let me know.
> 
> Joe
> to...@isi.edu

Re: Future Handling of Blue Sheets

[Bob Hinden]

On Apr 23, 2012, at 9:05 PM, Dave Crocker wrote:

> 
> 
> On 4/23/2012 1:13 AM, Kireeti Kompella wrote:
>> RFCs are not gospel. They can, and, in this instance, should, be changed: 
>> either remove that last item, or stately explicitly that there is no 
>> expectation of privacy at IETF meetings.  (I have a sinking feeling I know 
>> which way that will go.)
> 
> Actually, an RFC like this /is/ gospel, for this topic.  Gospel can be 
> changed, as you note, according to IETF consensus.
> 
> However as much as I appreciate the benefits of privacy and the detriments of 
> eroding it, I think there is an odd conceptual confusion taking place here:  
> This is an entirely public event.  It makes no sense to participate in a 
> formal portion of that event and expect privacy.

+1

The work we do in the IETF is done in public.  It is a basic element of our 
open standards process.

Bob


> 
> That said, I've certainly no objection to adding to the bloat of warnings and 
> declarations that we already have, in the humorous belief that listing this 
> disclaimer will somehow change people's expectations...
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: Variable length internet addresses in TCP/IP: history

[Bob Hinden]

Noel,

On Feb 17, 2012, at 10:32 AM, Noel Chiappa wrote:

>> From: Bob Hinden 
> 
>> the other reason why we went with 128-bit address with a 64/64 split
>> as the common case and defining IIDs that indicate if they have
>> global uniqueness. This creates a framework that an ID/locator split
>> could be implemented. ... we have a framework that would allow it
>> without having to roll out another version of IP. 
> 
> Alas, the inclusion of _both halves_ of the IPv6 address in the TCP
> checksum means the framework you speak of is basically useless for an
> identity/location split.
> 

That's why I described it as a framework.  The TCP pseudo-checksum would have 
to change and likely the addition of some sort of authentication at connection 
establishment to associate an identifiers with a set of locators.  Not trivial, 
but doable.  

Bob




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

Re: Variable length internet addresses in TCP/IP: history

[Bob Hinden]

Steve,

On Feb 16, 2012, at 6:46 PM, Steven Bellovin wrote:

> 
> On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote:
> 
>> Steven Bellovin wrote:
>> 
 Thus, IPv6 was mortally wounded from the beginning.
>>> 
>>> The history is vastly more complex than that.  However, this particular 
>>> decision
>>> was just about the last one the IPng directorate made before reporting back 
>>> to
>>> the IETF -- virtually everything else in the basic IPv6 design had already
>>> been agreed-to.
>> 
>> I understand that, unlike 64 bit, 128 bit enables MAC based
>> SLAAC with full of states, which is as fatal as addresses
>> with 32 hexadecimal characters.
> 
> That decision came later.  In fact, the deficiencies of relying on MACs were
> discussed quite frequently in the directorate.


And that's why the standard allows for other types of identifiers to be used to 
create Interface Identifiers.


>> 
>>> I don't think this was "the" wrong decision.
>> 
>> Isn't it obvious that, with a lot more than 1% penetration of the
>> Internet to the world today, we don't need address length much more
>> than 32 bits?
> 
> No.  I did and I do think that 64 bits was inadequate.
> 
> Why?  Apart from the fact that if this transition is painful, the next
> one will be well-nigh impossible, having more bits lets us find creative
> ways to use the address space.  Stateless autoconfig is one example,
> though I realize it's controversial.  ID/locator split, which I've been
> a proponent of for very many years, works a lot better with more bits,
> because it allows topological addressing both within and outside an
> organization.
> 

To confirm what your are saying about an ID/locator split in IPv6, that the 
other reason why we went with 128-bit address with a 64/64 split as the common 
case and defining IIDs that indicate if they have global uniqueness.  This 
creates a framework that an ID/locator split could be implemented.  

Opinions vary if ID/locator split is useful, but we have a framework that would 
allow it without having to roll out another version of IP.  A win IMHO.

Bob


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

Re: Variable length internet addresses in TCP/IP: history

[Bob Hinden]

Martin,

On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:

> Brian E Carpenter wrote:
>> 
>> Martin,
>> 
>>> One the one hand, the IETF was frowning upon NATs when they were
>>> developed outside of the IETF.  But if you look at the IETFs
>>> (lack of) migration plan, the translation that you need in order
>>> to make old-IPv4 interoperate with new-IPv6, is actually worse than
>>> an IPv4 NAT.
>> 
>> I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
>> hosts that are numbered out of an address space greater than 32 bits
>> requires some form of address sharing, address mapping, and translation.
>> It doesn't matter what choice we made back in 1994. Once you get to the
>> point where you've run out of 32 bit addresses and not every node can
>> support >32 bit addresses, you have the problem.
> 
> But what is your point?
> 
> With a fully backwards compatible transparent addressing scheme,
> a much larger fraction of the nodes would have switched to actively
> use IPv6 many years ago.

Right, just like they could have deployed dual stack many years ago too.

The deployment problem was not due to technical issues, it was because the 
Internet changed to only deploy new technology that generated revenue in the 
short term.  After a lot of thought, I have come to the conclusion that it 
wouldn't have mattered what the IETF did, we would still be facing the same 
problems.  It wouldn't be seriously deployed until IPv4 address ran out.

These "if we had only done foo" discussions all miss the biggest deployment 
factor.

Bob



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

Re: [sieve] Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard

[Bob Hinden]

On Jan 26, 2012, at 12:12 AM, Dave CROCKER wrote:

> 
> 
> On 1/25/2012 1:50 PM, Adrian Farrel wrote:
>> I believe the document should be returned to the working group who are the 
>> main
>> victims of the disruptive behaviour by the author.
> 
> 
> The working group might be the closest and could reasonably have the highest 
> sense of frustration -- Pete's later posting notwithstanding -- but forgive 
> my noting that they are not the main victims.
> 
> Variously the IETF and the Internet community are the main victims.  The IETF 
> for the rather sustained violation of its policies and the Internet community 
> for the delay in being able to use a mechanism that presumably would be 
> useful.

+1

Bob


> 
> Somehow, an apology does not seem sufficient.  Something more substantial is 
> warranted.
> 
> d/
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: ITC copped out on UTC again

[Bob Hinden]

Brian,

On Jan 20, 2012, at 11:26 AM, Brian E Carpenter wrote:

> On 2012-01-21 03:20, Phillip Hallam-Baker wrote:
>> If we are ever going to get a handle on Internet time we need to get rid of
>> the arbitrary correction factors introduced by leap seconds.
> 
> Time is and always will be an arbitrary measurement scheme, and the only
> thing that makes sense for the Internet is to use the same arbitrary scheme
> as everybody else. We just have to suck up the resulting inconveniences,
> as GPS has to. It would be unthinkable to go it alone.

+1

> 
> Alternatively we could revert to the Julian (365.25 day) calendar, which
> was considerably more convenient for programmers, or perhaps to one of the
> old Iranian (360 day) calendars, which are convenient in some ways but do
> require occasional leap months.

Or a lunar calendar.  Some years, it would be nice to have an extra month :-)

Bob

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

Re: [IAOC] primary Paris hotel booking

[Bob Hinden]

Wes,

I think everyone on the IAOC was surprised when we first heard that the meeting 
hotel insisted that people can only use fax or email to send in their 
reservations.  We tried to get the hotel to change this, but they would not 
budge.  This included their rejection of accepting reservations by phone.

Other nearby hotels were much more expensive, so this reservation method was 
reluctantly accepted.

You are, of course, free to book online but when I checked earlier today the 
rates were higher even without breakfast included  (but the cancelation policy 
less was severe).  Your tradeoff.  In this venue, the IETF will receive credit 
for your stay if you book on line (or through your corporate travel department).

It also most goes with out saying that there are also many other hotels in 
Paris at lower and higher rates.

Bob





On Jan 3, 2012, at 8:52 AM, George, Wes wrote:

> Happy New Year, it's time for our triannual hotel complaint thread.
> I hate to do it, but I think that there are people who haven't looked at this 
> yet, and I'm hoping that we can perhaps rectify it before the majority of 
> folks try to book:
> 
> "Instructions for making reservations at Hotel Concorde:
> Please fill out the reservations form and fax it directly to the hotel at: 
> +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com"
> 
> It's 2012, but the IETF and this hotel chain expects us to book reservations 
> at the main conference hotel by (international) FAX or by *emailing* a form 
> which includes a credit card number so that the hotel can hold the room and 
> implement its relatively bizarre prepay/anti-cancellation policy.
> Would it be trolling to ask whether anyone verified that "cmasson" has 
> support for PGP encrypted-email and a proper method of securely storing (and 
> then destroying after use) the several hundred credit card numbers they are 
> about to receive?
> 
> What person or rate code should we ask for when booking our rooms over the 
> phone? (hey if I'm going old school, I'm doing it all the way!) Though, given 
> the above, I'm relatively worried that my credit card number will simply end 
> up on an unprotected spreadsheet on a PC somewhere in their office even if I 
> call to book.
> 
> More practically, the hotel blocks at the primary hotel typically fill up 
> quite fast once registration is opened, especially since the overflow hotel 
> is actually more expensive than the primary. Does the hotel fax/call us back 
> to tell us that they have no more rooms available for our requested dates, or 
> is the block open-ended such that they will keep selling rooms in it until 
> the cutoff regardless of the number?
> 
> Evidently "ability to book group rate rooms online" is something that should 
> be added to our list of hotel requirements. I'm stunned that it's not there 
> already.
> 
> Wes George
> 
> 
> 
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject to 
> copyright belonging to Time Warner Cable. This E-mail is intended solely for 
> the use of the individual or entity to which it is addressed. If you are not 
> the intended recipient of this E-mail, you are hereby notified that any 
> dissemination, distribution, copying, or action taken in relation to the 
> contents of and attachments to this E-mail is strictly prohibited and may be 
> unlawful. If you have received this E-mail in error, please notify the sender 
> immediately and permanently delete the original and any copy of this E-mail 
> and any printout.
> ___
> IAOC mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/iaoc

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

Re: Last Call: (Experiences from an IPv6-Only Network) to Informational RFC

[Bob Hinden]

I support publishing this document.  It is covers an important topic that is 
useful to the community.

Bob

On Dec 10, 2011, at 12:33 AM, The IESG wrote:

> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Experiences from an IPv6-Only Network'
>   as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2012-01-06. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document discusses our experiences from moving a small number of
>   users to an IPv6-only network, with access to the IPv4-only parts of
>   the Internet via a NAT64 device.  The document covers practical
>   experiences as well as road blocks and opportunities for this type of
>   a network setup.  The document also makes some recommendations about
>   where such networks are applicable and what should be taken into
>   account in the network design.  The document also discusses further
>   work that is needed to make IPv6-only networking applicable in all
>   environments.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-arkko-ipv6-only-experience/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-arkko-ipv6-only-experience/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: Travel/Attendees list FAQ

[Bob Hinden]

Wes,

On Dec 7, 2011, at 9:28 AM, George, Wes wrote:

>> On Dec 7, 2011, at 7:11 AM, Margaret Wasserman wrote:
>> 
>>> 
>>> What is the value in publishing a living document as an RFC (which
>> inherently a static, archival document)?  Wouldn't it make more sense
>> to convert the contents of this document to a Wiki page that we could
>> jointly edit and maintain going forward?
>> 
>> +1
>> 
>> I think it's important that this be dynamic and easy to change.
>> 
>> Bob
> 
> [WEG] I think that we're already off in the weeds based on an incorrect 
> assumption, so I'd like to clarify before we get too far along with this. 
> This is a list of the *questions* because they do not change much from one 
> meeting to the next. The document already recommends that the *answers* which 
> will be different for every venue be kept in a place where they are more 
> easily updated.
> 

While I agree that the questions won't change as often as the answers, it will 
likely change.  We have come a long way from just asking how many cookies there 
will be.  

Also, if it gets published as an RFC, it is going to be viewed as a 
"specification".  I think it's best to avoid that and just have a wiki.I 
would be surprised if this topic continues to be as active area of discussion 
in the future, making it unlikely that there would be new RFCs published.  

Further, is this something we really want in the historical record.  

Bob



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

Re: Travel/Attendees list FAQ

[Bob Hinden]

On Dec 7, 2011, at 7:11 AM, Margaret Wasserman wrote:

> 
> What is the value in publishing a living document as an RFC (which inherently 
> a static, archival document)?  Wouldn't it make more sense to convert the 
> contents of this document to a Wiki page that we could jointly edit and 
> maintain going forward?

+1

I think it's important that this be dynamic and easy to change.  

Bob


> 
> Margaret
> 
> On Dec 7, 2011, at 9:27 AM, Dave CROCKER wrote:
> 
>> 
>> 
>> On 12/7/2011 6:09 AM, George, Wes wrote:
>>> I'm also open to suggestions as to the appropriate publication track for
>>> thisdocument, whether I should look to have it sponsored as a GenArea doc 
>>> or simply>
>>> put it forward as an individual submission.
>> 
>>> http://tools.ietf.org/html/draft-george-travel-faq
>> 
>> 
>> I suggest that this be processed as an individual submission.  It will still 
>> get IETF review but I believe it does not require the level of active 
>> consensus by a working group (pseudo or otherwise) that a typical technical 
>> specification does.
>> 
>> However I suggest that the document cast itself as a snapshot of an on-going 
>> documentation process, with the "master" copy being an IETF Wiki; the 
>> document should contain a point to the wiki.
>> 
>> I'll also suggest that there be an on-going mailing list for discussing 
>> meeting logistics issues, rather than a different mailing list for each 
>> meeting. (ietf-meeting?)
>> 
>> The current contents -- a template of information to be developed -- looks 
>> quite good.  But it can't be "complete", and the definition of "complete" is 
>> likely to change frequently.  That's a perfect candidate for a wiki effort.
>> 
>> d/
>> -- 
>> 
>> Dave Crocker
>> Brandenburg InternetWorking
>> bbiw.net
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: "class E" (was: Consensus Call: draft-weil-shared-transition-space-request)

[Bob Hinden]

Noel,

On Dec 5, 2011, at 10:58 AM, Noel Chiappa wrote:

>> From: Bob Hinden 
> 
>> As far as I can tell, it would only require the CPE router, CGN's, and
>> routers between the CPE and CGN's to support it. ... I think it's
>> reasonable for the ISPs who want to deploy this CGN gear to the deal with
>> upgrading the CPE routers of their customers.
> 
> The problem is that for a lot of ISPs, the CPE equipment is owned by the
> customers, and comes from a zillion different vendors, and upgrading all of
> them is just not feasible.

Sure, for all forms of CPE currently deployed.  I assume that there aren't any 
CPE deployed behind CGN today.  That is, all CPE today work without CGN and any 
sort of special addresses, probably use public IPv4 space on the WAN/ISP side.  
So a CGN deployment is a new deployment and the ISPs choosing to do this could 
make sure that their customers CPE can support class E addresses, upgrade the 
CPE firmware, or send them new CPE.  

Bob


> 
>> The proposal to use some of the remaining public IPv4 space for this,
>> IMHO has everyone else incur the costs.
> 
> Scenario I: The IETF defines a /10 for this use, to be shared by all ISPs.
> Scenario II: The IETF refuses to define a /10 for this use, each ISP goes
>   out and asks for its own.
> 
> Scenario II is incurring less cost on 'everyone else'... how?
> 
> 
> Which does lead me to something I've been wondering about, though.
> 
> Why don't the ISPs get together, outside the IETF (I so wanted to expand on
> this thought, but I had better not), and have one of them - one which is in
> an area with an RIR with the most available space - go their RIR and ask for
> a /10 for their in-house CGN - and then publish the number and say 'hey,
> everyone, here's a /10 that anyone can use for their CGN'? And then, _once
> it's already allocated_, they could even publish an I-D/non-standard-track
> RFC documenting it, and how to use it...
> 
>   Noel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: "class E" (was: Consensus Call: draft-weil-shared-transition-space-request)

[Bob Hinden]

Marshall,

On Dec 5, 2011, at 10:21 AM, Marshall Eubanks wrote:

> On Mon, Dec 5, 2011 at 1:00 PM, David Conrad  wrote:
>> Frank,
>> 
>> On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
>>> The last state I'm aware of is that the 240/4 addresses minus one
>>> were and still are (RFC 5735) reserved for IETF experiments, did I miss
>>> some newer IETF consensus about this?
>> ...
>>> 
>> 
>> Does it actually matter?  What RFCs say (or don't say) about 240/4 means 
>> precisely nothing to the deployed, non-field-upgradable CPE that I 
>> understand is driving the interest draft-weil.
> 
> That IMO is the rock that proposals to use Class E have floundered on.
> There is a lot of gear out there that will not be able to
> deal with any Class E internetworking protocol, little prospect that
> that will be changed any time soon, and a general feeling that it is
> unwise to spend limited resources changing this.
> 


While all of that is true to use the Class E space for general purpose usage, 
the current proposal for using it for the CGN is different.  As far as I can 
tell, it would only require the CPE router, CGN's, and routers between the CPE 
and CGN's to support it.  It would not require any support by the customer 
behind the CPE or the rest of the Internet.  That the reason why several people 
have suggested it.

I think it's reasonable for the ISPs who want to deploy this CGN gear to the 
deal with upgrading the CPE routers of their customers.   They get the 
"benefit", they should incur the costs.  The proposal to use some of the 
remaining public IPv4 space for this, IMHO has everyone else incur the costs.

Bob


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

Re: An Antitrust Policy for the IETF

[Bob Hinden]

+1

Bob


On Dec 1, 2011, at 10:44 AM, Christian Huitema wrote:

> Note that the suit does not complain about the 3GPP and ETSI rules. It 
> alleges instead that the rules were not enforced, and that the leadership of 
> these organization failed to prevent the alleged anti-competitive behavior of 
> some companies.
> 
> I believe that our current rules are fine. They were specifically designed to 
> prevent the kind of collusion described in the complaint. Yes, these rules 
> were defined many years ago, but the Sherman Antitrust Act is even older -- 
> it dates from 1890. We have an open decision process, explicit rules for 
> intellectual property, and a well-defined appeals process. If the plaintiffs 
> in the 3GPP/IETF lawsuit had been dissatisfied with an IETF working group, 
> they could have use the IETF appeal process to raise the issue to the IESG, 
> and the dispute would probably have been resolved after an open discussion.
> 
> Rather than trying to set up rules that cover all hypothetical developments, 
> I would suggest a practical approach. In our process, disputes are 
> materialized by an appeal. Specific legal advice on the handling of a 
> specific appeal is much more practical than abstract rulemaking.
> 
> -- Christian Huitema
> 
> 
> 
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel 
> jaeggli
> Sent: Thursday, December 01, 2011 8:56 AM
> To: Jorge Contreras
> Cc: Ted Hardie; IETF Chair; IETF; IESG
> Subject: Re: An Antitrust Policy for the IETF
> 
> On 11/28/11 12:58 , Jorge Contreras wrote:
>> On Mon, Nov 28, 2011 at 2:35 PM, GTW > > wrote:
>> 
>>__
>>Ted, I like your approach of enquiring what problem we are striving
>>to solve and I like Russ's concise answer that it is "Recent suits
>>against other SDOs that  is the source of the concern" 
>> 
>>Russ, what are  some of the  "Recent suits against other SDOs"  It
>>would be good to pin down the problem we are addressing
>> 
>>There is  FTC and N-data matter from 2008
>>http://www.gtwassociates.com/alerts/Ndata1.htm
>> 
>> 
>> George -- one recent example is the pending antitrust suit by True 
>> Position against ETSI, 3GPP and several of their members (who also 
>> employ some IETF participants, I believe).  Here is some relevant 
>> language from the Complaint:
> 
> When or if that suit is concluded you may be able to divine whether the 
> antitrust policy of either SDO was of any value.
> 
>> "100.   By their failures to monitor and enforce the SSO Rules, and to
>> respond to TruePosition's  specific complaints concerning violations 
>> of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible 
>> for, and complicit in, the abuse of authority and anticompetitive 
>> conduct by Ericsson, Qualcomm, and Alcatel-Lucent.  These failures 
>> have resulted in the issuance of a Release 9 standard tainted by these 
>> unfair processes, and for the delay until Release 11, at the earliest, 
>> of a 3GPP standard for UTDOA positioning technology.  By these 
>> failures, 3GPP and ETSI have authorized and ratified the 
>> anticompetitive conduct of Ericsson, Qualcomm, and Alcatel-Lucent and 
>> have joined in and become parties to their combination and conspiracy."
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: Consensus Call: draft-weil-shared-transition-space-request

[Bob Hinden]

On Nov 30, 2011, at 6:27 AM, Michael Richardson wrote:

> 
>> "Randy" == Randy Bush  writes:
>>> skype etc. will learn.  This does prevent the breakage it just
>>> makes it more controlled.  What's the bet Skype has a patched
>>> released within a week of this being made available?
> 
>Randy> cool.  then, by that logic, let's use 240/4.  the apps will
>Randy> patch within a week.  ok, maybe two.
> 
> Seriously, I think we *SHOULD* use 240/10.
> (let's keep some for the next horrible hack)

I agree, this is a good use of the "Experimental" Class E IPv4 addresses.  It 
seems to me that this is for new deployments (the CDN gear and new customer CPE 
equipment).  The operators who want this should be able to make this work and 
and incur the cost for doing so.

Bob



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

Re: Consensus Call: draft-weil-shared-transition-space-request

[Bob Hinden]

On Nov 29, 2011, at 10:16 PM, Christian Huitema  wrote:

>> I did share what I was smoking - it's called 'reality' :).
> 
> Which reality? I think Randy is much more realistic!

+1

> 
> You are telling us that you want a /10 of private address space set aside 
> because you cannot use the current allocation of private address space in RFC 
> 1918. You tell us that the effect you want to achieve cannot be attained if 
> the address that you use are also used by customer networks. But then, there 
> is no mechanism whatsoever that would prevent customer networks from using 
> the new /10 as soon as it would be allocated. Sure, you may put text in a RFC 
> somewhere, but that is not a mechanism. Ergo, if we were to make that 
> allocation, it will become unusable for your stated purpose in a very short 
> time. 
> 
> I think that's not a very good idea. I would rather not see that allocation 
> being made.
> 

That is my view as well.  I think this is a bad idea for the reasons stated. 
 
Bob


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

Re: Plagued by PPTX again

[Bob Hinden]

On Nov 15, 2011, at 11:01 AM, Barry Leiba wrote:

>> Please can everybody who doesn't upload PDF to the meeting materials page
>> at least take care to upload PPT instead of PPTX?
> 
> As a chair, I convert PPT and PPTX to PDF first, and always upload the
> PDF.  (And I ask participants to send me PDF in the first place.)

+1

Bob


> 
> Some people prefer to send PPT(X) because they want to do fancy
> animations.  I try to discourage that, unless they can really make the
> case that the animations make things significantly clearer.  So far,
> no one has even tried to convince me.
> 
> Barry
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: [IAOC] I-D Action: draft-barnes-healthy-food-04.txt

[Bob Hinden]

An IETF food list sounds right to me.

Bob

On Nov 1, 2011, at 7:40 AM, Mary Barnes wrote:

> I think the document in general should be discussed on a separate mailing 
> list as it's not meeting specific. And, previous attempts at discussing this 
> topic on more general mailing lists have not been particularly positive.  
> 
> I would agree that sharing information on general information related to 
> finding food at the meetings on the attendees mailing list might be a good 
> idea.  However, some of the details may be of no interest to the majority.  
> For example, there is small (but growing) subset of the IETF population that 
> needs to eat Gluten-Free. This tends to get into very detailed discussions 
> (per my document) and these might seem totally trivial and unnecessary for 
> folks that don't deal with this and while it might seem obvious to some folks 
> what we can and cannot eat, it's not nearly as simple as it might appear.  
> For example, asian food is always risky due to the use of soy sauce (which 
> contains wheat). And, cross-contamination is a big issue, so the waitstaff is 
> equally as important in ensuring we get safe food as having a cook that 
> understands the concept.   So, personally I would prefer to have those sorts 
> of discussions on the ietf-food list as I'm sure most attendees have no 
> interest w
 hatsoever in a topic like this.  
> 
> Mary. 
> 
> On Tue, Nov 1, 2011 at 8:38 AM, Eric Burger  
> wrote:
> Any reason not to use attendees...@ietf.org?  I do not regularly participate 
> in the ietf-food list, but I am interested in the results.  For example, I am 
> not a vegetarian, but I like vegetarian food.  Likewise, I am on a budget, so 
> knowing where to buy good food outside the venue interests me.
> 
> The idea being that while there is a core group for whom food is critically 
> important, e.g., getting very ill from the wrong food, there is a larger 
> audience that would be interested in the discussion, too.
> 
> On Nov 1, 2011, at 9:31 AM, Mary Barnes wrote:
> 
> > I have a separate mailing list setup for the "food" discussion in general:
> > ietf-f...@employees.org
> >
> > Mary.
> >
> > On Mon, Oct 31, 2011 at 7:02 PM, Marshall Eubanks 
> >  wrote:
> >
> >
> > On Mon, Oct 31, 2011 at 6:34 PM, David Morris  wrote:
> >
> >
> > On Mon, 31 Oct 2011, Marshall Eubanks wrote:
> >
> > > Dear Mary;
> > >
> > > Which is the appropriate community mailing list for discussion of this
> > > draft ? IETF@ietf.org ?
> >
> > A more limited traffic alternative might be useful ... my wife is a
> > Registered Dietician and might be willing to provide feedback and
> > suggestions, but not if she has to wade through the wide variety of
> > discussion on the ietf@ietf list. I suspect there may be other experts
> > who'd feel the same.
> >
> >
> > Ray, Russ - could we set up a mailing list for _general_ meeting related 
> > discussions ? (Or,
> > maybe, such already exists.)
> >
> > I think that just diet may be too narrow a focus...
> >
> > Regards
> > Marshall
> >
> >
> > Dave Morris
> >
> >
> >
> >
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: The death John McCarthy

[Bob Hinden]

Eliot,

On Oct 27, 2011, at 2:15 PM, Eliot Lear wrote:

> Bob,
> 
> First, I share your admiration for John McCarthy (after all, who does
> not?).  In that spirit, my understanding was that LISP was an homage,
> and as such should not be viewed in a negative light.  You're of course
> right that we do stand on shoulders– many.

I reviewed some of the early drafts and the closest thing I could find to an 
acknowledgment related to the chosen name was in :

   In particular, we would like to thank Dave Meyer for his clever
   suggestion for the name "LISP". ;-)

Bob



> 
> Eliot
> On 10/27/11 11:08 PM, Bob Hinden wrote:
>> John McCarthy died a few days ago.  I won't try to summarize his 
>> accomplishments myself but thought that the obituary in the NY Times was 
>> very good:
>> 
>>  http://www.nytimes.com/2011/10/26/science/26mccarthy.html
>> 
>> "John McCarthy, a computer scientist who helped design the foundation of 
>> today’s Internet-based computing and who is widely credited with coining the 
>> term for a frontier of research he helped pioneer, Artificial Intelligence, 
>> or A.I., died on Monday at his home in Stanford, Calif. He was 84.
>> 
>> In 1958, Dr. McCarthy moved to the Massachusetts Institute of Technology, 
>> where, with Marvin Minsky, he founded the Artificial Intelligence 
>> Laboratory.  It was at M.I.T. that he began working on what he called List 
>> Processing Language, or Lisp, a computer language that became the standard 
>> tool for artificial intelligence research and design."
>> 
>> With his death, I have a request.
>> 
>> I request that the relevant authors and IETF working group rename what it 
>> currently calls "LISP" to something else.  To put it politely, the IETF 
>> should be standing on the shoulders of the giants who have laid the 
>> groundwork of the Internet, not stepping on their toes. 
>> 
>> Bob
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 

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

Re: The death John McCarthy

[Bob Hinden]

Ned,

On Oct 28, 2011, at 8:17 AM, ned+i...@mauve.mrochek.com wrote:

>> First, as someone who chartered the working group, who has implemented Lisp
>> (the programming language) at least four times, and who views Dr. McCarthy 
>> as a
>> hero I disagree that name is problematic or disrespectful. And I almost take
>> offense in the claim that this is a generational thing.
> 
> I didn't charter the group and I've only done two Lisp implementations, but
> aside from that, +1. (Or should I say "t" instead?)
> 
> And frankly, if there's disrespect to be found here, IMO it lies in using this
> sad event as a proxy to criticize some IETF work some people apparently don't
> like.


Just to be clear, my request was limited to the name.  I said nothing about the 
work itself.

Bob

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

The death John McCarthy

[Bob Hinden]

John McCarthy died a few days ago.  I won't try to summarize his 
accomplishments myself but thought that the obituary in the NY Times was very 
good:

  http://www.nytimes.com/2011/10/26/science/26mccarthy.html

"John McCarthy, a computer scientist who helped design the foundation of 
today’s Internet-based computing and who is widely credited with coining the 
term for a frontier of research he helped pioneer, Artificial Intelligence, or 
A.I., died on Monday at his home in Stanford, Calif. He was 84.

In 1958, Dr. McCarthy moved to the Massachusetts Institute of Technology, 
where, with Marvin Minsky, he founded the Artificial Intelligence Laboratory.  
It was at M.I.T. that he began working on what he called List Processing 
Language, or Lisp, a computer language that became the standard tool for 
artificial intelligence research and design."

With his death, I have a request.

I request that the relevant authors and IETF working group rename what it 
currently calls "LISP" to something else.  To put it politely, the IETF should 
be standing on the shoulders of the giants who have laid the groundwork of the 
Internet, not stepping on their toes. 

Bob


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

Re: What? This thread is talking about *voting* now?

[Bob Hinden]

+1

Bob

On Oct 27, 2011, at 5:24 AM, Brian E Carpenter wrote:

> It's really annoying when a thread drifts to a wildly different topic
> without somebody thinking to change the Subject header.
> 
> My comments on nominees would be much less frank if I knew they
> would be published. In fact, I doubt if I would make any at all.
> 
> Here's a comment I sent in a number of years ago.
> 
> "Arrogant, sometimes rude, not interested in listening to other
> people. I think  would be an abysmal AD."
> 
> In public? I don't think so. The whole idea of honest feedback only
> works when kept confidential.
> 
> As for voting, I understand Mary's frustration at the lack of
> participation, but this really must not become a popularity
> contest and certainly not be put at risk of capture by companies
> or countries that send a lot of people to meetings. After all,
> this thread started out about how to *not* need to go to meetings.
> 
> Regards
>   Brian
> 
> On 2011-10-27 16:00, Ross Callon wrote:
>> Mary;
>> 
>> Would you want the comments that are currently sent in privately to nomcom 
>> to become public, or do you want the voters to make their choices without 
>> hearing these comments?
>> 
>> Ross
>> 
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mary 
>> Barnes
>> Sent: Wednesday, October 26, 2011 4:52 PM
>> To: Peter Saint-Andre
>> Cc: John C Klensin; ietf@ietf.org
>> Subject: Re: Requirement to go to meetings
>> 
>> On Wed, Oct 26, 2011 at 2:50 PM, Peter Saint-Andre 
>> mailto:stpe...@stpeter.im>> wrote:
>> On 10/26/11 1:47 PM, Fred Baker wrote:
>>> On Oct 26, 2011, at 8:38 AM, Peter Saint-Andre wrote:
>>> 
 (e.g., the NomCom
 schedule is defined in terms of three meetings a year).
>>> no problem. We stop having the nomcom.
>> Sure, we just set up a (two-tier?) membership structure and have all the
>> members vote. Easy.
>> 
>> [MB] You don't need a membership structure to have voting - you just allow 
>> anyone that has attended the requisite number of meetings per the Nomcom 
>> process to vote - i.e., if you are qualified to be a voting member of the 
>> Nomcom, you can vote.I personally believe that voting would be better 
>> than the current model.  As it is, a very small percentage of the 
>> participants actually contribute to the process in the form of nominating or 
>> providing feedback:
>> http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00 (section 6.2)
>> 
>> So, making it easier to provide input in the form of a vote might actually 
>> get more folks caring about who the leaders are.It would also save a 
>> tremendous amount of work on the part of the folks that serve on the Nomcom. 
>>  [/MB]
>> 
>> [Also, ducking]
>> 
>> Mary.
>> 
>> 
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Bob Hinden]

John,

You seem to be making a lot of assumptions about the RFP that aren't part of 
the RFP.  Or perhaps you are reading between the lines.  For example that the 
RFP will only be sent to the IETF list, that we won't allow non-IETFers to bid, 
that no discussion will occur between who ever does this work and the 
community, that the requirements are fixed, that the conclusions are 
pre-determined, etc., etc.  

The goal of the RFP is to hire someone who will investigate the problem, talk 
to many people, analyze the data, and make a proposal for what is doable.  The 
RFP is not a specification of the outcome.  We want to hire someone who will 
think about the problem space and make a proposal for the functions that should 
be present in a remote access system that the IETF will use.   Any contract 
awarded based on this RFP will require the contractor to interact with the 
community.  

BCP101 requires the IAOC to operate in a transparent manner.  I don't see how 
publishing an RFP to hire someone to write a specification that includes public 
review of the work and an IETF wide last call isn't transparent.  It would have 
been non-transparent if the IAOC had hired someone with out first doing a 
public RFP.  BCP101 doesn't require that everything the IAOC thinks about must 
be first sent to the community for review.  

Bob



On Oct 20, 2011, at 12:23 PM, John C Klensin wrote:

> --On Thursday, October 20, 2011 10:50 -0700 Bob Hinden
>  wrote:
> 
>> John,
>> 
>> The RFP is not a solicitation to vendors of remote
>> participation services.  It is to hire someone to write a
>> requirements document for remote participation services.  It
>> is not to develop any code nor are the items listed in the RFP
>> the only things that should be included.  
> 
> Bob,
> 
> I was somewhat confused by differences between the description
> of the RFP in the announcement that was sent out and the RFP
> itself (aggravated very slightly by the link in the announcement
> not being correct).  I apologize for that confusion at the same
> time I suggest that propriety suggests that they should be
> consistent.
> 
> That said, I understood that this was to hire someone to write a
> requirements document.  I suggest that, if you want a fair and
> open process, it would be good to follow the rules closely
> enough to make it possible for non-insiders to bid (or to make
> it explicit that only insiders and regular attendees are
> eligible).
> 
> As I mentioned in my response to Henk, what you ask for in an
> RFP not only affects what you get (even if all you are looking
> for is a requirements spec) and who is likely to consider it
> plausible to bid.  More important, I see nothing in BCP 101 that
> says that the IAOC does not need to expose draft RFPs to
> community review just because they do not, e.g., require code to
> be written.  If the IAOC believes that such an exception is
> needed because things don't work without it, then BCP 101 very
> explicitly requires that the IAOC submit a change proposal to
> the community.  That hasn't been done, so there is no exception.
> 
>> Note that it
>> explicitly calls for having community input into the
>> requirements.  The RFP includes:
>> 
>>  "After gathering all of this input, the contractor will
>> prepare aninitial specification for review by the IETF
>> Tools Team and thevmeet mail list participants."
>> 
>> and
>> 
>>  "Specifications will be circulated as IETF Internet-Drafts
>> (I-D)"
> 
> Right.  But those are provisions for community review of a
> requirements spec, expressed as an I-D.  We know how to handle
> those, especially if you already have General AD and IESG
> agreement for a Last Call.  What I'm concerned about is
> community review of the RFP to be sure that any proposals
> address the right set of issues and use adequate mechanisms to
> be sure a good spec is developed (see my note to Henk).
> 
>> The intent of this work is to develop a set of requirements
>> for community review.  I don't see any significant value in
>> asking the community for input on an RFP that is for hiring
>> someone to write a specification to generate community input.  
> 
> Again, I don't believe that BCP 101 or the associated
> discussions and precedents give you (or the IAOC) the authority
> to eliminate community review on the grounds that you don't see
> it as having significant value.  Consider what would happen if
> the IESG decided to waive IETF Last Call on a Standards-Track
> document on the grounds that they understood the community well
> enough to know that such a Last Call would be unlikely to yield
> any signi

Re: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Bob Hinden]

John,

The RFP is not a solicitation to vendors of remote participation services.  It 
is to hire someone to write a requirements document for remote participation 
services.  It is not to develop any code nor are the items listed in the RFP 
the only things that should be included.  Note that it explicitly calls for 
having community input into the requirements.  The RFP includes:

  "After gathering all of this input, the contractor will prepare an
   initial specification for review by the IETF Tools Team and the
   vmeet mail list participants."

and

  "Specifications will be circulated as IETF Internet-Drafts (I-D)"

The intent of this work is to develop a set of requirements for community 
review.  I don't see any significant value in asking the community for input on 
an RFP that is for hiring someone to write a specification to generate 
community input.  

Also, while the SOW does not indicate it, because it is not something the 
contractor will do, the Internet-Draft will be "last called" to confirm that it 
represents community consensus.  This will be done by the General AD as has 
been done earlier with other specification tasks.

Regarding the IAOC minutes, the IAOC is aware that there is a problem.  I am 
sorry to report that the current volunteer approach to taking and producing 
IAOC minutes is not working.  I had hoped we could make the volunteer approach 
work.  The IAOC concluded on today's IAOC call that we should approach ISOC to 
get additional administrative support to improve this function.  I will report 
on the outcome of that in Taipei.

Regards,
Bob



On Oct 20, 2011, at 1:27 AM, John C Klensin wrote:

> Ray and IAOC,
> 
> I hate to keep bringing this up, but the discussions leading up
> to BCP 101 and the oft-replated principle of "maximum amount of
> transparency to the IETF community that can be reasonably
> obtained" strongly suggest that documents that are intended to
> evolve into RFPs be circulated in draft to the IETF community
> for comment.  If there is some reason why that it not possible,
> reasonable transparency suggests that the IAD or IAOC
> proactively provide an explanation to the community, rather than
> waiting to be asked.   
> 
> Community review of draft RFPs is particularly important
> because, for reasons outlined in BCP 101, there is little
> opportunity for effective community input once proposals are
> received and contract negotiations start.
> 
> Each time this issue has been raised in the past, the IAOC has
> agreed that exposing RFP drafts is The Right Thing to do, yet
> RFPs keep appearing without opportunity for community review.
> 
> Two omissions from this document illustrates why community input
> is important:
> 
> (1) I don't know how much experience IAOC members have with
> trying to participate remotely, but, having done so, there are
> insights into what is needed that one just cannot obtain by
> physically attending a meeting and observing how things work.
> If any RFP or subsequent contract does not provide for input
> from, and probably interviews of, selected people who have tried
> to participate remotely while carrying out various roles, then
> the odds are high that the resulting work will not be adequate
> in practice.  Instead, this RFP appears to provide only for
> "observ[ing] group and plenary sessions" and then review of the
> initial specifications by groups that are unlikely to include
> the full range of remote participants.  
> 
> It seems to me that a call for comments from those with actual
> remote participation experience and for contractor interviews
> with a selection of those people.   There is a long history of
> asking developers and tool-builders what users need.  The
> perceived success level in having a process that is limited to
> asking developers and tool-builders produce results that
> actually match user needs has been abysmal. 
> 
> (2) The list of "Environments" is also interesting.  Whether
> caused by health issues, travel limitations, or other
> considerations beyond the control of the individuals, we've had
> experience that has required remote participation of IAB and
> IESG members, members of key committees (the RSOC and RFC
> Editorial Board are on my mind at the moment, but, if the IAOC
> itself has not been affected yet, I believe that is only a
> matter of time).  At least parts of the meetings of those groups
> are, properly, not open.  While most of those meetings are
> scheduled far in advance, ad hoc sessions for which
> participation by members who happen to be remote do occur.
> Those bodies and meetings create remote participation
> requirements that are quite different from the environments
> listed -- small meeting support that goes well beyond "8 being
> simultaneous at any one time", a need for session privacy, and a
> need to accommodate meetings that are scheduled on relatively
> short notice.
> 
> I don't fault the IAD or IAOC for failure to identify those
> types of issues 

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

John,

I don't see how you took what I said and then interpreted it as suggesting that 
I was saying proposing an "absolute dictatorship".  You do have a good 
imagination :-)

Also, I have been proposing some other ways of solving the I* overload problems 
as you suggested, except that I don't think the solution to the I* overload 
problem is in the IASA.  

If we (the community) are going to solve the I* overload problem, it would be 
good to have some actual data on how the I* chairs spend their time.  It would 
be good to have a better understanding of the problem before proposing 
solutions.

Bob


> 
> 
> --On Friday, September 23, 2011 11:04 +0300 Bob Hinden
>  wrote:
> 
>>> I also claim that for the third item there is no necessity
>>> for the I* chairs to be a voting member, nor for the fourth.
>>> That said, I am sensitive to the argument that if I* chairs
>>> are members they may actually pay more attention (human
>>> nature and such) and that being effective at those item
>>> without being a member is tough.
>> 
>> I theory I can agree, but in practice I think the more
>> separation there is the more likelihood for organizational
>> problems.  
>> ...
> 
> Bob,
> 
> Of course.  But that is just a corollary to an old principle
> that, if one wants a really efficient government, with minimal
> chances of "organizational problems", the most efficient form is
> an absolute dictatorship (or an absolute monarchy) with one
> person in charge of, and responsible for, everything.  As long
> as that person is competent and has the bandwidth, things are
> nothing if not efficient and, some aesthetic and moral issues
> aside, the only major disadvantages are that there is a single
> point of failure for the entire system and recruiting
> appropriate dictators (or monarchs) has a long history of being
> problematic.
> 
> We have chosen, I think for really good reasons, to avoid that
> sort of model.  That --almost inherently-- means that there will
> be some inefficiency and some risk of organizational problems.
> Frankly, I'd rather have that risk in the IASA, than having it
> affect the ability of the IAB and IESG to do substantive
> (standards and external relationship) work.  That doesn't mean I
> want an inefficient and organizationally-troubled IASA, only
> that, if there is pain, I think that the IASA --which, should it
> become necessary, is also more easily reorganized without
> significant disruption to the IETF's work than the IESG or IAB--
> is the right place to feel, and deal with, that pain.  For that
> reason, I'd much prefer to to have IASA leaders saying "well
> this might be bad for the IASA, but we've thought about it and
> these are ways to make the best of a bad situation" rather than
> what often seem to be variations on a theme of "the IASA (IAOC,
> Trust) are so much more important than anything else that, if
> something has to suffer inefficiency or organizational problems,
> it should obviously be the IAB and IESG".
> 
> I don't think you really intend to say that, but it is what some
> of your (and other) comments come out sounding like.  YMMD.
> 
>john
> 
> 
> 
> 
> 

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Olaf,

On Sep 21, 2011, at 7:59 PM, Olaf Kolkman wrote:

> 
> On Sep 21, 2011, at 4:27 PM, Bob Hinden wrote:
> 
>>> 
>>> It is important for the I* chairs to be connected with the community.
>>> It is important for the IAOC to be connected with the community.
>>> It is important for the I* chairs to be informed about what is happening in 
>>> the IAOC
>>> It is important for the IAOC to be informed about what the I* chairs find 
>>> important.
>>> 
>> 
>> Yes, but I don't understand your point.  We get that today with the current 
>> makeup.  Your proposal breaks these links.
> 
> Oops..I did not finish the paragraph.


That makes more sense :-)

> 
> 
> Retry:
>>> It is important for the I* chairs to be connected with the community.
>>> It is important for the IAOC to be connected with the community.
>>> It is important for the I* chairs to be informed about what is happening in 
>>> the IAOC
>>> It is important for the IAOC to be informed about what the I* chairs find 
>>> important.
> 
> I claim that the first two items are independent of I* chairs being voting 
> members of the IAOC.
> 
> I also claim that for the third item there is no necessity for the I* chairs 
> to be a voting member, nor for the fourth. That said, I am sensitive to the 
> argument that if I* chairs are members they may actually pay more attention 
> (human nature and such) and that being effective at those item without being 
> a member is tough.

I theory I can agree, but in practice I think the more separation there is the 
more likelihood for organizational problems.  The point I am trying to make is 
that there needs to be close coordination between the IESG/IAB/ISOC and having 
a responsible person (currently the chairs, there are other possibilities as 
outlined in some other emails, XO model, etc.) taking voting responsibility is 
the best way to implement that.  It won't happen if it's just another person 
the, for example, the IESG appoints as your proposal sugests.  Likewise, I 
don't think having the chairs be non-voting members will work because the 
chairs are too busy for this to work over time.

Bob


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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Jari,

On Sep 21, 2011, at 5:50 PM, Jari Arkko wrote:

> Bob,
> 
>> Goggle translate was helpful here :-)
>> 
> 
> Good... and next time when we meet over beer I can reveal the correct 
> translation :-)

Cool!

> 
>>> I do like your idea that IAOC itself needs to work smarter though. It 
>>> should really be just a board, not the guys doing the actual work. As an 
>>> outsider, it sometimes feels like you guys are doing too much. In any case, 
>>> if you and Bob think this would be a good direction for the IAOC to take, 
>>> can you comment how feasible it is? Has it been tried, could it be tried? 
>>> (And shouldn't it already be done if it was easy?)
>> I am not sure what you mean by the members of the IAOC doing the actual 
>> work.  The IAD does most of the work behind the scenes.  That includes 
>> writing RFPs, motions, budgets, SOWs, agendas, works with the volunteer 
>> minute takers to produce the minutes, organizes contractor reviews, 
>> negotiates with contractors, works with ISOC finance department, works with 
>> legal council, organizes conference calls and meetings, etc., etc.  The 
>> secretariat does the leg work to collect information on venues, costs, 
>> hotels, etc.  The IAOC voting members review, comment, approve/disapprove 
>> things, but that's not where most of the real work is.  The voting members 
>> are responsible for the decisions and actions.  I want to make it clear that 
>> most of the actual work is not done by the voting members.   Given the 
>> source of our members, we do tend to get involved in details for better or 
>> worse.  The IAOC (and Trust chairs) have a bigger load than the rest of the 
>> voting members.
> 
> This all sounds good. But do you agree that workload for the chairs is an 
> issue? Because I thought Jonne was saying that it is an issue and the 
> solutions should come from a better organization within the IAOC rather than 
> from Olaf's proposal. But if I read the above, it almost sounds like you 
> think everything is done pretty much as well as it can be done, and there's 
> little to change. Up-leveling the discussion: I guess we need to agree about 
> the problem statement before we can talk about the solutions.

Firstly, I was correcting your assertion that the IAOC voting members were 
doing most of the work.

I am sure things can be improved, but I don't think the work load of the IAOC 
voting members is onerous.  Certainly, less than, for example, being on the 
IESG.  It's not a full time job.  I think there is a reasonable balance between 
what the IAD and contractors/staff do and the IAOC voting members, not perfect 
of course.  It may be working better now than earlier.  

I do agree that there are issues with the load of the I* chairs.  My issue is 
with this solution.  

Bob


> 
> Jari
> 
> 

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Frank,

On Sep 23, 2011, at 10:45 AM, Frank Ellermann wrote:

> On 22 September 2011 20:02, Michael StJohns wrote:
> 
>> I actually think that delegating this to a co-chair or executive
>> vice chair would work.  The similar military model is
>> commander/executive officer where the commander (chair) is
>> responsible for strategic thinking and the XO (co-chair) is
>> responsible for tactical execution.  Also the commander tends to
>> be outward facing and the XO inward facing.
> 
>> I don't know that the models are close enough to be a perfect fit,
>> but they might suggest some ways of splitting up the load.
> 
> A "general area" with two ADs like all other areas, where one AD is
> the Chair, and the other AD the XO, sounds like a good idea.  Do
> they decide who does what, and swap roles when they feel like it,
> or is that predetermined by NomCom?

I think the IESG defines it's structure (e.g., deciding on a new area, two ADs 
per area, etc), then Nomcom then fills the positions.  

Bob


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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Mike,

On Sep 22, 2011, at 9:02 PM, Michael StJohns wrote:

> Hi Bob - 
> 
> I actually think that delegating this to a co-chair or executive vice chair 
> would work.  The similar military model is commander/executive officer where 
> the commander (chair) is responsible for strategic thinking and the XO 
> (co-chair) is responsible for tactical execution.  Also the commander tends 
> to be outward facing and the XO inward facing.
> 
> I don't know that the models are close enough to be a perfect fit, but they 
> might suggest some ways of splitting up the load.

I prefer something like this vs. the current proposal.  The XO model is very 
tied in to the commander and it's reasonable to expect them to be in sync on 
important issues.  He/she probably doesn't last long if there isn't a close tie 
in.  Having the XO then be on the IAOC (and Trust) would work.
 
> 
> If you wanted the chair to retain the IAOC/Trust, you'd have to be able to 
> figure out what other responsibilities to parcel off to the co-chair. I'm not 
> sure I agree with you that the IETF chair MUST be on the IAOC.  In any case,  
> I definitely think giving a co-chair the General Area would make sense.  
> Maybe also sticking him/her with the document review responsibility (but 
> leave the decision for the vote in the chair's hand but be based on the 
> co-chairs recommendation).

Yes, something like that.  


> 
> The other reason I suggested adding a co-chair is that our process of finding 
> an IETF chair replacement is haphazard at best and criminally negligent at 
> worst.  I'd really like to get a few apprentices identified and qualified 
> before Russ quits or dies from overwork.  Having someone do part of the job 
> and observe the rest seems to be a reasonable approach to meeting that (what 
> I perceive as a ) need.
> 

I generally agree, but I would still have it be a nomcom decision.  If they 
didn't think the XO was ready to be promoted (following your model) to 
commander, they could bring someone else in.

Bob



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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Mike,

On Sep 22, 2011, at 2:01 AM, Michael StJohns wrote:

> I've been watching this with interest.  I'm especially in agreement with 
> Leslie's comments about chair load.
> 
> Because of the legal issues with respect to the IETF trust and the 
> implementing documents for the IAOC, its going to be pretty difficult to come 
> up with a way to remove some of the responsibilities from the Chairs (meeting 
> attendance, voting, etc) without also removing the authority.
> 
> We're arguing somewhat in circles.
> 
> I agree with Bob's comments below that the leadership of the IESG and the IAB 
> need to be involved in the operation of the IAOC, but I no longer think there 
> are enough hours in the day for the IETF and IAB chairs to be able to do 
> everything they need to do.
> 
> I hesitate to suggest this, but its probably time:
> 
> Let's add a position to the IESG - Executive Vice-Chair or Co-Adjutor Chair.  
>  Basically, either the chair's personal representative (Executive Vice-Chair) 
> or their replacement in waiting (Co-Adjutor Chair).
> 
> Have the IAB select a vice-chair when they select the chair.
> 
> Modify the various documents to describe the various responsibilities for the 
> Vice-chairs - suggestions for the IETF co-chair would be to stick him/her 
> with the IAOC, the Trust and at least half of the Administrivia..  For the 
> IAB - ditto plus liaison and appeals.
> 
> Modify the IAOC documents to permit either of the two co-chairs to be 
> designated for a year at a time as IAOC members by the respective chairs 
> choice (but can't be pulled off once on).   No modificiations to the Trust 
> legal document, but probably modify the administrative document to require 
> the chair and co-chair for the IAB and IETF be invited to all non-closed 
> meetings.
> 
> Job description to the Nomcom - for the IETF, the co-chair is a 
> chair-in-training with the expectation they may make a decent Chair when and 
> if the time comes.  Maybe rotate that job every two years regardless to 
> ensure a couple of people with some of the chair experience are in the pool.  
> Maybe even every year.

I think something like you propose would be better than what the current draft 
proposes.

I think the three chair positions we are discussing are different and need 
different solutions.  For example:

ISOC CEO/President

This responsibility can't be delegated to just anyone.  It needs to be an 
officer of ISOC.  For example the Chief Financial Officer (CFO) or Chief 
Operating Officer (COO).  It's very different from the board selecting another 
IAOC member, there needs to be someone from ISOC who has fiduciary 
responsibility in ISOC.  While I don't think having the CFO or COO would be 
good as having CEO, it would be workable.

IAB Chair

The IAB chair is selected by the IAB, it's not an nomcom selected position.  As 
you propose, if the IAB created another leadership position, maybe analogous to 
an IAB COO that could work.  It would have to be a leadership position in the 
IAB with real responsibility, including being a voting member of the IAOC and 
IETF Trust.

If the IAB doesn't want to do this, then the IAB should consider ways of 
reducing it's load.  It has taken on more responsibility in recent years.  I 
think some of that could be moved out of the IAB.  For example, the IAB could 
more fully delegate decision making to the RSOC and only deal with appeals.

IETF Chair

The IETF chair is chosen by the nomcom.  The job requirements are clear in 
advance.  Anyone applying is aware of the job.  I don't think the IETF Chair 
position on the IAOC and IETF Trust can be delegated to anyone else without 
serious risk to the overall IETF standards operation.  The IETF chair needs to 
be a voting IAOC and IETF Trust member.  Too much of the IETF operation for 
it's successful operation is tied to the IETF chair for he/she to delegate it 
to anyone else.  It's just part of the job.   

I think we should look for other ways to reduce the load on IETF chair, like 
giving up the general area (have a separate AD for that), or a more 
comprehensive change to the IESG where more of the decisions are moved to 
individual areas (e.g., add an other level to the IESG).  The IESG is getting 
large for a flat management structure.

Bob


> 
> Mike
> 
> 
> 
> At 10:27 AM 9/21/2011, Bob Hinden wrote:
>>>> I think it's very important for the I* chairs to share the responsibility 
>>>> for IAOC decisions by being voting members.  
>>> 
>>> Why?
>> 
>> 
>> So we don't have the IESG and IAB having disputes with the IAOC.  Having the 
>> IETF and IAB chairs share the decisions avoids a lot of this.  I think you 
>> are aware of a few times where we got close to this and I think the current 
>> structure helped avoid it.
> 
> 

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Olaf,

On Sep 20, 2011, at 1:51 PM, Olaf Kolkman wrote:

> 
> Thanks Bob,
> 
> I appreciate your thoughts on the matter!

Thanks.

> 
>> 
>>> 
>>> Dear Colleagues,
>>> 
>>> Based on the discussion I've updated the draft:
>>> http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
>>> 
>>> Essentially I incorporated Dave Crocker's proposal to 
>>> 1) replace the 'chairs' by voting members appointed by the respective 
>>> bodies.
>>> 2) allow the chairs to participate in all meetings and provide 
>>> (unsolicited) advice.
>> 
>> 
>> There were many comments on your earlier draft and I don't see how these 
>> changes resolve all of issues raised.  The new draft is different, but I 
>> think the main issues remain.  Could you show how the issues raised are 
>> solved by the current draft?
>> 
>> For example, there seemed to me to be a rough consensus in the discussion on 
>> the earlier draft that the IETF Chair should not be included in the 
>> proposal.  Why did you not remove the IETF chair from the proposal?
> 
> 
> I did not see that rough consensus, but let us not argue that, I believe it 
> is up for Jari to say were the consensus is.

To repeat what I said, I didn't see the new draft resolving issues that I and 
other raised on the list. The new draft is a different approach, but as Leslie 
pointed out, it might be worse.  In the old draft, the I* chairs were allowed 
to appoint someone to represent them, in the new one they are non-voting 
advisors.  Busy people being busy, will tend to not follow or attend the 
meetings.  Many small decisions can have unintended consequences.  

> 
> To the substance of that point: there is an argument to be made that if the 
> IETF Chair has full voting power than the IAB chair should so to. I believe 
> that it is beneficial for the organization if there is some symmetry there. 
> 
> For completeness, and in relation to that symmetry argument.  Jari wrote in 
> another mail:
>> And if the chairs have to be voting members in IAOC, why aren't they voting 
>> members in IAB and IESG?
> 
> The IETF Chair is voting (full) member of the IAB (see section 1.1 of RFC 
> 2850)
> The IAB Chair is ex-officio member of the IESG (see RFC3710 section 2) but 
> for Decision making the IAB chair is excluded from the consensus process 
> (RFC3710 section 3.1 2nd paragraph). The obvious reason for that is that the 
> IAB is in the appeal chain.


I am not sure I understand the point here.  Further, isn't this cross 
membership another cause of I* chair overload?  Why not eliminate that too?  
Why are you only considering the IAOC roles?  Why is the IETF chair a member of 
the IAB and why does the IAB chair attend IESG meetings?  Wouldn't the reduce 
their load too?  They could appoint a liaison?  Same for the ISOC CEO.


> 
> 
>>> I believe that allows chairs to exercise their responsibilities of keeping 
>>> a coherent perspective of the organization an allow them to steer outcomes 
>>> if needed, but doesn't require the day-to-day involvement that is required 
>>> from a diligent voting member.
>> 
>> As I said earlier, I continue to think this is a bad idea.  We now have a 
>> system that works well.  Certainly not perfect, but I am concerned your 
>> proposed changes will make it work worse.
> 
> At some point I'd be perfectly happy to agree to disagree on the merit of the 
> idea. But I want to understand the motivation and make sure there is nothing 
> actionable on my side.

Other than dropping the proposal :-)

I agree there is a problem with I* chair overload, but you have proposed a 
point solution without having the general discussion.  It would be better if 
the community had that discussion before evaluating solutions.  

> 
>> In my time as IAOC chair, the I* chairs have been actively involved in the 
>> most significant decisions the IAOC makes, they tend to be less active in 
>> many of the day to day operational issues.  For example, there are weekly 
>> calls in the months before an IETF meeting that the host, NOC team, IAD, 
>> host, and other people attend.  I don't think an I* chair has been involved 
>> at this level.  Also, the IAOC has several subcommittees (e.g., meetings, 
>> budget, specific RFPs, and Tools).  I* chair attendance in these varies.  
>> The IETF chair is very active in the RFP subcommittee and Tools.  The ISOC 
>> chair has reduced her attendance in the subcommittees.
>> 
> 
> There is no requirement that members of committees are IAOC members, is there?

It's usually a mix of IAOC members and invited members.  The subcommittees make 
recommendations to the IAOC, the IAOC make the decision.

> 
> 
>> I think the I* chairs bring a broad view of the community and operational 
>> needs based on what's involved in doing their jobs than other appointees 
>> would not have.  In order for the I* chairs to be effective, they will need 
>> to be involved.  If they are involved, then they might as well be voting 
>> members.  
>> 
>> With t

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Jari,

A few comments on your email to Jonne.  

On Sep 19, 2011, at 9:36 PM, Jari Arkko wrote:

> Jonne,
> 
> First, I want to thank you for the clear expression in Finnish. (Maheeta! 
> Vaikka näiden muutosten läpivienti alkaa kyllä tuntua siltä kuin jäitä 
> polttelisi, saa odottaa perse ruvella että kukaan olisi samaa mieltä mistään, 
> 'kele!) Too bad the English version was not as graphic.

Goggle translate was helpful here :-)


> 
> Anyway, I like your description of the issue and it helps me understand the 
> concerns. That being said, I could probably construct a similar argument for 
> all of the bodies that an IETF chair, for instance, has to attend. Are we 
> really saying that under all circumstances, the chairs have to attend 
> everything that IAOC deals with? And be voting members? And if that is too 
> much then the entire IAOC has to delegate more of its work? Really? And if 
> the chairs have to be voting members in IAOC, why aren't they voting members 
> in IAB and IESG?
> 
> I have some trust in the chairs ability to prioritize, delegate and engage in 
> the important discussions.

They do that today.

> 
> I do like your idea that IAOC itself needs to work smarter though. It should 
> really be just a board, not the guys doing the actual work. As an outsider, 
> it sometimes feels like you guys are doing too much. In any case, if you and 
> Bob think this would be a good direction for the IAOC to take, can you 
> comment how feasible it is? Has it been tried, could it be tried? (And 
> shouldn't it already be done if it was easy?)

I am not sure what you mean by the members of the IAOC doing the actual work.  
The IAD does most of the work behind the scenes.  That includes writing RFPs, 
motions, budgets, SOWs, agendas, works with the volunteer minute takers to 
produce the minutes, organizes contractor reviews, negotiates with contractors, 
works with ISOC finance department, works with legal council, organizes 
conference calls and meetings, etc., etc.  The secretariat does the leg work to 
collect information on venues, costs, hotels, etc.  The IAOC voting members 
review, comment, approve/disapprove things, but that's not where most of the 
real work is.  The voting members are responsible for the decisions and 
actions.  I want to make it clear that most of the actual work is not done by 
the voting members.   Given the source of our members, we do tend to get 
involved in details for better or worse.  The IAOC (and Trust chairs) have a 
bigger load than the rest of the voting members.

Bob



> 
> Jari
> 
> On 19.09.2011 15:35, jonne.soini...@renesasmobile.com wrote:
>> Hi Olaf,
>> 
>> I went through the draft just now, and I have some quite strong feelings
>> about it. I'm sorry I'm sending my comments so late in the game.
>> 
>> A disclaimer first: I was the chairman of the IAOC some years back, but I
>> haven't been actively involved with IETF administration after that.
>> Therefore, my reactions are based on the history, and I don't necessarily
>> have the up-to-date information of today, anymore.
>> 
>> Anyways, I thank Olaf of bringing up this real problem: the IAOC is a lot
>> of work measured in time, and effort. At least, when I was there, I think
>> it was too much work for people who were already busy in so many other
>> ways.
>> 
>> However, I think the solution is a bit "menemistä perse edellä puuhun" (==
>> putting the cart before the horse): The IAOC should be a _strategic_ body
>> that gives a direction for the administration of the IETF. Basically IAOC
>> is the closest you have to the board of the IETF (financial management,
>> asset management, management of the operations). Therefore, by design, you
>> have the stakeholders represented in the body (the main chairs, the
>> president and CEO of ISOC).
>> 
>> The Trust on the other hand is everything the IETF has (as ownership - the
>> biggest asset the IETF has is of course the community). It owns the fruits
>> of the labour of the whole community - the intellectual property that the
>> community creates. I think it is very clear that the main stakeholders
>> (the I* chairs) and the main responsible for the administrator of the
>> trust (the president/CEO of ISOC) have to be trustees and show ownership
>> of the trust - you just cannot delegate that.
>> 
>> Like said, I understand the problem: The IAOC is a lot of work for people
>> who already have a lot to do. However, I think that problem should be
>> managed without reducing the oversight of the IETF leadership over the
>> IETF financials, assents, and other important activities.
>> 
>> Perhaps, the IAOC should think how to reorganize, and strengthen the
>> operational part of the IETF to reduce the burden of the IAOC. This might
>> mean increasing the level of investment to the operations of the IETF to
>> make sure the IAOC members do not have to be part of the operational
>> stuff, but can concentrate on making just the strategic decisions and
>> doing 

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Jari,

On Sep 19, 2011, at 4:10 PM, Jari Arkko wrote:

> Bob,
> 
> I appreciate your view on this, particularly when you are day-to-day seeing 
> how the current system works with IAOC.

Thanks.  I also note that several past IAOC chairs have expressed concern about 
this proposal as well.  That should be given some weight.

> 
> That being said, I do think it is important to give some flexibility to 
> chairs on organizing their work. And it is important to provide tools for 
> them to manage their time, including ability to delegate some tasks.

For sure, but why only address this aspect of their jobs?  We should be talking 
about the general problem before evaluating a point solution.  We don't 
normally take this approach when chartering working groups, their usually has 
to be a discussion of the problems before proposing specific solutions.

> 
> I understand the point about chairs being involved. But I'm also sure there 
> will never be an IAB/IETF chair who would ignore important IAOC business. 
> This draft is about the ability (but not a requirement) of the chairs to 
> delegate most of the day-to-day business and just stay on for the important 
> stuff. One practical issue is that if the chairs under today's rules would 
> stay out of the day-to-day business, that would mean missing one voting 
> member. I'm not sure that is desirable either, and I really don't think you 
> want to force them to be in every meeting.

 
I don't think it so easy to distinguish between "important IAOC business" vs. 
"day to day".  "Day to day" decisions can have unexpected consequences.  It's 
just not that black and white.  Also, different chairs get involved in 
different things.  The IETF chair is very involved in tools, secretariat 
related issues, venues, the IAB chair is involved in RFC editor related issues, 
the ISOC CEO is very involved in the budget.  It's not all the same.  Their 
involvement varies a lot depending on the topic and their role.

The proposal treats them all the same.

> 
> I also understand the point about chairs sharing the responsibility for 
> decisions. I just don't think the suggested new scheme would affect that. The 
> IAOC would for sure still listen to a message from the chairs very carefully. 
> And if you are in any board with multiple people having voting power, if the 
> rest of the board ignores your opinion it really doesn't matter if you lost 
> by 1-9 or by 0-9... (and again, any of the chairs would for sure still be 
> behind the decisions anyway.)

Having a vote is very different from just being an advisor.  

I also think that over time, the chairs will become less involved in the IAOC 
because they are busy.  It doesn't make sense to me to say on one hand that the 
chairs are too busy to be voting members of the IAOC, but at the same time they 
will have enough time to effect important decisions.  It doesn't work that way 
in practice.  

Bob


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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Olaf,

On Jul 26, 2011, at 3:52 PM, Olaf Kolkman wrote:

> 
> Dear Colleagues,
> 
> Based on the discussion I've updated the draft:
> http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
> 
> Essentially I incorporated Dave Crocker's proposal to 
> 1) replace the 'chairs' by voting members appointed by the respective bodies.
> 2) allow the chairs to participate in all meetings and provide (unsolicited) 
> advice.


There were many comments on your earlier draft and I don't see how these 
changes resolve all of issues raised.  The new draft is different, but I think 
the main issues remain.  Could you show how the issues raised are solved by the 
current draft?

For example, there seemed to me to be a rough consensus in the discussion on 
the earlier draft that the IETF Chair should not be included in the proposal.  
Why did you not remove the IETF chair from the proposal?


> I believe that allows chairs to exercise their responsibilities of keeping a 
> coherent perspective of the organization an allow them to steer outcomes if 
> needed, but doesn't require the day-to-day involvement that is required from 
> a diligent voting member.

As I said earlier, I continue to think this is a bad idea.  We now have a 
system that works well.  Certainly not perfect, but I am concerned your 
proposed changes will make it work worse.  

In my time as IAOC chair, the I* chairs have been actively involved in the most 
significant decisions the IAOC makes, they tend to be less active in many of 
the day to day operational issues.  For example, there are weekly calls in the 
months before an IETF meeting that the host, NOC team, IAD, host, and other 
people attend.  I don't think an I* chair has been involved at this level.  
Also, the IAOC has several subcommittees (e.g., meetings, budget, specific 
RFPs, and Tools).  I* chair attendance in these varies.  The IETF chair is very 
active in the RFP subcommittee and Tools.  The ISOC chair has reduced her 
attendance in the subcommittees.

I think the I* chairs bring a broad view of the community and operational needs 
based on what's involved in doing their jobs than other appointees would not 
have.  In order for the I* chairs to be effective, they will need to be 
involved.  If they are involved, then they might as well be voting members.  

With the changes you propose we could end up with an IAOC that none of the I* 
chairs participate.  As you point out, they are all busy and will have a hard 
time to following the issues if their involvement is optional.  This will 
result in an IAOC that is disconnected from the community.  

I think it's very important for the I* chairs to share the responsibility for 
IAOC decisions by being voting members.  Same for the IETF Trust, your proposal 
would result in the I* chairs not being members of the IETF Trust (unless the 
Trust was changed, another issue in itself).  

The current structure with the I* chairs being voting members of the IAOC has 
worked well.  The I* members are involved in the important decisions, share the 
responsibility for the decisions, and keep the IAOC/IASA connected to the 
community.  

I am sympathetic to the issue this draft is attempting to resolve, but I think 
there are better ways to reduce the load we put on the I* chairs, than what 
this draft proposes.

Bob



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

Re: 2119bis

[Bob Hinden]

On Sep 1, 2011, at 7:49 AM, Donald Eastlake wrote:

> I do not believe there is any need to change RFC 2119.

+1

Bob


> 
> Thanks,
> Donald
> =
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
> 
> 
> On Wed, Aug 31, 2011 at 9:28 AM, Scott O. Bradner  wrote:
>> I've been traveling so have not had a chance to do anything but watch
>> the discussion on a RFC 2119 update.
>> 
>> a few thoughts
>> 
>> 1/ I am far from convinced that there is a need to update RFC 2119
>>  there is a bug in the boilerplate (as has been mentioned)
>>  and some people seem to have a hard time understanding what
>>  (to me) seem like clear descriptions of (for example) MUST &
>>  SHOULD - but the issues do not seem serious enough to warrant
>>  replacing what is, basically, a simple dictionary & usage
>>  constraint
>> 
>> 2/ it seems like a very Bad Idea to move 2119 to historic- we move
>> RFCs to historic when no one uses them or when they are a Bad
>> Idea in light of updated technology - I do not think that makes
>> much sense in this case - in addition it makes the status of RFCs
>> that have a normative reference to a historic document a bit
>> funky - if an update is actually needed there is no reason that
>> I can come up with that it could not just be that -- an update
>> 
>> 3/ I doubt that I'll ever catch up with Postel as the most referenced
>> RFC author so that is not a consideration (for me)
>> 
>> I wrote RFC 2119 (most using text from RFC 1122) because people were
>> using MUST without saying what they meant, an update, if people think
>> that one is actually needed, will serve that purpose as well as 2119 has.
>> 
>> When I posted the original ID it was pointed out that I should also
>> address when such terms should be used (i.e. try to limit the use to
>> where it actually made sense protocol-wise) - I tried to do that but
>> that part may not have been as successful as it might have been - any
>> update might try to be clearer in this area that RFC 2119 is.
>> 
>> Scott
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

[Bob Hinden]

Dave,

On Fri, Jul 29, 2011 at 9:53 AM, Dave CROCKER  wrote:
>
>
> On 7/29/2011 11:13 AM, Russ Housley wrote:

 (2) At any time after two years from the approval of this document as a
 BCP, the IESG may choose to reclassify any Draft Standard document as
 Proposed Standard.
>>>
>>> I think this is unfair to the people who have done considerable work to
>>> get
>>> a document to Draft Standard.  I hope that the IESG would only do this
>>> after giving a lot of notice to the authors, appropriate working groups,
>>> and the IETF community to give them the opportunity to request
>>> advancement
>>> to Internet Standard.
>>
>> This was added after the discussion that Draft Standards could linger for
>> a
>> very long time.  Some people said that would not be a problem, and other
>> people said it would be harmful.  I conclude that no one knows, so we
>> should
>> include the powers necessary to resolve the problems if they emerge.  If
>> they
>> do not emerge, there is no requirement that the IESG do anything.
>
> If a document no longer has anyone watching it, there's a reasonable concern
> that it no longer has much constituency.  In that case, it's better to treat
> it as immature rather than mature.

In order to have reached Draft Standard, the w.g. must have shown
multiple implementations.  In at least one case I can think about the
protocol is very widely used operationally.  The working group is
disbanded, only the mailing list remains.  The protocol is very mature
and stable.  It's only the IETF activity that is inactive.

You can't measure maturity of a protocol at draft standard by looking
at the IETF activity.

Bob




>
>
>>> I think this Section of the document needs to provide additional detail
>>> on
>>> how this should work.
>>
>> I do not think we should add speculation about the potential problems to
>> this
>> document.
>
> +1
>
> d/
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

[Bob Hinden]

Hi,

I generally support this proposal, but have some questions on Section 2.3, 
"Transition to a Standards Track with Two Maturity Levels".  I am both an 
author of several Draft Standards and have chaired working groups that have 
produced them.

>Any protocol or service that is currently at the abandoned Draft
>Standard maturity level will retain that classification, absent
>explicit actions.  Two possible actions are available:
> 
>(1) A Draft Standard may be reclassified as an Internet Standard as
>soon as the criteria in Section 2.2 are satisfied.


What is the process for this?  Is the IESG going to review all Draft Standards. 
 Should authors and/or working groups propose a change of status as defined in 
the document?  Something else?  Most draft standards very likely meet most of 
the requirements listed in the document for Internet Standard.


> 
>(2) At any time after two years from the approval of this document as
>a BCP, the IESG may choose to reclassify any Draft Standard
>document as Proposed Standard.


I think this is unfair to the people who have done considerable work to get a 
document to Draft Standard.  I hope that the IESG would only do this after 
giving a lot of notice to the authors, appropriate working groups, and the IETF 
community to give them the opportunity to request advancement to Internet 
Standard. 

I think this Section of the document needs to provide additional detail on how 
this should work.

Regards,
Bob






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

Re: Getting to Quebec City

[Bob Hinden]

On Jun 18, 2011, at 12:09 PM, Alastair Johnson wrote:

> That's what I'm doing - the SFO-ORD-YQB fare was the same as flying to YUL.

+1

Bob


> 
> AJ
> 
> On 18/06/2011, at 11:50 AM, Michael StJohns  wrote:
> 
>> Why didn't you fly ORD-YQB? There's a 7pm flight that gets in around 10:23.  
>> It had to be cheaper than a hotel and train ride.
>> 
>> Mike
>> 
>> 
>> At 12:20 PM 6/18/2011, Ole Jacobsen wrote:
>> 
>>> Here is what I am doing:
>>> 
>>> * Fly SFO-ORD and ORD-YUL, gets me to Montreal at 21:14
>>> 
>>> * Spend the night at the Hilton Montreal, this is very close to the 
>>> train station.
>>> 
>>> * Take Train 620 @ 0830 from Montreal, arrives 11:35 in Quebec City 
>>> (if it runs on time :-)
>>> 
>>> That should at least get me to the meeting before the opening 
>>> reception, we'll see...
>>> 
>>> Yes, this involves an extra hotel night etc, but I think it will be 
>>> a lot less stressful.
>>> 
>>> Ole
>>> 
>>> 
>>> Ole J. Jacobsen
>>> Editor and Publisher,  The Internet Protocol Journal
>>> Cisco Systems
>>> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
>>> E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
>>> Skype: organdemo
>>> 
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Fwd: Draft Secretariat SOW for Community Comment: Deadline 20 May

[Bob Hinden]

Reminder, the comment period ends on Friday 20 May 2011.

Bob


Begin forwarded message:

> From: IETF Administrative Director 
> Date: May 6, 2011 4:23:30 PM EDT
> To: IETF Announcement list 
> Cc: wgcha...@ietf.org, ietf@ietf.org, i...@ietf.org, 
> rfc-inter...@rfc-editor.org, i...@iab.org, i...@ietf.org
> Subject: Draft Secretariat SOW for Community Comment: Deadline 20 May 
> 
> The IETF Administrative Oversight Committee (IAOC) plans to issue a
> Request for Proposal (RFP) in late May for a vendor to perform the
> Secretariat functions when the current contract ends on 31 January 2012. 
> To that end the IAOC invites community comments on the draft Statement of
> Work (SOW) that is located at .
> 
> The community comment period will run from 6 to 20 May 2011.  The IAOC
> will consider all comments it receives during that period. 
> 
> The Secretariat provides various meeting, IT, clerical, finance and other
> services to Supporting Organizations, including Working Groups, Internet
> Engineering Steering Group (IESG), Internet Architecture Board (IAB), IETF
> Administrative Oversight Committee (IAOC), and the Internet Research
> Steering Group (IRSG). 
> 
> Changes in this proposed SOW from the current Secretariat SOW include,
> but aren't limited to:
> 
>   1.  Provision of IAB Administrative Services (IAB Executive Assistant)
>   2.  Provision of NomCom Administrative Services (NomCom Executive
> Assistant)
>   3.  Provision of RFC Publisher Services, which will replace the current
> separate contract,
>   4.  Adding the RFC Series Editor (RSE), Independent Submissions Editor
> (ISE) and Nominating Committee (NomCom) to the list of Supported
> Organizations for which services may be provided in the future.
>   5.  Production of minutes of the IETF Meeting Plenaries
>   6.  Requirement to book meeting venues three years in advance, instead 
> of
> two years, and
>   7.  Requirement to cryptography sign Internet-Drafts
> 
> Community comment is due no later than 20 May 2011 to
> secretariat-2...@ietf.org.  One may subscribe to that list here:
> .
> 
> All information submitted in response to this announcement is voluntary
> and may be used in the development of the SOW and a subsequent RFP.
> 
> Thanks for your continuing advice and support.
> 
> Ray Pelletier
> IETF Administrative Director
> Internet Society 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: How to pay $47 for a copy of RFC 793

[Bob Hinden]

Steve,

On May 9, 2011, at 5:05 PM, Steve Crocker wrote:

> A simpler and more pragmatic approach is to include a statement in the 
> boilerplate of every RFC that says, "RFCs are available free of charge online 
> from ..."
> 
> The copyright rules would prohibit anyone from removing this statement.  If 
> someone pays $47 for a copy and then reads this statement, he is unlikely to 
> pay $47 again.
> 

I wonder how they came up with $47?  

It is such a nice prime number.  See:

  http://en.wikipedia.org/wiki/47_(number)

I recommend reading it.  I never knew that a number could be so interesting.

Bob

p.s. Maybe this can be the end of this thread...




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

Re: How to pay $47 for a copy of RFC 793

[Bob Hinden]

John,

> 
> The main difference is also familiar: the IETF wants to limit
> reproduction permission for published versions (presumably to
> continue to make money on them to offset other expenses) while
> we permit unlimited distribution and reproduction without
> special permission as long as the documents are intact or meet
> specific other criteria.  

Did you mean to say IEEE above?  

Bob



> A second difference is that we've
> never asked folks to go find online versions of I-Ds and update
> them to point explicitly to the successor RFCs.  I have no idea
> how one actually does that or enforces it but, in principle, it
> is an idea we might actually find it beneficial to consider.
> Finally, the IEEE insists on formal copyright transfer at a
> well-defined point (and, as far as I know, always has).  "We"
> don't think we need that.
> 
> best,
>   john
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Brian,

If we are going to do this, then I tend to agree with your conclusions.

> 
> 
>> I agree with you that the views of the I* Chairs are important.
> 
> In the case of the IETF Chair I believe the issue is that it's
> highly desirable, from a governance viewpoint, that the IETF Chair
> has *personal* responsibility in IAOC decisions, and therefore should
> be a voting member as a matter of principle.


My preference is that the IETF not delegate this responsibility.  One 
additional reason for this is that the IETF chair is appointed by the nomcom 
(vs. the IAB who appoints their own chair).  It is part of the job and an 
important part.


> I don't believe that argument applies to the IAB Chair - we should
> IMHO have a collective goal to sharply reduce the IAB's involvement
> in administrative issues, so that it can do its architectural and
> liaison jobs properly. Delegating the IAB Chair role in the IAOC
> would be a step in that direction, along with appointing the permanent
> RFC Series Editor.


In the case of the IAB, I would prefer that the IAB selected it's 
representative to the IAOC and that they become the full IAOC voting member 
(and a member of the IETF trust).  That is, it be completely delegated for a 
fixed term.  The IAB could consider this person as a vice-chair or even a 
co-chair.  The both represent other ways to reduce the load on the chair.  


> We haven't discussed the third proposed delegation, that of the ISOC
> President's seat, very much. Assuming it was delegated to another
> officer of ISOC, that would seem reasonable too. But it shouldn't
> be delegated to just anybody, IMHO.

Also agree.  I think it should be limited to the CFO or COO.  I think, as above 
with the IAB, it should be fully delegated.

Bob


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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

SM,

> Eric Burger
> Dave Crocker
> Marshall Eubanks
> Bob Hinden
> Ray Pelletier (non-voting)
> 
> None of them are new to the IETF.  If it requires I* Chairs for the IAOC to 
> be transparent, something is not right.

But that may not always be the case that all IAOC members have a lot of IETF 
experience.  We need to have a governance model that works into the future.  

> 
>> I think the I* chairs, in my view bring a broad view of the community and 
>> operational needs based on what's involved in doing their jobs than another 
>> person would not have.
> 
> If I understand your arguments, it is also about avoiding a disconnect 
> between the administrative side of the IETF and the IAB/IESG.

Yes

> 
> draft-kolkman-iasa-ex-officio-membership-00 argues for a change to reduce the 
> workload and make the I* Chair positions more attractive.  Would it help if 
> the IAOC Chair has a liaison position on the IAB and IESG?  The IAB and IESG 
> Chairs can use their discretion to determine which IAOC meetings they should 
> attend.  The IAOC Chair gets a broader view.
> 
> The above pushes the workload around instead of addressing the problem.  If 
> this trend continues, the best fit people will turn down I* positions.

It would certainly give the IAOC chair a broader view, but still not the views 
of the I* chair.  Also, if the I* chairs (3 of 9 voting members) regularly 
didn't attend, it would be much harder to get a quorum for a meeting and pass 
motions.  

Bob

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Dave,

On Apr 19, 2011, at 10:33 AM, Dave CROCKER wrote:

> Bob, et al,
> 
> On 4/18/2011 2:25 PM, Bob Hinden wrote:
>> I didn't say no one else could do the job adequately.  I said "would have a
>> negative impact" on the operations of the IETF.
> 
> Right. And my second sentence did go farther than I meant.
> 
> However rejecting an effort to change the current arrangement -- especially 
> when it is initiated by a principal -- means that alternatives are not 
> acceptable, which translates roughly to saying the alternatives will not 
> produce adequate performance.  Otherwise it looks like a difference between 
> 'adequate' and perhaps "perfect"?

We don't get perfect :-)

> 
> There is a core reality, here, that the I* Chairs are overburdened. This is 
> obvious from looking at the list of their duties and underscored by the 
> source of the current initiative.  We can choose to defer doing anything, 
> under the guise of taking a 'holistic' view or we can try to help with the 
> specific burden that is the focus of the overburdened folk.  On the average, 
> we do better with incremental change and this is the one before us now.


Then let's talk about the overall problem and not a point solution.

> If I generalize this, I would say that the I* chairs have been actively
>> involved in the most significant decisions the IAOC makes, they tend to be
>> less active in many of the day to day operational issues.
> ...
>> I think the I* chairs, in my view bring a broad view of the community and
>> operational needs based on what's involved in doing their jobs than another
>> person would not have.
> 
> My own simplistic summary:  For some topics it is extremely helpful to have 
> the broader knowledge and insight that can be provided by an I* chair. For 
> many topics, this is not needed, but for some it makes a significant 
> difference.


I agree, and it is representative of the level of current participation of I* 
chairs.


> 
> To that end, here's a very simple proposal that resolves the issue cleanly:
> 
> 1. ISOC, IAB and IESG each appoint one person currently.  Change this to 
> be two each, the same as Nomcom.  Each year, they would appoint one person.
> 
> 2. Move the I* Chairs to be non-voting ex-officio participants, the same 
> as the IETF Administrative Director.  They are welcome to participate or be 
> explicitly invited to all IAOC/Trust activities.
> 
> This produces the continuity that is needed for the admin work, but also 
> retains access to the expertise of the I* chairs.


I don't agree.  Appointing two people (or more?) doesn't solve the problem I am 
concerned about, it still doesn't bring the chairs perspective.  It also 
significantly changes the governance model by changing the balance between 
between nomcom, iab, iesg, and ISOC appointed members.  Also, adding six people 
(still counting the chairs) will make the IAOC much larger and unwieldy.  

Bob



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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Dave,

> On 4/14/2011 9:51 AM, Bob Hinden wrote:
>> My concern is that this proposed change would likely make the IAOC work
>> worse.   That is, I think it would have a negative impact on the operations 
>> of
> > the IETF and that is why I am concerned.
> 
> Bob,
> 
> That is a concrete and basic assertion.  Please put some flesh on its bones 
> so that the basis for your view can be understood better.
> 
> The implication is that the people sitting in the positions of IAB Chair and 
> IETF Chair are essential to the good operation of the IAOC/Trust.  Someone 
> else from their groups or even someone else that they appoint from outside 
> cannot perform the task of IAOC/Trust member adequately.

I didn't say no one else could do the job adequately.  I said "would have a 
negative impact" on the operations of the IETF.  

Some examples where an I* chair had a significant influence on a decision that 
IAOC made include:

 - The hiring of the Transitional RSE
 - Many of the Beijing meeting issues (prior and post signing the MOU)
 - Specific venue selections (in one case avoiding a less than ideal venue)
 - The need for transparency in certain IAOC actions (day passes, venue 
rotation)
 - Discussion of what policy decisions that the IAOC can make vs. the IESG vs. 
community
 - Discussion about when to get community feedback
 - Secretariat contract (RFP, bidders review, selection, etc.)
 - RFC Publisher and Publisher contracts  (RFP, bidders review, selection, etc.)

Some of these decision might have been different without one or more I* chairs 
being directly involved in the decision.  Please review the minutes for more 
detail.

If I generalize this, I would say that the I* chairs have been actively 
involved in the most significant decisions the IAOC makes, they tend to be less 
active in many of the day to day operational issues.  For example, there are 
weekly calls in the months before an IETF meeting that the host, NOC team, IAD, 
and a few other people attend.  I don't think an I* chair has every been 
involved at this level.

I think the I* chairs, in my view bring a broad view of the community and 
operational needs based on what's involved in doing their jobs than another 
person would not have.  

> 
> Why?
> 
> What are the specific contributions (insights and skills) that these roles 
> regularly perform, in the conduct of the IAOC/Trust that cannot be performed 
> adequately by others?

I think it because the role has the individual doing the job getting involved 
in the many related activities that gives them more insight than someone else, 
even a member of the same group.  To cite an example, I was on the IAB in the 
past, but I wouldn't claim to have the same total understanding of the IAB (and 
the things the IAB is responsible for) as the IAB chair at the time.  It's not 
the skill per se, it's being involved in the all of the topics that the chair 
is naturally involved in.  

> 
> d/
> 
> ps. Reminder: I've just joined the IAOC/Trust, which means I've attended a 
> few meetings and seen some operation.  As always, my comments have nothing to 
> do with the individuals; this is about organizational design.

My concern is as you say about the "organizational design", not the current set 
of individuals.  I want to make sure this keeps working well with the next set 
of leaders and the set after that.

Bob



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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Russ,


> The proposed update to BCP 101 permits further delegation of the IAOC voting 
> position.  While I do not see myself taking advantage of this new feature, I 
> do think we should give future IETF Chairs this option.  It is a cohesive 
> part of the work that can be delegated.  Some coordination between the IETF 
> Chair and the delegate would be necessary, but the time commitment would be 
> significantly less than participating in the IAOC and a subset of its 
> committees.


This prompts me to ask a question.  Who would the IETF Chair delegate this 
responsibility to?  The draft doesn't specify.  

An Area Director is the obvious answer, except from what I understand ADs are 
also extremely busy.  This trades one problem for another.  If it is someone 
not on the IESG, then this is effectively turning into giving the IESG another 
IAOC slot to select. 

As a general comment on the draft, I think it needs to be clear as to who the 
delegation can be made to and how much authority is delegated.

Thanks,
Bob





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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

John,

>> Bob,
> 
> I think you and Olaf (and myself and others) are addressing two
> rather different questions.  Your note seems to assume the
> question is "how to make the IAOC work better".  Your answer, if
> I understand it correctly, is "it works fairly well today isn't
> broken, let's not fix it".  If that were the question, I'd agree.

No that is not correct, you have it reversed.  My concern is that this proposed 
change would likely make the IAOC work worse.  That is, I think it would have a 
negative impact on the operations of the IETF and that is why I am concerned.

I am sympathetic to the leadership's overload problem, but think we should take 
a broader view.  For example, another approach might be to split the IAB's 
responsibilities into two groups, one focused on architecture (the IAB's 
traditional role) and another new group to deal with the parts of the job that 
seems to be growing (liaisons, RFC Editor, etc.).  Something like this might 
make the NOMCOM job easier in the sense that it wouldn't have find people who 
were strong in architecture and policy administration (I don't think that is 
the best description of the rest, but can't think of anything better at the 
moment).

Bob



> 
> But, remembering that the IASA has only the purpose of making
> the extended IETF (including the IAB) work more efficiently, I
> see a somewhat different question.  The roles and resource
> requirements of the IAB and IETF Chairs have expanded
> dramatically over the last several years.. expanded to the point
> that the appointing bodies may soon have to choose, not among
> the best people for the job, but from those who have spare time
> and resources on their hands or, worse, who work for
> organizations who see particular value in having one of their
> employees in those positions.  We have been lucky so far in
> finding very good people despite those pressures, but we can't
> count on its lasting.
> 
> That situation suggests to me that we should be asking the
> question of how we can reduce the absolute requirements
> associated with the IAB and IETF Chair positions.  If whomever
> is in those positions has the time, resources, and interest to
> also serve on the IAOC, I'm very much in favor of that.   But,
> if an individual --or the Nomcom-- have to choose between
> exclusion of the best candidate because there aren't enough
> resources for him or her to do the [rest of the] Chair job _and_
> the IAOC versus spreading the workload out, then I think it is
> in the community's interest to have an alternative.My
> personal preference continues to be to make the decision of who
> from the IAB (and potentially the IESG) serves on the IAOC be
> the decision of the IAB or IESG respectively rather than using
> the "delegation" model Olaf suggests but, in practice, I think
> it really makes no difference because any reasonable Chair is
> going to discuss those options with the relevant body.
> 
> Even if we were not worried about overall workload, we've
> discovered at several recent IETF meetings that the schedule for
> IAOC-related meetings keeps the IAB and IETF Chairs out of other
> meetings that might, objectively, have been important for them
> to attend.  So it is not clear to me that having those two
> people on the IAOC in person is optimal for the community,
> independent of whether or not it is desirable for IASA.
> 
>> From that point of view, the right question from the IASA/IAOC
> perspective should not be "is it working well enough that there
> is no internal reason to make a change" but "can this type of
> change be made without serious damage".
> 
> As far as the Trust is concerned, while we couldn't change the
> relationship until recently, we can now: if the linkage between
> Trust and IAOC membership is interfering with the simultaneous
> successful operation of the Trust and the efficient operation of
> the IAB and/or IESG, let's just change it.
> 
>john
> 

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Brian,

On Apr 14, 2011, at 8:34 AM, Brian E Carpenter wrote:

> John,
> 
> On 2011-04-15 01:10, John C Klensin wrote:
> ...
>> But, remembering that the IASA has only the purpose of making
>> the extended IETF (including the IAB) work more efficiently, I
>> see a somewhat different question.  The roles and resource
>> requirements of the IAB and IETF Chairs have expanded
>> dramatically over the last several years.. 
> 
> We really need to understand that better, and the underlying
> reasons for it, in some detail. I don't think that cherry-picking
> parts of the jobs to be delegated should be the starting point.
> We really need to start by reviewing all the tasks together and
> then decide what should be changed. I'd really like to hear from
> Olaf, Bernard and Russ what has changed in the workload in the
> last few years. You are of course correct that if the workload
> is constantly increasing, it will make NomCom's task very hard.
> 
> Certainly the IASA/IAD/IAOC reorganisation produced a noticeable
> reduction in the IETF Chair workload, but what has changed since
> http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00 ?
> It would be good to have a similar analysis for the IAB chair role.

+1

If there is a systemic problem, let's talk about that before proposing point 
solutions.  The overload problem also affects other leadership positions such 
as the IESG AD members.  

Bob



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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Olaf,

On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote:

> 
> [as editor:]
> 
> It seems that the high order bit of this discussion circles around the 
> question on whether it a requirement for the IETF Chair to have a voting 
> position in order to effectively perform oversight. Once we figured out where 
> we want to go with that we can think about delegation by the chair vs 
> appointment by the bodies and the implementation details with respect to the 
> trust.

For the record, I don't agree with this summary.  That is, I still question the 
basic assumption in the proposal.  We have "running code" in the IASA model and 
it appears to work reasonable well.  Not perfect, of course.  In particular I 
think that having the IETF chair, IAB chair, and ISOC president as voting 
members of the IAOC (and IETF Trust) has worked very well.  It makes them an 
active part of decisions the IAOC and IETF Trust are making and helps keep the 
IAOC from getting disconnected from the community.  It also makes them share 
the responsibility for decisions by having their vote be publicly recorded.  

I also don't understand what the effect of the proposal is on the IETF Trust.  
Currently all IAOC members are members of the IETF Trust.  They have to sign a 
letter accepting this role.  I don't think it can then be delegated.  

Your draft focuses on one area (that is, reducing the burden of these 
positions), but does not discuss any other aspects of making this change.  What 
might the negative aspects of delegating this responsibility be?  How will this 
be dealt with?

Each of the positions (IETF Chair, IAB chair, ISOC President) are different in 
the way they are selected and this effects their ability to delegate their 
responsibility and who they might delegate it to.  For example, the IETF chair 
is selected by the NOMCOM and one of his/her responsibilities is to sit on the 
IAB, IAOC, and IETF Trust.  The IAB chair is selected by the IAB.  The ISOC 
president is hired by the ISOC Board of Trustees.  Consequently, I think the 
authority to delegate differs and they should be considered separately.  

> 
> [as olaf:]
> 
> I agree that the IETF chair needs to have a good oversight about what goes on 
> in the IETF, to a lesser extend it is good that the IAB has that oversight 
> too (specifically with respect to its chartered responsibilities) but I 
> wonder if a voting membership is the appropriate instrument.

Why not?  It does appear to work.

> I believe effective oversight depends on having the appropriate high level 
> information and having the opportunity to timely inject information that is 
> needed to steer an outcome. An alternative method for sharing and injecting 
> is having regular meetings between the I* chairs and the ISOC President/CEO. 
> I believe that such meetings are much more effective for the parties involved 
> than being exposed to all details.

Do we really need to have another regular meeting?  Would this give the I* 
chairs more authority than they have now?  Sort of an executive committee.  
Would these meetings be public, have votes, have public minutes?  

> This only an illustration of an instrument, there may be other instruments 
> for oversight as well. But I do not think the ex-officio membership is the 
> only method.

It's not perfect but it is the one we have now and it is working.   We should 
only change it if we are sure that it will improve the overall IASA operation.  
I am seriously concerned about the current proposal.

Bob


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

Re: Last Call: (IANA Procedures for Maintaining the Timezone Database) to BCP

[Bob Hinden]

On Apr 13, 2011, at 9:38 AM, Cyrus Daboo wrote:

> Hi,
> 
> --On April 11, 2011 5:31:56 AM -0700 The IESG  wrote:
> 
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'IANA Procedures for Maintaining the Timezone Database'
>>   as a BCP
> 
> I support publication of this document (with changes already provided by 
> others' feedback).

+1

Bob


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

Re: Buckets of spam coming through IETF lists

[Bob Hinden]

John,

If you want to report a SPAM problem with an IETF mailing list, please report 
it to .  It will get prompt response.  

>From the email you forwarded, it looks like a problem with lists hosted at 
>ISI.EDU (that is, not at ietf.org).  

Bob

p.s. Or should I have taken the date you sent this more seriously?



On Apr 1, 2011, at 10:28 PM, John R. Levine wrote:

> Some clever spambot seems to have scraped a bunch of addresses out of the 
> archives and is sending spam with multiple addresses on the From: line 
> through IETF and IRTF mailing lists.  Surely I'm not the only one who's 
> seeing it.
> 
> Given the amount of legitimate mail with multiple From: addresses (none, in 
> practice) a quick shim in front of Mailman should deal with it until someone 
> can go fix the underlying code.
> 
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly
> 
> -- Forwarded message --
> Date: Thu, 31 Mar 2011 14:47:22 -0700 (PDT)
> From: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, 
> cor...@isi.edu,
>jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu,
>ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu,
>newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu,
>han...@isi.edu, rba...@isi.edu
> To: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu,
>jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu,
>ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu,
>newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu,
>han...@isi.edu, rba...@isi.edu
> Subject: [IRSG] An offer you can't refuse
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

IETF Badge Checking

[Bob Hinden]

There was some discussion at the Wednesday plenary IAOC open mic about the 
badge checking that took place during the Beijing IETF meeting.  I thought it 
would be good to clarify what happened at that meeting.

The IAOC was not aware that badge checking was going to happen prior to this 
meeting. It was implemented by the meeting host in conjunction with the hotel. 
It is our understanding that the host wanted to ensure that only registered 
attendees were given access to the IETF meeting rooms.

Had the IAOC been made aware of this prior to the meeting, we would have 
notified the community, similar to the way we notified the community that there 
would be a need for wireless network login well in advance of the Beijing 
meeting.

In the future if there is a need for badge checking (or network login) at an 
IETF meeting, the IAOC will notify the community as early as possible. Also, if 
we plan meetings in similar venues we will determine if anything like this is a 
local requirement.

Bob Hinden
IAOC Chair


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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Brian,

On Apr 1, 2011, at 6:36 AM, Brian E Carpenter wrote:

> On 2011-04-01 08:38, SM wrote:
>> Hi Brian,
>> At 00:07 31-03-2011, Brian E Carpenter wrote:
>>> And that is exactly the problem with 'non-voting' status in a committee
>>> that mainly operates by consensus. It allows people who really ought
>>> to share accountability to apear to avoid it.
>> 
>> According to IOAC procedures:
>> 
>>  "All decisions of the members must be approved by majority vote of
>>   the members then in office."
>> 
>> I don't consider that as operating by consensus.  
> 
> That is the tie-break rule. I can't speak for recent IAOCs, but when
> I was a member we esentially always achieved consensus.

In my time on the IAOC, we usually reach consensus, but not always.  The votes 
are recorded in the public minutes.  

> 
> But my point is that I believe the IETF Chair *should* have accountability
> and that means being a formal voting member.

I agree.

Given the roles the IAB is taking on, such as the selection of an RSE, that 
have a close relationship with the IAOC, I am concerned if the IAB Chair is not 
also a IAOC voting member, or if the vote can or should be delegated.  I do 
note that the IAB chair is different from the IETF chair as the IAB chair is 
selected by the IAB vs. the IETF chair is selected directly by the NOMCOM.

Bob



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

[Update on Day Pass Experiment]

[Bob Hinden]

I had intended to send this update on the Day Pass Experiment to the IETF list 
in the middle of January.  For reasons I don't understand, it was not sent.  My 
apologies.

>>> Subject:  Update on Day Pass Experiment
>>> 
>>> On 16 December 2010, the IAOC reviewed that status of the Day Pass 
>>> experiment.  After a long discussion, that is documented in the minutes 
>>> (available at http://iaoc.ietf.org/minutes/iaoc_minutes.html), the IAOC 
>>> approved the continuation of the Day Pass program for 2011.  The IAOC will 
>>> review the Day Pass program at the end of 2011 to make sure it is not 
>>> having a negative impact.
>>> 
>>> Day Passes are available as one of the registration choices for IETF 80 in 
>>> Prague.
>>> 
>>> Bob Hinden
>>> IAOC Chair

Day passes were available for Prague as you may have noticed, and were shown in 
the statistics presented in the Wednesday plenary.

Bob Hinden
IAOC Chair





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

Re: Question regarding proceedings

[Bob Hinden]

Fred,

On Mar 30, 2011, at 6:16 PM, Fred Baker wrote:

> I just went to http://www.ietf.org to review the proceedings from IETF 79. It 
> appears that the proceedings have been reorganized. They look great. I'm 
> puzzled.
> 
> What I was looking for was the minutes from v6ops/IETF-79 and the slideware 
> related to it. I couldn't find it. Where should I be looking?

See: http://www.ietf.org/proceedings/79/v6ops.html

The minutes are found under the link  titled "Minutes".  The meeting slides are 
listed below "Meeting Slides" header a little further down the page.

Bob


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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Michael,

> I got the impression that the purpose of this was that the IETF Chair
> could ask someone else to attend a meeting (I specifically do not mean
> an IETF meeting) on s/he behalf.  

My impression is that it was for a long term delegation.  Sounds like it should 
be clarified.

Bob


> 
> A typical reason might be due to need to attend to personal issues
> (i.e. can't travel for the next month due to sick mother).  For
> continuity reasons, having sent Person Y to meeting Z, it might make
> sense to continue to send Person Y for a period of a few months.
> 
> -- 
> ]   He who is tired of Weird Al is tired of life!   |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>  then sign the petition. 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Olaf,

On Mar 30, 2011, at 1:21 PM, Olaf Kolkman wrote:

> 
> Dear Colleagues,
> 
> I have just chartered a very short draft that intends to update BCP101. It 
> can be found at:
> http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
> 
> The draft is very short and contains only a few sentences of substance:
> 
>   The IETF chair, the IAB chair, and the ISOC President/CEO may
>   delegate their responsibilities to other persons.  The delegations by
>   the IETF chair and the IAB chair need to be confirmed by the IESG and
>   IAB respectively.  The terms of delegation is for a longer term for
>   instance aligned with the IESG and IAB appointment cycles (roughly
>   anual).

To clarify, from our 1:1 discussions, the intent is to allow the IETF chair to 
delegate their position on the IAB, IAOC, and IETF Trust, allow the IAB chair 
to delicate their position on the IAOC, IETF Trust, and IESG, and the ISOC 
President to delegate their position on the IAOC, IETF-Trust, and IAB.  From 
reading the discussion, it not clear to me that everyone understands this.

The above text does not say "delegate their ex-officio memberships", it says 
"delegate their responsibility".  That is it ways they can delegate all of 
their responsibility.  I don't think this was your intent, but if it was it 
goes too far.  Please clarify.


> John Klensin made me aware he also had a similar idea earlier:
>   http://tools.ietf.org/id/draft-klensin-iaoc-member-00.txt
> 
> The main difference is between his and this draft is that John's I-D makes 
> the person the chair delegates to a non-voting liaison. I have a small 
> preference for the IAB and the IESG keeping the control point, and I 
> implicitly assume that for IASA matters the persons delegated to will 
> escalate to the chairs and ask for specific guidance when appropriate. I 
> realize that for the Trust anybody serves on personal title. For the trust 
> alignment with the IAOC membership is just a practical considerations.

With my IAOC hat on, I am concerned about the delegation of these roles to the 
IAOC.  I think the community has been well served by the IAOC having the IETF 
chair, IAB chair, and ISOC President as full voting members of the IAOC.  It 
has kept the IAOC from "going off the rails".  I am concerned that this 
proposal will weaken the effective governance model that has worked well.

I haven't checked yet, but would these proposed changes require changes to any 
of the IETF Trust documents?  More may have to change than BCP 101.  Did you 
check?

I don't have any issue with the delegation of the ex-officio responsibilities 
to/from the IAB and IESG.

> 
> The shared requirement is unloading the I* chairs and the ISOC president and 
> empowering the people that serve in that role to organize themselves. (I 
> should have paid more attention to this much earlier.)
> 
> I plan to seek a sponsoring AD for getting this I-D published as a BCP 
> shortly. 


Doesn't a BCP require a 4 week last call?  I don't think this can or should be 
done quickly.  It's a non-trivial change.

Bob

> 
> Assuming this is an appropriate list for further discussion,
> yours,
> 
> --Olaf
> 
> 
>  
> 
> Olaf M. KolkmanNLnet Labs
>   Science Park 140, 
> http://www.nlnetlabs.nl/   1098 XG Amsterdam
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: draft-housley-two-maturity-levels

[Bob Hinden]

On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote:

> 
> 
> On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote:>
 Another proposal as for your document. So, it fails to mention what are
 the procedures for reclassification of Standards Track RFCs to Historic.
> 
> 
> Generally, the document tries to limit itself to discussion of what it 
> changes.
> 
> There are no changes proposed for moving to Historic. (The question of 
> Historic has not been part of the many discussions about streamlining the 
> standards labeling.)
> 
> Hence that issue is out of scope for the document.

+1

Bob


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

Re: xml2rfc RFP

[Bob Hinden]

On 11 February 2011 the IAOC issued an RFP for the development of the xml2rfc 
tool.  Following community feedback the IAOC put the RFP on hold and requested 
community input on the Statement of Work. The comment period ran from 23 
February to 9 March 2011. 

While the comments didn't result in any major changes to the Statement of Work 
in the RFP, it did generate several feature requests that were added to the 
list of new features to be considered in a future development phase.

The IAOC appreciates the input received on this RFP.

The revised schedule and answers to questions raised by interested bidders can 
be found at 

  http://iaoc.ietf.org/rfpsrfis.html

The RFP will be reissued later today.

Bob Hinden
IAOC Chair



On Mar 8, 2011, at 10:48 AM, Bob Hinden wrote:

> The comment period ends tomorrow.
> 
> Bob
> 
> On Feb 22, 2011, at 9:31 PM, Bob Hinden wrote:
> 
>> Based on the discussion, the IAOC has decided to put the XML2RFC RFP on 
>> hold, notify potential bidders of this, and have a community comment period 
>> on the tools-disc...@ietf.org list.  Subscription information can be found 
>> at:
>> 
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>> 
>> The RFP is located at:  
>> 
>> http://iaoc.ietf.org/rfpsrfis.html 
>> 
>> The comment period will end on March 9.  
>> 
>> Please note that the main goal is to have a supportable xml2rfc tool this 
>> year that works for the current users and provides the functionality of the 
>> current tool with some incremental improvements.  There will be an 
>> opportunity in the future for changes that can not be accommodated in this 
>> phase.  
>> 
>> Bob
>> 
>> 
>> 
>> 
> 

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

Re: xml2rfc RFP

[Bob Hinden]

The comment period ends tomorrow.

Bob

On Feb 22, 2011, at 9:31 PM, Bob Hinden wrote:

> Based on the discussion, the IAOC has decided to put the XML2RFC RFP on hold, 
> notify potential bidders of this, and have a community comment period on the 
> tools-disc...@ietf.org list.  Subscription information can be found at:
> 
>  https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> The RFP is located at:  
> 
>  http://iaoc.ietf.org/rfpsrfis.html 
> 
> The comment period will end on March 9.  
> 
> Please note that the main goal is to have a supportable xml2rfc tool this 
> year that works for the current users and provides the functionality of the 
> current tool with some incremental improvements.  There will be an 
> opportunity in the future for changes that can not be accommodated in this 
> phase.  
> 
> Bob
> 
> 
> 
> 

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