RE: IETF Diversity Question on Berlin Registration?
All of which is why we should limit our attempts to do numerical analysis for this topic, and worry far more about the basics, including such things as interaction (in)sensitivities, group tone and style, and observable misbehaviors, all of which are likely to produce biasing results. Certainly useful, but it is easy to inject one's own bias into such processes, and to overlook other factors. I may be biased, but I have the impression that the largest source of bias in IESG selection is the need to secure funding for the job, which effectively self-select people working for large companies making networking products. Gender may be the least of the problems there; there are other dimensions of diversity, e.g. academic vs. industry, network equipment versus internet service providers, software versus hardware, etc. Only a fraction of these segments can afford to have someone working full-time on the IESG. Now, having to work full time is a bit much for a volunteer position, and we may want to consider ways to remedy that. -- Christian Huitema
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 01:53, Margaret Wasserman wrote: Hi Tom, On Apr 19, 2013, at 6:03 AM, t.p. daedu...@btconnect.com wrote: If we required the IETF to reflect the diversity of people who are, e.g., IT network professionals, then the IETF would fall apart for lack of ability. […] If the ADs of the IETF have to represent the diversity of the world - which could in extremes.. Has anyone even suggested that IESG should reflect the diversity of these groups? Where is this coming from? You are putting up strawmen, so that you can tear them down… The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. The evidence seems to be that human's are terrible at guessing statistics, and the only statistics that are reliable as those objectively gathered and subjected to rigorous statistical analysis. You can often see this in human assessments of risk. It is also in the nature of statistics that you get long runs of outliers, and that only when you take a long view to you see the averages you would expect. Again Humans are terrible with this, assuming for example that a coin that comes up heads 10 times in a row the assumption is that this is bias, and not a normal statistical variation that you would expect in an infinite number of throws. Given the diversity ratios that we see, it is unclear to me whether we are observing a systematic effect or a statistical effect. It would be useful to the discussion if we could see data on diversity that was the output of a rigorous statistical analysis. i.e. one that included a confidence analysis and not a simple average in a few spot years. - Stewart
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 05:05, Michael StJohns wrote: At 08:53 PM 4/28/2013, Margaret Wasserman wrote: The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. Let's consider for a moment that this may not actually be the correct question. Instead, consider Why the diversity of the IETF leadership doesn't reflect the diversity of the set of the IETF WG chairs? I believe this is a more representative candidate population for the IAB and IESG. By my count (using the WG chairs picture page), there are 202 current working group chairs. Of these 15 are female - or 7.4% of the population [It would be more reliable to do this for any WG chair in the last 5-10 years, but the above was readily available and I think provides at least the basis for discussion. Anticipating the argument, I would assume for the sake of discussion a fairly similar percentage of ex-working group chairs per gender unless there is evidence to the contrary] There are 14 (current area directors plus the chair) members of the IESG, of which none are currently female. There are 12 current IAB members of which 1 member is female. Assuming perfect distribution, that would suggest that 14 * (15/202) or 1.03 IESG members should be female. Assuming perfect distribution, that would suggest that 12 * (15/202) or .89 IAB members should be female. Assuming perfect distribution, that would suggest that 26 * (15/202) or 1.93 IAB + IESG members should be female. And pretending for a moment that picks for the IAB and IESG are completely random from the candidate set of Working group chairs, the binomial distribution for 7.4% for 27 positions is: 0 - 12.5%, 1 - 27.0%, 2 - 28.1%, 3 or more - 32.5%. (e.g. about 40% of the time, the IAB and IESG combined will have 0 or 1 female members). for 7.4% for 15 positions (IESG) is: 0 - 31.4%, 1 - 37.8%, 2 - 21.2%, 3 or more - 9.5% for 7.4% for 12 positions (IAB) is: 0 - 39.6%, 1 - 38.1%, 2 - 16.8%, 3 or more - 5.4% But the actual one you should consider is 7.4% for 14 positions (annual replacement): 0 - 34%, 1 - 38.1%, 2 - 19.9%, 3 or more - 8%. This last one says that for any given nomcom selection, assuming strict random selection, 72% of the time 0 or 1 females will be selected across both the IAB and IESG. You should use this one as the actual compositions of the IAB/IESG are the sum of all the nomcom actions that have happened before. There are statistical tests to determine whether there is a statistically significant difference in populations, but my admittedly ancient memories of statistics suggest that the population size of the IAB/IESG is too small for a statistically valid comparison with either the WG chair population or the IETF population. Of course, the nomcom doesn't select and the confirming bodies do not confirm based on a roll of the dice. But looking at this analysis, it's unclear - for this one axis of gender - that the question why the diversity of the IETF leadership does not reflect the diversity of the set of IETF WG chairs has a more correct answer than the luck of the draw. My base premise may be incorrect: That you need to have been a WG chair prior to service as an IAB or IESG member. I hope it isn't as I think this level of expertise is useful for success in these bodies. Assuming it is correct, then the next question is whether or not there is a significant difference in percentage of female attendees vs percentage of female working group chairs and is there a root cause for that difference that the IETF can address in a useful manner. Mike This is in line with my own estimate based on an approximation of 1:10 which with random selection gives an error approximation of sqrt(1)=1 The other thing to remember is that whilst your proportional estimates are likely to be correct, in a random process you will get long runs of bias that only average out in the long run. So you will get long runs of 0. Very infrequently you will also get long runs of 27. In both cases it is in human nature to would assume something is wrong, when it is an artifact of random numbers. Humans have considerable difficulty discriminating between systematic and statistical problems, and taking the long view rather than the short view. For that reason, as I noted in my previous post, we need a rigorous statistical analysis with proper confidence intervals, rather than simple averages on spot years. - Stewart
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 06:57, Dave Crocker wrote: On 4/28/2013 10:52 PM, Christian Huitema wrote: Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. Mike actually mentioned that. Let's assume a simplified curriculum of participant - author/editor - WG chair - IESG, which more or less reflects increasing seniority in the IETF. We may suspect that there is bias that, at each step, privileges some candidates over others. However, the mechanisms are different at each step. Exactly. Complicated processes, needing high quality data that gets complicated analysis, that we aren't well-enough trained to do well and aren't going to be doing. Dave Of all the social mixes you would anticipate the IETF to be in the likely to do it, likely to do it correctly quadrant. Stewart
RE: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Hi, This new text is OK. Thanks Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 29 April, 2013 11:26 AM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Roni Even ron.even@gmail.com wrote: Martin, Thanks for the response. I am OK with your responses to the nits. As for the comment on location I think I understand but what got me thinking was the examples. In E.1 An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create namefastethernet-1/0/name /interface When the server processes this request, it will set the leaf type to ethernetCsmacd and location to 1/0. Thus, if the client performs a get-config right after the edit-config above, it will get: interface namefastethernet-1/0/name typeethernetCsmacd/type location1/0/location /interface I can see how the linkage between the location and name is done. I am not sure how the operator knows from the response what is the physical location without knowing the device type and manufacturer but at least the linkage is there and this is why I thought of it more as a logical device and not physical one. Ok. Since this is an example of a configuration of a physical interface, it is assumed that the operator somehow knows which physical port is being reconfigured -- somehow the operator must be able to know what the port where the new cable was inserted is called in the config. But it makes sense to be more clear about this. How about this change: OLD: The implementation restricts the names of the interfaces to one of fastethernet-N/M or gigabitethernet-N/M. The location of an interface is a string on the form N/M. The implementation auto-initializes the values for type and location based on the interface name. NEW: The implementation restricts the names of the interfaces to one of fastethernet-N/M or gigabitethernet-N/M. The location of an interface is a string on the form N/M. It is assumed that the operator is aware of this naming scheme. The implementation auto-initializes the values for type and location based on the interface name. When looking at E2.2 example (ditto for this example.) /martin An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create nameacme-interface/name typeethernetCsmacd/type location1/0/location /interface Here the operator need to know the device to configure a specific interface and know how many interface exist and how they are named. So you assume that for this case this is known to the configuration. Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 28 April, 2013 12:50 PM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Thank you for your review. Comments inline. Roni Even ron.even@gmail.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. The sentence just before the quoted one above says: The format of this string is device- and type-dependent. and then the text says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. So the exact procedure is currently left to the vendors, but may be standardized in a future document (if possible...) I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments:
Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
On 4/29/13 12:59 AM, mohamed.boucad...@orange.com wrote: Robert, Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy: (1) OLD: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). NEW: The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. (2) OLD: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. NEW: Furthermore, means to recover state in failure events (e.g., [RFC5460]) must be supported, but are not discussed in this document. Is this better? 1 is better. 2 is an improvement, I might say such as instead of e.g. to even more strongly avoid someone thinking you are _requiring_ implementation of RFC5460. Even then, it's still not clear whether you're trying to say Something that doesn't do this is does not conform to this specification or Something that doesn't do this isn't as good a tool as it can be and may create a condition that operators and users will not like much. You chose not to use MUST in that sentence. Can you make it less likely that someone will assume you meant to? Cheers, Med -Message d'origine- De : Bernie Volz (volz) [mailto:v...@cisco.com] Envoyé : samedi 27 avril 2013 06:24 À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 Robert: The reason to allow this is that otherwise client A will be unnecessarily reconfigured many times. (It is also possible that a client might Renew on its own just as this is happening and thus it can also be removed from the Reconfigure.) I think the text should be cleaned up to indicate that allowing removal of already reconfigured clients is recommended (to prevent unnecessary reconfigures) when retransmitting the Reconfigure-Request. Note that if clients are added, that is not a retransmission but requires a new message (new XID). - Bernie -Original Message- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Friday, April 26, 2013 12:19 PM To: mohamed.boucad...@orange.com Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools .ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Med: This example does not apply for that text. Really? What text constrains how you change what's in the retransmission? In fact, the example should be the other way around. Perhaps, this can be made clearer if we change (e.g., update the Client Identifier list) to (e.g., remove a client from the Client Identifier list). If I understand you correctly, you need more than just changing a parenthetical e.g.. I think you're
Gen-ART review of draft-ietf-karp-crypto-key-table-07
Document: draft-ietf-karp-crypto-key-table-07 Reviewer: David L. Black Review Date: April 25, 2013 IETF LC End Date: April 29, 2013 Summary: This draft is on the right track, but has open issues described in the review. This draft describes a conceptual key database for use by protocols. It's definitely useful and valuable work, as key management is often an afterthought in protocol design, even when security functionality is actively worked on in the design process. The draft text is in good shape and reads cleanly, but the draft is short on precision in specifying a number of the fields for the database, and the IANA registries; most of the open issues are requests for the level of precision needed for interoperability and reuse of database implementation across different protocol implementations. Major issues: (Section 2) [1] LocalKeyName and PeerKeyName are strings. What character set? If Unicode (e.g., UTF-8?), add text on Unicode considerations (e.g., normalization). Finding a Unicode expert will help in getting this done quickly. I have similar concerns for other strings, and in particular, IANA should be told what a string is for any registry field that contains one. [2] I'm not sure that I understand what a KDF really is from its high level description in this draft. At the least, I'm surprised that the importance of non-invertibility of a KDF is not mentioned - beyond that, a functional description of inputs and outputs would help, including a strong recommendation to inject unpredictable nonce material. This could be handled by referencing material on what a KDF is that exists elsewhere. (Section 4) [3] It's important that this section cover all the fields involved in the database lookups in Section 3 whose format may be protocol-specific (the Direction and various time fields aren't). Protocol should be covered by the IANA registry, peers and key names are covered here, but interface appears to be missing - item (9) covers presence vs. absence of interface information, but not its format. --- Lots of issues with the IANA Considerations (Section 8) (Section 8.1.1) [5] No field format information for the fields in a registry entry. IANA should be told what formats to expect/use. [6] Protocol Specific Values is not the same as ProtocolSpecificInfo in section 2; the same name should be used, but whitespace differences are ok. [7] Should some sort of formats for Peers and Interfaces be included in registering a Protocol? If not, the lookups in section 3 may be implementation-dependent (strings that work w/one implementation may not work w/other implementations of the same protocol). The specification reference may suffice based on the requirements in section 4 for what has to be in each referenced specification. (Sections 8.2 and 8.3) [8] No registry entry content descriptions. Need to supply information on what to register and the formats of the elements of a registry entry. [9] I suggest Expert Review for these registries, not just First Come First Served, so that someone with a security clue can check that the proposed registrations are reasonable. Minor issues: [A] Overall - I would like to see a paragraph added on how this database conceptually relates to the IPsec Peer Authorization Database (PAD) - see RFC 4301, section 4.4.3. [B] (Section 2) Where is key size recorded? Is that an implicit attribute of Key? [C] (Section 3) Where does key selection occur? I would suggest that the database return all possible keys and let the protocol figure out what to use. This is particularly important for inbound traffic for obvious reasons. Nits/editorial comments: I suggest dividing section 3 into - 3.1 Outgoing Traffic - 3.2 Incoming Traffic idnits 2.12.16 found a truly trivial nit - == Line 76 has weird spacing: '...strains where...' Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Med: This example does not apply for that text. In fact, the example should be the other way around. Perhaps, this can be made clearer if we change (e.g., update the Client Identifier list) to (e.g., remove a client from the Client Identifier list). Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? Med: I'm not aware of any; but if there is one we can cite it. If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. Med: Will consider that option if you think this is really needed. Nits/editorial comments:
RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Robert: The reason to allow this is that otherwise client A will be unnecessarily reconfigured many times. (It is also possible that a client might Renew on its own just as this is happening and thus it can also be removed from the Reconfigure.) I think the text should be cleaned up to indicate that allowing removal of already reconfigured clients is recommended (to prevent unnecessary reconfigures) when retransmitting the Reconfigure-Request. Note that if clients are added, that is not a retransmission but requires a new message (new XID). - Bernie -Original Message- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Friday, April 26, 2013 12:19 PM To: mohamed.boucad...@orange.com Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Med: This example does not apply for that text. Really? What text constrains how you change what's in the retransmission? In fact, the example should be the other way around. Perhaps, this can be made clearer if we change (e.g., update the Client Identifier list) to (e.g., remove a client from the Client Identifier list). If I understand you correctly, you need more than just changing a parenthetical e.g.. I think you're saying that you are constraining the message changes to be such that if anything earlier in the retransmission sequence succeeded, the request in the retransmission would also have succeeded. But why do you need that much complexity? Do you have it already with any other request? Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? Med: I'm not aware of any; but if there is one we can cite it. If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. Med: Will consider that option if you think this is really needed. Nits/editorial comments: ___ dhcwg mailing list dh...@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Hi, Thank you for your review. Comments inline. Roni Even ron.even@gmail.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. The sentence just before the quoted one above says: The format of this string is device- and type-dependent. and then the text says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. So the exact procedure is currently left to the vendors, but may be standardized in a future document (if possible...) I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments: 1.In the introduction section maybe add to the first sentence a reference to RFC6244 with some text. Ok, this probably makes sense. I will check w/ the WG and other documents. 2.In section 2 are the must and should used as described in RFC2119, if yes need capital letters Seciton 2 is more of a background, non-normative section. It lists some of the design objectives. 3.In section 3.1 It is optional in the data model, but if the type represents a physical interface, it is mandatory, suggest having RFC2119 language It is OPTIONAL in the data model, but if the type represents a physical interface, it is MUST be specified I think the first one should not be OPTIONAL, but the second one is correct. So I suggest this: It is defined as being optional in the data model, but if the type represents a physical interface, it MUST be specified. /martin
Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Hi, Roni Even ron.even@gmail.com wrote: Martin, Thanks for the response. I am OK with your responses to the nits. As for the comment on location I think I understand but what got me thinking was the examples. In E.1 An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create namefastethernet-1/0/name /interface When the server processes this request, it will set the leaf type to ethernetCsmacd and location to 1/0. Thus, if the client performs a get-config right after the edit-config above, it will get: interface namefastethernet-1/0/name typeethernetCsmacd/type location1/0/location /interface I can see how the linkage between the location and name is done. I am not sure how the operator knows from the response what is the physical location without knowing the device type and manufacturer but at least the linkage is there and this is why I thought of it more as a logical device and not physical one. Ok. Since this is an example of a configuration of a physical interface, it is assumed that the operator somehow knows which physical port is being reconfigured -- somehow the operator must be able to know what the port where the new cable was inserted is called in the config. But it makes sense to be more clear about this. How about this change: OLD: The implementation restricts the names of the interfaces to one of fastethernet-N/M or gigabitethernet-N/M. The location of an interface is a string on the form N/M. The implementation auto-initializes the values for type and location based on the interface name. NEW: The implementation restricts the names of the interfaces to one of fastethernet-N/M or gigabitethernet-N/M. The location of an interface is a string on the form N/M. It is assumed that the operator is aware of this naming scheme. The implementation auto-initializes the values for type and location based on the interface name. When looking at E2.2 example (ditto for this example.) /martin An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create nameacme-interface/name typeethernetCsmacd/type location1/0/location /interface Here the operator need to know the device to configure a specific interface and know how many interface exist and how they are named. So you assume that for this case this is known to the configuration. Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 28 April, 2013 12:50 PM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Thank you for your review. Comments inline. Roni Even ron.even@gmail.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. The sentence just before the quoted one above says: The format of this string is device- and type-dependent. and then the text says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. So the exact procedure is currently left to the vendors, but may be standardized in a future document (if possible...) I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments: 1. In the introduction section maybe add to the first sentence a reference to RFC6244 with some text. Ok, this probably makes sense. I will check w/ the WG and other documents. 2. In section 2 are the must and should used as described in RFC2119, if yes need capital letters Seciton 2 is more of a background,
Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07
Here are some quick initial responses to your comments. Thanks much for the review and I'll follow up with more detail in a while. Black, == Black, David david.bl...@emc.com writes: Black, Major issues: Black, (Section 2) Black, [1] LocalKeyName and PeerKeyName are strings. What Black, character set? If Unicode (e.g., UTF-8?), add text on Black, Unicode considerations (e.g., normalization). Finding a Black, Unicode expert will help in getting this done quickly. I Black, have similar concerns for other strings, and in particular, Black, IANA should be told what a string is for any registry Black, field that contains one. They are strings that can be compared using binary comparison. I agree we need to state that in the draft. Character set, to the extent it is specified will be specified by the individual protocol. In practice the protocol will say that it's an integer represented as an ASCII string. We needed to add the entire complexity of making these fields be strings not integers because of some non-IETF protocols that use key names. I'm reasonably confident I can sell Pete on the concept of a binary identifier for this field from an i18n standpoint. But issues, of length, format, etc are all specified by the protocol spec. Black, [2] I'm not sure that I understand what a KDF really is from Black, its high level description in this draft. At the least, I'm Black, surprised that the importance of non-invertibility of a KDF Black, is not mentioned - beyond that, a functional description of Black, inputs and outputs would help, including a strong Black, recommendation to inject unpredictable nonce material. This Black, could be handled by referencing material on what a KDF is Black, that exists elsewhere. I'm open to text either proposed on the IETF list from one of the other authors. Some protocols have a KDF input some do not. If they do, it will be drawn from a set of allowable valuable for that protocol. Black, (Section 4) Black, [3] It's important that this section cover all the fields Black, involved in the database lookups in Section 3 whose format Black, may be protocol-specific (the Direction and various time Black, fields aren't). Protocol should be covered by the IANA Black, registry, peers and key names are covered here, but Black, interface appears to be missing - item (9) covers presence Black, vs. absence of interface information, but not its format. The interface is implementation-specific not protocol specific. We mandate that you must be able to tie things to interface. However the format of an interface is quite specific to the routing platform in questino. I don't think there's a way that an IETF document can go into useful detail on that. SNMP and Netconf have models of how interfaces are represented. If we ever put together a Netconf schema for this database, we'd specify the interface there. Black, --- Lots of issues with the IANA Considerations (Section 8) Black, (Section 8.1.1) Black, [5] No field format information for the fields in a registry Black, entry. IANA should be told what formats to expect/use. Thanks, agreed. Black, [6] Protocol Specific Values is not the same as Black, ProtocolSpecificInfo in section 2; the same name should be Black, used, but whitespace differences are ok. Good catch. Black, [7] Should some sort of formats for Peers and Interfaces be Black, included in registering a Protocol? If not, the lookups in Black, section 3 may be implementation-dependent (strings that work Black, w/one implementation may not work w/other implementations of Black, the same protocol). The specification reference may suffice Black, based on the requirements in section 4 for what has to be in Black, each referenced specification. When you register a protocol you need to point to a specification that gives details on this sort of thing. Black, (Sections 8.2 and 8.3) Black, [8] No registry entry content descriptions. Need to supply Black, information on what to register and the formats of the Black, elements of a registry entry. Thanks. Black, [9] I suggest Expert Review for these registries, not just Black, First Come First Served, so that someone with a security Black, clue can check that the proposed registrations are Black, reasonable. As an individual, I support FCFS, because I think getting expert approval for some of the uses that have been proposed for these registries will be challenging.
RE: Gen-ART review of draft-ietf-karp-crypto-key-table-07
Thanks for the quick response - most of your message looks reasonable to me. I have a few additional comments. [1] Character set for key names, etc. They are strings that can be compared using binary comparison. I agree we need to state that in the draft. That's certainly a reasonable goal, and there are plenty of examples of protocols that do that. OTOH, when the character set is Unicode, generating strings for which that binary comparison for equality works as expected has a number of subtleties when the strings are input by humans. Pete Resnick and yours truly are among the people familiar with the dragons that lurk here (and the precis WG is grappling with). We needed to add the entire complexity of making these fields be strings not integers because of some non-IETF protocols that use key names. I'm reasonably confident I can sell Pete on the concept of a binary identifier for this field from an i18n standpoint. I have no problem with the field being a binary identifier, but I think implementers should be put on notice that binary comparison of human input Unicode strings doesn't work as expected unless some things are done to make it work (this used to be known as string preparation). A warning to that effect, perhaps citing a reference for details on what can go awry, accompanied by making the protocol spec responsible for getting this right ought to suffice. [3] Protocol responsibility to specify interface format We mandate that you must be able to tie things to interface. However the format of an interface is quite specific to the routing platform in question. Ok, I suggest explaining that as part of a statement that a protocol cannot in general be expected to specify interface formats that apply across all implementations due to implementation diversity. [7] Additional format information in registry Black, [7] Should some sort of formats for Peers and Interfaces be Black, included in registering a Protocol? If not, the lookups in Black, section 3 may be implementation-dependent (strings that work Black, w/one implementation may not work w/other implementations of Black, the same protocol). The specification reference may suffice Black, based on the requirements in section 4 for what has to be in Black, each referenced specification. When you register a protocol you need to point to a specification that gives details on this sort of thing. That makes sense, and section 4's requirements on the specifications cover this area, but I thought I'd ask. [9] Registry policy As an individual, I support FCFS, because I think getting expert approval for some of the uses that have been proposed for these registries will be challenging. The two registries involved are for KDFs and cryptographic algorithm identifiers. This feels like something that the security area ought to weigh in on, as it looks like it includes the vanity crypto discussion tarpit ;-). At a minimum, I would think that there ought to be some means of prohibiting registration of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13). Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Thursday, April 25, 2013 12:47 PM To: Black, David Cc: Russ Housley; tim.p...@nist.gov; zhangdach...@huawei.com; gen- a...@ietf.org; k...@ietf.org; ietf@ietf.org; stbry...@cisco.com Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07 Here are some quick initial responses to your comments. Thanks much for the review and I'll follow up with more detail in a while. Black, == Black, David david.bl...@emc.com writes: Black, Major issues: Black, (Section 2) Black, [1] LocalKeyName and PeerKeyName are strings. What Black, character set? If Unicode (e.g., UTF-8?), add text on Black, Unicode considerations (e.g., normalization). Finding a Black, Unicode expert will help in getting this done quickly. I Black, have similar concerns for other strings, and in particular, Black, IANA should be told what a string is for any registry Black, field that contains one. They are strings that can be compared using binary comparison. I agree we need to state that in the draft. Character set, to the extent it is specified will be specified by the individual protocol. In practice the protocol will say that it's an integer represented as an ASCII string. We needed to add the entire complexity of making these fields be strings not integers because of some non-IETF protocols that use key names. I'm reasonably confident I can sell Pete on the concept of a binary identifier for this field from an i18n standpoint. But issues, of length, format, etc are all specified by the protocol spec. Black, [2] I'm not sure that I understand what a KDF really is from Black, its high level description in this draft. At
RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Robert, Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy: (1) OLD: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). NEW: The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. (2) OLD: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. NEW: Furthermore, means to recover state in failure events (e.g., [RFC5460]) must be supported, but are not discussed in this document. Is this better? Cheers, Med -Message d'origine- De : Bernie Volz (volz) [mailto:v...@cisco.com] Envoyé : samedi 27 avril 2013 06:24 À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 Robert: The reason to allow this is that otherwise client A will be unnecessarily reconfigured many times. (It is also possible that a client might Renew on its own just as this is happening and thus it can also be removed from the Reconfigure.) I think the text should be cleaned up to indicate that allowing removal of already reconfigured clients is recommended (to prevent unnecessary reconfigures) when retransmitting the Reconfigure-Request. Note that if clients are added, that is not a retransmission but requires a new message (new XID). - Bernie -Original Message- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Friday, April 26, 2013 12:19 PM To: mohamed.boucad...@orange.com Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaqhttp://wiki.tools .ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Med: This example does not apply for that text. Really? What text constrains how you change what's in the retransmission? In fact, the example should be the other way around. Perhaps, this can be made clearer if we change (e.g., update the Client Identifier list) to (e.g., remove a client from the Client Identifier list). If I understand you correctly, you need more than just changing a parenthetical e.g.. I think you're saying that you are constraining the message changes to be such that if anything earlier in the retransmission sequence succeeded, the request in the retransmission would also have succeeded. But why do you need that much complexity? Do you have it already with any other request? Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? Med: I'm not aware of
Re: IETF Diversity Question on Berlin Registration?
On 4/29/2013 2:15 AM, Stewart Bryant wrote: On 29/04/2013 06:57, Dave Crocker wrote: Exactly. Complicated processes, needing high quality data that gets complicated analysis, that we aren't well-enough trained to do well and aren't going to be doing. Dave Of all the social mixes you would anticipate the IETF to be in the likely to do it, likely to do it correctly quadrant. If by 'it', you mean statistical analysis of human behavior, no. I'd expect our group methodology to be exactly as poor at it as we are... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07
On Apr 25, 2013, at 2:49 PM, Black, David david.bl...@emc.com wrote: I have no problem with the field being a binary identifier, but I think implementers should be put on notice that binary comparison of human input Unicode strings doesn't work as expected unless some things are done to make it work (this used to be known as string preparation). +1.
RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
FYI - Stable storage or some kind of redundancy solution may be another way to recover state. So, I don't think there is a hard requirement for RFC 5460. I don't think there is a strong reason to avoid e.g., it is for example so it is only one of many possible. And such as is basically saying the same thing. --- But then we come to why this is even important ... The original text was: This setup assumes the relay has a record of the client, so that it has enough information to send the Reconfigure-Request message to the server. How the state is recorded in the relay is out of scope. Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. I'm a bit skeptical why this draft even brings the 'recover state' up. Yes, the relay does need to record the client in order to initiate a Reconfigure-Request. But I think the sentence Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. is not needed. Sure, if the relay has no way of recovering this state, traffic to/from clients will likely not work and certainly if the relay is reconfigured, it will be unable to generate a Reconfigure-Request. But I don't really see this draft needing this requirement. Reconfigure-request could still work until the state is lost. And if the state is lost, there is a lot more than is potentially broken. But I don't really see this as a big issue and the must is the lower-case variant anyway. - Bernie -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] Sent: Monday, April 29, 2013 9:45 AM To: mohamed.boucad...@orange.com Cc: Bernie Volz (volz); dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 On 4/29/13 12:59 AM, mohamed.boucad...@orange.com wrote: Robert, Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy: (1) OLD: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). NEW: The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. (2) OLD: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. NEW: Furthermore, means to recover state in failure events (e.g., [RFC5460]) must be supported, but are not discussed in this document. Is this better? 1 is better. 2 is an improvement, I might say such as instead of e.g. to even more strongly avoid someone thinking you are _requiring_ implementation of RFC5460. Even then, it's still not clear whether you're trying to say Something that doesn't do this is does not conform to this specification or Something that doesn't do this isn't as good a tool as it can be and may create a condition that operators and users will not like much. You chose not to use MUST in that sentence. Can you make it less likely that someone will assume you meant to? Cheers, Med -Message d'origine- De : Bernie Volz (volz) [mailto:v...@cisco.com] Envoyé : samedi 27 avril 2013 06:24 À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 Robert: The reason to allow this is that otherwise client A will be unnecessarily reconfigured many times. (It is also possible that a client might Renew on its own just as this is happening and thus it can also be removed from the Reconfigure.) I think the text should be cleaned up to indicate that allowing removal of already reconfigured clients is recommended (to prevent unnecessary reconfigures) when retransmitting the Reconfigure-Request. Note that if clients are added, that is not a retransmission but requires a new message (new XID). - Bernie -Original Message- From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Friday, April 26, 2013 12:19 PM To: mohamed.boucad...@orange.com Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- reconfigure-05 On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42
Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
On Apr 29, 2013, at 10:18 AM, Bernie Volz (volz) v...@cisco.com wrote: But I don't really see this as a big issue and the must is the lower-case variant anyway. There's a big debate about whether this makes any difference. It's generally thought to be better not to say must if you don't mean MUST. I think the idea of just saying e.g. is the right thing, and stable storage and bulk leasequery would be two really great examples to use.
Re: IETF Diversity Question on Berlin Registration?
--On Monday, April 29, 2013 09:55 +0100 Stewart Bryant stbry...@cisco.com wrote: The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. The evidence seems to be that human's are terrible at guessing statistics, and the only statistics that are reliable as those objectively gathered and subjected to rigorous statistical analysis. I mostly agree with this, but it means that attempts at statistical measurement of populations we can't really characterize are irrelevant. In particular, as soon as one talks about the diversity of _the IETF_, one is talking about the participant population. There is no evidence at all, and some evidences to the contrary, that the attendee population is a good surrogate (approximation to a random sample, if you prefer) for the participant population. Making that assumption by polling or measuring the attendee function and assuming it is representative of the IETF may introduce far more biases than most of what we are talking about. You can often see this in human assessments of risk. It is also in the nature of statistics that you get long runs of outliers, and that only when you take a long view to you see the averages you would expect. Again Humans are terrible with this, assuming for example that a coin that comes up heads 10 times in a row the assumption is that this is bias, and not a normal statistical variation that you would expect in an infinite number of throws. On the other hand, as a loyal empirical Bayesian, I suggest that, if I observe a run of 10 heads and, as a result, bet on the next toss being heads, I am somewhat more likely to carry home my winnings at the end of the day that you are if you continue to bet on a 50-50 chance no matter how long the run gets... _even_ if the rules are normal statistical variation. Now, after an infinite number of coin tosses occur, you may be proven correct, but part of the reason for that Bayesian judgment (or a judgment based on moving average properties of the time series) is that few of us are going to be able to wait for that infinite number of tosses. It would be useful to the discussion if we could see data on diversity that was the output of a rigorous statistical analysis. i.e. one that included a confidence analysis and not a simple average in a few spot years. I agree. But I also suggest that humans are pretty good at binary comparisons and some longitudinal relationships that do not involve population samples. For example, with no effort to compare the population statistics of the IESG with the population statistics of the IETF (the precise comparison that is most susceptible to the statistical problems both of us are concerned about), it is easy to look at IESG membership longitudinally and observe that, between the early 1990s and 2010, there were always at least one, and often two or three, women on the IESG. Since then, zero.Now, based on around 17 years of moving average, I feel somewhat justified statistically in believing that something odd is happening. I would feel much more justified if we went a couple years more with no change in our procedures and how we think about things and the zero women trend continued, but that illustrates the other problems with this sort of analysis and an attempt to base it on population statistics, especially the population statistics of experimental design. First, our having these discussions have, I believe, already increased sensitivities to the issues and maybe even how the community thinks about it. If we end up with a woman or three on the IESG a year from now, it will basically be impossible to know whether that was -- simply a return to normal behavior after a period of deviation that could be attributed to statistical variation or -- whether it was because this discussion was effectively a consciousness-raising exercise that changed how decisions are made. The second issue is that, as in a clinical trial in which it becomes obvious (with all of those subjective human judgments as well as strict statistical ones) that one of the treatment groups is doing much better than others, it may be socially and morally unacceptable to continue the experiment in order to get cleaner statistical results. --On Monday, April 29, 2013 06:14 + Christian Huitema huit...@microsoft.com wrote: Certainly useful, but it is easy to inject one's own bias into such processes, and to overlook other factors. I may be biased, but I have the impression that the largest source of bias in IESG selection is the need to secure funding for the job, which effectively self-select people working for large companies making networking products. Or at least large companies and mostly those with a significant stake in the Internet. I agree with this impression. In principle, we could separate gender (or other) bias
Re: IETF Diversity Question on Berlin Registration?
On 4/29/2013 9:38 AM, John C Klensin wrote: First, our having these discussions have, I believe, already increased sensitivities to the issues and maybe even how the community thinks about it. Actually, it probably hasn't. It has raised awareness that there are people who are sensitive to the topic. It probably has raised some people's awareness that there are serious issues here and that the IETF ought to pay attention to them (better). I seriously doubt it has afforded many folk a sense of how to behave differently, and how to evaluate community and management choices in terms of diversity concerns. Let's not confuse activity with progress. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IETF Diversity Question on Berlin Registration?
On 4/29/13 1:11 AM, Stewart Bryant wrote: The other thing to remember is that whilst your proportional estimates are likely to be correct, in a random process you will get long runs of bias that only average out in the long run. Right, although if normal statistical fluctuation gives us a long period of woman-free leadership, somewhere in your long run we might expect the same statistical fluctuation to deliver unto us a stretch in which women are overrepresented in the leadership. Melinda
Re: [IAB] Call for Comment: 'Privacy Considerations for Internet Protocols'
Hi Dave, Thanks for your response. We discussed it within the privacy program and the full IAB. I've added the following sentence to the end of the intro in section 3 in the pre-publication -09 version: Examples of several different brief definitions are provided in RFC 4949. I realize this may not fully assuage your concerns, but we thought it might help to point out the brief(er) definitions in 4949. Notably, even that document gives three different definitions of privacy and none of them are a single sentence long, reflecting the difficulty of trying to boil down the multiple facets of the concept. To your point about privacy versus security, I'm not sure there is more we can say beyond what is in sections 4 and 7. Thanks for your thorough review. Although we have a few differences of opinion, I'm glad that you seem to think the document has value. Best, Alissa On Apr 17, 2013, at 8:15 PM, Dave Crocker dcroc...@bbiw.net wrote: Alissa, On 4/17/2013 10:23 AM, Alissa Cooper wrote: Hi Dave, Just wanted to make sure you saw this. I plan to submit the document to the IAB for publication approval next week. hmmm. I did see it, but now I can't find your original response, which is probably why I didn't followup. So thanks for the re-probe. I've left a few snippets from your reply at the end, as basic context, but I'll just comment in summary, rather than in-line. The summary of the summary is pretty simple: I do understand the history, complexities and even controversy that make it difficult to document specific choices, such as defining privacy. But I submit that due diligence for a document like this obligates the IAB to take some basic, solid positions, in the service of making its guidance useful. 1. Audience We often wind up writing documents that work best for people who are already relatively familiar with a topic. As you know better than most, writing for those new to a topic is a significantly different task. I certainly agree that it's challenging but I see it as the essence of this draft. That is, I believe you intend this document primarily for those who are less familiar with discussion and practice of privacy considerations. But this must begin with an understanding that they don't really have a reliable, workable definition of the term. There are many different definitions and you note that even on the IAB, for this draft, it has been challenging to settle on a definition. I'll submit that that should alert you to the increased need for this document to offer a single, useful definition, rather than to cause you to shy away from it. 2. Definition. The alternative that you've left the reader with is to have a basic lack of comfort with the topic and a certainty of inconsistent definition. All the good guidance later in the document will depend upon an inconsistent sense of when to apply it. In addition, the directive that they derive their version of the definition from the detail later in the document is -- forgive me -- simply unreasonable extra work. It's the sort of thing done for an academic texbook, not a guidance document. This draft is an operational tutorial, as well as a set of guidelines. Tutoring for application starts with explaining terms and privacy is the most essential term to define. The exemplar definition I provided should be modified to cover 'organization' data as well as personal, but I think it's viable as a working form. That said, I don't care whether you use it, as long as the document provides a meaningful definition that gives the /average/, uninformed reader a pragmatic sense of what is inside the scope of privacy and what is outside. 3. Privacy vs. Security The fact that the two topics overlap or that one can be viewed as a subset of the other or that... The fact that there is so much confusion here again requires that the document give concrete guidance that distinguishes what is security, as we use it for RFCs, and what is privacy, as you intend to scope it for this draft and for future Privacy Considerations work. My own view is that Security is largely a technical and mechanical topic, while Privacy is primarily a human and social topic. Within the IETF, we deal with security issues primarily in terms of algorithms and component technology. I believe you intend Privacy to take a larger view and think that's entirely appropriate, but also quite different. That privacy often plays heavily on the techniques of security does present challenges. But, for example, I think that 'confidentiality' is not 'privacy'. I'll state it differently: If the IAB cannot agree on a meaningful and simple statement that distinguishes between privacy and confidentiality, then it ought to reconsider giving expert advice about the handling of privacy considerations. To repeat: In practice within the IETF, confidentiality
Re: IETF Diversity Question on Berlin Registration?
--On Monday, April 29, 2013 09:46 -0700 Dave Crocker d...@dcrocker.net wrote: On 4/29/2013 9:38 AM, John C Klensin wrote: First, our having these discussions have, I believe, already increased sensitivities to the issues and maybe even how the community thinks about it. Actually, it probably hasn't. It has raised awareness that there are people who are sensitive to the topic. It probably has raised some people's awareness that there are serious issues here and that the IETF ought to pay attention to them (better). I seriously doubt it has afforded many folk a sense of how to behave differently, and how to evaluate community and management choices in terms of diversity concerns. I am trying (temporarily) to be more optimistic than that, but I fear that you may be correct. If so, we may be in big trouble and/or wasting our time by even having this discussion. If raising awareness and sensitivity isn't enough to get people to think about and make decisions differently and the only criteria the community will accept for either the existence of a problem or evidence that progress is being made is hard, frequency-based, statistical (or statistical analyses of experimental) data then, -- we can quibble endlessly about what should be measured and what the measurements mean and probably will, and -- we will never agree on quantitative criteria for progress or adequate diversity because such criteria will have the odor of preferential treatment and quotas (whether they are or not). And that applies not just to selections by the Nomcom but to all of the selections that are affected by the select people whom you know and know can do the job behavior that has been discussed at length in another thread. Let's not confuse activity with progress. Indeed. Let's also try to avoid defining progress in a way that makes even useful activity impossible. But, again, I fear you are correct about all of this. john
RE: IETF Diversity Question on Berlin Registration?
What a concept. Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore Sent: Monday, April 29, 2013 9:52 AM To: ietf@ietf.org Subject: Re: IETF Diversity Question on Berlin Registration? On 4/29/13 1:11 AM, Stewart Bryant wrote: The other thing to remember is that whilst your proportional estimates are likely to be correct, in a random process you will get long runs of bias that only average out in the long run. Right, although if normal statistical fluctuation gives us a long period of woman-free leadership, somewhere in your long run we might expect the same statistical fluctuation to deliver unto us a stretch in which women are overrepresented in the leadership. Melinda
Re: IETF Diversity Question on Berlin Registration?
On Apr 29, 2013, at 1:08 PM, John C Klensin john-i...@jck.com wrote: If raising awareness and sensitivity isn't enough to get people to think about and make decisions differently Statistical analysis shows that even when peoples' awareness is raised, biases continue to exist, not because the people are bad people, but because cognitive biases are simply not affected by consciousness raising alone. So IMHO at least, what we are looking for here is not consciousness-raising, but some method of determining if we are indeed suffering from cognitive biases here, and if so, some method for actually addressing the problem.
Re: IETF Diversity Question on Berlin Registration?
Did anyone notice the NPR piece this AM? http://www.npr.org/blogs/alltechconsidered/2013/04/29/178810467/blazing-the-trail-for-female-programmers Perhaps it's time for an IETF equivalent/chapter of http://railsbridge.org/, http://blackfounders.com/, http://wisecampaign.org.uk/, etc. ... Lou On 4/29/2013 12:46 PM, Dave Crocker wrote: Let's not confuse activity with progress.
Re: IETF Diversity Question on Berlin Registration?
At 01:38 PM 4/29/2013, Ted Lemon wrote: On Apr 29, 2013, at 1:08 PM, John C Klensin john-i...@jck.com wrote: If raising awareness and sensitivity isn't enough to get people to think about and make decisions differently Statistical analysis shows that even when peoples' awareness is raised, biases continue to exist, not because the people are bad people, but because cognitive biases are simply not affected by consciousness raising alone. So IMHO at least, what we are looking for here is not consciousness-raising, but some method of determining if we are indeed suffering from cognitive biases here, and if so, some method for actually addressing the problem. Yup. The problem here is that the sample set of leadership positions is so small its difficult to get any reasonable measure one way or the other. When you start mixing and matching gender, race, citizenship etc into the pot as possible determiners it just gets worse. The normal measure for determining whether one population is distinct from another appears to be the Chi Squared test. Throwing in a matrix of WG Chairs IAB/IESG Members Male 187 25 Female15 1 And running the calculation (http://www.quantpsy.org/chisq/chisq.htm) using the Yates' values (because the sample size is so small), there is a 79.13% chance that any observed differences in the composition of the two groups is solely due to statistical variations. And playing off of John's message, if you look around 2005 when there were 4 female members of the IAB and IESG (and assuming the same composition of WG chairs), that calculation yields something 31.4% - or 2 chances in 3 that the differences were due to something other than statistical variations. When I look at this as a pure numbers problem, I'm unable to say there is a cognitive bias in the selection process and in fact the numbers would argue against being able to say that without a much larger set of IAB/IESG members. Mike
Re: IETF Diversity Question on Berlin Registration?
At 01:34 AM 4/29/2013, Dave Crocker wrote: On 4/28/2013 9:05 PM, Michael StJohns wrote: Let's consider for a moment that this may not actually be the correct question. Instead, consider Why the diversity of the IETF leadership doesn't reflect the diversity of the set of the IETF WG chairs? I believe this is a more representative candidate population for the IAB and IESG. Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. A couple of points: Actually, I don't think this is even a mostly correct statement - that AD select chairs. I believe that most chairs are self-selected [e.g. hey AD, I want to run a BOF on this topic with the idea of forming a working group - here's the other person who might chair, what do you think? Sure - go ahead, we may twiddle with things a bit at charter formation, but you look like you know what you're doing]. With one exception (where I was asked to chair an evaluation panel), that's been my experience. Would you have evidence to the contrary? Second point: You ignored most of the post and went directly to my last question - 'If there is no statistical difference between the IAB/IESG and the WG chair set, should we then consider the relationship between the IETF attending constituency and the WG chair set?Say the average meeting had 1500 attendees. 7.4% would suggest that there are 111 female attendees. If the actual number is higher or lower it MAY represent a statistically significant difference in the composition of the two groups. Or it may not. And even then, may only have a very indirect impact in the composition of the IAB/IESG. Care to do the analysis? Later, Mike d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IETF Diversity Question on Berlin Registration?
At 01:57 AM 4/29/2013, Dave Crocker wrote: including such things as interaction (in)sensitivities, group tone and style, and observable misbehaviors, all of which are likely to produce biasing results. But in which direction? The same thing could be said of pushing personal or cultural biases into the interpretation of group tone, style, and taking offense at behaviors which one culture might construe as offensive but for 50 other cultures is just the way things work. We have an IETF culture - like it or not. It changes over time, as the population changes. We can't and shouldn't expect to be able to change it by fiat, or to adopt as whole cloth a bias free culture (for some values of bias). Mike
Re: IETF Diversity Question on Berlin Registration?
At 12:51 PM 4/29/2013, Melinda Shore wrote: On 4/29/13 1:11 AM, Stewart Bryant wrote: The other thing to remember is that whilst your proportional estimates are likely to be correct, in a random process you will get long runs of bias that only average out in the long run. Right, although if normal statistical fluctuation gives us a long period of woman-free leadership, somewhere in your long run we might expect the same statistical fluctuation to deliver unto us a stretch in which women are overrepresented in the leadership. Hi Melinda - Actually, look at the time frame around 2004-5. Multiple women on the IAB and multiple women on the IESG. Almost double the expected value of 2 given the WG proportions. One of the things I saw, but didn't comment on elsewhere, was that I had noted that a number of the women who had participated as IESG or IAB members have since stopped participating (attending actually) IETF meetings. I didn't comment on it because I didn't have a good feel for whether that proportion was higher or lower than the men who have been IESG/IAB members and are now not participating. Analysis of this might yield some data on whether or not we're losing long term female participants at a higher rate than long term male participants - if so, it may be worthwhile to ask former members the why question to see if there's anything we can do to mitigate. Long term participants appear (my opinion) to be more attractive candidates for IAB/IESG positions. Mike Melinda
Re: IETF Diversity Question on Berlin Registration?
Hi Mike, On Apr 29, 2013, at 3:15 PM, Michael StJohns mstjo...@comcast.net wrote: We have an IETF culture - like it or not. It changes over time, as the population changes. We can't and shouldn't expect to be able to change it by fiat, or to adopt as whole cloth a bias free culture (for some values of bias). How you do you think a culture evolves to be more inclusive? Might that start with discussions like these? Margaret
Re: IETF Diversity Question on Berlin Registration?
For what it's worth, I'm not finding the current discussion is providing me useful information for making decisions. It doesn't really matter to me whether the problem is selection of WG chairs or selection of IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to attempt to improve both situations in parallel, and the sorts of conclusions being drawn from the statistical discussion we're currently having cannot possibly change my opinion on that issue. I'm not saying that my mind is closed to being changed; simply that I've considered all the possible conclusions that I think could be drawn from the analysis being considered and from my standpoint they don't affect how I'd feel about various proposals that could be brought forward. Which I guess speaks to John's point that I at least am a member of the community who doesn't think the hard statistical analysis is useful here.
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 20:39, Sam Hartman wrote: For what it's worth, I'm not finding the current discussion is providing me useful information for making decisions. It doesn't really matter to me whether the problem is selection of WG chairs or selection of IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to attempt to improve both situations in parallel, and the sorts of conclusions being drawn from the statistical discussion we're currently having cannot possibly change my opinion on that issue. I'm not saying that my mind is closed to being changed; simply that I've considered all the possible conclusions that I think could be drawn from the analysis being considered and from my standpoint they don't affect how I'd feel about various proposals that could be brought forward. Which I guess speaks to John's point that I at least am a member of the community who doesn't think the hard statistical analysis is useful here. Sam, Why would you disregard a statistical analysis? That seems akin to disregarding the fundamentals of science and engineering. Stewart
How does the IETF evolve to continue to be an effective, efficient, and relevant source of high quality Internet standards? Was: Re: IETF Diversity Question on Berlin Registration?
At 03:30 PM 4/29/2013, Margaret Wasserman wrote: Hi Mike, On Apr 29, 2013, at 3:15 PM, Michael StJohns mstjo...@comcast.net wrote: We have an IETF culture - like it or not. It changes over time, as the population changes. We can't and shouldn't expect to be able to change it by fiat, or to adopt as whole cloth a bias free culture (for some values of bias). How you do you think a culture evolves to be more inclusive? Might that start with discussions like these? I believe your statement implies some preconceptions - that you believe the IETF culture is not inclusive enough and that more inclusiveness will benefit the IETF. I'm not sure there's evidence to support the first - hence the numerical analysis. It may be the case that we're not inclusive enough is a correct evaluation, but see Stewart's note on the human tendency to impute patterns into random results. I would ask this instead - How does the IETF evolve to continue to be an effective, efficient, and relevant source of high quality Internet standards? If one of the answers to that question necessarily involves inclusiveness, then the conversation should go forward on that topic, but preferably not in isolation, not as the fix this now knee jerk (my perception) type of activity that seems to be going on. Let me ask a couple of specific questions of you. Who have you mentored in the past 5 years? Have they ended up as working group chairs, or ADs or IAB members? Do they mostly represent under-represented groups? How many of them were employed by your employer (e.g. was this a work related task?)? During your time as an AD, how many women did you arm twist/recruit specifically (or ask nicely) to take WG positions in your area (as opposed to them coming to you or your co-AD)? How many non-employee, under-represented population attendees is your current employer supporting to go to the IETF? Have you addressed this with your employer? Why is the inclusiveness question more of an IETF question, as opposed to one of personal actions? I'm asking the above, because I'm trying to get a calibration on what you mean by inclusiveness and how important it actually is for you, and possibly for your employer. Mike Margaret
Re: IETF Diversity Question on Berlin Registration?
On 4/29/2013 12:04 PM, Michael StJohns wrote: At 01:34 AM 4/29/2013, Dave Crocker wrote: Actually, I don't think this is even a mostly correct statement - that AD select chairs. It is a long-standing, simple, objective, unvarying management fact of IETF procedure: ADs hire and fire wg chairs. Second point: You ignored most of the post and went directly to my last question I went to the meta-point that the line of discussion isn't methodologically meaningful or educationally useful. Possibly you noticed one or two additional postings in this sub-thread asserting the same thing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IETF Diversity Question on Berlin Registration?
On Mon, April 29, 2013 12:39 pm, Sam Hartman wrote: For what it's worth, I'm not finding the current discussion is providing me useful information for making decisions. It doesn't really matter to me whether the problem is selection of WG chairs or selection of IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to attempt to improve both situations in parallel, and the sorts of conclusions being drawn from the statistical discussion we're currently having cannot possibly change my opinion on that issue. I'm not saying that my mind is closed to being changed; simply that I've considered all the possible conclusions that I think could be drawn from the analysis being considered and from my standpoint they don't affect how I'd feel about various proposals that could be brought forward. Sounds to me like you have the cart in front of the horse. You already have in mind various proposals (interestingly left unstated) and are looking for data that can justify them being brought forward. Apparently, this data does not help you justify these proposals so you find no use discussing in it. Maybe we should let the data drive the proposals instead of the other way around. Dan.
Re: IETF Diversity Question on Berlin Registration?
Stewart == Stewart Bryant stbry...@cisco.com writes: Stewart Why would you disregard a statistical analysis? That seems Stewart akin to disregarding the fundamentals of science and Statistical analysis is only useful if it's going to tell you something that matters for your decision criteria. Let's take Mike's most recent messages here. It doesn't actually matter to me whether the problem in gender diversity is at the nomcom level or at the wg chair selection level. So, a statistical discussion of whether there's bias in nomcom choosing leaders from the wg chairs does not provide input that matters in my decision criteria, so I disregard that particular analysis. I certainly did not mean to imply that I disregard statistics, or even disregard statistics in diversity discussions. Simply, I don't find the statistical discussion here pointful, and I think it's a sufficient distraction that I felt a need to speak out about it.
Re: IETF Diversity Question on Berlin Registration?
On 2013-04-29, at 16:49, Sam Hartman hartmans-i...@mit.edu wrote: Stewart == Stewart Bryant stbry...@cisco.com writes: Stewart Why would you disregard a statistical analysis? That seems Stewart akin to disregarding the fundamentals of science and Statistical analysis is only useful if it's going to tell you something that matters for your decision criteria. http://i.imgur.com/47D7zGq.png Joe
Re: [IETF] Re: IETF Diversity Question on Berlin Registration?
On Apr 29, 2013, at 4:55 PM, Joe Abley jab...@hopcount.ca wrote: On 2013-04-29, at 16:49, Sam Hartman hartmans-i...@mit.edu wrote: Stewart == Stewart Bryant stbry...@cisco.com writes: Stewart Why would you disregard a statistical analysis? That seems Stewart akin to disregarding the fundamentals of science and Statistical analysis is only useful if it's going to tell you something that matters for your decision criteria. http://i.imgur.com/47D7zGq.png Wow, that *was* useful, and has helped reinforce my belief that I chose the right browser -- Think of the children, don't use IE. Couldn't resist: http://xkcd.com/552/ W Joe -- There were such things as dwarf gods. Dwarfs were not a naturally religious species, but in a world where pit props could crack without warning and pockets of fire damp could suddenly explode they'd seen the need for gods as the sort of supernatural equivalent of a hard hat. Besides, when you hit your thumb with an eight-pound hammer it's nice to be able to blaspheme. It takes a very special and straong-minded kind of atheist to jump up and down with their hand clasped under their other armpit and shout, Oh, random-fluctuations-in-the-space-time-continuum! or Aaargh, primitive-and-outmoded-concept on a crutch! -- Terry Pratchett
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
If anyone wishes to see one aspect of what is wrong with IETF Diversity, then see whats going on in SPF BIS WG where a key IETF cog essentially attempts to shutdown discussions and communications, attacks posters which by my estimate were making progress. Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in SPFBIS. Many in DNS community do not agree with the change of removing a long term migration path to a SPF RRTYPE. In fact, not changing the existing specification would end the issue and hopefully satisfy all principles. -- HLS On 4/29/2013 5:03 PM, Dave Crocker wrote: Folks, This is one of those threads that will go on for as long as people seem to think they need to keep posting, but it won't make any progress or resolve any issues. For that matter, I have no idea what anyone thinks they are accomplishing by continuing to post on it, which raises the question of why they keep bothering. And 'bothering' is what this thread mostly /is/ doing, in reducing the S/N ratio. Please shut the thread down. d/
Re: IETF Diversity Question on Berlin Registration?
On 4/29/2013 2:20 PM, Michael StJohns wrote: At 04:40 PM 4/29/2013, Dave Crocker wrote: Actually, I don't think this is even a mostly correct statement - that AD select chairs. It is a long-standing, simple, objective, unvarying management fact of IETF procedure: ADs hire and fire wg chairs. The AD's do have the final say. No question. But select implies that the own the entire process of creating and staffing a WG. Nope. They do own it; that's a formal truth. That they often delegate details and concur with self-organizing choices means nothing, in terms of their authority. Don't confuse efficiency hacks with formal authority. d/ ps. I'm sure this was really quite an important point to debate, relative to problems with IETF diversity and culture. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: W3C standards and the Hollyweb
From: m...@sap.com (Martin Rex) DRM system are evil in any way you look at it. Originally, copyright was a conceived as a temporary (50yrs) monopoly. The protection period has in recent years been prolonged in many years to at least 70 years. [...] I read an analysis somewhere that pointed out that DRM is evil in considerably different ways than one naively thinks. You tend to think of DRM as a way of enforcing copyright. But the real power of DRM is in effectively eliminating the right of first sale. Currently, once you've bought a copy of a copyrighted work, you have bought a physical object, the copy, and that ownership gives you a bundle containing a considerable number of rights, including the right to sell the copy to someone else. The real economic purpose of DRM is to be able to subdivide the bundle of rights traditionally associated with the copy so that they can be sold and priced individually. Even better, since the copy may no longer be transferrable between customers, different customers can be charged different prices for the same thing. The net effect is that the work creators can get larger aggregate sales for the creation than before. Which may or may not be a good thing. Wikipedia has a long article, Price discrimination, on this. Dale
Re: IETF Diversity Question on Berlin Registration?
On Mon, April 29, 2013 2:28 pm, Dave Crocker wrote: On 4/29/2013 2:20 PM, Michael StJohns wrote: At 04:40 PM 4/29/2013, Dave Crocker wrote: Actually, I don't think this is even a mostly correct statement - that AD select chairs. It is a long-standing, simple, objective, unvarying management fact of IETF procedure: ADs hire and fire wg chairs. The AD's do have the final say. No question. But select implies that the own the entire process of creating and staffing a WG. Nope. They do own it; that's a formal truth. That they often delegate details and concur with self-organizing choices means nothing, in terms of their authority. But it might mean something in terms of the discussion at hand. If the ADs are concurring with self-organizing choices as opposed to selecting WG chairs, then they aren't really imposing a looks like me bias into the selection process. Dan.
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
The really annoying thing is that SPF is techically superior to TXT is lots of ways. 1. It uniquely identifies the roll of the record. 2. As SPF records are singletons you don't need to identify and remove the old record when updating. You can just remove all SPF record and add the replacement. For TXT you need to lookup the existing RRset, extract the v=spf1 record from it. You then need to create a UPDATE message to delete just that record as well as add the new TXT record. You then have to hope that no one else is performing a simultanious update as you may get two TXT v=spf1 records in the RRset. The complains about using SPF is that there are broken firewalls and some servers drop queries for it, some registars don't support it. For firewalls, fix/replace the firewall if you intend to deploy SPF and it doesn't support it. It is total !@##@# that firewall are incapable of handling new DNS record types. New records we exected to occur from the very beginning and have been coming out regularly ever since the DNS was invented. Firewall vendors that are incapable of handling new DNS types are incompetent and do not deserve repeat business. For servers than drop SPF queries they really are at the noise level. When you identify one you complain to the owners of it. Yes, that does work. We needed to do that for records. For registrars, change registrar to one that does. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Do we have an estimated date for completing the IESG selection process for this year?
So, this page: http://www.ietf.org/iesg/members.html still has TBD listed for one of the transport ADs. Is there a projected date for appointment at this point? Forgive the broad distribution of the question, but it's not clear whether this question is solely directed at the nomcom, the IESG, the IAB or the community at large. regards, Ted Hardie
Re: IETF Diversity Question on Berlin Registration?
Mike: Actually, I don't think this is even a mostly correct statement - that AD select chairs. Dave: It is a long-standing, simple, objective, unvarying management fact of IETF procedure: ADs hire and fire wg chairs. Mike: The AD's do have the final say. No question. But select implies that the own the entire process of creating and staffing a WG. Nope. Dave: They do own it; that's a formal truth. That they often delegate details and concur with self-organizing choices means nothing, in terms of their authority. Dan: But it might mean something in terms of the discussion at hand. If the ADs are concurring with self-organizing choices as opposed to selecting WG chairs, then they aren't really imposing a looks like me bias into the selection process. OK, here: I have to step in now. Let me look at the new working group chairs and BoF chairs in the App Area (as that's my area) since I've been an AD (one year, so far). Chair changes: APPSAWG: added Murray Kucherawy and Salvatore Loreto CORE: added Andrew McGregor IRI: added Peter Saint-Andre New working groups WEIRDS: Olaf Kolkman and Murray Kucherawy SCIM: Morteza Ansari and Leif Johansson SPFBIS: SM and Andrew Sullivan IMAPMOVE: Ned Freed and Alexey Melnikov JCARDCAL: Bert Greevenbosch and Peter Saint-Andre QRESYNC: Dave Cridland and Eliot Lear BoFs at IETF 83: SCIM: Eliot Lear and Steve Bellovin WEIRDS: Andrew Sullivan BoFs at IETF 84: DSII: Beth Pale and Ted Hardie BoFs at IETF 86: AGGSRV: Peter Saint-Andre JSON: Joe Hildebrand In all but one of these cases, we (the ADs) contacted people and *asked* them to chair. The exception was DSII and Beth Pale, but this was not a working-group-forming BoF (and Ted was the one we solicited). For the SCIM working group, Morteza was one of the proponents of the IETF 83 BoF, but he did not ask to be chair, and *I asked him* only after consulting with folks and getting opinions that suggested that he would be a good choice. That has generally been my approach and Pete's to finding chairs: getting opinions other than our own. We have a couple of other new chartering efforts in process, and we'll be handling those similarly: selecting people we think will be appropriate to chair those working groups. Of course, if someone comes to us and says that they'd like to chair a working group, we will take that into consideration. But we most certainly do NOT simply appoint people because they're technology proponents, nor because they ask us to. My sense of the rest of the IESG is that they behave similarly. I can tell you unequivocally that the ADs appoint the chairs, and own the entire process of [...] staffing a WG. We are not just taking the people who come to us and saying, Yeah, sure, you'll do. We also want to find new chairs -- in the working-group chairs list above, Andrew, Morteza, SM, Bert, and Dave are all first-time chairs. Pete and I are also actively looking to increase the diversity in App Area chairs -- perhaps you'll notice that we have *no* female chairs in the App Area, at least partly because we have no women who are active in the App Area just now. We're working on that (and on other diversity aspects) -- see, for example, the first item here: http://www.ietf.org/proceedings/85/slides/slides-85-apparea-0.pdf We're always eager for suggestions for people to be on our list of potential chairs; please send such to app-...@tools.ietf.org. And, yes, we *do* own the staffing process. Barry, Applications AD
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
Hi Hector, At 14:15 29-04-2013, Hector Santos wrote: If anyone wishes to see one aspect of what is wrong with IETF Diversity, then see whats going on in SPF BIS WG where a key IETF cog essentially attempts to shutdown discussions and communications, attacks posters which by my estimate were making progress. Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in SPFBIS. Many in DNS community do not agree with the change of removing a long term migration path to a SPF RRTYPE. In fact, not changing the existing specification would end the issue and hopefully satisfy all principles. The following messages were posted to the SPFBIS mailing list: http://www.ietf.org/mail-archive/web/spfbis/current/msg03593.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03598.html It has also been mentioned that there are two long threads at: http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html http://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html Regards, S. Moonesamy
Re: IETF Diversity Question on Berlin Registration?
On 30/04/2013 08:49, Sam Hartman wrote: ... Statistical analysis is only useful if it's going to tell you something that matters for your decision criteria. Yes. And I would like to know, in statistical terms, whether there are significant differences between (for example) the M/F ratios among (a) IETF registrants, (b) active participants, (c) WG chairs secretaries and (d) I* members. [Discussion on the objective definition of active participation is deferred for now.] The null hypothesis would be that no significant differences exist. If that turns out to be true, we know that our problem is only lack of diversity among registrants. If it turns out to be false, we know that we have an internal problem of some kind as well. Brian
Re: IETF Diversity Question on Berlin Registration?
Brian == Brian E Carpenter brian.e.carpen...@gmail.com writes: Brian The null hypothesis would be that no significant differences Brian exist. If that turns out to be true, we know that our Brian problem is only lack of diversity among registrants. If it Brian turns out to be false, we know that we have an internal Brian problem of some kind as well. Yes. I'll admit that that particular question--which is far more involved than the numbers I've seen thrown around to date--is somewhat interesting. Although while it influences how I'd think about deciding on proposals, there's no answer to that question that has a clear set of decisions for me, even ignoring questions about methodology, definitions of participants, etc, etc. 1) I may believe that increasing diversity among leadership so that the leadership is more diverse than the population as a whole will help increase diversity of the population. 2) I may believe that the diversity of the leadership is more of a problem in terms of either quality of spec or credibility of organization than diversity of the participants/registrants. But you've definitely started to get into a realm where the statistics are more interesting to me. And i'll drop this now, because I realize I'm only one participant and I discussion that doesn't provide helpful information for me may well provide useful information for others.
Re: User Culture or Management (was Re: IETF Diversity Question on Berlin Registration?)
retransmited (not received at IETF or published) On 4/29/13, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi Mike, (sorry for my long message, will try to improve) I like the concept and reasoning of your message, and would like to add, is there other reasons for the results and conclusion your message got to? Is there something we can fix in the ietf-culture or ietf-procedures to make the diversity more established? I think that female managers/leaders are important to any world-organisation to get successful, and to be specific, I will recommend all world NPOs (Non-Profit Org.) need gender diversity (male or female, which one may be minority) at *least* 10-20 percent of management teams. An NPO with all male or all female management is not successful for the world of diverse *gender* and *users*. Management skills if gender-diversed will reflect better community involvement, choices, culture, and decisions. IMHO, Organisation Management objectives are to make 1) *users* increase in numbers, 2) increase in diverse, and 3) increase in satisfaction. If only present/current users select the management there is no dought that their decisions reflect users-culture and awareness, but do they increase the three objectives. My concerns in the diversity issue is to focus on the diversity of *management-gender* and *ietf-users* to benefit future decisions and make *awareness* into the ietf-culture. Your message discussed both but for the diversity of ietf-users not in similar depth compared with gender, which I think you may help me understand/evaluate its diverse in ietf. Regards, AB ++ From: Michael StJohns mstjohns at comcast.net To: Margaret Wasserman mrw at lilacglade.org,t.p. daedulus at btconnect.com Cc: ietf at ietf.org Date: Mon, 29 Apr 2013 00:05:37 -0400 Let's consider for a moment that this may not actually be the correct question. Instead, consider Why the diversity of the IETF leadership doesn't reflect the diversity of the set of the IETF WG chairs? I believe this is a more representative candidate population for the IAB and IESG. By my count (using the WG chairs picture page), there are 202 current working group chairs. Of these 15 are female - or 7.4% of the population [It would be more reliable to do this for any WG chair in the last 5-10 years, but the above was readily available and I think provides at least the basis for discussion. Anticipating the argument, I would assume for the sake of discussion a fairly similar percentage of ex-working group chairs per gender unless there is evidence to the contrary] There are 14 (current area directors plus the chair) members of the IESG, of which none are currently female. There are 12 current IAB members of which 1 member is female. Assuming perfect distribution, that would suggest that 14 * (15/202) or 1.03 IESG members should be female. Assuming perfect distribution, that would suggest that 12 * (15/202) or .89 IAB members should be female. Assuming perfect distribution, that would suggest that 26 * (15/202) or 1.93 IAB + IESG members should be female. And pretending for a moment that picks for the IAB and IESG are completely random from the candidate set of Working group chairs, the binomial distribution for 7.4% for 27 positions is: 0 - 12.5%, 1 - 27.0%, 2 - 28.1%, 3 or more - 32.5%. (e.g. about 40% of the time, the IAB and IESG combined will have 0 or 1 female members). for 7.4% for 15 positions (IESG) is: 0 - 31.4%, 1 - 37.8%, 2 - 21.2%, 3 or more - 9.5% for 7.4% for 12 positions (IAB) is: 0 - 39.6%, 1 - 38.1%, 2 - 16.8%, 3 or more - 5.4% But the actual one you should consider is 7.4% for 14 positions (annual replacement): 0 - 34%, 1 - 38.1%, 2 - 19.9%, 3 or more - 8%. This last one says that for any given nomcom selection, assuming strict random selection, 72% of the time 0 or 1 females will be selected across both the IAB and IESG. You should use this one as the actual compositions of the IAB/IESG are the sum of all the nomcom actions that have happened before. There are statistical tests to determine whether there is a statistically significant difference in populations, but my admittedly ancient memories of statistics suggest that the population size of the IAB/IESG is too small for a statistically valid comparison with either the WG chair population or the IETF population. Of course, the nomcom doesn't select and the confirming bodies do not confirm based on a roll of the dice. But looking at this analysis, it's unclear - for this one axis of gender - that the question why the diversity of the IETF leadership does not reflect the diversity of the set of IETF WG chairs has a more correct answer than the luck of the draw. My base premise may be incorrect: That you need to have been a WG chair prior to service as an IAB or IESG member. I hope it isn't as I think this level of expertise
Last Call: draft-ietf-forces-interop-07.txt (Interoperability Report for Forwarding and Control Element Separation (ForCES)) to Informational RFC
The IESG has received a request from the Forwarding and Control Element Separation WG (forces) to consider the following document: - 'Interoperability Report for Forwarding and Control Element Separation (ForCES)' draft-ietf-forces-interop-07.txt as 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 i...@ietf.org mailing lists by 2013-05-13. 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 captures results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. RFC 6053 reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-forces-interop/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-forces-interop/ballot/ No IPR declarations have been submitted directly on this I-D.
WG Action: Formed IMAP QRESYNC Extension (qresync)
A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. IMAP QRESYNC Extension (qresync) Current Status: Proposed Working Group Chairs: Dave Cridland d...@cridland.net Eliot Lear l...@cisco.com Assigned Area Director: Barry Leiba barryle...@computer.org Mailing list Address: imap...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/imapext Archive: http://www.ietf.org/mail-archive/web/imapext/ Charter of Working Group: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for accessing email messages on a server that implements a message store from a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. Base IMAP as described in RFC 3501 requires that in order to discover flag changes and expunged messages in a mailbox, the client has to fetch flags for all messages it knows in the mailbox and compare returned results with its own state. This can generate a significant amount of traffic for big mailboxes. The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP clients to quickly resynchronize mailbox flag changes in a mailbox. The IMAP QRESYNC extension (RFC 5162) extends CONDSTORE to also cover expunged messages, and reduces the number of round trips needed to resynchronize by extending the SELECT/EXAMINE command. The CONDSTORE and QRESYNC extensions are deployed in both clients and servers. These deployments have exposed errors and clarity issues in the specifications, and they need correcting. The IMAP QRESYNC Extension working group has the task of updating CONDSTORE and QRESYNC extensions on the Standards Track. The working group might produce one (combined) or two separate documents (as now) updating these extensions. The working group will review errata and update the documents as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes at this stage to a minimum and avoid incompatible changes. No other IMAP extension work is in scope for this working group. Milestones: Dec 2013 - Request publication on updated qresync/condstore spec(s)
RFC 6909 on IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6
A new Request for Comments is now available in online RFC libraries. RFC 6909 Title: IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 Author: S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli Status: Standards Track Stream: IETF Date: April 2013 Mailbox:sgund...@cisco.com, zhou.xing...@zte.com.cn, jouni.nos...@gmail.com, gfe...@cisco.com, rkoo...@cisco.com Pages: 14 Characters: 34575 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netext-pmipv6-sipto-option-12.txt URL:http://www.rfc-editor.org/rfc/rfc6909.txt This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network. This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6911 on RADIUS Attributes for IPv6 Access Networks
A new Request for Comments is now available in online RFC libraries. RFC 6911 Title: RADIUS Attributes for IPv6 Access Networks Author: W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet Status: Standards Track Stream: IETF Date: April 2013 Mailbox:w...@cisco.com, sarik...@ieee.org, glenz...@gmail.com, davidmi...@google.com, blour...@juniper.net Pages: 15 Characters: 28123 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-radext-ipv6-access-16.txt URL:http://www.rfc-editor.org/rfc/rfc6911.txt This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6925 on The DHCPv4 Relay Agent Identifier Sub-Option
A new Request for Comments is now available in online RFC libraries. RFC 6925 Title: The DHCPv4 Relay Agent Identifier Sub-Option Author: B. Joshi, R. Desetti, M. Stapp Status: Standards Track Stream: IETF Date: April 2013 Mailbox:bharat_jo...@infosys.com, ramakrishna...@infosys.com, m...@cisco.com Pages: 8 Characters: 17664 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dhc-relay-id-suboption-13.txt URL:http://www.rfc-editor.org/rfc/rfc6925.txt This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6926 on DHCPv4 Bulk Leasequery
A new Request for Comments is now available in online RFC libraries. RFC 6926 Title: DHCPv4 Bulk Leasequery Author: K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz Status: Standards Track Stream: IETF Date: April 2013 Mailbox:kkinn...@cisco.com, m...@cisco.com, ramakrishna...@infosys.com, bharat_jo...@infosys.com, neil.e.russ...@gmail.com, kurap...@juniper.net, v...@cisco.com Pages: 41 Characters: 88215 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt URL:http://www.rfc-editor.org/rfc/rfc6926.txt The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6928 on Increasing TCP's Initial Window
A new Request for Comments is now available in online RFC libraries. RFC 6928 Title: Increasing TCP's Initial Window Author: J. Chu, N. Dukkipati, Y. Cheng, M. Mathis Status: Experimental Stream: IETF Date: April 2013 Mailbox:hk...@google.com, nandi...@google.com, ych...@google.com, mattmat...@google.com Pages: 24 Characters: 56523 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-initcwnd-08.txt URL:http://www.rfc-editor.org/rfc/rfc6928.txt This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'FCAST: Object Delivery for the ALC and NORM Protocols' to Experimental RFC (draft-ietf-rmt-fcast-08.txt)
The IESG has approved the following document: - 'FCAST: Object Delivery for the ALC and NORM Protocols' (draft-ietf-rmt-fcast-08.txt) as Experimental RFC This document is the product of the Reliable Multicast Transport Working Group. The IESG contact person is Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rmt-fcast/ Technical Summary This document specifies a set of data formats and instructions on how to use ALC (RFC 5775) and NORM (RFC 5740) to implement a file-casting service. In particular this document specifies an in-band method to advertise the content and duration of a file-casting session. It also specifies exactly how instantiate an ALC or NORM transport session for use within this context. Working Group Summary FCAST represents the consensus of the RMT WG participants. FCAST was initially proposed at the beginning of the RMT effort (circa 2001) and then superseded by a more comprehensive approach (FLUTE, draft-ietf-rmt-flute-revised-11). Due to late reported IPR claims on FLUTE, FCAST was re-added to the WG scope to offer an alternative to FLUTE. Document Quality There is no known implementation of FCAST in its current incarnation, however FCAST was implemented and widely reviewed in its first incarnation. The current specification, similar to the original one, also had substantial review from WG members. Personnel Lorenzo Vicisano (lore...@vicisano.net) is the document shepherd. Martin Stiemerling (martin.stiemerl...@neclab.eu) is the responsible AD.
RFC 6886 on NAT Port Mapping Protocol (NAT-PMP)
A new Request for Comments is now available in online RFC libraries. RFC 6886 Title: NAT Port Mapping Protocol (NAT-PMP) Author: S. Cheshire, M. Krochmal Status: Informational Stream: Independent Date: April 2013 Mailbox:chesh...@apple.com, m...@apple.com Pages: 33 Characters: 87897 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-cheshire-nat-pmp-07.txt URL:http://www.rfc-editor.org/rfc/rfc6886.txt This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC Port Control Protocol (PCP), which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6887 on Port Control Protocol (PCP)
A new Request for Comments is now available in online RFC libraries. RFC 6887 Title: Port Control Protocol (PCP) Author: D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk Status: Standards Track Stream: IETF Date: April 2013 Mailbox:dw...@cisco.com, chesh...@apple.com, mohamed.boucad...@orange.com, repe...@cisco.com, pselk...@isc.org Pages: 88 Characters: 221314 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pcp-base-29.txt URL:http://www.rfc-editor.org/rfc/rfc6887.txt The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. This document is a product of the Port Control Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
BCP 127, RFC 6888 on Common Requirements for Carrier-Grade NATs (CGNs)
A new Request for Comments is now available in online RFC libraries. BCP 127 RFC 6888 Title: Common Requirements for Carrier-Grade NATs (CGNs) Author: S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida Status: Best Current Practice Stream: IETF Date: April 2013 Mailbox:simon.perrea...@viagenie.ca, iku...@nttv6.jp, miyak...@nttv6.jp, a-nakag...@jpix.ad.jp, hiash...@cisco.com Pages: 15 Characters: 32484 Updates:RFC 4787 See Also: BCP 127 I-D Tag:draft-ietf-behave-lsn-requirements-10.txt URL:http://www.rfc-editor.org/rfc/rfc6888.txt This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 6889 on Analysis of Stateful 64 Translation
A new Request for Comments is now available in online RFC libraries. RFC 6889 Title: Analysis of Stateful 64 Translation Author: R. Penno, T. Saxena, M. Boucadair, S. Sivakumar Status: Informational Stream: IETF Date: April 2013 Mailbox:rpe...@juniper.net, tasax...@cisco.com, mohamed.boucad...@orange.com, ssent...@cisco.com Pages: 15 Characters: 33171 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-behave-64-analysis-07.txt URL:http://www.rfc-editor.org/rfc/rfc6889.txt Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
