Re: [73attendees] Is USA qualified for2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?

[Soininen Jonne (NSN FI/Espoo)]

Hi everybody,

In the IAOC, we have followed the visa situation for different nations
closely. It is obviously in the benefit for the IETF to have all the
participants that want and need to come to the IETF could also come.

Historically, the IETF community has indicated the preference of having a
big part of the meetings in the North American region. This makes us often
come to the USA. Traditionally a major part of the participation is from the
North American region.

Of course, we should periodically check this policy, and also follow the
visa situation very carefully.

I think it would be good for people that were trying to come to the IETF and
couldn't to tell the IAD or me what happened. Accurate data is very
important.

Cheers,

Jonne.




On 11/18/08 10:08 PM, "ext Joel Jaeggli" <[EMAIL PROTECTED]> wrote:

> Yi Zhao wrote:
>> Based on my knowledge, for Chinese citizens there is no any problem to
>> get the visa to other countries except US.
> 
> I know for a fact that several of your countrymen have had trouble
> obtaining visas for other recent IETF destinations.
> 
>>  
>> 
>> 
>> 
>> *From:* [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] *On Behalf Of *David Quigley
>> *Sent:* Tuesday, November 18, 2008 1:56 PM
>> *To:* Nicholas Weaver
>> *Cc:* [EMAIL PROTECTED]; ietf@ietf.org
>> *Subject:* Re: [73attendees] Is USA qualified
>> for2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?
>> 
>>  
>> 
>> Disclaimer: What I say here are my words and don't represent the views
>> of my employer.
>> 
>>  
>> 
>> From what I see here the issues are mostly experienced by Chinese
>> citizens. Most of the other countries have reciprocal visa agreements
>> with the US. China however doesn't have that agreement with Ireland,
>> Sweden, Japan, or the US. Were there similar problems with gaining
>> entrance into Ireland? Will there be similar issues with gaining
>> entrance into Sweden or Japan?
>> 
>>  
>> 
>> Dave
>> 
>> On Tue, Nov 18, 2008 at 1:40 PM, Nicholas Weaver
>> <[EMAIL PROTECTED] > wrote:
>> 
>> 
>> On Nov 18, 2008, at 10:53 AM, Scott Brim wrote:
>> 
>> Excerpts from Randy Bush on Tue, Nov 18, 2008 10:39:57AM -0600:
>> 
>> [EMAIL PROTECTED]  wrote:
>> 
>> I believe our US government would like to grant visas to as many
>> people as they can. However, if anyone wants to attend a meeting in
>> the US is granted a visa to come here, then I can imagine there will
>> be 100 million visa applications for the IETF meeting in CA next year
>> alone.
>> 
>> 
>> thank you for demonstrating so clearly the jingoistic prejudice at the
>> us government level that should preclude ietf being held in the united
>> states.
>> 
>> 
>> How would you solve the problem?  Let 100 million people in on false
>> pretenses?  I'm not going to defend the behavior of the US government,
>> but I want you to admit that US immigration has a difficult problem.
>> Slinging labels around doesn't help.
>> 
>>  
>> 
>> Remember, the IETF is NOT special.  There are tens of thousands of
>> conferences, and they are all pretty much need-to-be-treated equal.  If
>> the US gave effectively carte blanch to conference attendees, you would
>> have no immigration controls, period, as this would be a big enough
>> loophole to fly an A380 through.
>> 
>> The Visa issue in the US is serious, but how many people are really
>> affected by this?
>> 
>> We need hard data, because the notion of simply "not holding IETF
>> meetings in a terrorist country" is not effective.
>> 
>> And if you want to do Visa issues as a criteria, you can strongly argue
>> that all IETF meeting SHOULD be in a country where a visa is not
>> required for travel for EU, US, Japanese, and Canadian citizens.
>> 
>> 
>> 
>> ___
>> 73attendees mailing list
>> [EMAIL PROTECTED] 
>> https://www.ietf.org/mailman/listinfo/73attendees
>> 
>>  
>> 
>> 
>> 
>> 
>> ___
>> 73attendees mailing list
>> [EMAIL PROTECTED]
>> https://www.ietf.org/mailman/listinfo/73attendees
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [EMAIL PROTECTED]


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

RE: IETF74 T-Shirt Art Donated to IETF Trust

[Soininen, Jonne (NSN - FI/Espoo)]

Hi,
Though, I think IETF has been always in the lavanguardia of fashion, I think 
Henk is absolutely right.  Let people have their t-shirt if they want to. As 
long as there is no risk for the IETF.

