Linus Nordberg | 16 Sep 13:52 2014
Picon

IETF web site behind CloudFlare

Hi IETF,

It seems like www.ietf.org is behind CloudFlare:

$ dig +short www.ietf.org
www.ietf.org.cdn.cloudflare.net.
104.20.1.85
104.20.0.85

This is sad because it's now not possible to visit the site without
accepting JavaScript. At least if you get selected for solving a
CAPTCHA. Tor users is one group of users who are selected.

Is this permanent?
Will it hit more domains than www?
Where can I read about the decision to hide www behind CloudFlare?

Thanks,
Linus

Olafur Gudmundsson | 16 Sep 14:55 2014

Re: Substantial nomcom procedure updates (Was: Re: Consolidating BCP 10 (Operation of the NomCom))


On Sep 15, 2014, at 10:44 PM, Michael StJohns <mstjohns <at> comcast.net> wrote:

At 05:32 PM 9/15/2014, Jari Arkko wrote:
Michael,

Your list is good and worth working on. Thank you!

I do have some comments and questions though.

1) Update 3777 to merge in the various changes that have been posted. (this rev)
2) Add text to fix the revealed-broken recall process

Remind me what this is about.

This was related to the painful process we started to implement to resolve the IAOC issue.  Basically, even at the beginning of the process we started finding problems (e.g. petitioner's couldn't serve on the recall committee turned out to have some warts).  I looked at the process as described in 3777 and realized that it would take most of 2 months to complete the process and concluded that a long drawn out process was bad for the IETF.  That led to the text in the above document to shorten various process related actions (selection of the recall committee comes from last nomcom volunteer list as a suggestion).


I started the only recall process, it started in October and ran into November meeting. 
One of the issues I ran into was “who is nomcom eligible” this is important when a process spans an IETF meeting,  i.e. can someone gain/loose nomcom 
eligibility during the meeting. 
Having people that sign recall petition excluded from the recall committee is double edged sword, it may motivate people to either sign (in order to avoid serving) or refuse to server in the hope of being picked for committee.
I think the suggestion that last set of Nomcom volunteers be used as a group to select from is a good one, but that again gets into the the issue of who is nomcom eligibility 
at the time of appointment. 

The whole set of rules as to who works for the same company are difficult at best to manage, I would like to see them clarified to be 
- “affiliation at last IETF meeting attended”, 
- “affiliation on the date of action. 
I had to rule out a person who told me confidentially that they were interviewing a company X which already had max people signing the recall, just to avoid possible 
problem that down the road. 

There is no time limit to collect recall signatures. One month seems reasonable time frame for failing a recall petition. 

On a different note, appointing nomcom in current process depends on having a chair.
Appointing a chair frequently is difficult due to the time commitment that the chair must make. 
I would seriously advocate that we remove from the chair as much work as possible, 
for example anyone can run the selection process.
We can possibly create a position of Nomcom Selector who’s only role is to run the selection process on time during April and May each year.
The same person would be expected to run the selection process if there is need at later times. 
An alternate is to have the secretariat run this process, as there is no magic other than selecting the 
seeds for the program. 

Olafur


Melinda Shore | 16 Sep 07:35 2014
Picon

Re: Substantial nomcom procedure updates (Was: Re: Consolidating BCP 10 (Operation of the NomCom))

On 9/15/14 8:55 PM, Michael StJohns wrote:
> Mostly I think its about too large a representation by large
> organizations, regardless of their individual foci of commercial,
> educational, international or state goals.   As a matter of
> pragmatism, the folks we select for our leadership positions tend to
> come from large organizations, simply due to the level of support
> necessary for a participant to be successful in an IETF leadership
> position.  Changing the selection process for the composition of the
> Nomcom is realistically NOT going to change that tendency.  What
> modification of the selection process should do is reduce one of the
> enablers for oligarchical organizational behavior - specifically like
> selecting like.

I think that's correct, and addressing it requires more structural
changes than we're likely to be able to implement any time soon.
But.  I do think there's value in having leadership come from companies
competing with each other, if we're limited to having the leadership
come from large vendors.  It's not only because it helps diffuse
influence, but also because they can be very different organizationally,
and that can be useful (different decision-making and management styles,
for example).

Melinda

