Re: Content-free Last Call comments
On 6/12/13 9:42 PM, Ted Lemon wrote: On Jun 12, 2013, at 3:31 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I think these messages are useless, not harmful. But perhaps I have more confidence in the inherent skepticism of your average IETF participant than Pete does... FWIW, until I read Pete's document on consensus, I thought that +1 statements were part of the consensus process. This was not a strongly held opinion—it was just my understanding of how consensus operated, from having watched other working group chairs run their working groups. I think the point Pete is making is very important, because the consensus process Pete describes is more in keeping with how I think the IETF ought to operate than the process in which +1 counts for something. +1 / -1 are conventions that crept in from other standards bodies, they don't have any particular place or meaning here, apart from what you can literally interpret them as e.g. the equivalent of hand raising in agreement or disagreement. (BTW, in case it wasn't obvious, I've been engaging in this discussion with my AD and working group chair experience in the back of my mind, but my AD hat off.)
Re: Renaming RFC
- Original Message - From: l.w...@surrey.ac.uk To: ietf@ietf.org Sent: Wednesday, June 12, 2013 10:55 PM Subject: Renaming RFC RFC should be renamed to Resulted From Comments. It's now the endpoint of the process; Request For Comments dated from when it was the start. tp Fundamentally disagree. Some SDOs produce standards as tablets of stone, and the world at large is not even allowed to read them. The IETF says this is the best we can do, can you help us make it better, by making a request for comments. For me, this is the reason why the IETF succeeds, because it looks to engage the whole world, to do yet better. Tom Petch /tp (Though RFCs through workgroups are arguably Resulted from Collaboration/Consensus/Chairing). If you're going to alter the process in any way, start here. Lloyd Wood http://sat-net.com/L.Wood/
ipv6hackers meeting in Berlin (July 28th, 2013)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, - From a couple of years now, we have had a mailing-list devoted to IPv6 hacking (i.e., testing, tools, low-level stuff, etc.). The mailing-list (charter, subscription options, etc.) is available at: http://lists.si6networks.com/listinfo/ipv6hackers/. We're planning to have our first in-person meeting on July 28th, 2013, in Berlin (most likely in the afternoon, between lunch and the IETF welcome reception). The venue would be either the IETF venue (InterContinental Berlin), or some nearby hotel/room (to be confirmed soon). We're planning to have some presentations (which MUST be accompanied with code :-) ), and might also have an IPv6 mini-hackathon (i.e., work on code, test implementations, try stuff). In order to plan for the meeting, we'd need to have some indication of how many people would attend, whether they would have stuff to present, etc. So I've set up a very short on-line survey to help us plan for the meeting. If you're interested, please take 5 minutes to complete the survey at: https://www.surveymonkey.com/s/FFL386K Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRuaZpAAoJEK4lDVUdTnSSkKQQAIWh/Mq05UuWxkgtExF4M3g4 +uHMsw4+RH1lWUn3Ti8RhVLCJuDVJZbhgOGDC8Z7+sHj5NxcQMWEjTAuOjiBkRXD LG3U9DNGAkk5NxHXHqIRRa1o01PnN/+kSMlly+n+BnSvfMMYTaQ/raVP16wV/HoH PMwt683Q2HHaTJKzb5iALYySToqPorgBTAA8Hd2Rz36U5+4WXra0shzAnNiaz+fy aIstttyGzUzgara/8Hkbl07U2fYE+/qX6DRxjiXrFBpqjcXUuC4lBZpssp6rCNKG Z1rGgMG5paLkJ229Mk8HY0c0dcBiNniksL4HcMjqpbvFjks0lIDhGlL7dvq1qO0e W+1n8Z7VPkCWyX+KDz8vZt1/aP3f6DFa8lPomnw2KOL41a/ClR5pdib7nlsZFexE 1uX10PfpYf7z1kL044VCadHZnlLjACOLHk1xSqdYH9fRGOb3kuKJD0EdoHtHSr1q TRpgCtArV9fk7O1ducXNbVfHK/B7+xCM5uzXOzpbYKPJ62OguL+hs5OnVbqylzhV lPBW4QfVHoDPL8/OOYKDLGZcjxOmDiXGpmEH+5RqrF5K4KZqVwBahvS44ZetEYuO WEWQZFtJOx/9DeTIcCxcUAsIpBpIEVJtRmtLF3aLyLUfMxbKuDehpzdC6n3P5hwV mpg+egMOpHuoQx+DjhWJ =KV2V -END PGP SIGNATURE-
Re: Renaming RFC
Cf. http://tools.ietf.org/html/rfc5513 On Thu, Jun 13, 2013 at 5:30 AM, t.p. daedu...@btconnect.com wrote: - Original Message - From: l.w...@surrey.ac.uk To: ietf@ietf.org Sent: Wednesday, June 12, 2013 10:55 PM Subject: Renaming RFC RFC should be renamed to Resulted From Comments. It's now the endpoint of the process; Request For Comments dated from when it was the start. tp Fundamentally disagree. Some SDOs produce standards as tablets of stone, and the world at large is not even allowed to read them. The IETF says this is the best we can do, can you help us make it better, by making a request for comments. For me, this is the reason why the IETF succeeds, because it looks to engage the whole world, to do yet better. Tom Petch /tp (Though RFCs through workgroups are arguably Resulted from Collaboration/Consensus/Chairing). If you're going to alter the process in any way, start here. Lloyd Wood http://sat-net.com/L.Wood/
Re: Content-free Last Call comments
Without agreeing with or disagreeing with Pete, I'll point out that Pete was talking about IETF last call. It's perfectly reasonable for a WG participant who has been actively involved to say, This one is ready. Ship it, and Pete isn't saying otherwise. In that case there is context that helps. Barry On Wednesday, June 12, 2013, Randy Presuhn wrote: Hi - From: Ted Lemon ted.le...@nominum.com javascript:; Sent: Jun 12, 2013 12:42 PM To: Peter Saint-Andre stpe...@stpeter.im javascript:; Cc: ned+i...@mauve.mrochek.com javascript:; ned+i...@mauve.mrochek.com javascript:;, Alexey Melnikov alexey.melni...@isode.com javascript:;, Pete Resnick presn...@qti.qualcomm.com javascript:;, ietf@ietf.org javascript:;Discussion ietf@ietf.org javascript:; Subject: Re: Content-free Last Call comments On Jun 12, 2013, at 3:31 PM, Peter Saint-Andre stpe...@stpeter.imjavascript:; wrote: I think these messages are useless, not harmful. But perhaps I have more confidence in the inherent skepticism of your average IETF participant than Pete does... FWIW, until I read Pete's document on consensus, I thought that +1 statements were part of the consensus process. This was not a strongly held opinion—it was just my understanding of how consensus operated, from having watched other working group chairs run their working groups. I think the point Pete is making is very important, because the consensus process Pete describes is more in keeping with how I think the IETF ought to operate than the process in which +1 counts for something. ... As a former WG chair who's had to deal with some very rough consensus calls... Not counting a +1 is more consistent with a classical definition of consensus. But, particularly at a WG level (less so, perhaps, at the IETF level) +1 is very helpful in determining whether the previously mentioned Abilene Paradox should be of concern. Randy
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
I am told that draft has been revved again in response to discussion on the list. http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05 Please direct your attention to the security considerations section. If it turns out that informational documentation of the two RR-Type assignments remains controversial, I will likely withdraw my sponsorship of this draft. Thanks joel On 5/27/13 5:40 PM, joel jaeggli wrote: On 5/20/13 6:44 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt as Proposed Standard I would direct the attention of the commentors to draft 04 http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-04.txt Which addresses concerns expressed in IETF last call over the intended status. It also incorporates edits proposed by John Klensin in his review. Notes: from the author: - changed intended status to informational - incorporation of John's suggestions in the Terminology section, to indicate that we're using 2119 keywords even though this is not a standards track document - added a couple of sentences to the security considerations sections to underscore the fact that this document specifies optional mechanisms that people might well not use if privacy considerations dictate otherwise The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended Unique Identifiers (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g. ethernet. This document defines two new DNS resource record types, EUI48 and EUI64, for encoding ethernet addresses in the DNS. The file can be obtained via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
I am told that draft has been revved again in response to discussion on the list. http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05 Please direct your attention to the security considerations section. If it turns out that informational documentation of the two RR-Type assignments remains controversial, I will likely withdraw my sponsorship of this draft. the addition of This document recommends that EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. alleviates my worst fears. though i wish it was a MUST NOT, i will not insist. thanks joe and joel. randy
Re: Renaming RFC
I think this suggestion should be discussed on rfc-interest, not this mail list. Russ On Jun 12, 2013, at 5:55 PM, l.w...@surrey.ac.uk l.w...@surrey.ac.uk wrote: RFC should be renamed to Resulted From Comments. It's now the endpoint of the process; Request For Comments dated from when it was the start. (Though RFCs through workgroups are arguably Resulted from Collaboration/Consensus/Chairing). If you're going to alter the process in any way, start here. Lloyd Wood http://sat-net.com/L.Wood/
Re: [Gen-art] Gen-ART review of draft-eastlake-rfc5342bis-03
I'm concerned about readers who aren't as cognizant of and comfortable/familiar with the relationships among OUIs and the identifiers based on them as people like you and me. Thanks your review, David. The Gen-ART reviews are important for me in helping decide if the documents may have issues where I need to dig in deeper. In this case I agree with the issue you raise and think it is a mistake that should be corrected. I see that Barry has already raised a discuss about that, however. I am balloting a No-Objection based on your review. Jari
Weekly posting summary for ietf@ietf.org
Total of 158 messages in the last 7 days. script run at: Fri Jun 14 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 10.13% | 16 | 9.82% | 124800 | ted.le...@nominum.com 5.06% |8 | 6.98% |88757 | d...@cridland.net 4.43% |7 | 4.80% |61022 | presn...@qti.qualcomm.com 3.80% |6 | 3.80% |48351 | s...@resistor.net 3.80% |6 | 3.54% |45049 | l.w...@surrey.ac.uk 3.16% |5 | 4.16% |52840 | abdussalambar...@gmail.com 3.80% |6 | 3.04% |38633 | d...@dcrocker.net 3.16% |5 | 2.73% |34740 | brian.e.carpen...@gmail.com 3.16% |5 | 2.56% |32572 | melinda.sh...@gmail.com 3.16% |5 | 2.00% |25369 | ra...@psg.com 2.53% |4 | 2.37% |30074 | nar...@us.ibm.com 1.90% |3 | 2.47% |31426 | magnus.westerl...@ericsson.com 2.53% |4 | 1.77% |22553 | d...@xpasc.com 1.90% |3 | 2.14% |27243 | a...@yumaworks.com 1.90% |3 | 1.70% |21617 | joe...@bogus.com 1.90% |3 | 1.61% |20461 | stpe...@stpeter.im 1.27% |2 | 1.68% |21373 | elw...@folly.org.uk 1.27% |2 | 1.62% |20640 | droma...@avaya.com 1.27% |2 | 1.62% |20584 | david.bl...@emc.com 1.27% |2 | 1.50% |19051 | t...@ecs.soton.ac.uk 1.27% |2 | 1.43% |18119 | d3e...@gmail.com 1.27% |2 | 1.34% |16981 | stephen.farr...@cs.tcd.ie 1.27% |2 | 1.26% |15973 | s...@harvard.edu 1.27% |2 | 1.20% |15292 | turn...@ieca.com 0.63% |1 | 1.80% |22839 | jdr...@juniper.net 1.27% |2 | 1.15% |14594 | ulr...@herberg.name 1.27% |2 | 1.11% |14169 | bob.hin...@gmail.com 1.27% |2 | 1.11% |14096 | rpellet...@isoc.org 1.27% |2 | 1.10% |14014 | john-i...@jck.com 1.27% |2 | 1.09% |13798 | jari.ar...@piuha.net 1.27% |2 | 1.06% |13454 | mcr+i...@sandelman.ca 1.27% |2 | 1.00% |12670 | mansa...@besserwisser.org 0.63% |1 | 1.62% |20647 | yi.ji...@gmail.com 1.27% |2 | 0.99% |12579 | do...@dougbarton.us 1.27% |2 | 0.96% |12163 | hous...@vigilsec.com 0.63% |1 | 1.27% |16099 | l...@netapp.com 0.63% |1 | 0.98% |12438 | ted.i...@gmail.com 0.63% |1 | 0.86% |10985 | barryle...@computer.org 0.63% |1 | 0.81% |10259 | doug.mtv...@gmail.com 0.63% |1 | 0.80% |10208 | co...@isoc.org 0.63% |1 | 0.79% |10055 | war...@kumari.net 0.63% |1 | 0.76% | 9637 | mthor...@adobe.com 0.63% |1 | 0.73% | 9336 | og...@earthlink.net 0.63% |1 | 0.67% | 8536 | r...@ipv.sx 0.63% |1 | 0.67% | 8463 | m...@mnot.net 0.63% |1 | 0.59% | 7508 | iab-ch...@iab.org 0.63% |1 | 0.59% | 7458 | martin.stiemerl...@neclab.eu 0.63% |1 | 0.58% | 7344 | carlosm3...@gmail.com 0.63% |1 | 0.56% | 7178 | glenz...@gmail.com 0.63% |1 | 0.56% | 7122 | m...@blackops.org 0.63% |1 | 0.55% | 6963 | ma...@isc.org 0.63% |1 | 0.53% | 6792 | daedu...@btconnect.com 0.63% |1 | 0.52% | 6659 | alexey.melni...@isode.com 0.63% |1 | 0.52% | 6606 | l...@cisco.com 0.63% |1 | 0.52% | 6584 | randy_pres...@mindspring.com 0.63% |1 | 0.51% | 6541 | arturo.ser...@gmail.com 0.63% |1 | 0.51% | 6495 | fg...@si6networks.com 0.63% |1 | 0.50% | 6378 | jul...@braga.eti.br 0.63% |1 | 0.48% | 6084 | pe...@akayla.com 0.63% |1 | 0.48% | 6076 | jo...@taugh.com 0.63% |1 | 0.48% | 6055 | stbry...@cisco.com 0.63% |1 | 0.47% | 5965 | elw...@dial.pipex.com 0.63% |1 | 0.47% | 5916 | adr...@olddog.co.uk 0.63% |1 | 0.46% | 5880 | amor...@amsl.com 0.63% |1 | 0.46% | 5847 | ned+i...@mauve.mrochek.com 0.63% |1 | 0.43% | 5509 | c...@tzi.org 0.63% |1 | 0.42% | 5331 | swm...@swm.pp.se 0.63% |1 | 0.36% | 4587 | j...@mercury.lcs.mit.edu +--++--+ 100.00% | 158 |100.00% | 1271437 | Total
Last Call: draft-ietf-appsawg-rfc5451bis-07.txt (Message Header Field for Indicating Message Authentication Status) to Internet Standard
The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Message Header Field for Indicating Message Authentication Status' draft-ietf-appsawg-rfc5451bis-07.txt as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/ballot/ Reviewers should particularly note the downref information in Section 7.1 of the document. No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-manet-rfc6622-bis-02.txt (Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)) to Proposed Standard
The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)' draft-ietf-manet-rfc6622-bis-02.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document revises, extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt (Extensions to VPLS PE model for Provider Backbone Bridging) to Informational RFC
The IESG has received a request from the Layer 2 Virtual Private Networks WG (l2vpn) to consider the following document: - 'Extensions to VPLS PE model for Provider Backbone Bridging' draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running RSTP or MSTP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-pbb-vpls-pe-model/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-pbb-vpls-pe-model/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1498/