Who would that hurt? The money goes for a good cause - making the Internet work.

Cheers,

Jonne.


-Original Message-
From: ext Henk Uijterwaal
Sent: 02/08/2009 12:53:02

Cc: ietf@ietf.org
Subject: Re: IETF74 T-Shirt Art Donated to IETF Trust


Marshall Eubanks wrote:

> If the IETF sold 100 shirts we would IMO be doing well. If we sold 1000, 
> we would be doing spectacularly well IMHO.
> 
> That would net $ 5000. That's less than ten registrations at a meeting. 
> I am neutral about whether or not we do this, but please don't imagine 
> that it will supplant registration fees or otherwise lead to sudden riches.

I'd be suprised if we sold more than a 100 shirts.   I see this primarily
as a service to attendees, not as a way to generate money.  You get a shirt
for free, if you want a 2nd one for whatever reason, you can buy it.  The
IETF gets a few $$ for the trouble.

Henk

-- 
--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.xs4all.nl/~henku
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Belgium: an unsolvable problem, discussed in endless meetings, with no
  hope for a solution, where everybody still lives happily.
___
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: Request for community guidance on issue concerning a future me etingof the IETF

[Soininen, Jonne (NSN - FI/Espoo)]

Everybody,

How I read the condition text it is basically saying if the IETF breaks the 
Chinese law the meeting is over. Having it twice (once in the law and second 
time in the contract) seems to be just to remind the the meeting organizer the 
law exists as the law is for many people quite unusual.

Even striking that text from the contract wouldn't IMHO change- anything, 
because the law basically says the same anyway.

Entering a country puts you always under the local law - whether you agree with 
the laws or not. 

However, I think when not quite this strict, other countries restrict political 
activity of visitors. If I remember correctly, the US law restricts the 
possibility of political activism for visa holders. 

Regardless of what I think of the Chinese law, and having such text in the 
contract, I don't think the particular text is an issue for the IETF meeting. 
Many other organizations (3GPP, Wimax Forum, etc.) have had meetings in China 
for many years without any issues.

Cheers,

Jonne.

--- original message ---
From: "ext Marshall Eubanks" 
Subject: Request for community guidance on issue concerning a future meetingof 
the IETF
Date: 18th September 2009
Time: 6:48:36 pm

Greetings;

We have received numerous suggestions and requests for an IETF meeting
in China and the IAOC has been working on a potential China meeting for
several years. We are now close to making a decision on a potential
upcoming  meeting in China. However, the following issue has arisen
and we would appreciate your feedback.

The Chinese government has imposed a rule on all conferences held
since 2008 regarding political speech. A fundamental law in China
requires that one not criticize the government. Practically, this
has reference to public political statements or protest marches, which
are not the IETF's custom. The government, which is a party to the  
issue,
requires that people who attend conferences in China (the IETF being
but one example) not engage in political speech during their tour
in China. We consider this to be acceptable, on the basis that the
IETF intends to abide by the laws of whatever nations it visits and
we don't believe that this impacts our ability to do technical work.

The rule is implemented in the Hotel agreement and reads (note that
the "Client" would be the Host, and the "Group" would be the IETF) :

"Should the contents of the Group's activities, visual or audio
presentations at the conference,or printed materials used at the
conference (which are within the control of the Client) contain
any defamation against the Government of the People's Republic
of China, or show any disrespect to the Chinese culture, or
violates any laws of the People's Republic of China or feature
any topics regarding human rights or religion without prior
approval from the Government of the People's Republic of China,
the Hotel reserves the right to terminate the event on the spot
and/or ask the person(s) who initiates or participates in any or
all of the above action to leave the hotel premises immediately.

The Client will support and assist the Hotel with the necessary
actions to handle such situations. Should there be any financial
loss incurred to the Hotel or damage caused to the Hotel's
reputation as a result of any or all of the above acts, the Hotel
will claim compensation from the Client."

What does this condition mean ? The hotel staff would have, in theory,
the legal right to shut down the meeting and ask the offending
participants to leave the property immediately. While we do not
foresee a situation where such action would take place, we feel that
it is proper to disclose these conditions to the community.

The members of the IAOC, speaking as individuals, do not like this
condition as a matter of principle. The IAOC does believe that this
condition would not prevent the IETF from conducting its business.

We note that the Vancouver/Quebec survey conducted earlier this year
asked for people to suggest venues in Asia; an overwhelming majority
(94%) of those who mentioned China were in favor of having a meeting
there.