Hosnieh Rafiee | 11 Sep 17:23 2014

RE: Question about Crypto algorithm

 

Dear Prof. Margraf,

 

Thanks a lot for your message and the time you spend to answer my question. Please find my responses in red color.

 

 

Best Regards,

Hosnieh (Sara)

P.S. I included two people who are interested to know the security aspect of this proposal (in particular crypt aspects)

 

From: Margraf, Marian, Dr. [mailto:marian.margraf <at> h-da.de]

Sent: Thursday, September 11, 2014 4:08 PM

To: Hosnieh Rafiee

Subject: Fwd: Question about Crypto algorithm

 

Dear Mr Rafiee,

 

Mr Heinemann asked me to answer you. 

 

My first remark is, that an ecc public key (in bit representation) is not uniformly distributed. It depends on the format of the public key that you use. For example, if you use the uncompressed format, the public key is of the form (x,y), a point on the curve. For a value x there are at most two values of y such that (x,y) is a point on the curve. Maybe this leads to a lower entropy as 64 bit (but I am not sure).

 

Do you mean that with this way we will not have much randomization of the IP addresses in a certain network?

does it only randomization issue or it might also impact on its security since it is easy for an attacker to find the same value because of lacks of entropy?

There is actually standard document that explain how to implement ECC (http://tools.ietf.org/html/rfc6090 ) , I used this document as a reference and considered my nodes would implement it. May I ask you please skim on the document about this ECC algorithm to see whether or not it does have this compression.

Thank you

 

 

Second remark: Of course, only the owner of the private key can sign the value (random IDD +  time stamp). But this private key is not be used in the following communication (or is it, I am not familiar whit IPv6 in detail). My question: What happens, if the attacker blocks the original message, choose the same idd and then sends the message as his own idd to the other nodes. Is this possible.

 

I understand that you are crypto specialist so I try to explain the IPv6 scenario in an simple example. Before I briefly address your question.

 

The attacker cannot block the packets since it is like flooding to all nodes in the network. But the attacker can only send a packet to the victim node and claim that he has the same IP address as the victim node but with its own generated public/private key values otherwise the signature verification will be failed. Also blocking this packet does not help the attacker because the victim node expects to receive an answer and if it does not receive any answer, it starts using that IP address. (we presume in this scenario that the victim node was not compromised so that the private key is exposed to the attacker).

 

The attack on my algorithm are in two cases

1-  The attacker must use ECC algorithm to generate the same 64 bits as the legitimate node – this attack only possible in a few seconds because later other nodes keep the public key of this legitimate nodes in their memory after a successful verification

2-  The attacker then needs to generate the same public key as what the legitimate node has (after the few seconds)

 

How a computer generates and IP address

 

-    Computer A generates a key pairs using ECC public key cryptography. (RFC 6090)

-    Computer A use my draft RFC and apply my algorithm to generate and use 64 bits of this public key

(Half from right part of public key and half from left.)

-    Computer A concatenates this 64 bits public key (so called IID) with a fixed 64 bits and this indicates the IP address of the node.

-    Computer A signs (128-bit IP address + timestamp)

-    Computer A creates a packet, uses this IP address as a source of the packet, includes this signature as an optional part of this packet, adds the public key to the optional part of the packet and submits it to all other computers in this network. With this way it checks whether or not anybody in the network has the same IP address as computer A has.

 

Verification Process in computer A

If computer B has the same IP address (or it is an attacker that claims to have the same IP address) as computer A, it immediately generates a packet with the same way as computer A did and sends this packet to computer A. When computer A receives this packet, it needs to verify this claim because computer B now claims that it has the IP address that computer A generated (or they both have the same 64 bits IID). Computer A follow the following steps for the verification (I skip the timestamp verification and only focus on the main points);

1.  Computer A verifies the signature, if it is successful it goes to next step

2.  Computer A retrieves the public key from the computer B’s packet and divide it into two halves (use the same algorithm to generate the same value as computer A generates its IP address)

3.  Computer A takes 32 bits from each halves and concatenates these values. The resulting value is 64 bits

4.  Computer A also concatenate this 64 bits with the fixed value so called router prefix and generates a 128 bits IP address

5.  Computer A compares this value with computer’s B source IP address. If it needs to choose another IP address. If it is not the same, then Computer A understands that this is an attacker who wanted to not let computer A to generate an IP address and enter to the network.

6.  When computer B cannot claim to have the IP address of computer A, now computer A send the same packet with signed the new timestamp to all nodes and ask them to save its public key so that it complicates the attack

 

Private key is only used to sign the packet but never sent to computer B or never exchanged. Computer A only sends its public key to other nodes for the purpose of verification. The packets only signed but not encypted.

 

 

 

Do you think that this scenario is clear enough to judge about the algorithm?

Thank you,

 

 

 

 

Best regards, Marian Margraf

 

--

Prof. Dr. Marian Margraf

Theoretische Informatik und IT-Sicherheit

 

Hochschule Darmstadt

University of Applied Sciences

 

Schoefferstr. 8b

D-64295 Darmstadt

Telefon: +49(0)6151-168457

Mobil:     +49(0)171 6534179

 

 

 

 

From: Hosnieh Rafiee <hosnieh.rafiee <at> huawei.com>

Subject: Question about Crypto algorithm

Date: 10. September 2014 | KW 37 10:29:47 MESZ

To: "andreas.heinemann <at> h-da.de" <andreas.heinemann <at> h-da.de>

 

Dear Prof. Heinemann,

 

I just found your name accidentally during my search for people who works in security, in particular, cryptography. (My profile : http://rozanak.com/contact.aspx  ).

 

I have finished my Ph.D. at Hasso plattner Institute in security in internet technologies and now work as a senior security researcher at Huawei technologies. I am not a crypto person but only use cryptographic algorithms for security purposes and only evaluated their performance. I am working on standards and security standards and this is why I am active at IETF.

 

Why I contact you is because I am in a need of a crypto reviewer to only give us his/her opinion about the following case:

I have a draft RFC which is about IPv6 address generation in a secure manner. This is alternative approach to Cryptographically Generated Addresses (CGA). that I have submitted it to independent track.

 

How the algorithm work is that, since IPv6 address is only 128 bits and only I can generate 64 bits of this value. To avoid an attacker to forge the identity of my node, I use ECC algorithm and generate a key pairs. Then I divide the public key in two halves (only for randomization) and retrieve 32 bits from each halves. Then I concatenate these value and the result would be 64 bits interface ID of my IPv6 address.

My node then needs to check the conflicts in the network. For doing this it sign this value including a timestampt to avoid replay attack with its private key and sends the signature + public key to all nodes in the local link. Since 64 bits of this node is ECC public key (not exactly like finger print of public key), so the attacker only has a few seconds during this step to break this 64 bits. After this few seconds, all nodes in this local link cache the public key of this node.

 

My claims:

1- The attacker cannot predict what IP address a new node might choose so that it can break it offline

2- The attacker needs a very big database to try to create a rainbow table for each single possible values for 2^64 bits so in practice this is not possible

3- After a few seconds of the first check the attacker needs to do this attack against the whole public key which depends on the security of ECC.

 

So now what is your opinion. Do you think this approach work well?

If you need more information, I would be glad to share that with you.

 

This is where you can find this draft

https://tools.ietf.org/html/draft-rafiee-6man-ssas-10

 

Thank you,

I look forward to receiving your response.

Best Regards,

 

 

------

Dr. Hosnieh Rafiee

Security Competence Department

HUAWEI TECHNOLOGIES DUESSELDORF GmbH

Munich Office, European Research Center

Riesstraße 25

80992 München

Tel: +49 (0)89 158834 4047

M: +49 (0)162 204 74 58

 

E-mail: hosnieh.rafiee <at> huawei.com

 

HUAWEI TECHNOLOGIES Duesseldorf GmbH

Am Seestern 24, 40547 Düsseldorf, Germany, www.huawei.com Registered Office: Düsseldorf, Register Court Düsseldorf, HRB 56063, Managing Director: Jingwen TAO, Wanzhou MENG, Lifang CHEN Sitz der Gesellschaft: Düsseldorf, Amtsgericht Düsseldorf, HRB 56063,

Geschäftsführer: Jingwen TAO, Wanzhou MENG, Lifang CHEN

 

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁

止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中

的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended

recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

 

 

--

Prof. Dr. Andreas Heinemann

Fachbereich Informatik

Hochschule Darmstadt - University of Applied Sciences

Haardtring 100 

D-64295 Darmstadt

 

Tel.:  06151-16-8482

Fax.: 06151-16-8935

E-Mail: andreas.heinemann <at> h-da.de

Büro: D14/1.10, Schöfferstr. 8b, 64295 Darmstadt

 

PGP-Public Key:

https://www.fbi.h-da.de/organisation/personen/heinemann-andreas.html

http://pool.sks-keyservers.net:11371/pks/lookup?search=0x60355C96811D6CB7

 

 

 

 

 

Michael Richardson | 15 Sep 14:39 2014
X-Face
Picon

Re: Consolidating BCP 10 (Operation of the NomCom)


Michael StJohns <mstjohns <at> comcast.net> wrote:
    > At 07:20 PM 9/13/2014, Joel M. Halpern wrote:
    >> Might it make sense to follow the original proposal first, and just ge
    >> the current procedures as understood documented in one place.  And
    >> make sure that is correct, before embarking on changes?

    > As far as I understand, Murray is proposing "no change in effective
    > behavior" in the first pass, so whether or not we manage to get an RFC
    > through before the next nomcom or not, the publication of a simply
    > updated 3777 is really nothing more than clean up without any change in
    > effect to the current Nomcom, nor in the behavior of any follow-on
    > Nomcom.

The idea was a clean up, no significant changes.

For instance, it turns out that you have to read very carefully to determine
that the IRTF chair is not eligible for nomcom, because the IRTF chair
is an ex-officio member of the IAB, and IAB members, including ex-officio
are not eligible.  It would be nice to include that conclusion explicitely.
I think that text about that should be included, and I'll propose some to
Murray.

On the other hand, it appears that both ISOC and AMSL (secretariat) employees
are nomcom eligible.  It's not clear that they should be; changing that
would require some additional thinking, and I would not propose any change.

    > That's a long winded way of saying no.  If there were a pressing need
    > for the current Nomcom, I'd suggest they use the "operational
    > discretion" portion of the document.  If there were a well understood
    > set of changes that have been incorporated in practice, but not in
    > documentation, I *might* say yes.  Neither of these appear to apply -
    > hence, "No".

The risk is a failure to pass on enough oral tradition from one nomcom chair
to another;  this results in proceedural mistakes due to mis-reading.  Being
consistent to what we wrote down is pretty important in my opinion.

--
Michael Richardson <mcr+IETF <at> sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Michael StJohns | 14 Sep 23:12 2014
Picon
Picon

Re: Consolidating BCP 10 (Operation of the NomCom)

At 01:09 AM 9/14/2014, Murray S. Kucherawy wrote:
On Sat, Sep 13, 2014 at 5:06 PM, Michael StJohns <mstjohns <at> comcast.net> wrote:
As far as I understand, Murray is proposing "no change in effective behavior" in the first pass, so whether or not we manage to get an RFC through before the next nomcom or not, the publication of a simply updated 3777 is really nothing more than clean up without any change in effect to the current Nomcom, nor in the behavior of any follow-on Nomcom.


Correct, that's the intent.
Â
Given that there's a real cost (can you say Last Call?) to the community as a whole for each and every RFC action, I'm underwhelmed at the idea of opening up 3777 without making a commitment to actually address its warts.


On the other hand, isn't the cost of an IETF Last Call on what amounts to consolidation of already-approved documents, and nothing else, a fair bit less than the real cost of a typical IETF Last Call on new, updated, or otherwise not-yet-approved work?  Given the no changes constraint, the Last Call reviewers only need to confirm that the consolidation was done correctly and the result is still understandable.  There's nothing new to debate here.

Have you see an IETF Last Call (humorous rhetorical question)?  More seriously, I appreciate your optimism, but empirical evidence  (e.g. the 5 or 6 messages with language changes for your draft, as well as every other Last Call in recent history) would suggest that the chances of getting this through last call without pain are slender if not non-existent.


Â
That's a long winded way of saying no.  If there were a pressing need for the current Nomcom, I'd suggest they use the "operational discretion" portion of the document.  If there were a well understood set of changes that have been incorporated in practice, but not in documentation, I *might* say yes.  Neither of these appear to apply - hence, "No".


I'm on the current NomCom (and was on the last one too), and I think it would be reasonable for me to say that both of them sure thought it would be nice to have had this work done ahead of time.  I wouldn't say it's a pressing need, but if one NomCom after the next seems to have the same sentiment, then it's probably work that's due or even past due.

Instead, let me suggest you do the above - but to a specific ID stage.  Let the/a Nomcom adopt the operations section of a specific ID as part of their 3777 permitted operational discretion.   That deals with the Nomcom's particular problems without the need to deal with the RFC process.

It also leaves the clock ticking as each ID expires after 6 months.  That will ensure that instead of just saying "its good enough" we have incentive to go ahead and fix the issues that have occurred.



Â
To be blunt, we're already... *sigh* splitting nits about the meaning of certain sections, words, word combinations, etc.  I'd really rather not go through that more than once every 5 years or so.


By that reasoning, it's time, since RFC3777 is more than ten years old and all but one of the applied updates are at least five years old.  I suggest that doing this first will make it easier to do the follow-on work you're suggesting, especially since a diff to this document (when published), and thus to the true current practice, will be very easy to generate.


We didn't open up 3777 to add the interim fixes because it was "too hard".  If we're not going to open 3777 up for substantive changes, then I see no reason to publish what is nothing more than a cosmetic reworking of existing and documented practice.    It's work for the editor, but more than that its work for the RFC staff, for the IESG, for the IAOC and for the IAB (yup - all have to sign off on it).

Instead, let's do it the right way.  Get the Chairs (IAB, IETF and IAOC) to appoint a design team in the general area and provide a page or two of things they think need to be fixed.  Solicit the community for any other issues.  Draft the first public version of the document to be feature complete for those issues and have text for each approach to solving each identified problem.


-MSK


I do understand the desire to take small bites - I just think you're trying to solve your first problem (Nomcom process) the wrong way.

Mike



Murray S. Kucherawy | 14 Sep 07:09 2014
Picon

Re: Consolidating BCP 10 (Operation of the NomCom)

On Sat, Sep 13, 2014 at 5:06 PM, Michael StJohns <mstjohns <at> comcast.net> wrote:
As far as I understand, Murray is proposing "no change in effective behavior" in the first pass, so whether or not we manage to get an RFC through before the next nomcom or not, the publication of a simply updated 3777 is really nothing more than clean up without any change in effect to the current Nomcom, nor in the behavior of any follow-on Nomcom.

Correct, that's the intent.
 
Given that there's a real cost (can you say Last Call?) to the community as a whole for each and every RFC action, I'm underwhelmed at the idea of opening up 3777 without making a commitment to actually address its warts.

On the other hand, isn't the cost of an IETF Last Call on what amounts to consolidation of already-approved documents, and nothing else, a fair bit less than the real cost of a typical IETF Last Call on new, updated, or otherwise not-yet-approved work?  Given the no changes constraint, the Last Call reviewers only need to confirm that the consolidation was done correctly and the result is still understandable.  There's nothing new to debate here.
 
That's a long winded way of saying no.  If there were a pressing need for the current Nomcom, I'd suggest they use the "operational discretion" portion of the document.  If there were a well understood set of changes that have been incorporated in practice, but not in documentation, I *might* say yes.  Neither of these appear to apply - hence, "No".

I'm on the current NomCom (and was on the last one too), and I think it would be reasonable for me to say that both of them sure thought it would be nice to have had this work done ahead of time.  I wouldn't say it's a pressing need, but if one NomCom after the next seems to have the same sentiment, then it's probably work that's due or even past due.
 
To be blunt, we're already... *sigh* splitting nits about the meaning of certain sections, words, word combinations, etc.  I'd really rather not go through that more than once every 5 years or so.

By that reasoning, it's time, since RFC3777 is more than ten years old and all but one of the applied updates are at least five years old.  I suggest that doing this first will make it easier to do the follow-on work you're suggesting, especially since a diff to this document (when published), and thus to the true current practice, will be very easy to generate.

-MSK
Tony Hansen | 14 Sep 04:27 2014
Picon

Re: Bug reporting/tracker for xml2rfc?

On 9/13/14, 1:40 PM, Michael StJohns wrote:
> Ok - I've looked and I can't find a specific or even general email address for sending outage/problem
reports on xml2rfc.ietf.org.  As of a few minutes ago it was broken in that it doesn't actually seem to be
running the conversion code.  Uploading files results in no output.
>
> There are a lot of email addresses associated with this tool, but most seem to be related to the form of the
RFC rather than reporting tool issues.

Henrik and I do most of the care and feeding of xml2rfc.ietf.org.

For this particular problem, /var/tmp was out of space on the machine.

I've cleared out /var/tmp, but evidently something broke with whatever 
used to automatically keep that directory clean.

I'll check with Henrik to see what he has to say.

     Tony Hansen

Joel M. Halpern | 14 Sep 01:20 2014

Re: Consolidating BCP 10 (Operation of the NomCom)

It may (or may not) make sense to examine all of the issues you list.
It seems to me the next thing to certain that the work will not even be 
completed by the time the next nomcom is seated.

Might it make sense to follow the original proposal first, and just ge 
the current procedures as understood documented in one place.  And make 
sure that is correct, before embarking on changes?

Yours,
Joel

On 9/13/14, 2:46 PM, Michael StJohns wrote:
> At 02:09 AM 9/4/2014, Murray S. Kucherawy wrote:
>> Colleagues,
>>
>> As part of my work with NomCom '14, I'm preparing a revision of
>> RFC3777 that incorporates all of the updates made to it subsequent to
>> its publication ten years ago.  This would roll all of the documents
>> making up the NomCom's definition and procedures into one place.
>>
>> The draft is available here:
>>
>> https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/
>>
>> It is at present nothing more than a republishing of RFC3777 verbatim,
>> with some slight organization adjustments that come along with
>> conversion to xml2rfc (RFC3777 was done in nroff), and all of the
>> changes made by the other documents that currently comprise BCP 10
>> have been incorporated.  There have been no other substantive content
>> changes made.
>>
>> My plan is to keep it that way for this go-around.Â
>
> Hi Murray -
>
>
> Until I read the "for this go around" sentence, I was actually hoping
> someone was opening this up for a comprehensive revision.
>
> Here's what I think needs to happen (prior to the next IETF nomcom
> selection):
>
> 1) Update 3777 to merge in the various changes that have been posted.
> (this rev)
> 2) Add text to fix the revealed-broken recall process
> 3) Add text to fill out what constitutes a vacancy.  E.g.
>      a) Vacancy by term completion
>      b) Vacancy by resignation
>      c) Vacancy by death or incapacity
>      d) Vacancy by recall
>      e) Vacancy by expulsion
> 4) Add text to fix disconnects between what the Nomcom and the
> confirming bodies believe to be true with respect to:
>     a) what is and is not confidential about a candidate with respect to
> the confirming body
>     b) what MUST be provided to the confirming bodies
>     c) what MAY be provided
>     d) what must be provided to the nomcom by the confirming body on
> rejection of candidates (my take, simply the fact of rejection)
>     e) that the rejection of a candidate is NOT a failure of process.
> 5) [This one is one of my hot buttons, but is somewhat controversial.
> It's based  in part on my belief that the "we all participate as
> individuals, rather than members of company" trope is no longer even
> minimally true, especially for more recent participants.] Rework the
> Nomcom selection process to minimize the statistical affects of one or
> more companies each comprising large portions of the Nomcom volunteer
> pool. [Statistically,  if a company has 30% of the volunteers, they have
> an 85% chance of having 2 nomcom members, a 97% chance of having at
> least 1].
>
>
> Item's 2, 3 and 4 are fixes  for events (failures of process) that have
> happened since the publication of 3777.
>
> With respect to 5 - the text in 3777 is that the selection process
> should be fair - which is defined to mean:  "
>
> A method is fair if
> each eligible volunteer is equally likely to be selected."
> That definition is already broken in that we cap the number of nomcom
> members from any given company at 2 - which means that anyone in a large
> company already has a lesser chance of selection then that represented by
> his portion of the volunteer pool.
>
> I think we benefit from diversity of opinion, and even more from
> diversity of experience. I'm concerned that the Nomcom has been at times
> rather over populated with large company representatives with a related
> narrowing of the experience pool.
>
>
>> Then, if the community would like to actually crack open the document
>> and revisit some of the content, that would be a second project (for
>> which I would probably volunteer to act as editor).
>
> See above.  I don't think you actually gain anything by splitting this
> into two stages as the text from the roll up revision is going to need
> to change; going through the process - twice - to move revisions to RFC
> seems to be to be a waste of effort.
>
> Mike
>
>
>
>
>> Comments welcome.
>>
>> -MSK, hatless
>

