Re: 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 13:15 29-04-2013, Michael StJohns wrote: Let me ask a couple of specific questions of you. I think that these are good questions. 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?)? I don't mentor IETF participants as I consider everyone who does not have a title as a peer. None of the peers I have interacted with ended up as working group chair, Area Director or IAB member. I have not given much thought about whether most of the peers I have interacted with represent under-represented groups. My guess is that it is a significant number. 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)? I do some things on behalf of the Applications Area directorate. At the last IETF meeting I asked four women whether they would like to do some reviews. There was one positive answer. There are people of different ages. There are people who work for a range of vendors on the directorate. There are a few people who work for universities. There are people who come from different parts of the world. The list of reviewers and the work they perform is published on an IETF web site [1]. If anyone has questions about under-represented groups in relation to the directorate please post a message to this mailing list and I will reply. Regards, S. Moonesamy 1. http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
Re: FW: Last Call: draft-ietf-netmod-interfaces-cfg-10.txt (A YANG Data Model for Interface Management) to Proposed Standard
Thanks Dave for your thorough review. You have some very valid points. I've not seen any replies from the author. Maybe he doesn't monitor this list. So, including some extra mailing lists. Martin, NETMOD WG, can you please address David's points. Note: there is also a reply from Tom Petch on this email. See http://www.ietf.org/mail-archive/web/ietf/current/msg78808.html Regards, Benoit Hi, I have reviewed this document and feel that is almost ready for approval. This document defines a new data model in YANG format, based on the same information model as the Interfaces MIB module (IF-MIB). Effectively, the YANG model is a second (duplicative) standard for much of the same information. It is expected that devices may implement both the MIB and the YANG data models. My primary concern regards co-existence and synchronization across data models. I think this document would benefit from an Operational Considerations section that discusses synchronization, or an explanation why they might reasonably be out-of-sync. Here are a few points to consider: 1) the ifIndex of an interface is used within the YANG model, matching the ifIndex in IF-MIB. RFC2863 discusses the fact that ifIndex numbering might change during hot-swaps. This document does not discuss the need to ensure that IF-MIB ifIndex changes need to be reflected in the YANG model. The ifIndex in the YANG module must match that in IF-MIB (really, that in the underlying instrumentation). Failure to sync the ifIndex could lead NM applications to confuse which already-retrieved data records are related to which interface. This could cause an NM application to misinterpret/corrupt gathered trending information, and possibly to apply changes to the wrong interfaces. 2) ifType - can an interface be hot-swapped to use a different type? Is this discussed someplace? 3) ifType - the description says the value of this mandatory object MAY be initialized. What value should an NM application expect if it is NOT initialized? 4) enabled - Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus ...; should this be a MAY/SHOULD/MUST? How will this coexist with SNMP-based NM applications? Is there potential for conflict? What if NETCONF sets this as enabled, then an operator sets it to disabled via SNMP? Does NETCONF know that its enable value (adminStatus) is out of date? (does it matter? See note 7). What if the NETCONF system directky changes the underlying instrumentation for adminstatus without going through the MIB? 5) is there a reason why description value MAY match IF-MIB ifAlias ***and MAY restrict the values***? Is there a particular use case for this lack of standardization of restrictions across data models? The persistence is a pretty important restriction related to the functionality of ifAlias, and the dynamism of ifIndex. If NETCONF is used to set the value, ignoring IF-MIB restrictions, what happens to IF-MIB ifAlias as a persistent handle to the interface? 6) What error is returned via NETCONF if YANG attempts to set a value that violates the SNMP agent implementation restrictions, and the SNMP agent refuses the requested SET operation to ifAlias? Is there a simple way for an operator to tell whether the implementation supports the restrictions (other than deliberately triggering an error)? 7) what should an NM application or operator do if the YANG oper-status and the IF-MIB operStatus differ? IF-MIB has substantial discussion of the relationship between ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable discussion. Given that there could e additional delay incurred between setting enable, updating ifAdminStatus, the change to ifOperStatus, and the update to oper-status, I recommend some mention in the description of enable and/or oper-status of the detailed description in RFC2863, and applicability to ietf-interfaces. 8) link-up-down-trap-enable: The text says this indicates whether traps should be generated for the interface; shouldn't this be configures? 9) persistence isn't discussed in the config object descriptions. Do they match the IF-MIB object persistences? 10) IF-MIB counters do not typically start at zero; a delta must be calculated. This is a common misunderstanding for new MIB developers and users. I don't see any comparable discussion related to ietf-interfaces counters. Where should one look for a discussion of YANG counter initialization values? Where should one look for a discussion of YANG counter rollover? It would help to have a discussion of how to utilize discontinuity_time and counters, especially for implementers not familiar with SNMP (and not implementing IF-MIB). 11) Is it expected that counters in ietf-interfaces and counters in IF-MIB are synchronized? Can an NM application reasonably compare two readings - one of in-octets and one of ifHCInOctets? If not, I think that should be made clear. (The reference clauses seem to link them) 12) From
Re: IETF Diversity Question on Berlin Registration?
I was counting femal ADs. I ment no female names in the AD list apears (in my understandning I mybe wrong because in my culture some families name their memebrs with names that we cannot notice gender). As I am a remote participant I am not aware and may never notice difference. But I can refer now for better than my count [1]. http://www.ietf.org/mail-archive/web/ietf/current/msg78882.html AB On 19 April 2013 at 12:22 Abdussalam Baryun abdussalambaryun at gmail.com wrote on this list: No name in the AD list appear so far, but if your the discuss-list is right then it may be good progress, hoping for more names for diversity. I count three ADs on the diversity discussion list at the moment. Why is my count different from yours? Adrian
Re: [netmod] Last Call: draft-ietf-netmod-interfaces-cfg-10.txt (A YANG Data Model for Interface Management) to Proposed Standard
Martin, It's interesting to note that Dave came up with similar feedback as I had during my AD review. And you had to re-explain this again, via email. This leads me to think that we need some more background information, typically in Operational Considerations section. http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 could be part of that new section, but other topics could/should be addressed: - Failure to sync the ifIndex - is there a reason why description value MAY match IF-MIB ifAlias ***and MAY restrict the values***? - what should an NM application or operator do if the YANG oper-status and the IF-MIB operStatus differ? - persistence - Is it expected that counters in ietf-interfaces and counters in IF-MIB are synchronized? - etc... Basically addressing many points made by Dave Regards, Benoit Hi David, Thank you for your detailed review! Comments inline. David Harrington ietf...@comcast.net wrote: Hi, I have reviewed this document and feel that is almost ready for approval. This document defines a new data model in YANG format, based on the same information model as the Interfaces MIB module (IF-MIB). Effectively, the YANG model is a second (duplicative) standard for much of the same information. It is expected that devices may implement both the MIB and the YANG data models. My primary concern regards co-existence and synchronization across data models. I think this document would benefit from an Operational Considerations section that discusses synchronization, or an explanation why they might reasonably be out-of-sync. Here are a few points to consider: 1) the ifIndex of an interface is used within the YANG model, matching the ifIndex in IF-MIB. RFC2863 discusses the fact that ifIndex numbering might change during hot-swaps. Actually, RFC 2863 points out that a ifIndex must not be reused until after the following re-initialization of the network management system. This document does not discuss the need to ensure that IF-MIB ifIndex changes need to be reflected in the YANG model. The ifIndex in the YANG module must match that in IF-MIB (really, that in the underlying instrumentation). Absolutely! That's the intention. The description for the read-only leaf if-index says: The ifIndex value for the ifEntry represented by this interface. Failure to sync the ifIndex could lead NM applications to confuse which already-retrieved data records are related to which interface. This could cause an NM application to misinterpret/corrupt gathered trending information, and possibly to apply changes to the wrong interfaces. Fully agree - this is why the if-index is present; to facilitate the mapping between the models. 2) ifType - can an interface be hot-swapped to use a different type? Is this discussed someplace? Hot-swapping sounds like a physical property. The data model in this document can handle this -- provided the system physically supports it, of course. Note that the type is a writable leaf just like others. You can change it, but as with any other leaf a device that cannot support a particular change will reject it. 3) ifType - the description says the value of this mandatory object MAY be initialized. What value should an NM application expect if it is NOT initialized? None. And since it is mandatory, in this case the NM application has to explicitly provide the type. If you write a completely generic NM application you would probably always provide the type, since you cannot count on the server auto-initializing it. But if you *know* that the server auto-initialize the type, you don't have to provide it. 4) enabled - Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus ...; should this be a MAY/SHOULD/MUST? How will this coexist with SNMP-based NM applications? Is there potential for conflict? What if NETCONF sets this as enabled, then an operator sets it to disabled via SNMP? Does NETCONF know that its enable value (adminStatus) is out of date? (does it matter? See note 7). What if the NETCONF system directky changes the underlying instrumentation for adminstatus without going through the MIB? It is not clear to me if we can / want to require that these objects share the same instrumentation. Some of this might be b/c ifAdminStatus is a a bit unclear in some regards. For example, it talks about how per configuration information retained by the managed system, ifAdminStatus is then changed [...] I would assume (but this might be incorrect) that the configuration information could be things configured through the CLI for example, and this configuration information could thus also be the data defined in this YANG model. So it seems RFC 2863 makes a distinction between ifAdminStatus and what is actually configured. Also, the description of ifAdminStatus doesn't say anything about persistence, so it might be
Re: [netmod] Last Call: draft-ietf-netmod-interfaces-cfg-10.txt (A YANG Data Model for Interface Management) to Proposed Standard
On 30/04/2013 13:07, Benoit Claise wrote: Martin, It's interesting to note that Dave came up with similar feedback as I had during my AD review. And you had to re-explain this again, via email. This leads me to think that we need some more background information, typically in Operational Considerations section. http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 could be part of that new section, but other topics could/should be addressed: - Failure to sync the ifIndex - is there a reason why description value MAY match IF-MIB ifAlias ***and MAY restrict the values***? - what should an NM application or operator do if the YANG oper-status and the IF-MIB operStatus differ? - persistence - Is it expected that counters in ietf-interfaces and counters in IF-MIB are synchronized? - etc... Basically addressing many points made by Dave And I see that Carlos, part of the Re: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt feedback has got some similar points. - physical versus virtual interfaces - location - counter32 and counter64, and mapping to the MIB OIDs - etc... That reinforces in my thinking that we need an operational considerations section. Regards, Benoit Regards, Benoit Hi David, Thank you for your detailed review! Comments inline. David Harrington ietf...@comcast.net wrote: Hi, I have reviewed this document and feel that is almost ready for approval. This document defines a new data model in YANG format, based on the same information model as the Interfaces MIB module (IF-MIB). Effectively, the YANG model is a second (duplicative) standard for much of the same information. It is expected that devices may implement both the MIB and the YANG data models. My primary concern regards co-existence and synchronization across data models. I think this document would benefit from an Operational Considerations section that discusses synchronization, or an explanation why they might reasonably be out-of-sync. Here are a few points to consider: 1) the ifIndex of an interface is used within the YANG model, matching the ifIndex in IF-MIB. RFC2863 discusses the fact that ifIndex numbering might change during hot-swaps. Actually, RFC 2863 points out that a ifIndex must not be reused until after the following re-initialization of the network management system. This document does not discuss the need to ensure that IF-MIB ifIndex changes need to be reflected in the YANG model. The ifIndex in the YANG module must match that in IF-MIB (really, that in the underlying instrumentation). Absolutely! That's the intention. The description for the read-only leaf if-index says: The ifIndex value for the ifEntry represented by this interface. Failure to sync the ifIndex could lead NM applications to confuse which already-retrieved data records are related to which interface. This could cause an NM application to misinterpret/corrupt gathered trending information, and possibly to apply changes to the wrong interfaces. Fully agree - this is why the if-index is present; to facilitate the mapping between the models. 2) ifType - can an interface be hot-swapped to use a different type? Is this discussed someplace? Hot-swapping sounds like a physical property. The data model in this document can handle this -- provided the system physically supports it, of course. Note that the type is a writable leaf just like others. You can change it, but as with any other leaf a device that cannot support a particular change will reject it. 3) ifType - the description says the value of this mandatory object MAY be initialized. What value should an NM application expect if it is NOT initialized? None. And since it is mandatory, in this case the NM application has to explicitly provide the type. If you write a completely generic NM application you would probably always provide the type, since you cannot count on the server auto-initializing it. But if you *know* that the server auto-initialize the type, you don't have to provide it. 4) enabled - Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus ...; should this be a MAY/SHOULD/MUST? How will this coexist with SNMP-based NM applications? Is there potential for conflict? What if NETCONF sets this as enabled, then an operator sets it to disabled via SNMP? Does NETCONF know that its enable value (adminStatus) is out of date? (does it matter? See note 7). What if the NETCONF system directky changes the underlying instrumentation for adminstatus without going through the MIB? It is not clear to me if we can / want to require that these objects share the same instrumentation. Some of this might be b/c ifAdminStatus is a a bit unclear in some regards. For example, it talks about how per configuration information retained by the managed system, ifAdminStatus is then changed [...] I would assume
Re: [netmod] Last Call: draft-ietf-netmod-interfaces-cfg-10.txt (A YANG Data Model for Interface Management) to Proposed Standard
On Apr 30, 2013, at 7:25 AM, Benoit Claise bcla...@cisco.com wrote: On 30/04/2013 13:07, Benoit Claise wrote: Martin, It's interesting to note that Dave came up with similar feedback as I had during my AD review. And you had to re-explain this again, via email. This leads me to think that we need some more background information, typically in Operational Considerations section. http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 could be part of that new section, but other topics could/should be addressed: - Failure to sync the ifIndex - is there a reason why description value MAY match IF-MIB ifAlias ***and MAY restrict the values***? - what should an NM application or operator do if the YANG oper-status and the IF-MIB operStatus differ? - persistence - Is it expected that counters in ietf-interfaces and counters in IF-MIB are synchronized? - etc... Basically addressing many points made by Dave And I see that Carlos, part of the Re: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt feedback has got some similar points. - physical versus virtual interfaces - location - counter32 and counter64, and mapping to the MIB OIDs - etc... That reinforces in my thinking that we need an operational considerations section. +1. I think that an Operational Considerations addressing these issues would be a most useful addition to this document. For context, full review at http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html Thanks, -- Carlos. Regards, Benoit Regards, Benoit Hi David, Thank you for your detailed review! Comments inline. David Harrington ietf...@comcast.net wrote: Hi, I have reviewed this document and feel that is almost ready for approval. This document defines a new data model in YANG format, based on the same information model as the Interfaces MIB module (IF-MIB). Effectively, the YANG model is a second (duplicative) standard for much of the same information. It is expected that devices may implement both the MIB and the YANG data models. My primary concern regards co-existence and synchronization across data models. I think this document would benefit from an Operational Considerations section that discusses synchronization, or an explanation why they might reasonably be out-of-sync. Here are a few points to consider: 1) the ifIndex of an interface is used within the YANG model, matching the ifIndex in IF-MIB. RFC2863 discusses the fact that ifIndex numbering might change during hot-swaps. Actually, RFC 2863 points out that a ifIndex must not be reused until after the following re-initialization of the network management system. This document does not discuss the need to ensure that IF-MIB ifIndex changes need to be reflected in the YANG model. The ifIndex in the YANG module must match that in IF-MIB (really, that in the underlying instrumentation). Absolutely! That's the intention. The description for the read-only leaf if-index says: The ifIndex value for the ifEntry represented by this interface. Failure to sync the ifIndex could lead NM applications to confuse which already-retrieved data records are related to which interface. This could cause an NM application to misinterpret/corrupt gathered trending information, and possibly to apply changes to the wrong interfaces. Fully agree - this is why the if-index is present; to facilitate the mapping between the models. 2) ifType - can an interface be hot-swapped to use a different type? Is this discussed someplace? Hot-swapping sounds like a physical property. The data model in this document can handle this -- provided the system physically supports it, of course. Note that the type is a writable leaf just like others. You can change it, but as with any other leaf a device that cannot support a particular change will reject it. 3) ifType - the description says the value of this mandatory object MAY be initialized. What value should an NM application expect if it is NOT initialized? None. And since it is mandatory, in this case the NM application has to explicitly provide the type. If you write a completely generic NM application you would probably always provide the type, since you cannot count on the server auto-initializing it. But if you *know* that the server auto-initialize the type, you don't have to provide it. 4) enabled - Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus ...; should this be a MAY/SHOULD/MUST? How will this coexist with SNMP-based NM applications? Is there potential for conflict? What if NETCONF sets this as enabled, then an operator sets it to disabled via SNMP? Does NETCONF know that its enable value (adminStatus) is out of date? (does it matter? See note 7). What if the NETCONF system directky changes the underlying instrumentation for adminstatus without going through
Re: Last Call: draft-ietf-netmod-interfaces-cfg-10.txt (A YANG Data Model for Interface Management) to Proposed Standard
Hi David, Thank you for your detailed review! Comments inline. David Harrington ietf...@comcast.net wrote: Hi, I have reviewed this document and feel that is almost ready for approval. This document defines a new data model in YANG format, based on the same information model as the Interfaces MIB module (IF-MIB). Effectively, the YANG model is a second (duplicative) standard for much of the same information. It is expected that devices may implement both the MIB and the YANG data models. My primary concern regards co-existence and synchronization across data models. I think this document would benefit from an Operational Considerations section that discusses synchronization, or an explanation why they might reasonably be out-of-sync. Here are a few points to consider: 1) the ifIndex of an interface is used within the YANG model, matching the ifIndex in IF-MIB. RFC2863 discusses the fact that ifIndex numbering might change during hot-swaps. Actually, RFC 2863 points out that a ifIndex must not be reused until after the following re-initialization of the network management system. This document does not discuss the need to ensure that IF-MIB ifIndex changes need to be reflected in the YANG model. The ifIndex in the YANG module must match that in IF-MIB (really, that in the underlying instrumentation). Absolutely! That's the intention. The description for the read-only leaf if-index says: The ifIndex value for the ifEntry represented by this interface. Failure to sync the ifIndex could lead NM applications to confuse which already-retrieved data records are related to which interface. This could cause an NM application to misinterpret/corrupt gathered trending information, and possibly to apply changes to the wrong interfaces. Fully agree - this is why the if-index is present; to facilitate the mapping between the models. 2) ifType - can an interface be hot-swapped to use a different type? Is this discussed someplace? Hot-swapping sounds like a physical property. The data model in this document can handle this -- provided the system physically supports it, of course. Note that the type is a writable leaf just like others. You can change it, but as with any other leaf a device that cannot support a particular change will reject it. 3) ifType - the description says the value of this mandatory object MAY be initialized. What value should an NM application expect if it is NOT initialized? None. And since it is mandatory, in this case the NM application has to explicitly provide the type. If you write a completely generic NM application you would probably always provide the type, since you cannot count on the server auto-initializing it. But if you *know* that the server auto-initialize the type, you don't have to provide it. 4) enabled - Systems that implement the IF-MIB use the value of this leaf to set IF-MIB.ifAdminStatus ...; should this be a MAY/SHOULD/MUST? How will this coexist with SNMP-based NM applications? Is there potential for conflict? What if NETCONF sets this as enabled, then an operator sets it to disabled via SNMP? Does NETCONF know that its enable value (adminStatus) is out of date? (does it matter? See note 7). What if the NETCONF system directky changes the underlying instrumentation for adminstatus without going through the MIB? It is not clear to me if we can / want to require that these objects share the same instrumentation. Some of this might be b/c ifAdminStatus is a a bit unclear in some regards. For example, it talks about how per configuration information retained by the managed system, ifAdminStatus is then changed [...] I would assume (but this might be incorrect) that the configuration information could be things configured through the CLI for example, and this configuration information could thus also be the data defined in this YANG model. So it seems RFC 2863 makes a distinction between ifAdminStatus and what is actually configured. Also, the description of ifAdminStatus doesn't say anything about persistence, so it might be impossible to map this to the persistently stored configuration. 5) is there a reason why description value MAY match IF-MIB ifAlias ***and MAY restrict the values***? Is there a particular use case for this lack of standardization of restrictions across data models? The persistence is a pretty important restriction related to the functionality of ifAlias, and the dynamism of ifIndex. If NETCONF is used to set the value, ignoring IF-MIB restrictions, what happens to IF-MIB ifAlias as a persistent handle to the interface? The only reason the description leaf is mapped to ifAlias is b/c this is what many implementations do. So we wanted to point out the differences in the value space for these objects so that implementers are aware of this. And of course it is
Re: [netmod] Last Call: draft-ietf-netmod-interfaces-cfg-10.txt (A YANG Data Model for Interface Management) to Proposed Standard
On Apr 30, 2013, at 12:20 PM, Martin Bjorklund m...@tail-f.com wrote: 5) is there a reason why description value MAY match IF-MIB ifAlias ***and MAY restrict the values***? Is there a particular use case for this lack of standardization of restrictions across data models? The persistence is a pretty important restriction related to the functionality of ifAlias, and the dynamism of ifIndex. If NETCONF is used to set the value, ignoring IF-MIB restrictions, what happens to IF-MIB ifAlias as a persistent handle to the interface? The only reason the description leaf is mapped to ifAlias is b/c this is what many implementations do. So we wanted to point out the I think it is a dubious practice. differences in the value space for these objects so that implementers are aware of this. And of course it is not possible to actually set *ifAlias* and ignore its syntax constraints. However, you can use non 7-bit ascii in description, and in this case the description value cannot be used unmodified as ifAlias. If I correctly understand IF-MIB, a natural mapping would be +--++ | YANG data node | IF-MIB object | +--++ | name | ifAlias| | local-name | ifName | +--++ with local-name being a new config=false leaf. The location leaf then could be removed. The lack of correspondence between name and ifName is somewhat confusing, so perhaps an alternative could be to follow suit of IF-MIB and use alias (== ifAlias) as the key of interface list, and name (== ifName) as the config=false local name. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
Re: Do we have an estimated date for completing the IESG selection process for this year?
Hi Ted, On 04/30/2013 01:19 AM, Ted Hardie wrote: 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. It is the NOMCOM and the IAB as confirming body. Martin -- IETF Transport Area Director martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
On 4/2/13 4:58 AM, Brian E Carpenter wrote: Just picking a couple of points for further comment: On 02/04/2013 08:46, Liubing (Leo) wrote: Hi, Robert ... -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] ... The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. Robert is right, though, sending people to a long-expired draft is a bad idea. Of course we have to acknowledge it, but maybe we should pull some of its text into an Appendix. Tim Chown, any opinion? The most recent version (and the one slated for the next telechat) still has this long-expired draft referenced. RjS
Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
On 4/30/13 8:33 AM, Robert Sparks wrote: On 4/2/13 4:58 AM, Brian E Carpenter wrote: Just picking a couple of points for further comment: On 02/04/2013 08:46, Liubing (Leo) wrote: Hi, Robert ... -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] ... The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. Robert is right, though, sending people to a long-expired draft is a bad idea. I'm not sure I see that as worse than referring to Wikipedia, an expired draft has the property that it's not going to change. I have no problem with the idea that it would be an informative reference. but yes it's a bit much to say go read this. Of course we have to acknowledge it, but maybe we should pull some of its text into an Appendix. Tim Chown, any opinion? The most recent version (and the one slated for the next telechat) still has this long-expired draft referenced. RjS
Re: IETF Diversity Question on Berlin Registration?
- Original Message - From: Margaret Wasserman m...@lilacglade.org To: t.p. daedu...@btconnect.com Cc: Dan Harkins dhark...@lounge.org; ietf@ietf.org Sent: Monday, April 29, 2013 1:53 AM 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_. There is no inherent reason why 40+-year-old, white, western males who work at large networking equipment vendors are inherently more capable of serving on the IESG than people from other groups within the IETF, and there would be _considerable internal benefit_ to having an IESG that was more diverse, because diverse groups make better decisions and better represent the needs of the whole organization. Therefore, if there is something about our culture, our structure, our selection process, or the way we run our meetings that is causing us to predominantly select our leadership from a restricted group, we would have _more capable_ and _better_ leadership if we could find a way to broaden that pool. _That_ is what this discussion is about. This is not an effort to meet some externally imposed notion of diversity. tp Margaret The first I saw of this idea was the post by Ray, which said The IETF is concerned about diversity. As good engineers, we would like to attempt to measure diversity while working on addressing and increasing it. To that end, we are considering adding some possibly sensitive questions to the registration process, for example, gender. For me, this came out of the blue. I have no idea why it is considered that the IETF - note, IETF not IAB or IESG or IAOC - has become concerned nor what evidence there is of concern. And note, 'for example, gender' which seems to have become the only measure under consideration; was that Ray's intent, or was he being coy and leaving out other frequent lacks of diversity which are more delicate to discuss? I immediately assumed the latter, based on no evidence at all! Given the way the discussion has gone, perhaps he meant 'only and exclusively gender but I could not possibly say that':-) As Michael StJohns has said, How does the IETF evolve to continue to be an effective, efficient, and relevant source of high quality Internet standards? which I think is spot on. I do not see diversity (lack of) as being part of that until it is shown to be. I do see the IESG as key to the work of the IETF and see filling positions there as challenging, perhaps a risk to the long term existence of the IETF. The requirements - technical knowledge, experience, time to spend on IETF business, e.g. - make the candidate pool rather small and I believe that any more constraints will weaken that pool and could hazard the IETF. There are workshops for (potential?) WG Chairs; I would see merit in more such sessions on how to work effectively within the IETF, at any level, with a subtext of it is possible to do more, to 'advance', it is really not (quite) impossible. Diversity would have no place in such workshops but it could increase the candidate pool for a variety of posts. Tom Petch /tp Margaret
Re: [IETF] Re: IETF Diversity Question on Berlin Registration?
- Original Message - From: Warren Kumari war...@kumari.net To: Joe Abley jab...@hopcount.ca Cc: Sam Hartman hartmans-i...@mit.edu; ietf@ietf.org; stbry...@cisco.com Sent: Monday, April 29, 2013 10:01 PM 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. tp Warren The correlation that has attracted attention near me is the marked drop in crime rates compared with a reduction in the use of leaded petrol; here, you can make a comparison with countries that have or have not reduced the use of leaded petrol at different times, and the correlation stands up, so perhaps Microsoft is not implicated in this one. Tom Petch 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
On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote: 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. That's true, except that one has TXT records anyway. The complains about using SPF is that there are broken firewalls and some servers drop queries for it, some registars don't support it. Nits, as explained below. The basic fact that killed the SPF type is the ability to use TXT as a replacement. There must be an analogous of Gresham's law: Bad types drive out good ones. 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. While it's too late for SPF, we can learn this lesson.
Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6renum-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10, 2013 IESG Telechat date: May 16, 2013 Summary: Ready with nits (that border on minor issues) This update improved the readability significantly, and addressed my major concern about being able to build a list of the gaps. Thank you. There are a few issues from my last call review that are still not addressed. I have left the classification of minor issue vs nits the same as the original review to make referring to the earlier review easier, but please consider all of these Nits. The IESG will need to decide whether to escalate them. I've trimmed away the points that were addressed. On 4/1/13 3:46 PM, Robert Sparks wrote: -- Minor issues: The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. This version still references that long expired draft. There was also conversation on apps-discuss about making that reference normative. IMHO, this is not the right way to treat the RFC series, and strongly encourage moving the text that you want to reference into something that will become an RFC. Should section 8 belong to some other document? It looks like operational renumbering advice/considerations, but doesn't seem to be exploring renumbering gaps, except for the very short section 8.2 which says we need a better mechanism without much explanation. Afaict, this wasn't addressed at all. In particular, we need a better mechanism is still all that section 8.2 says. Section 5.1, first bullet. The list below the impact of ambiguous M/O flags says things like there is no standard and it is unspecified. I think you are trying to say that there is ambiguity in what's written, not that nothing's written. This entire list would benefit from being recast in terms of what needs to be done (what are the gaps?). This text remains unmodified. -- Nits/editorial comments: There are a few sentences ending with etc. in the document. Please consider deleting the word from the list - it doesn't help each sentence make its point. There were some changes, but mostly these still exist. I'll leave pressing this point further to the RFC Editor. Seciton 7.1: The first bullet does not parse. If I guess its meaning correctly (that it would be benificial to tell hosts that local DNS has been updated and they may want to make fresh queries), please be careful with the wording. The hosts don't know which names are likely to resolve locally. This text remained unchanged, and when coming back to the document for a re-review (which is somewhat like coming back to an RFC you've read before just for reference), it's even harder to understand what it's trying to say than it was when reading the document linearly. I think you are trying to say A notification mechanism may be needed to indicate _to_ hosts that a renumbering event has _changed how local recursive DNS servers will respond_. That mechanism may also need to indicate that such a change will happen at a specific time in the future. Section 7.1, third bullet - This isn't obviously about notification. Why is it in this section? What's the gap this is trying to identify? This text was unchanged. Section 9.4 - what is it about these that make them gaps, much less unsolvable gaps. Is this discussion in the wrong section of the document? This is now section 10.3 and is mostly unchanged. It's still not clear why this discussion is in the unsolvable gaps section.
Call for Technical Plenary Topics
The plenary topic for IETF 86, The End of POTS, was proposed by an IETF participant. That plenary topic was well received. As the IAB prepares for IETF 87, we want to reach out to the IETF community for technical plenary topics. Please send suggestions to iab at iab.org. The IAB is interested in hearing suggestions that could be presented by invited speakers, panels, or lightning talks. In other words, please do not let the format of past plenary presentations narrow your suggestions. Thank you, Russ Housley IAB Chair
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
While it's too late for SPF, we can learn this lesson.
As has been repeatedly pointed out in the discussion on both dnsext and
spfbis, it is NOT too late for SPF. The way forward is simple:
1. Publish the bis draft which says for senders to publish both SPF and
TXT versions, and receivers to query first for the SPF RRtype.
2. Update the HOW-TO docs to reflect this change.
3. Update the software to query SPF first (Note, Perl's NET::SPF, used
by SpamAssassin, already made this change).
4. Let time pass.
5. When the next version of the SPF protocol (v=spf{1}) comes out make
it SPF/99 only.
The discussion about this on the spfbis list all revolved around the
fact that TXT is widespread, SPF/99 is rarely used, so let's just stick
with TXT. In a pre-3597 world there _were_ problems with querying for
SPF first, so the fact that historically querying for SPF/99 first was
painful is a valid data point. However the problems encountered in the
early days of SPF deployment with servers not handing unknown types
gracefully haven't been relevant for many years now. Yet, the SPF
community has continued to push TXT only, in spite of the advice of
4408. Almost like a self-fulfilling prophecy ...
The reasons brought forward by participants in the spfbis group to not
make this change all revolve around the fact that it would involve
additional work. Personally I don't find those arguments compelling.
First, some of the arguments about the extra work are just plain silly
(ala, cut and paste of the same data for 2 RRtypes is too difficult).
Second, there are not that many implementations that query SPF, and the
change is not difficult. Third, most of the work to be done is to wait
for time to pass and for people to upgrade to the new versions of
software. This is a bog-simple long tail problem that we deal with in
the DNS world all the time.
There was one objection that made some sense, which is that right now,
because the SPF world has steadfastly distributed the advice to use TXT
only, querying for SPF/99 first gives you what is likely to be 1
spurious DNS lookup per e-mail message. The obvious answer to that is to
do a better job of encouraging folks to publish SPF records. Meanwhile,
I have a fairly traditional mail server implementation that does a
variety of anti-spam checks. By rough count it generates about 8 DNS
queries for every message already. Generating 1 more is in the noise
in the short term, and as shown above goes away in the long term.
Not only is this a case where doing the right thing is good for SPF, the
SPF example of let's just go with TXT because using a new RRtype is
hard has spread like wildfire, especially in the mail authentication
world (DKIM, DMARC, etc.). The slippery slope has been well-greased at
this point, and it would be nice to move things back in the right
direction (see 5507 for example).
To be fair, there was one other objection raised, which is that DNS
provisioning systems haven't caught up with the need for new RRtypes. So
some can't go to their registrar's/web hoster's/etc. web interface and
enter a proper SPF record. That's a problem, sure. But it's a problem
that has to be solved, assuming we're actually going to take the advice
in 5507 seriously. Personally I'm not willing to allow all progress
forward in DNS to be stymied by those unwilling to make an investment in
their own infrastructure.
In case Dave is still wondering what all the fuss is about, and because
the folks in spfbis seem completely unwilling to deal with this issue in
the group, consider this my first draft of an IETF last call objection
to the fact that 4408bis wants to deprecate use of the SPF RRtype.
Doug
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On 4/30/2013 10:11 AM, Doug Barton wrote: As has been repeatedly pointed out in the discussion on both dnsext and spfbis, it is NOT too late for SPF. As has repeatedly been pointed out, the market has already had plenty of time to adopt the RR and has overwhelmingly rejected it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Appointment of Deborah Brungard as new IETF Liaison Manager to the ITU-T for MPLS
The IAB has just notified the ITU-T that Deborah Brungard will be the new IETF Liaison Manager to the ITU-T for MPLS. Deborah was appointed following an open call for volunteers (see email from Scott Mansfield to the IETF list on Fri 3/29/2013 4:32 PM EDT). Please congratulate Deborah when you see her. Please thank Scott Mansfield for his past service in this role. Scott is now the overall liaison manager to ITU-T, and as such I am confident that he will provide valuable support for Deborah. Thanks, Russ From: IAB Chair iab-ch...@iab.org Date: April 30, 2013 1:35:53 PM EDT To: tsbs...@itu.int, ITU-T TSAG tsbt...@itu.int Cc: ITU TSBDir tsb...@itu.int, IAB i...@iab.org, IESG i...@ietf.org, IETF Liaison Statements stateme...@ietf.org Subject: Appointment of Deborah Brungard as new IETF Liaison Manager to the ITU-T for MPLS The IAB would like to bring to the ITU-T's attention the appointment of Ms Deborah Brungard as the new IETF Liaison Manager to the ITU-T for MPLS. The IETF-ITU-T MPLS liaison role helps facilitate communication between the IETF and the ITU-T on matters of MPLS. The MPLS liaison manager is responsible for ensuring the liaisons from the IETF on MPLS are routed to the correct study group(s) in the ITU-T and any incoming liaison from the ITU-T on MPLS is communicated to the proper working groups, usually MPLS, CCAMP, and PWE3 working groups. Deborah Brungard has been with ATT for more than 28 years with experience in network and service management. She is a Lead Member of Technical Staff in ATT's Network Technologies Unit. She is IETF Routing Area's CCAMP Co-Chair, she has co-chaired CCAMP for more than 6 years. CCAMP (Common Control and Measurement Plane) is responsible for GMPLS and works cooperatively with MPLS, L2VPN, PWE3, OSPF, PCE, IDR, and ISIS. She is also the Routing Area Directorate Coordinator and Routing Area Secretary. Deborah has actively contributed in SG15 for more than 15 years, including as an Editor (in the early 2000's). She is very familiar with the ITU-T process, she was Chair of ANSI (American National Standards) T1X1.5 (Optical Standards) for several years in the early 2000's. For the IAB, Russ Housley IAB Chair
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On Apr 30, 2013, at 12:28, Alessandro Vesely wrote: ...The basic fact that killed the SPF type is the ability to use TXT as a replacement. There must be an analogous of Gresham's law: Bad types drive out good ones. I disagree with the assertion that what killed SPF is the ability to use TXT as a replacement. It has nothing to do with one option being superior to the other, it was the lack of technical incentive to switch from one to the other. I post this in the sense that if the root cause is not understood, no solution will stick. Here is a message with my recounting of what led us to this point: http://www.ietf.org/mail-archive/web/dnsext/current/msg12681.html I don't see the death of SPF has a harbinger of things to come. There's a strong case to be made the failure happened before 2004 and the root cause has since been corrected by changing the RRTYPE type allocation policies. Still that fix was too late to ever let SPF sprout wings. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
Dave, On Apr 30, 2013, at 10:13 AM, Dave Crocker d...@dcrocker.net wrote: On 4/30/2013 10:11 AM, Doug Barton wrote: As has been repeatedly pointed out in the discussion on both dnsext and spfbis, it is NOT too late for SPF. As has repeatedly been pointed out, the market has already had plenty of time to adopt the RR and has overwhelmingly rejected it. What is the IETF-approved timeframe in which the market is allowed to accept/reject a particular technology? Given no one appears to be making the argument that using the TXT RR and the MAIL FROM/HELO identity is the optimal solution (to put it mildly), I'm a bit confused why deprecating the SPF RR is being pushed so hard at this point in time. Is there some forcing function here? Regards, -drc
Re: Do we have an estimated date for completing the IESG selection process for this year?
Hi Martin, On Apr 30, 2013, at 6:21 PM, Martin Stiemerling martin.stiemerl...@neclab.eu wrote: Hi Ted, On 04/30/2013 01:19 AM, Ted Hardie wrote: 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. It is the NOMCOM and the IAB as confirming body. While this is true, we've been aware of a problem for three months now, and we're not aware of any resolution or of any attempt to resolve the issue. We know that there are several candidates (Still listed on the NomCom website) and for some reason (which we can only guess at) none of them is being appointed. Will that seat remain vacant for a year? Two years? Is there some flaw in the process that prevents this issue from being resolved? Inquiring minds want to know Yoav
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On 4/30/2013 11:08 AM, David Conrad wrote: As has repeatedly been pointed out, the market has already had plenty of time to adopt the RR and has overwhelmingly rejected it. What is the IETF-approved timeframe in which the market is allowed to accept/reject a particular technology? I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. Given no one appears to be making the argument that using the TXT RR and the MAIL FROM/HELO identity is the optimal solution (to put it mildly), I'm a bit confused why deprecating the SPF RR is being pushed so hard at this point in time. Is there some forcing function here? Surely this has been amply covered, multiple times. Rehashing it won't be productive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
Doug, Aren't you tired of repeatedly pointing out your half of the argument? I am of ours. The Monty Python argument clinic sketch comes to mind. On Tue, Apr 30, 2013 at 10:11 AM, Doug Barton do...@dougbarton.us wrote: The discussion about this on the spfbis list all revolved around the fact that TXT is widespread, SPF/99 is rarely used, so let's just stick with TXT. In a pre-3597 world there _were_ problems with querying for SPF first, so the fact that historically querying for SPF/99 first was painful is a valid data point. However the problems encountered in the early days of SPF deployment with servers not handing unknown types gracefully haven't been relevant for many years now. Yet, the SPF community has continued to push TXT only, in spite of the advice of 4408. Almost like a self-fulfilling prophecy ... As has been repeatedly pointed out, the haven't been relevant for many years now conclusion you've reached is contradicted by both anecdotal and empirical data. I assure you that I hear all of the points you are making. I also assure you that none of them resolve any of the points being made on the other side. There's no dialog happening here. The reasons brought forward by participants in the spfbis group to not make this change all revolve around the fact that it would involve additional work. Personally I don't find those arguments compelling. Sure, because you don't have to do the work, nor are you confronted with the weight of the long tail in this case. I submit that it is presumptuous to assert that the properties of one community's long tail problems are the same as they are in others. First, some of the arguments about the extra work are just plain silly (ala, cut and paste of the same data for 2 RRtypes is too difficult). I don't think anyone said that's difficult. I would also point out that it's not difficult, given a jumble of TXT RRs in a reply, to find any that start with a particular identifying substring which would mean this is an SPF record, so let's nip that one in the bud right now. These are all distractions from the real points being made. Second, there are not that many implementations that query SPF, and the change is not difficult. Nobody said that's a problem either. Third, most of the work to be done is to wait for time to pass and for people to upgrade to the new versions of software. This is a bog-simple long tail problem that we deal with in the DNS world all the time. ...during which time the service arguably operates in a degraded state. The assertion that You should just fix your DNS infrastructure! ignores the fact that the interfering piece of the infrastructure may not be under the control of the operator who can't complete an SPF operation, or, worse, that the owner of the problem lacks the resources or interest to get it fixed for a long while, if at all. Do we just have SPF operators call you for emotional support during this protracted transition time? Not only is this a case where doing the right thing is good for SPF, the SPF example of let's just go with TXT because using a new RRtype is hard has spread like wildfire, especially in the mail authentication world (DKIM, DMARC, etc.). The slippery slope has been well-greased at this point, and it would be nice to move things back in the right direction (see 5507 for example). This is also a separate argument given the underscore prefix debate. To be fair, there was one other objection raised, which is that DNS provisioning systems haven't caught up with the need for new RRtypes. So some can't go to their registrar's/web hoster's/etc. web interface and enter a proper SPF record. That's a problem, sure. But it's a problem that has to be solved, assuming we're actually going to take the advice in 5507 seriously. Personally I'm not willing to allow all progress forward in DNS to be stymied by those unwilling to make an investment in their own infrastructure. What are you prepared to do to help address the broken infrastructure? It's all well and good to lob directives over the wall, but I'd like to hear some advice about how to compel inattentive infrastructure operators to make these changes, especially when those operators aren't necessarily the ones affected. -MSK
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
Murray, On Apr 30, 2013, at 11:29 AM, Murray S. Kucherawy superu...@gmail.com wrote: I would also point out that it's not difficult, given a jumble of TXT RRs in a reply, to find any that start with a particular identifying substring which would mean this is an SPF record, so let's nip that one in the bud right now. SPF using TXT and hence, SPFBIS forces the uniquification of the DNS response into the application instead of in the DNS library. Given the ordering of individual TXT RRs within an RRset is not guaranteed, I suspect the chances that every application is going to do that parsing correctly is relatively low (btw, the example in 3.3 in spfbis-14 is a bit misleading: assuming second string is in a separate TXT RR (which is implied), the concatenation might be second stringv=spf1 . first). The more interesting bit is if/when another protocol uses TXT at the same ownername. What are you prepared to do to help address the broken infrastructure? Argue against deprecating the SPF RR :). The RR has been allocated and it is supported in most DNS servers and resolver libraries in one form or another. Provisioning systems take much longer, but that isn't surprising and shouldn't be an argument to deprecate (if it is, we might as well close the RRtype registry for new entries). In the past, the IETF used to make decisions based on long-term technical/architectural correctness, even in the face of pragmatic complications (e.g., the choice to mandate strong crypto despite real world challenges some companies faced in exporting that crypto in products). In this particular case, there seems to be an argument to explicitly disallow the long-term technically/architecturally correct approach because some folks choose not to add an RR to their zone files or support that RR in their provisioning systems. As I said in DNSEXT, this seems like the wrong approach to me. Regards, -drc
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote: What is the IETF-approved timeframe in which the market is allowed to accept/reject a particular technology? I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. Thanks, -drc
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On 4/30/2013 12:54 PM, David Conrad wrote: On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote: What is the IETF-approved timeframe in which the market is allowed to accept/reject a particular technology? I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. Gosh, David. I guess you win. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IETF Diversity Question on Berlin Registration?
I think the statistics are very interesting and we should continue developing them, but we should also not be driven by them. I'll repeat again what I've said before: I can see increasing both participation diversity and leadership diversity being useful for the IETF. We are limited by various constraints, type of people who are in our field, where the industry is located in the world, funding resources, expertise gained by various participants, etc. But within those constraints, I'd see plenty of benefits to increasing diversity along many axes. (Or indeed even relaxing some of the constraints, such lowering participation costs by remote participation, or lowering leadership costs by requiring less than 100% time commitments.) Jari
Re: IETF Diversity Question on Berlin Registration?
you don't need a weatherman to know which way the wind blows. -- bob dylan we do not need measurements to know the ietf is embarrassingly non-diverse. it is derived from and embedded in an embarrassingly non-diverse culture. we need to do what we can to remedy this. progress not perfection is our goal. measurement may be useful to see if we are having effect and/or what things have effect (meeting locales, size of cookies, ...). we should be asking the minorities and those struggling to particiate what we can do to help. randy
Re: IETF Diversity Question on Berlin Registration?
On Tue, Apr 30, 2013 at 1:41 PM, Randy Bush ra...@psg.com wrote: you don't need a weatherman to know which way the wind blows. -- bob dylan we do not need measurements to know the ietf is embarrassingly non-diverse. it is derived from and embedded in an embarrassingly non-diverse culture. we need to do what we can to remedy this. progress not perfection is our goal. measurement may be useful to see if we are having effect and/or what things have effect (meeting locales, size of cookies, ...). we should be asking the minorities and those struggling to particiate what we can do to help. randy Nicely said Randy. --dmm
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On Apr 30, 2013, at 1:20 PM, Dave Crocker d...@dcrocker.net wrote: I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. Gosh, David. I guess you win. Gee Dave, great way to elevate the discussion. *plonk*
Re: IETF Diversity Question on Berlin Registration?
On Apr 30, 2013, at 4:53 PM 4/30/13, David Meyer d...@1-4-5.net wrote: On Tue, Apr 30, 2013 at 1:41 PM, Randy Bush ra...@psg.com wrote: you don't need a weatherman to know which way the wind blows. -- bob dylan we do not need measurements to know the ietf is embarrassingly non-diverse. it is derived from and embedded in an embarrassingly non-diverse culture. we need to do what we can to remedy this. progress not perfection is our goal. measurement may be useful to see if we are having effect and/or what things have effect (meeting locales, size of cookies, ...). we should be asking the minorities and those struggling to particiate what we can do to help. randy Nicely said Randy. --dmm Agreed - without consulting a weatherman, we've been having a discussion (among a rather un-diverse group of participants) about where we are, as opposed to asking the questions Randy suggests. - Ralph
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On 4/30/2013 2:37 PM, David Conrad wrote: On Apr 30, 2013, at 1:20 PM, Dave Crocker d...@dcrocker.net wrote: I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. Gosh, David. I guess you win. Gee Dave, great way to elevate the discussion. You were discussing? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
In message 51802793.3010...@dcrocker.net, Dave Crocker writes: On 4/30/2013 12:54 PM, David Conrad wrote: On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote: What is the IETF-approved timeframe in which the market is allowed to a ccept/reject a particular technology? I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. Gosh, David. I guess you win. When just about none of the documentation mentions the SPF record type nor has examples with both SPF and TXT records it isn't the market choosing. You can't choose of you really havn't been informed. BEWARE OF THE LEOPARD But Mr Dent, the plans have been available in the local planning office for the last nine months. Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn't exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything. But the plans were on display ... On display? I eventually had to go down to the cellar to find them. That's the display department. With a flashlight. Ah, well the lights had probably gone. So had the stairs. But look, you found the notice didn't you? Yes, said Arthur, yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. The Hitchhikerâs Guide to the Galaxy Douglas Adams Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
ICANN Nomcom Extends Deadline for SOIs to 15 May 2013
http://www.icann.org/en/news/announcements/announcement-30apr13-en.htm In order to provide additional time for candidates to apply, ICANN's 2013 Nominating Committee (NomCom) has extended the deadline for Statements of Interest until 15 May 2013 at 23:59 UTC. The 2013 NomCom is actively seeking qualified candidates for the following key positions within ICANN: * Three members of the Board of Directors of ICANN * Three members of the At Large Advisory Committee (ALAC) (one each from the Africa, Asia/Australia/Pacific Islands and Latin America/Caribbean Islands regions) * Two members of the Council of the Generic Names Supporting Organization (GNSO) * One member of the Council of the Country-Code Names Supporting Organization (ccNSO) More information about the positions is available at: http://nomcom.icann.org/positions-2013.htm Ole J. Jacobsen (2013 ICANN nomcom member)
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
I think I understand this issue well enough to comment and so I will. 1) I totally believe it is reasonable to consider operational challenges when designing protocols. Just upgrade your infrastructure, just use another registrar, just upgrade the infrastructure of the people you communicate with, are not generally reasonable advice to give people; ingoring these concerns tend to lead to things that cannot be deployed. 2) I think it's fine to come up with a solution that is harder to implement because it is easier to deploy given the sorts of concerns in 1. 3) having reviewed the DNS arguments, I generally would recommend txt records with distinct owner names over new RR types for most protocols. I understand there are residual issues with that approach. 4) Using txt RRs the way SPF does--where the owner name is shared potentially with other applications is kind of unfortunate. I don't know it's unfortunate enough to push for the SPF RR. But the issues people have brought up with regard to updates and RR order are very real. But so are the operational issues with SPF. So my personal opinion is that this is a valid discussion to be having even if we're having it again in IETF LC. However, to be successful we need to get new participants and to ad more respect for arguments to the discussion.
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
In message 517ff144.5040...@tana.it, Alessandro Vesely writes: On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote: 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. That's true, except that one has TXT records anyway. nsupdate update del example.com SPF update add example.com 3600 SPF v=spf1 send txt=`dig +short example.com TXT | \ sed -n -e '/^v=spf1 /s/^/update del example.com TXT /p' \ -e '/^v=spf1$/^/update del example.com TXT /p'` nsupdate EOF $txt update add example.com 3600 TXT v=spf1 send EOF But that doesn't work for 'example.com TXT v = s p f 1' which is a perfectly legal SPF record. sed -n -e '/^v=spf1 /s/^/update del example.com TXT /p' \ -e '/^v =spf1 /s/^/update del example.com TXT /p' \ -e '/^v = spf1 /s/^/update del example.com TXT /p' \ -e '/^v = s pf1 /s/^/update del example.com TXT /p' \ -e '/^v = s p f1 /s/^/update del example.com TXT /p' \ -e '/^v = s p f 1 /s/^/update del example.com TXT /p' \ -e '/^v = s p f 1 /s/^/update del example.com TXT /p' \ -e '/^v=spf1$/^/update del example.com TXT /p'` And keep going because the delete needs the rdata to be a perfect match to identify the record to be removed. I'm sure I could come up with a more compact way of identifying a spf record but it wouldn't be needed if people published type SPF. The complains about using SPF is that there are broken p firewalls and some servers drop queries for it, some registars don't support it. Nits, as explained below. The basic fact that killed the SPF type is the ability to use TXT as a replacement. There must be an analogous of Gresham's law: Bad types drive out good ones. 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. While it's too late for SPF, we can learn this lesson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
In message 517ffb33.30...@dougbarton.us, Doug Barton writes:
On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
While it's too late for SPF, we can learn this lesson.
As has been repeatedly pointed out in the discussion on both dnsext and
spfbis, it is NOT too late for SPF. The way forward is simple:
1. Publish the bis draft which says for senders to publish both SPF and
TXT versions, and receivers to query first for the SPF RRtype.
2. Update the HOW-TO docs to reflect this change.
3. Update the software to query SPF first (Note, Perl's NET::SPF, used
by SpamAssassin, already made this change).
As has libspf2.
4. Let time pass.
5. When the next version of the SPF protocol (v=spf{1}) comes out make
it SPF/99 only.
The discussion about this on the spfbis list all revolved around the
fact that TXT is widespread, SPF/99 is rarely used, so let's just stick
with TXT. In a pre-3597 world there _were_ problems with querying for
SPF first, so the fact that historically querying for SPF/99 first was
painful is a valid data point. However the problems encountered in the
early days of SPF deployment with servers not handing unknown types
gracefully haven't been relevant for many years now. Yet, the SPF
community has continued to push TXT only, in spite of the advice of
4408. Almost like a self-fulfilling prophecy ...
The reasons brought forward by participants in the spfbis group to not
make this change all revolve around the fact that it would involve
additional work. Personally I don't find those arguments compelling.
First, some of the arguments about the extra work are just plain silly
(ala, cut and paste of the same data for 2 RRtypes is too difficult).
Second, there are not that many implementations that query SPF, and the
change is not difficult. Third, most of the work to be done is to wait
for time to pass and for people to upgrade to the new versions of
software. This is a bog-simple long tail problem that we deal with in
the DNS world all the time.
There was one objection that made some sense, which is that right now,
because the SPF world has steadfastly distributed the advice to use TXT
only, querying for SPF/99 first gives you what is likely to be 1
spurious DNS lookup per e-mail message. The obvious answer to that is to
do a better job of encouraging folks to publish SPF records. Meanwhile,
I have a fairly traditional mail server implementation that does a
variety of anti-spam checks. By rough count it generates about 8 DNS
queries for every message already. Generating 1 more is in the noise
in the short term, and as shown above goes away in the long term.
Not only is this a case where doing the right thing is good for SPF, the
SPF example of let's just go with TXT because using a new RRtype is
hard has spread like wildfire, especially in the mail authentication
world (DKIM, DMARC, etc.). The slippery slope has been well-greased at
this point, and it would be nice to move things back in the right
direction (see 5507 for example).
To be fair, there was one other objection raised, which is that DNS
provisioning systems haven't caught up with the need for new RRtypes. So
some can't go to their registrar's/web hoster's/etc. web interface and
enter a proper SPF record. That's a problem, sure. But it's a problem
that has to be solved, assuming we're actually going to take the advice
in 5507 seriously. Personally I'm not willing to allow all progress
forward in DNS to be stymied by those unwilling to make an investment in
their own infrastructure.
In case Dave is still wondering what all the fuss is about, and because
the folks in spfbis seem completely unwilling to deal with this issue in
the group, consider this my first draft of an IETF last call objection
to the fact that 4408bis wants to deprecate use of the SPF RRtype.
Doug
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On Wednesday, May 01, 2013 07:54:46 AM Mark Andrews wrote: In message 51802793.3010...@dcrocker.net, Dave Crocker writes: On 4/30/2013 12:54 PM, David Conrad wrote: On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote: What is the IETF-approved timeframe in which the market is allowed to a ccept/reject a particular technology? I've no idea what the lower limit is or should be, but I'm quite sure that 7 years exceeds it by a very comfortable margin. By that logic we should abandon IPv6, DNSSEC, EDNS0, etc. Gosh, David. I guess you win. When just about none of the documentation mentions the SPF record type nor has examples with both SPF and TXT records it isn't the market choosing. You can't choose of you really havn't been informed. I've run what I believe to be the most popular online SPF record validator since 2005. You'll find it frequently linked to by other parties: http://kitterman.com/spf/validate.html The published SPF record validation part of the tool checks both for records of type TXT and of type SPF and mentions the absence of the type SPF record. It has done this since I first published the validator (in 2005 I believe, it may have been 2006). So it has been both supported and mentioned. The only real documentation, RFC 4408, mentions it effectively enough that some people were fooled into believing that publishing type SPF only would be a good idea, fortunately only a few were confused by the official documentation. Scott K
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On Wednesday, May 01, 2013 11:16:48 AM Mark Andrews wrote: 3. Update the software to query SPF first (Note, Perl's NET::SPF, used by SpamAssassin, already made this change). Actually it's Mail::SPF and as we already discussed on the spfbis list this design choice caused operational problems and in some cases applications that use Mail::SPF have disabled type SPF queries as a result. One perl module designer being overly theoretically correct doesn't really add much to your overly theoretical argument. So far, compared to the discussion we had in the working group at the time, there isn't any new information to evaluate. Scott K
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
On Tue, Apr 30, 2013 at 12:52 PM, David Conrad d...@virtualized.org wrote: SPF using TXT and hence, SPFBIS forces the uniquification of the DNS response into the application instead of in the DNS library. Given the ordering of individual TXT RRs within an RRset is not guaranteed, I suspect the chances that every application is going to do that parsing correctly is relatively low (btw, the example in 3.3 in spfbis-14 is a bit misleading: assuming second string is in a separate TXT RR (which is implied), the concatenation might be second stringv=spf1 . first). The more interesting bit is if/when another protocol uses TXT at the same ownername. Yes, I understand all of that, and I've written code to deal with it. It's not rocket science. The RR has been allocated and it is supported in most DNS servers and resolver libraries in one form or another. Provisioning systems take much longer, but that isn't surprising and shouldn't be an argument to deprecate (if it is, we might as well close the RRtype registry for new entries). We're not only talking about provisioning systems here. We're also talking about interference with queries and replies at the DNS protocol level. The survey work done for RFC6686 showed that something on the order of thousands of domains in the sample set suffered from this. It is a very real issue for a deployed protocol. In the past, the IETF used to make decisions based on long-term technical/architectural correctness, even in the face of pragmatic complications (e.g., the choice to mandate strong crypto despite real world challenges some companies faced in exporting that crypto in products). In this particular case, there seems to be an argument to explicitly disallow the long-term technically/architecturally correct approach because some folks choose not to add an RR to their zone files or support that RR in their provisioning systems. As I said in DNSEXT, this seems like the wrong approach to me. All things being equal, I would agree with you. And if SPF were starting anew today, I suspect I might have a different opinion. The question, then, is the weight of the mitigating circumstances, which obviously the two communities evaluate quite differently. -MSK
Call for Technical Plenary Topics
The plenary topic for IETF 86, The End of POTS, was proposed by an IETF participant. That plenary topic was well received. As the IAB prepares for IETF 87, we want to reach out to the IETF community for technical plenary topics. Please send suggestions to iab at iab.org. The IAB is interested in hearing suggestions that could be presented by invited speakers, panels, or lightning talks. In other words, please do not let the format of past plenary presentations narrow your suggestions. Thank you, Russ Housley IAB Chair
Appointment of Deborah Brungard as new IETF Liaison Manager to the ITU-T for MPLS
The IAB has just notified the ITU-T that Deborah Brungard will be the new IETF Liaison Manager to the ITU-T for MPLS. Deborah was appointed following an open call for volunteers (see email from Scott Mansfield to the IETF list on Fri 3/29/2013 4:32 PM EDT). Please congratulate Deborah when you see her. Please thank Scott Mansfield for his past service in this role. Scott is now the overall liaison manager to ITU-T, and as such I am confident that he will provide valuable support for Deborah. Thanks, Russ From: IAB Chair iab-ch...@iab.org Date: April 30, 2013 1:35:53 PM EDT To: tsbs...@itu.int, ITU-T TSAG tsbt...@itu.int Cc: ITU TSBDir tsb...@itu.int, IAB i...@iab.org, IESG i...@ietf.org, IETF Liaison Statements stateme...@ietf.org Subject: Appointment of Deborah Brungard as new IETF Liaison Manager to the ITU-T for MPLS The IAB would like to bring to the ITU-T's attention the appointment of Ms Deborah Brungard as the new IETF Liaison Manager to the ITU-T for MPLS. The IETF-ITU-T MPLS liaison role helps facilitate communication between the IETF and the ITU-T on matters of MPLS. The MPLS liaison manager is responsible for ensuring the liaisons from the IETF on MPLS are routed to the correct study group(s) in the ITU-T and any incoming liaison from the ITU-T on MPLS is communicated to the proper working groups, usually MPLS, CCAMP, and PWE3 working groups. Deborah Brungard has been with ATT for more than 28 years with experience in network and service management. She is a Lead Member of Technical Staff in ATT's Network Technologies Unit. She is IETF Routing Area's CCAMP Co-Chair, she has co-chaired CCAMP for more than 6 years. CCAMP (Common Control and Measurement Plane) is responsible for GMPLS and works cooperatively with MPLS, L2VPN, PWE3, OSPF, PCE, IDR, and ISIS. She is also the Routing Area Directorate Coordinator and Routing Area Secretary. Deborah has actively contributed in SG15 for more than 15 years, including as an Editor (in the early 2000's). She is very familiar with the ITU-T process, she was Chair of ANSI (American National Standards) T1X1.5 (Optical Standards) for several years in the early 2000's. For the IAB, Russ Housley IAB Chair
RFC 6930 on RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
A new Request for Comments is now available in online RFC libraries. RFC 6930 Title: RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Author: D. Guo, S. Jiang, Ed., R. Despres, R. Maglione Status: Standards Track Stream: IETF Date: April 2013 Mailbox:guo...@huawei.com, jiangsh...@huawei.com, despres.r...@laposte.net, rob...@cisco.com Pages: 12 Characters: 23573 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-6rd-radius-attrib-11.txt URL:http://www.rfc-editor.org/rfc/rfc6930.txt The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. This document is a product of the Softwires 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 6929 on Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
A new Request for Comments is now available in online RFC libraries. RFC 6929 Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions Author: A. DeKok, A. Lior Status: Standards Track Stream: IETF Date: April 2013 Mailbox:al...@networkradius.com, avi.i...@lior.org Pages: 68 Characters: 133099 Updates:RFC 2865, RFC 3575, RFC 6158 I-D Tag:draft-ietf-radext-radius-extensions-13.txt URL:http://www.rfc-editor.org/rfc/rfc6929.txt The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. 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 6930 on RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
A new Request for Comments is now available in online RFC libraries. RFC 6930 Title: RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Author: D. Guo, S. Jiang, Ed., R. Despres, R. Maglione Status: Standards Track Stream: IETF Date: April 2013 Mailbox:guo...@huawei.com, jiangsh...@huawei.com, despres.r...@laposte.net, rob...@cisco.com Pages: 12 Characters: 23573 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-softwire-6rd-radius-attrib-11.txt URL:http://www.rfc-editor.org/rfc/rfc6930.txt The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. This document is a product of the Softwires 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 6935 on IPv6 and UDP Checksums for Tunneled Packets
A new Request for Comments is now available in online RFC libraries. RFC 6935 Title: IPv6 and UDP Checksums for Tunneled Packets Author: M. Eubanks, P. Chimento, M. Westerlund Status: Standards Track Stream: IETF Date: April 2013 Mailbox:marshall.euba...@gmail.com, philip.chime...@jhuapl.edu, magnus.westerl...@ericsson.com Pages: 12 Characters: 29055 Updates:RFC2460 I-D Tag:draft-ietf-6man-udpchecksums-08.txt URL:http://www.rfc-editor.org/rfc/rfc6935.txt This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the inner packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method. This document is a product of the IPv6 Maintenance 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 6936 on Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
A new Request for Comments is now available in online RFC libraries. RFC 6936 Title: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums Author: G. Fairhurst, M. Westerlund Status: Standards Track Stream: IETF Date: April 2013 Mailbox:go...@erg.abdn.ac.uk, magnus.westerl...@ericsson.com Pages: 40 Characters: 99557 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-6man-udpzero-12.txt URL:http://www.rfc-editor.org/rfc/rfc6936.txt This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6. This document is a product of the IPv6 Maintenance 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 6941 on MPLS Transport Profile (MPLS-TP) Security Framework
A new Request for Comments is now available in online RFC libraries. RFC 6941 Title: MPLS Transport Profile (MPLS-TP) Security Framework Author: L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed. Status: Informational Stream: IETF Date: April 2013 Mailbox:luf...@cisco.com, b...@niven-jenkins.co.uk, scott.mansfi...@ericsson.com, r...@acm.org Pages: 15 Characters: 27119 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-tp-security-framework-09.txt URL:http://www.rfc-editor.org/rfc/rfc6941.txt This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 (Security Framework for MPLS and GMPLS Networks) by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network. This document is a product of the Multiprotocol Label Switching 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
RFC 6944 on Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
A new Request for Comments is now available in online RFC libraries. RFC 6944 Title: Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status Author: S. Rose Status: Standards Track Stream: IETF Date: April 2013 Mailbox:scottr.n...@gmail.com Pages: 7 Characters: 13876 Updates:RFC 2536, RFC 2539, RFC 3110, RFC 4034, RFC 4398, RFC 5155, RFC 5702, RFC 5933 I-D Tag:draft-ietf-dnsext-dnssec-algo-imp-status-04.txt URL:http://www.rfc-editor.org/rfc/rfc6944.txt The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. This document is a product of the DNS 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