We are therefore asking for input from the community by two means - by
commenting on the IETF discussion list, and also by completing a very
short survey on people's intentions to travel to China, or not,
subject to these conditions. This survey can be found here :

https://www.surveymonkey.com/s.aspx?sm=h4DUkRUOdG_2bVLqioPcYYHw_3d_3d

All responses received by October 1, 2009 at  9:00 AM EDT  (1300 UTC)
will be considered by the IAOC in making its decision. We appreciate
the assistance of the community in providing us with data that will
help us to make an informed decision.

Regards
Marshall Eubanks
(acting for the IAOC)

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___

Re: Request for community guidance on issue concerning afuture mee ting of the IETF

[Soininen, Jonne (NSN - FI/Espoo)]

Hi,

I think Steve has captured the core of the issue in this mail. I think his 
reasoning is the exact reason why we should go to Beijing with a positive 
attitude and have a great meetin in Beijing!

Cheers,

Jonne.

--- original message ---
From: "ext Steve Crocker" 
Subject: Re: Request for community guidance on issue concerning afuture meeting 
of the IETF
Date: 19th September 2009
Time: 10:56:24 pm

The choice is between engaging and not engaging.  Engaging is better.   
Not engaging isn't constructive.  The Internet and the IETF are all  
about engaging, expanding, communicating and being open.  Much of this  
dialog has been worried about possible extreme situations.  Let's  
focus on the center.  More than a billion people live in China and  
their use of the Internet is expanding rapidly.  They are building  
much of the technology and contributing technically.  It's to  
everyone's advantage to have comfortable, constructive interaction.   
Our first slogan was "Networks Bring People Together."

If you prefer to focus on the negatives, here's my analysis:

If we don't go to China, we have charted a downhill course and the  
rest of the world will come together without us.  The IETF will lose  
relevance.

If we do go to China and something bad happens, the consequences will  
be much worse for China than for the IETF.  The work of the IETF will  
suffer a bit, but we'll recover quickly enough.  However, China's  
quest for engagement with the rest of the world will be hurt more  
seriously.

Bottom line: We should go to China with a positive attitude.  We're  
robust enough to deal with any consequences.  If we don't go to China,  
however, we have weakened ourselves.

Steve

___
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 on draft-ietf-netlmm-proxymip6

[Soininen Jonne (NSN FI/Espoo)]

Hi Ted,

I agree with you on the notion that we shouldn't publish anything that we
know already that will need fixes or does not work properly for the intended
use at this point. However, I think it is completely proper to revise
specifications based on operational experience - ever rather quickly after
publishing as a PS. Though, seldom done I have understood it is has been
even the original idea of the three step standardization process.

However, that is not my main point. And I don't quite agree that this
document in its current format is in a shape where we would have to revise
it right after publishing.

I would like to comment a bit on your proposal to make the MN-AR draft a
normative reference, and moving MN-AR to standards-track. First of all, I'm
happy to say that the MN-AR draft has been revived and can be found at
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt

Secondly, taking into account the multiple customers for the pmip6 and the
multitude of environments where PMIP is either going to be used or
potentially going to be used (3GPP, 3GPP2, Wimax to my understanding) I
don't think it is possible to write a MN-AR draft that would cover
adequately those networks and be really useful for them. I think the purpose
of the MN-AN is not to show how PMIP6 should be deployed, but how it could
be deployed. I however do agree that MN-AR draft should go forward in the
working group and it should not be forgotten.

I cross-posted this to the netlmm mailing list to make sure everybody knows
this discussion is going on.

Cheers,

Jonne. 

On 2/14/08 3:01 AM, "ext Ted Hardie" <[EMAIL PROTECTED]> wrote:

> Summary:  One issue needs resolution.
> 
> First, let me start by saying that -09, which was put out for Last Call, was a
> substantial
> improvement over the -08.  I normally read Last Call documents using a diff
> tool,
> and the number of really solid additions in this update was quite high.  I was
> a bit
> surprised, given the extent of the new text, that there was no WG last call,
> but
> I assume that the WG is reviewing the changes in parallel.   I assume that the
> issuance
> of -10, which came out during the last call, was a response to one or more
> reviews
> from the WG or solicited experts.
> 
>  To call out one particular improvement, I found the update's language around
> multi-homing  much clearer, and I believe the risk of assignment of the same
> address to multiple interfaces is much reduced in this version.  Given the
> potential consequences (watching your stack scream "I'm melting!  I'm
> melting!" 
> as someone entertainingly put it), that's a really good thing.
> 
> There are still some opportunities for editorial update, and I hope that as
> the IESG enters its discussions that some of those are targets for resolution.
> I'd particularly like to see even more clear light on the description in
> bullet 4 of Section 6.9.1.1, as "predictably knows" is not as clean as
> it might be.  (The current sentence is: "The Handoff Indicator field MUST be
> set to 
> value 1  (Attachment over a new interface), if the mobile access  gateway
> predictably 
> knows that the mobile node's current   attachment to the network over this
> interface is not as a  result of an handoff of an existing mobility session
> (over
> the same interface or through a different interface), but as a result of an
> attachment over a new interface.  ").  But that is really a language clarity
> problem, at least I hope, at this point.
> 
> The big issue that remains is actually one that starts from the scope creep.
> 
> I was on the IESG during the period when this charter was approved, and it
> was clear at the time that some of the limitations being put in were intended
> to focus NETLMM on cases where nodes were re-associating at layer 2 with the
> same network.   The charter says, for example:  "The protocol will not attempt
> to hide handover  between two separate interfaces on the mobile node.".
> This document (and, as I understand it, the working group discussion for some
> time) 
> has gone beyond that initial scope.  A good portion of this document's
> complexity 
> is because it does handle the multi-interface case.  While it would have been
> nice 
> to have the charter updated to state the new scope, I don't personally have a
> problem with the scope.  I am concerned, however, that the design constraints
> changed with that new scope and that other parts of the charter are limiting
> folks' understandings of what can be done here, when those restraints are
> really 
> salient for the single layer 2 initial scope.
> 
> To put it simply, given the inter-technology handoff, signalling from the
> mobile node
> to the network is one of the clearest and most likely to be interoperable ways
> to achieve
> the correct behavior in some of the base cases.  At the moment, because the
> mechanisms 
> for setting the handoff indicator do not necessarily involve the mobile node
> (and are 
> appear 

Re: Last Call on draft-ietf-netlmm-proxymip6

[Soininen Jonne (NSN FI/Espoo)]

Ted,

Thanks for your kind words and sorry for taking my time to answer. Please,
find below some thoughts, comments, and questions to your mail.


On 2/15/08 3:55 AM, "ext Ted Hardie" <[EMAIL PROTECTED]> wrote:

> Hi Jonne,
> Thanks for your reply; some comments inline.
> 
> At 1:17 PM -0800 2/14/08, Soininen Jonne (NSN FI/Espoo) wrote:
>> Hi Ted,
>> 
>> I agree with you on the notion that we shouldn't publish anything that we
>> know already that will need fixes or does not work properly for the intended
>> use at this point. However, I think it is completely proper to revise
>> specifications based on operational experience - ever rather quickly after
>> publishing as a PS. Though, seldom done I have understood it is has been
>> even the original idea of the three step standardization process.
> 
> I agree that we should be able to revise specifications very quickly.
> RFC 2026 is pretty clear, though, that we shouldn't publish things that
> we believe are missing important pieces:
> 
>A Proposed Standard should have no known technical omissions with
>respect to the requirements placed upon it.  However, the IESG may
>waive this requirement in order to allow a specification to advance
>to the Proposed Standard state when it is considered to be useful and
>necessary (and timely) even with known technical omissions.

I agree, and I think I wrote that as well in my mail. We shouldn't publish
PS'es with known technical omissions. Instead we should fix the omissions or
problems when we find them.

However, I don't think we have such technical omissions in the current
draft. I think the draft - due to extensive review and long debates - is in
a pretty good shape.

> 
> The tricky bit here is that the requirements placed on this have shifted
> since the work was chartered, and it is not clear whether the technical
> omissions here are meant to be consonant with the original charter,
> even though they don't meet the technical requirements of the current
> working scope.

I think this is the general problem we seem to have sometimes in the IETF.
We charter things for a year's worth of work, but in the end the work takes
quite some years more than that. The requirements have shifted and the
original scope doesn't fit the solution needed in the end. Hence,
flexibility is needed.

I think "the right thing to do" would have been to recharter the work
already earlier to fit the right problem. However, it didn't seem worth the
effort earlier as the main focus still should be on the technical work.

> 
> As you should also note in reading my mail, I am encouraging the IESG to waive
> this requirement in order to get this document out in a timely fashion,
> but with a forward pointer in place that would allow us to indicate
> we intend to fill the empty slot in the toolbox and, generally speaking,
> where someone should eventually look for the tool.
> 

I'm happy that you also find the flexibility needed in this case. However,
I'm not really sure what you are referring to with your comment about an
empty slot in the toolbox. Which slot in your mind seems to be empty?

[snip]
> 
> I'm glad that you also support MN-AR going forward.  I also hope that you
> are too pessimistic on the possibility of making a general mechanism.
> While the networks you cite are certainly complex and will no doubt have
> systems engineering documents which describe exactly how to use PMIP
> in their environments, that's not the work I'm suggesting the IETF should take
> on.  Instead, I'm suggesting that we need and should complete the work
> of describing a general mechanism specifying how a mobile node
> talks to a mobile access gateway.  That may well not replace the systems
> engineering work needed by the current customers for PMIP, but it will make
> the work more generally useful.  It may even be in the fullness of time
> that the mobile-node to MAG signalling will be used in those environments,
> once it is generally available.

I am generally a pessimist. I have heard that a pessimist is never
disappointed. However, I think in this particular case I would say that it
is not really pessimism. Practically the MN-AR interface is very link layer
dependent. Different systems have quite different link layers and might have
rather different procedures. So, I don't think a general view is really
possible, or perhaps even desirable.

I have to say that I don't see much use currently to specify a standard for
MN-AR signalling in the IETF. Not at least currently. However, perhaps I'm
missing something here.

Thank you for your comments, and I guess I forgot to thank you for your
review of the document as well!

Cheers,

Jonne.

> 
> Tha

Re: Proposed Revisions to IETF Trust Administrative Procedures

[Soininen Jonne (NSN FI/Espoo)]

Hi,

I agree with Russ. I think the trust and the IAOC have a bit different focus
and it makes sense at times have a different chair for the different
positions.

This does not mean that we couldn't go in the future back to the common
IAOC/Trust chair, but currently the work split would make sense.

Cheers,

Jonne.


On 4/7/08 10:45 PM, "ext Russ Housley" <[EMAIL PROTECTED]> wrote:

> The IAOC and the IETF Trust have different focus.  The idea behind
> the separate chair is to make sure that someone is paying attention
> to the items that need to be handled by each body in a timely
> manner.  It is simply a mechanism to help ensure that noting is
> falling between the cracks.
> 
> Russ
> 
> --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand
> <[EMAIL PROTECTED]> wrote:
> 
>> After considering the comments so far, I think I disagree with having a
>> separate Trust chair.
>> 
>> The idea behind making the IAOC be the Trustees was, among other things,
>> to make sure that we didn't create yet another nexus of control in the
>> labyrinth of committees; I understood the legal existence of the
>> Trustees as something different (in name) from the IAOC to be strictly
>> something we did for legal purposes
>> 
>> If the IAOC chair is overburdened by having to manage the IAOC in two
>> different contexts, get him (or her) a secretary.
>> 
>> I agree with John's comment that leaving the current trustees in charge
>> on dissolution of the IAOC is inappropriate; for one thing, that also
>> removes all the recall mechanisms.
>> Figure out something else to do in this case.
>> 
>>Harald
> 
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [EMAIL PROTECTED]


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

NomCom IAOC position (Was:Re: On being public (Was: Call for Nominees))

[Soininen Jonne (NSN FI/Espoo)]

Hello everybody,

Sorry to be a little late on this. However, I think openness and
transparency is good, and should be encouraged. Therefore I would like to
tell that I'm NOT going to rerun for the currently open IAOC position, and I
hope people would propose good candidates for the IAOC position if they
already haven't done it.

Cheers,

Jonne.


On 9/13/08 6:25 AM, "ext Pete Resnick" <[EMAIL PROTECTED]> wrote:

> On 9/12/08 at 9:46 AM -0700, NomCom Chair wrote:
> 
>> If you are willing to serve, please nominate yourself.
>> If there is someone you think would do a good job, please nominate them.
> 
> I'd like to take this opportunity to encourage people to do something
> more open and transparent than we have in the past, without any
> changes to rules or NomCom activity.
> 
> As we all know, the NomCom process is confidential. That is, whatever
> one says to the NomCom with regard to nominees cannot be revealed by
> the NomCom. That's a good idea: People need to be frank and honest
> without worrying about jeopardizing personal relationships. However,
> the confidentiality requirement has always also been read to mean
> that the list of nominees must also be kept confidential. That's not
> entirely clear in RFC 3777, but that's always been the practice. (I
> believe the intent was to dissuade any kind of "campaigning", to
> avoid discomfort about "running against" an incumbent or popular
> nominee, as well as avoiding embarrassment for nominees who are not
> chosen.) But this has a terrible side effect: The NomCom is unable to
> get full feedback on nominees, both in the positive and the negative.
> If you are unaware that Joe is up for the Foobar Area Director, you
> may not have the opportunity to say to the NomCom, "Wow! It never
> even occurred to me to think of Joe as a potential Foobar AD. He'd be
> perfect!" Or conversely, "It never occurred to me that anyone
> (including Joe himself) would seriously consider him for Foobar AD.
> He'd be a disaster!"
> 
> There are just so many resources the NomCom has at its disposal to
> get good information about nominees. We want folks who could provide
> feedback to take the initiative, but they're really only going to do
> so if they know who has their hat in the ring.
> 
> Though I think campaigning should be avoided, I think the other
> issues surrounding revealing the names of nominees are not all that
> problematic:
> 
> - We should all get over the notion that any particular nominee "must
> obviously be chosen". It may turn out (perhaps on the *day* that the
> NomCom is making their decision) that our favorite cannot serve
> because they lose all funding in their current position, or change
> jobs and no longer have the ability to serve, or die unexpectedly.
> (And these things have happened.) We should be able to comment on all
> of the candidates on the off chance that they are the NomCom's
> apparent best choice.
> 
> - The fact that the NomCom must keep the reasons for *not* choosing
> any particular candidate confidential mitigates the embarrassment of
> not being chosen.
> 
> Obviously we can't change 3777 for this NomCom. However, there is
> nothing in 3777 or elsewhere that *requires* any nominee to keep
> their own nomination confidential. So, I'd like to encourage nominees
> to be public. Here's what I have in mind: If you've been nominated,
> post a simple message to the IETF list of the following form:
> 
> "My name was submitted to the NomCom for the position of ,
> and I've told the NomCom I'm willing to be considered. Of course,
> this is no guarantee that if I get selected, I'd still be able to
> serve. Please send them whatever positive or negative feedback you
> have."
> 
> End of message. No commentary on why you'd be wonderful (or terrible)
> for the job. Just inviting people to comment.
> 
> Thoughts on this?
> 
> pr

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [EMAIL PROTECTED]


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