Michael StJohns | 13 Sep 20:46 2014
Picon
Picon

Re: Consolidating BCP 10 (Operation of the NomCom)

At 02:09 AM 9/4/2014, Murray S. Kucherawy wrote:
Colleagues,

As part of my work with NomCom '14, I'm preparing a revision of RFC3777 that incorporates all of the updates made to it subsequent to its publication ten years ago.  This would roll all of the documents making up the NomCom's definition and procedures into one place.

The draft is available here:

https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/

It is at present nothing more than a republishing of RFC3777 verbatim, with some slight organization adjustments that come along with conversion to xml2rfc (RFC3777 was done in nroff), and all of the changes made by the other documents that currently comprise BCP 10 have been incorporated.  There have been no other substantive content changes made.

My plan is to keep it that way for this go-around. 

Hi Murray -


Until I read the "for this go around" sentence, I was actually hoping someone was opening this up for a comprehensive revision.

Here's what I think needs to happen (prior to the next IETF nomcom selection):

1) Update 3777 to merge in the various changes that have been posted. (this rev)
2) Add text to fix the revealed-broken recall process
3) Add text to fill out what constitutes a vacancy.  E.g.
    a) Vacancy by term completion
    b) Vacancy by resignation
    c) Vacancy by death or incapacity
    d) Vacancy by recall
    e) Vacancy by expulsion