Re: Requirements for Open IESG Positions

[Soininen Jonne (NSN FI/Espoo)]

Hi,

I just happened to read this mail today. I don't remember seeing such a mail
during previous nomcom rounds (they might have come, but I just didn't
notice them). I think this is a very good overview of the requirements
needed for the IESG positions and gives a nice background to think about the
people who would fit the positions.

However, I think one of the areas is described a bit too much in detail and
perhaps give a wrong impression about the job. The following extract is from
the Security Area:

> Specific expertise required for a Security AD includes strong knowledge
> of IETF security protocols.  To complement Tim Polk, the person selected
> as Security AD should have a working understanding of Kerberos, GSS-API,
> SASL, and how these relate to security protocols and to their use in
> applications and other security protocols.  A basic understanding of
> IPsec, IKE, TLS, PKI would also be useful.

I'm sure this is an oversight, but I think it is generally not according the
IETF process to specific technologies and "hard coding" the division of work
in an area. To my understanding, the Ads in an area are free to divide the
work between themselves as they wish according their strengths. So, if the a
possible new security AD would not be interested to look at these
technologies, perhaps Tim would look at them - according the new division of
work in the area.

In addition, I think it is a bit shaky to mention the current AD in this
context even when the person is not up. Theoretically (I don't know if this
has ever happened outside the creation of the RAI area), that AD could be
moved to the IAB or another position in the IESG. So, it is not 100% sure
that Tim would be continuing as the other security AD though probable.

However, thanks for this clarification I think it is very useful.

Cheers,

Jonne.



On 7/20/07 9:12 AM, "ext Lakshminath Dondeti" <[EMAIL PROTECTED]> wrote:

> RFC 3777 says the following about the qualifications required for open
> IESG/IAB positions:
> 
>   "The IESG and IAB are responsible for providing summary of the
>   expertise desired of the candidates selected for their
>   respective open positions to the Executive Director.  The
>   summaries are provided to the nominating committee for its
>   consideration.
> 
>2. The nominating committee selects candidates based on its
>   understanding of the IETF community's consensus of the
>   qualifications required and advises each confirming body of its
>   respective candidates."
> 
> The following is the information provided by the IESG to the nomcom.
> The nomcom is now accepting the community's input on the qualifications
> required for the open IESG positions.  Please send your notes, either as
> commentary on the following or independent notes to [EMAIL PROTECTED]
> 
> Thank you.
> 
> best regards,
> Lakshminath
> 
> 
> 
> This note describes the expertise desired in the candidates selected to
> fill the positions of the IESG members whose terms will expire during the
> first IETF Meeting in 2008.
> 
> Under the Nominations Committee (NomCom) procedures defined in RFC 3777,
> the IESG is responsible for providing a summary of the expertise desired
> of the candidates selected for open IESG positions. This information is
> included below, and is suitable for publication to the community, along
> with the NomCom request for nominations.
> 
> We realize that this is a long list of demanding qualifications, and that
> no one person will be able meet all of the requirements for a specific
> position.  We trust that the NomCom will weigh all of these
> qualifications and choose IESG members who represent the best possible
> balance of these qualifications.
> 
> 
> GENERIC REQUIREMENTS
> 
> IESG members are the managers of the IETF standards process. They they
> must understand the way the IETF works, be good at working with other
> people, be able to inspire and encourage other people to work together as
> volunteers, and have sound technical judgment about IETF technology and
> its relationship to technology developed elsewhere.
> 
> Area Directors (ADs) select and directly manage the Working Group (WG)
> chairs, so IESG members should possess sufficient interpersonal and
> management skills to manage 15 to 30 part-time people.  Most ADs are also
> responsible for one or more directorate or review teams.  The ability to
> identify good leaders and technical experts, and then recruit them for
> IETF work is important. Having been a WG chair helps understand the WG
> chair role, and it will help when trying to resolve problems and issues
> that a WG chair may have.
> 
> In addition, all IESG members should have strong technical expertise that
> crosses two or three IETF areas.  Ideally, an IESG member would have made
> significant technical contributions in more than one IETF area,
> preferably authoring documents and/or chairing WGs in more than one area