4) Add text to fix disconnects between what the Nomcom and the confirming bodies believe to be true with respect to:
   a) what is and is not confidential about a candidate with respect to the confirming body
   b) what MUST be provided to the confirming bodies
   c) what MAY be provided
   d) what must be provided to the nomcom by the confirming body on rejection of candidates (my take, simply the fact of rejection)
   e) that the rejection of a candidate is NOT a failure of process.
5) [This one is one of my hot buttons, but is somewhat controversial.  It's based  in part on my belief that the "we all participate as individuals, rather than members of company" trope is no longer even minimally true, especially for more recent participants.] Rework the Nomcom selection process to minimize the statistical affects of one or more companies each comprising large portions of the Nomcom volunteer pool. [Statistically,  if a company has 30% of the volunteers, they have an 85% chance of having 2 nomcom members, a 97% chance of having at least 1].


Item's 2, 3 and 4 are fixes  for events (failures of process) that have happened since the publication of 3777.

With respect to 5 - the text in 3777 is that the selection process should be fair - which is defined to mean:  "A method is fair if each eligible volunteer is equally likely to be selected."  That definition is already broken in that we cap the number of nomcom members from any given company at 2 - which means that anyone in a large company already has a lesser chance of selection then that represented by his portion of the volunteer pool. I think we benefit from diversity of opinion, and even more from diversity of experience. I'm concerned that the Nomcom has been at times rather over populated with large company representatives with a related narrowing of the experience pool.


Then, if the community would like to actually crack open the document and revisit some of the content, that would be a second project (for which I would probably volunteer to act as editor).

See above.  I don't think you actually gain anything by splitting this into two stages as the text from the roll up revision is going to need to change; going through the process - twice - to move revisions to RFC seems to be to be a waste of effort.

Mike




Comments welcome.

-MSK, hatless

Melinda Shore | 13 Sep 19:53 2014
Picon

Re: Bug reporting/tracker for xml2rfc?

On 9/13/14 9:40 AM, Michael StJohns wrote:
> There are a lot of email addresses associated with this tool, but
> most seem to be related to the form of the RFC rather than reporting
> tool issues.

I'm finding the support situation with regard to IETF tools rather
unclear in general (datatracker vs. tools vs. whatever) and have
writing something up for the chairs wiki on my "to do" list.
If you forward to me what you learn, I can add xml2rfc, as well.

Melinda


Gmane