Re: Requirements for Open IESG Positions

[Soininen Jonne (NSN FI/Espoo)]

Hi Brian,


On 7/24/07 2:29 AM, "ext Brian E Carpenter" <[EMAIL PROTECTED]>
wrote:

> Jonne,
> 
> On 2007-07-24 01:10, Soininen Jonne (NSN FI/Espoo) wrote:
>> Hi,
>> 
>> I just happened to read this mail today. I don't remember seeing such a mail
>> during previous nomcom rounds (they might have come, but I just didn't
>> notice them).
> 
> You didn't notice them :-)
> Also these descriptions have evolved from year to year
> (there is a version in the IESG wiki too, at
> http://www3.tools.ietf.org/group/iesg/trac/wiki/AreasDescription,
> maybe the IESG should bring it up to date...)

You mean there is e-mail in my inbox I haven't read? ;)
> 
> 
>> I think this is a very good overview of the requirements
>> needed for the IESG positions and gives a nice background to think about the
>> people who would fit the positions.
>> 
>> However, I think one of the areas is described a bit too much in detail and
>> perhaps give a wrong impression about the job. The following extract is from
>> the Security Area:
>> 
>>> Specific expertise required for a Security AD includes strong knowledge
>>> of IETF security protocols.  To complement Tim Polk, the person selected
>>> as Security AD should have a working understanding of Kerberos, GSS-API,
>>> SASL, and how these relate to security protocols and to their use in
>>> applications and other security protocols.  A basic understanding of
>>> IPsec, IKE, TLS, PKI would also be useful.
>> 
>> I'm sure this is an oversight, but I think it is generally not according the
>> IETF process to specific technologies and "hard coding" the division of work
>> in an area. To my understanding, the Ads in an area are free to divide the
>> work between themselves as they wish according their strengths. So, if the a
>> possible new security AD would not be interested to look at these
>> technologies, perhaps Tim would look at them - according the new division of
>> work in the area.
> 
> If you look at the description for the O&M area you will also surely find it
> very specific to half the area. I think it's realistic to do this. I don't
> object to it.

I think the O&M area(s) is a bit different. Here there are three specific
technologies mentioned whereas in O&M area there are two quite different
areas. There is perhaps not a such a clear division of task (like there
isn't in other areas either).

However, like I said this is most probably just an oversight.

> 
>> In addition, I think it is a bit shaky to mention the current AD in this
>> context even when the person is not up.
> 
> My personal taste would also be not to mention the co-AD by name.
> 
>> Theoretically (I don't know if this
>> has ever happened outside the creation of the RAI area), that AD could be
>> moved to the IAB or another position in the IESG. So, it is not 100% sure
>> that Tim would be continuing as the other security AD though probable.
> 
> True, but that would then invoke the mid-term replacement process
> for the person being moved - and it *has* happened.

Cheers,

Jonne.

> 
> Brian

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [EMAIL PROTECTED]



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

Re: Requirements for Open IESG Positions

[Soininen Jonne (NSN FI/Espoo)]

Hi,

I agree with Vidya. To be honest, I really thought this was an oversight and
not intentional. 

If the Security area has a similar split as the O&M area, I think this
really should be discussed. To my understanding, we don't have such split
documented to any other area and I think this kind of "hard" split should be
discussed. Perhaps the split is right and I just wasn't aware of it.
However, it seems other people were unaware of the split as well.

BTW, are the explicit technologies Kerberos, GSS-API, and SASL representing
the "other half" of the area. I'm asking, because I'm not a security expert
and not active in the security area.

Cheers,

Jonne.
On 7/25/07 1:12 AM, "ext Narayanan, Vidya" <[EMAIL PROTECTED]> wrote:

> I thought the requirements were too specific for the SEC area last year
> as well :) I do realize that the text has been largely reused from last
> year, but, I think we need to revisit some of these specific
> descriptions.  
> 
> We cannot expect the Nomcom to be familiar enough with all areas to use
> their judgment in addition to the requirements received.  I think we
> need to get better at providing the requirements so that the Nomcom will
> really know what they are looking for in candidates.
> 
> At the moment, I really think the SEC area requirements are misleading
> to the Nomcom and can use a revision.
> 
> Vidya 
> 
>> -Original Message-
>> From: Russ Housley [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, July 24, 2007 2:01 PM
>> To: Narayanan, Vidya
>> Cc: ietf@ietf.org
>> Subject: RE: Requirements for Open IESG Positions
>> 
>> One important thing needs to be considered in the Security
>> and O&M Areas.  There are two ADs, and they are expected to
>> have somewhat different skill sets.  For contrast, here are
>> the requirements that were provided to NomCom2006 for these positions.
>> 
>> Russ
>> 
>> ---
>> Operations & Management Area:
>> 
>> The primary technical areas covered by the Operations &
>> Management area include: Network Management, AAA, and various
>> operational issues facing the Internet such as DNS
>> operations, IPv6 operations, Routing operations.
>> 
>> Unlike most IETF areas, the Operations & Management area is
>> logically divided into two separate functions: Network
>> Management and Operations.
>> David Kessens is currently responsible for the Operations
>> portion of the OPS area, so specific expertise required for
>> the open position would include a strong understanding of
>> Internet operations, as well as the ability to step into
>> Network Management issues when necessary.
>> 
>> The Operations AD is largely responsible for soliciting
>> operator feedback and input regarding IETF work.  This is a
>> challenging task that requires strong contacts in the
>> operations community and a great deal of persistence.
>> 
>> Another important role of the Operations AD is to identify
>> potential or actual operational issues regarding IETF
>> protocols and documents in all areas, and to work with the
>> other areas to resolve those issues.
>> This requires a strong understanding of how new and updated
>> protocols may affect operations, and the ability to gather
>> information from the operations community and translate that
>> information into suggestions for protocol architecture and
>> design within the IETF.  It also requires a strong cross-area
>> understanding of IETF protocol architecture and technologies.
>> 
>> The Operations portion of the OPS area intersects most often
>> with the Routing, Internet and Security areas.  So,
>> cross-area expertise in any of those areas would be
>> particularly useful.
>> 
>> ---
>> Security Area:
>> 
>> The WGs within the Security Area are primarily focused on
>> security protocols.  They provide one or more of the security
>> services:
>> integrity, authentication, non-repudiation, confidentiality,
>> and access control.  Since many of the security mechanisms
>> needed to provide these security services are cryptographic,
>> key management is also vital.
>> 
>> Security ADs are expected to ensure that all IETF
>> specifications are reviewed for adequate security coverage.
>> They also manage a set of security resources that are
>> available to most IETF areas and WGs.
>> 
>> Specific expertise required for a Security AD would include a
>> strong knowledge of IETF security protocols, particularly
>> IPsec, IKE, and TLS, and a good working knowledge of security
>> protocols and mechanisms that have been developed inside and
>> outside the IETF, most notably including PKI.
>> 
>> Also, a Security AD should understand how to weigh the
>> security requirements of a protocol against operational and
>> implementation requirements.  We must be pragmatic; otherwise
>> people will not implement and deploy the secure protocols
>> that the IETF standardizes.
>> 
>> The Security Area intersects with all other IETF areas, and
>>