Re: The RFC xx99 Series
Or how about reserving RFC 3399 for use as an example RFC number... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Oct 8, 2013 at 2:32 PM, Eric Gray eric.g...@ericsson.com wrote: Maybe we should reserve RFC 3399 for an April 1st RFC? -- E -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of RFC Series Editor Sent: Tuesday, October 08, 2013 1:51 PM To: IETF Announcement List Cc: r...@iab.org Subject: The RFC xx99 Series Greetings, The RFC Editor is proposing to retire the practice of publishing RFCs xx99, the Request for Comments Summary for RFC Numbers xx00-xx99. In December 1991, RFC 1099 was the first Request for Comments Summary RFC published. It provides a list of document titles, authors, date of publication, and abstracts for each of the RFCs published in the range 1000 - 1099. Since that time, through the time that RFC 3299 was published, a new summary RFC was published every 100 RFCs, and RFC numbers ending with 99 were reserved for these summary documents. RFC 3399 was never published (for various reasons), though RFCs 3499 and 3599 were. RFC 3599 was the last of these summary documents to be published in December 2003. These snapshots are no longer needed because up-to-date data is available online. RFC abstracts are available using the RFC search engine (http://www.rfc-editor.org/search/rfc_search.php) and they are included in rfc-index.xml. RFCs xx99 summaries were never requested by the Internet Community and are not currently filling a need; therefore, the RFC Editor is retiring the publication of the RFC summary documents. RFC numbers typically reserved for these documents (i.e., numbers ending with 99) may be assigned to future RFCs. If there are any concerns about this course of action, please comment by October 18, 2013, on the rfc-inter...@rfc-editor.org mailing list. Thank you, Heather Flanagan, RSE
Re: making our meetings more worth the time/expense (was: Re: setting a goal for an inclusive IETF)
The most valuable part of IETF meeting is and has always been the hall conversations and side meetings Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Jul 30, 2013 at 12:10 PM, Michael Richardson mcr+i...@sandelman.ca wrote: Keith Moore mo...@network-heretics.com wrote: But earlier today I realized that the problem isn't just the cost of attending meetings - it's the value that we get in return for those meetings. I've been taking notes about how ineffectively we use our meeting time. Most of what I've observed won't surprise anybody, but here's a summary: Thanks for this. Rooms are set up not to facilitate discussion, but to discourage it. The lights are dim, the chairs are facing forward rather than other participants, the projector screen (not the person facilitating a discussion, even if someone is trying to facilitate a discussion) is the center of attention. The chairs are set so close together and with so few aisles that it's hard for most of the attendees to get to the mics. The microphone discipline which was intended to facilitate remote participation ends up making discussion more difficult for everybody who has paid to be on site. I think that these physical things are something that we can do some experiments about. Well, please excuse my candor, but f*ck habit. We can't be effective engineers if we let bad habits continue to dictate how we work. I agree. For 80% of most WG meetings, the lights should be bright, the participants should face each other. If there's a person facilitating the discussion that person should be the center of attention.If we're going to use microphones, the rooms should be set up to allow everyone in the room to have easy access to them. We should have several microphones, again facing each other, so that several people can have a conversation without everyone having to queue up. Can we please try this in Vancouver? This would work especially well for BOFs. Maybe we can start there. Chairs will need training as *facilitators* And maybe, in addition, we need to provide better places for people to hang out and work while trying to get an opportunity to interact with specific people. The terminal rooms are generally placed in out-of-the-way corners, but the most effective places to interact with people are in the hallways. I agree. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
Re: Gen-ART review of draft-ietf-trill-directory-framework-05
Hi David,
Thanks for the review. See responses below.
On Wed, Jul 17, 2013 at 7:54 PM, Black, David david.bl...@emc.com wrote:
Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013
Summary:
This draft is on the right track but has open issues, described in the review.
This draft describes a framework for using directory servers to provide
address mappings (address - destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.
The draft's generally well written and clear. I found a couple of minor
issues.
Thanks.
Major issues: None.
Minor issues:
[1] The last bullet in Section 3.1 says:
- In an environment where VMs migrate, there is a higher chance
of cached information becoming invalid, causing traffic to be
black-holed by the ingress RBridge, that is, persistently sent
to the wrong egress RBridge. If VMs do not flood gratuitous
ARP/ND or VDP [802.1Qbg] messages upon arriving at new
locations, the ingress nodes might not have MAC entries for the
MAC of the newly arrived VMs, causing unknown address flooding.
This is incorrect in multiple ways and should just be removed:
OK.
- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded. The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.
[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:
[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]
- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
none of which appear in that structure.
We'll try to clean that up.
Nits/editorial comments:
Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive. This should be added, as it is
present for the other three items .
I suggest combining point 1 with the material just before the table
and re-numbering points 2-4 to be 1-3.
Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network. Also, please define or explain virtual node.
OK on the first two points. On virtual node, that is only used in
the definition of station which is different from the definition of
end station. However, looking through the document, there was only
one instance of station without end before it and that instance
was talking about end stations. So I propose to remove the definition
of station and to insert end before the one occurrence of
station in the body of the document not already preceded by end.
Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.
OK.
Section 4 - remove (distributed model) from first paragraph,
as it's not explained.
OK.
Section 5.3, top of p.13:
therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.
or the like is vague. I suggest or becomes invalid for other
reasons.
OK.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
idnits 2.12.17 didn't find any nits that need attention.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.comMobile: +1 (978) 394-7754
Re: [trill] Last Call: draft-ietf-trill-directory-framework-05.txt (TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework) to Informational RFC
Based on the approval of draft-ietf-trill-fine-labeling, the directory framework document should mention TRILL Fine Grained Labels. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Jul 4, 2013 at 5:45 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework' draft-ietf-trill-directory-framework-05.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 ietf@ietf.org mailing lists by 2013-07-18. 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 Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame whose destination address (MACVLAN) that switch does not know, the data frame is flooded within the frame's VLAN across the TRILL campus. This document describes the framework for using directory services to assist edge RBridges in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND, thus improving TRILL network scalability. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-directory-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-directory-framework/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2007/ ___ trill mailing list tr...@ietf.org https://www.ietf.org/mailman/listinfo/trill
Re: Regarding call Chinese names
First/Last = bad/ambiguous Family (or maybe inherited) / Given = good Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Jul 11, 2013 at 10:22 AM, Cyrus Daboo cy...@daboo.name wrote: Hi Simon, --On July 11, 2013 at 3:58:10 PM +0200 Simon Perreault simon.perrea...@viagenie.ca wrote: We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Very cool! Thanks for writing this! I have a question: I think I've seen Chinese names written in both orders. That is, sometimes Hui Deng will be written Deng Hui. Am I right? Does this happen often? What is the most common order? Is there a way to guess what order a name is written in? Sometimes it's not easy for non-Sinophones to know which part is the given name and which part is the family name. Well that actually brings up a good technical point! In iCalendar (RFC5545) we have properties to represent the organizer and attendee of meetings. A parameter (attribute) of those properties is CN - defined to be the common name of the corresponding calendar user. Obviously that is a single string and typically the concatenation of first name/last name. But that of course is a very Western approach. I have had several people request that iCalendar instead define new parameters for FIRST-NAME and LAST-NAME. That then gives clients the option of re-ordering those for display purposes based on user locales and preferences. So, from a technical standpoint, it seems better to always represent user names using components (last, first, middle)? vCard does have an N property where individual components of a name can be broken out. -- Cyrus Daboo
Re: IETF registration fee?
The IETF values cross area interaction at IETF meeting and attendees have always been encouraged to attend for the week. Allowing one day passes is a recent phenomenon to which some people, including myself, are on balance opposed. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Wed, Jul 10, 2013 at 12:01 PM, Paul Aitken pait...@cisco.com wrote: Can you help me understand why the One Day Pass rate ($350) is so high compared with the full week rate ($650 / $800)? Registering for two days could cost more than a week! Surely the day rate should be a little more than (week/5), eg about $175 - $200, to encourage those who only want/need to contribute on particular days? Thanks, P.
Re: Final Announcement of Qualified Volunteers
Hi John, Excuse me for replying to just part of your message below: On Tue, Jul 9, 2013 at 9:31 AM, John C Klensin john-i...@jck.com wrote: ... (3) It is probably too late to even discuss it for this year (see below) but it occurs to me that, if one wanted to minimize the odds of organizations trying to game the nomcom selection process, it would be rational to do a two step draw, first randomly selecting two volunteers from any organization offering more than two and then including only those two in the final selection process.On the other hand, that would give you around 81 candidates for the final selection this year. If The current two nomcom member per sponsor limit is really pretty much of an honor system by self declaration. The Nomcom chair has no need to bindingly determine what affiliation every volunteer has. Only as nomcom members are selected does the Nomcom chair have to even think about this. I think that, as a result, there are probably at most a handful of cases where the Nomcom chair has to worry about this at all including ambiguous cases such as someone working for a subsidiary of a company that sponsors someone already selected for noncom or consultations that nominally work for a separate organization but are X% funded for their IETF work by BigCompany for various values of X. Any two step rule as you suggest will move affiliation from a tail end check designed to be sure that the nomcom passes the smell test to the heart of the selection process. I think the result would be a mess. However, if such a system were adopted, its not like an upfront selection to 2 per sponsor is the only alternative to the current unlimited pool from which the noncom is selected. Just to give an example of an alternative rule, since you have to classify all volunteers as to who their sponsor is, you could do initially a select among the V volunteers from sponsor S limited to the square root of V rounded up. That would seem like a more moderate intermediate course. running the final selection against order 140 people rather than order 81 causes the community to believe that it has a better sample, then that option probably would not be appropriate. I am not, however, convinced that we would actually have consensus for minimizing those odds, nor about whether a company's ability to nearly guarantee that at least one of its employees will be on the Nomcom by providing a large fraction of the volunteers violates the provision of Section 4, bullet 16, of RFC 3777 requiring ...unbiased if no one can influence its outcome in favor of a specific outcome. In my opinion, those words, in the context of the previous sentence which speaks of each volunteer being equally likely to be selected, means influence in favor of a particular volunteer or the like. (Although all volunteers are equally likely to be selected, the selections are ordered and after two have been selected with the same affiliate, subsequent selections with the same affiliation are discarded and additional selection(s) made.) ... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com best, john
Re: Final Announcement of Qualified Volunteers
Hi Brian, On Tue, Jul 9, 2013 at 4:40 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: (2) Four companies account for 44.3% of the volunteers. OK, but what would X be in Four companies account for X% of people eligible to volunteer? That said, the not more than two from the same employer rule was written in anticipation of a theoretical problem; it seems I think not. If I recall correctly, there was at least one noncom with three voting members with the same affiliation. While there was no particular evidence that these voting members were acting as other than individuals, the consensus was that it just smelled bad and so the limit of two per primary affiliation was adopted. (Also note that, according to the records, the first two nomcoms had only 7 voting members.) Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com that it was a good idea, but it does allow the following to become true: Four companies account for 67% of the NomCom members. Should we consider changing it to not more than one in view of today's data? Regards Brian
Re: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers
Hi, On Mon, Jul 1, 2013 at 7:40 PM, NomCom Chair 2013 nomcom-chair-2...@ietf.org wrote: Hi, everyone, We are short of our goal of 200 volunteers for the upcoming nomcom. Please do volunteer. Our publicly verifiable random algorithm has fully adequate entropy for a flood of volunteers - more names, more names, more names, more brains --- er, oops, not yet a zombie. The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF. Respond to this challenge and strengthen our statistical significance just by hitting Reply (but not Reply-All, please). The goal of 200 volunteers seems totally arbitrary to me. I understand that there is a wide range of opinions here, but I do not believe that the noncom is intended to be or should be a representative sample from those who just barely qualify as eligible to be volunteers under the current rules. Why is the quality of volunteers ignored in comparison with the quantity? No doubt many will strongly object to my use of quality but by that I mean understanding of the IETF culture and the IETF goal of benefiting the Internet community and a goodly amount of experience with IETF processes. For example, producing RFCs is clearly a large part of the IETF. Let's assume that, under current conditions, using only recent attendance as a qualifying criterion, we can get ~200 eligible volunteers but that adding the additional restriction that volunteers must have been a front page author/editor of an RFC issued within the past X years for some X would reduce the number of eligible volunteers to ~100. While I admit there is some volunteer pool size that would be too small (40? opinions will differ), my opinion is that 100 is more than enough and that such a change, to produce a pool of stronger and better qualified volunteers, would be an improvement. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Oh, first, please do check the official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 23:59 EDT (UTC -4 hours) July 04, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). On July 05, 2013 there will be an announcement of validated volunteers. If you haven't received an acknowledgement message from me to your email (indicating that you are or are not eligible) and you do not see your name in the July 05 list, contact me AS SOON AS POSSIBLE, on or before July 06. Looking forward to adding your name to the hat very soon, Allison Allison Mankin Nomcom Chair 2013-2014
draft-eastlake-trill-rfc6327bis-00 was replaced by draft-ietf-trill-rfc6327bis-00
Hi, Please note that draft-eastlake-trill-rfc6327bis-00 was replaced by draft-ietf-trill-rfc6327bis-00. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com
Re: Part of Improving IETF Electronic Diversity [was: RFC 6234 code]
Hi Hector, On Fri, Jun 28, 2013 at 11:56 AM, Hector Santos hsan...@isdg.net wrote: I believe this is all part of improving the IETF Electronic Diversity picture. Just like we have to deal with greater people personal globalization diversity issues, there is also greater technology and legal diversity issues to deal with. So many tools, so many languages, so many OSes, so many devices and communications API platforms, where are the proposals for better, new IETF Global Commons? Guidelines for technical writing for the new world engineers to use, etc. I think that computational code written in C, pretty much the lowest common denominator, is just fine. I don't think there is any greater diversity now that then was 10 or 20 years ago at that level. In fact, I think there is less. For me, when I saw this RFC, the things crossed my mind: - I have trouble with the licensing statement. The RFC describes public domain technology. It requires passing this thru your lawyer(s) to see if it can used in our commercial product lines. Sorry, the standard simplified BSD license is required for code in RFCs. The authors couldn't change it. But if you are doing a serious commercial product and you don't have a lawyer checking such things anyway, you are a fool. - Far too big to distribute via a RFC. Provide a link to some RFC site. Note, I'm just saying in general. I did not read in detail if the RFC already included links to the official source code. Nonsense. An RFC should be self contained and IO don't see what's too big about this one. The code is in a relatively compact region of the RFC, so you can read the text and skip the code, if you want, without undue effort. - Because it was too big, it requires a stripper/parser, although a good power programmer can quickly macro-clean it up. The RFCSTRIP tool, well, what language is that? I'm not an *nix person. So this adds to the complexity for the Windows shops to get at these hashing functions. Of course, its a piece of cake for a sharp programmer, but even the sharpest knives eventually get dull. This is just nonsense. If you are going to do anything serious with code, you need a source code editor. With that, it is no big deal to extract and test the code. Although I would agree that making the RFCSTRIP tool available over the web, as many other tools are, would be reasonable. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com -- HLS On 6/28/2013 4:53 AM, Dearlove, Christopher (UK) wrote: I'd actually tried the authors, but no reply yet (only a few days). I also tried the RFC Editor thinking they might have e.g. XML from which extraction might have been easier, but also no response yet. And I had found several libraries, but not the RFC code. I can't see any suggestion that the library you indicate includes that code, it also bills itself as a C++ library, which the RFC code is not (and also not what I want, but that's not a subject for this list). But the broader point is that if it's worth the IETF publishing the code as an RFC, it's worth making the code available straightforwardly. For me, a thanks to Tony Hansen, who did the extraction for me. (That makes me feel a little guilty, why should he do my work I could have done?) But the point of posting on this list was to say that the code should be available so that each person wanting that code doesn't have to do that again. Christopher
Re: Gen-ART review of draft-eastlake-rfc5342bis-03
Hi David, On Sun, Jun 9, 2013 at 1:47 PM, Black, David david.bl...@emc.com wrote: The -03 version of this draft resolves all of the concerns raised by the Gen-ART review of the -02 version. Thanks. Unfortunately, a serious typo/thinko snuck into the -03 version (been there, done that, myself). Section 3.2 currently says: 00-42 is a protocol number under the IANA OUI (that is, 00-00-0E-00-42) to be used for documentation purposes. The parenthetical expansion of the protocol number is incorrect. The correct expansion uses -5E- instead of -0E-: My apologies, you are correct. However, I believe that, in context, the typo is pretty obvious. 00-42 is a protocol number under the IANA OUI (that is, 00-00-5E-00-42) to be used for documentation purposes. I strongly suggest submitting a -04 version of this draft to make the necessary single character correction (e.g., as opposed to using a RFC Editor Note for that purpose). I defer entirely to JoelJaeggli, the sponsoring AD. I'd be happy to submit a -04 or it seems to me it could easily be fixed with an RFC Editor Note or at AUTH48 time. (Actually, it seems likely to me that during IESG consideration, some other change will be decided on and this can be fixed at the same time.) Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Thanks, --David -Original Message- From: Black, David Sent: Wednesday, June 05, 2013 6:13 PM To: d3e...@gmail.com; joe.ab...@icann.org; General Area Review Team Cc: Black, David; joe...@bogus.com; ietf@ietf.org Subject: Gen-ART review of draft-eastlake-rfc5342bis-02 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.comMobile: +1 (978) 394-7754
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
Hi SM, On Fri, Jun 7, 2013 at 6:24 AM, SM s...@resistor.net wrote: At 04:07 07-05-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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-04. Exceptionally, comments may be Sorry for the late comments. I'll defer to the authors on what to do about them. In Section 2.1.3: o must be for standards purposes (either for an IETF Standard or other standard related to IETF work), The above is not that clear. I suggest using IETF Review. BTW, the documentation requirement could also be fulfilled with Specification Required. I agree that it is not a precise, perfectly clear, mechanical rule. That is why there is a Expert to make judgements. This part is unchanged from RFC 5342 and actual experience does not indicate any problem. I believe that, since RFC 5342 came out, seven code points have been allocated under these provisions, all for single MAC addresses, and the only request I am aware of that has not yet been submitted is also for a single MAC address. I think it is silly to bother the whole IETF (or even the whole IESG) for the allocation of a single value when over ten million are available. I think it is enough just to bother the Expert. Section 2.3.2.1 mentions changes to RFC 2153. I suggest having an Updates: for that RFC. OK. In Section 3.1: o the assignment must be for standards use (either for an IETF Standard or other standard related to IETF work), IETF Review (see previous comment about that) could be used. See previous response. In Section 4: If different policies from those above are required for such a parameter, a BCP or Standards Track RFC must be adopted updating this BCP and specifying the new policy and parameter. Standards Action could be used for this. I believe the statement is brief, clear, and unambiguous and do not see any reason to change it. In Section 5.1 I suggest using IESG Approval. BTW, IESG Ratification of an Expert Review approval recommendation looks unusual to me. I believe the provisions of Section 5.1 are fine. In the extremely rare cases (perhaps once every five years or so?) where a request would require IESG Ratification, prior review by the Expert would be beneficial so the IESG would have the benefit of the Expert's opinion before they consider the request. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Regards, -sm
Re: Gen-ART review of draft-eastlake-rfc5342bis-02
Hi David, Thanks for this review. See below: On Wed, Jun 5, 2013 at 6:13 PM, Black, David david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Right, I'm working on a response to Pearl. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. OK. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. OK. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. OK. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. I think your suggestions are all good. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.comMobile: +1 (978) 394-7754
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
The first part of Section 2.1 should have a sentence added like An RRTYPE code has been assigned so 48-bit MAC addresses can be stored using the DNS protocol. with an appropriate reference. A similar sentence for 64-bit MAC addresses should be added to the first part of Section 2.2. The lists of Ethertypes in Appendix B should be brought up to date. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, May 7, 2013 at 7:07 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/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
On Mon, May 27, 2013 at 7:54 PM, Randy Bush ra...@psg.com wrote: while i appreciate joe's listening to my other comments on the draft, i still strongly object to publication of this draft as an rfc for the reasons made very clear in the sec cons. please read the summary section of rfc 2804. While the RFC should not be materially misleading, I don't think there is a requirement for Informational RFCs to guarantee any particular level or security or privacy. RFC 2804 is about the security of communications content, not the security of statically stored address information. I'm not denying the applicability of some security considerations, I'm just saying that RFC 2804 doesn't seem to me to be particularly applicable. In any case, the final part of the summary section of RFC 2804 calls for the publication of specifications that might affect security. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com randy
Re: IETF Meeting in South America
On Thu, May 23, 2013 at 4:39 PM, Arturo Servin arturo.ser...@gmail.com wrote: This is very good news. If done, it would show how the IETF is evolving and adapting to this new world that it is own creation the Internet has make us live in. You seem slightly confused. If you look at the original message, it talks about there having been increased attendance at IETF meetings from South and Central America. As far as I know, it has been and is still more or less the policy of the IETF to hold meetings where attendees have been coming from. The purpose of IETF meetings is to contribute to standards development, not outreach or something, which is a goal for other organizations. If few attend from some part of the world, there will be few/no IETF meetings there no matter what the population or amount of network use in that part of the world. I do not see and do not particularly want any evolving in how the IETF decides where to meet. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Regards, as On 5/23/13 3:30 PM, Alia Atlas wrote: Never been to Buenos Aires - but it sounds like a great idea. I know that the search has been on for an acceptable venue in South America for a long while. Alia
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
On Wed, May 22, 2013 at 10:03 PM, Dale R. Worley wor...@ariadne.com wrote: ... Coming into this from the outside, the issues are interesting. I originally thought RRTYPEs are scarce, since all the ones I was aware of are less than 256. But it turns out that RRTYPEs are 16 bit integers, and we've only consumed about 110 of them in ~25 years; we have about 15,000 years' supply of them. So they can be handed out rather generously. There actually is a standard for allocating RRTYPEs, which is RFC 6195 (section 3.1). RRTYPEs are to be handed out rather freely. Obsoleted by RFC 6895 but not too much change. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com
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
Hi John, On Mon, May 20, 2013 at 11:56 AM, John C Klensin john-i...@jck.com wrote: --On Monday, May 20, 2013 07:53 -0700 joel jaeggli joe...@bogus.com wrote: ... This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? the basis for assignment of rr-types is expert review. Whether the draft advances or not the rr-types have been assigned. http://tools.ietf.org/html/rfc6895#section-3.1.1 http://www.iana.org/assignments/dns-parameters/dns-parameters. xml#dns-parameters-3 Joel, I don't know who the current expert is and, for the moment, am glad I don't and don't intend to check. I believe there is broad consensus in the community that having something as significant as an RRTYPE documented in the RFC Series is a good idea. Certainly leaving the reference pointing, long-term, to an I-D would not be a good idea (and would violate several other principles). There has been a long term fight to make RRTYPEs easy to get, a fight in which substantial victory has only recently been achieved (RFC6895). The result of tight control over RRTYPEs is that most new uses just take the path of least resistance and overload the TXT RRTYPE, something which requires no one's permission but, as per RFC 5507, has significant long term disadvantages. One lesson of the Internet has been the benefits of FREEDOM TO INNOVATE. In my opinion, most IETF WGs impose tighter control over code points that necessary most of the time (note most, not all). However, if (i) the expert review consists largely of making sure that the template contains the right information and the ducks are not obviously out of line rather than a design/architectural review with at least meaningful potential for community review of the request, and The guidelines are in RFC 6895 which I recommend you consult. There is no requirement for community review. A primary concern is that the RRTYPE can be safely handled an unknown RRTYPE (or is an ignorable meta RRTYPE). The community has people that will complain about and delay andy new RRTYPE. How is an RRTYPE any more earth-shaking than, say, an AFN number, a range of which are available on a first-come, first-served basis? What are these principles you refer to above that require RFC documentation of RRTPYEs when no documentation whatsoever is required for some AFN numbers? (ii) the response to a design/architectural concern raised during IETF LC is essentially too late, code points already allocated, and (iii) Proposed Standard still does not imply recommended and the alternative to approving the I-D for that category is non-publication, then I would like to understand, as a procedural matter, what the IETF Last Call is about. Certainly it is not for editorial review; that is the RFC Editor's job and there are, IMO, no glaring editorial problems. If the RRTYPEs have been allocated and can't be un-allocated and this is in use, then there is nothing to propose as an individual submission for standardization: an informational document to inform the community about what this is about would be both appropriate and sufficient. Perhaps it should be informational. I believe the author was originally going to submit as an Informational Independent submission. Others, including myself, suggested different paths. Perhaps we were mistaken. The perfect is always the enemy of the good. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Beyond that, your shepherd's report implies that the issue I raised may have been discussed and successfully resolved in DNSEXT. If that is the case, an explanation in the document about the tradeoffs and decision would still be appropriate. Alternatively and especially if there wasn't clear consensus in DNSEXT, if this really is to be processed as a Proposed Standard, then a suggestion during IETF Last Call that the IETF Standard way to represent EUIs in the DNS should be a single RRTYPE with length/type information in the DATA is still in order: the community could reasonably conclude that the single RRTYPE is a better solution, that the single type should be allocated, and that these two types should be deprecated. We have certainly done similar things before with other protocols and parameters that were already in use before standardization was proposed from an individual submission. john p.s. I've tried reading your shepherd writeup now in three different browsers. It appears to be formatted for extremely long (paragraph-length) lines, with no provision for automatic wrapping to fit the page
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
People were already storing MAC addresses in DNS for the reason given in the draft and perhaps others, it is just that they were doing so in a variety of proprietary ways. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, May 20, 2013 at 12:48 PM, SM s...@resistor.net wrote: At 06:44 20-05-2013, 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 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 This draft is about putting MAC addresses in the DNS. The purpose is for IP address tracking by vendors. As the RRTYPE has already been allocated it is useful to document the format. In my humble opinion it is not a good idea to put MAC address in the DNS. There is some text in Section 9 about why it may not be a good idea. In Section 9: These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. The querier already know some other permanent identifier reminds me of security through obscurity. I'll do some selective quoting from another document: Once the MAC-derived suffix mechanism was standardized, it was perceived to be required and therefore became part of compliance suites, which continue to compel implementations to support it many years after the associated vulnerabilities have been identified. A comprehensive privacy threat model was never developed (which seems to be a recurring theme with older protocol development efforts) The write-up mentions: The intended status is standards track with the label of propsed standard. Why is the intended status Proposed Standard? As a comment to Joe, the first line in Appendix A.2 was entertaining. :-) Regards, -sm
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
Hi, On Mon, May 20, 2013 at 9:06 PM, John C Klensin john-i...@jck.com wrote: ... ... The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If you are getting an address to connect with a device on an Ethernet link, you just have to know what the right address size is. After whatever start of frame mark there is, it is just DA-SA and using the wrong size MAC addresses isn't going to work. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. john
Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.
The theory that all April 1 dates RFCs are simply jokes and nothing else is also easily refuted. Consider RFC 3092. It is an April 1st RFC produced through that process and has certainly produced some chuckles. Yet I've lost count of the number of emails I've gotten over the years from non-English speakers thanking me for the RFC and saying it was helpful to them... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, Apr 8, 2013 at 3:21 AM, Måns Nilsson mansa...@besserwisser.org wrote: Subject: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes. Date: Sun, Apr 07, 2013 at 04:58:52PM -0400 Quoting Hector Santos (hsan...@isdg.net): This is one of those DPEP (Diversity Problem Entry Point) arising from globalization, April 1 HRC (Humor Recognition Culture) differences, IETF stalization and the growth of I-D submissions. I suggest there is a direct correlation among these factors with the end goal efficacy of the submission. Fortunately, there is a technical solution for this particular DPEP: if Date is April.1 then id.filename = joke-+id.filename. end if This solution has all the virtues of carpet-bombing. Mission accomplished but cost and collateral damage are improportionally large. To me, both as humour /per se/ and as sorting help when selecting vendors (cf. my message in this thread yesterday), the value almost totally lies in the subtle play with form and the resulting ambigousness. In other words, if we make it possible to determine by simple logic whether a document is a pun or dead serious, it is useless. I am aware that my position as stated above will be possible to interpret as excluding. As parent of a child diagnosed with Aspergers syndrome, I fully well know the potential consequences of failure to interpret social hints. I believe that * transient failure to get a joke not is cause for safing jokes. The failure is part of the process. * the speed with which we unfail and start to appreciate this art form is personal and differs according to our experience, background and intellectual skills but that the initial failure is necessary. There are subtler ways than policy and procedure to nudge people along when they persist in failing. * the Internet idea of loosely cooperating networks REQUIRES autonomous judgement from the people operating the system. Fostering a culture where IETF texts are seen as close to faultless holy scripture does nothing to encourage skepticism and personal responsibility. * enough has been said in this that we already are risking the sweet uncertainity. Accordingly, I'll try to not communicate further on this, and definitely not propose any procedure work. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I am deeply CONCERNED and I want something GOOD for BREAKFAST! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlFib/gACgkQ02/pMZDM1cVp0wCePKf4nLxF85ZBOACv1itL0G8s pDwAoKPsjMy06MZRr2eMHiOegi5vCs/g =UNMB -END PGP SIGNATURE-
Re: It's a personal statement (Re: On the tradition of I-D Acknowledgements sections)
On Mon, Mar 25, 2013 at 12:35 PM, Joel M. Halpern j...@joelhalpern.com wrote: It seems to me that you are setting up by assertion a standard that has never applied to this community. Having said that, if we want to go down this path, then we could do what groups like IEEE do. Remove all authors names, all personal acknowledgements, etc. The work is simply the product of the committee. I would prefer not to go down that path. I don't see how it is possible for the IETF to copy the IEEE policy at the WG level. (And I agree that it would not be desirable to do so.) IEEE standards (at least in IEEE 802) do not have any title page author(s) but do have the complete list of 802... WG voting members in the WG that approved the document, then the complete list of IEEE Sponsor Ballot voters that approved the document, then the complete list of IEEE Standards Association Board members when the Standards Board approved the document. For example, just glancing at IEEE Std. 802.1BR-2012, there is prefatory information with the following sub-intros under the overall heading Participants: At the time this standard was approved, the IEEE 802.1 Working Group had the following voting members: (So, for example, I am listed although I don't believe I submitted a comment on that document.) The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention. and When the IEEE-SA Standards Board approved this standard on 14 May 2012, it had the following membership: The first of these lists specifically distinguishes the WG and task group Officers and the Editor involved in the document. Note that, other than perhaps the listing of the Editor, these lists have nothing to do with who supported or opposed the document or who submitted or drafted text or comments. They are purely formalistic lists based on status, although in practice, most of those who commented or drafted text would be included. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com But if the alternative is copying every name from every person reported to have commented on the draft in the minutes or shown in the archive to have sent an email about the draft into a meaningless acknowledgements section, then the pure committee view would seem more sensible. Yours, Joel On 3/25/2013 8:36 AM, Abdussalam Baryun wrote: Hi Carsten, In general, I agree we don't force authors/owners of documents, as tradition in the world and in all reasonable organisation, we never force any author to be thankful. But don't forget the situation in IETF is different and the documents are different as well. The document is a IETF document (not individual) and the authors are not the only owners of the I-D as in other documents outside IETF (we name them editors because IETF works/documents are shared for its better publication not the authors' publication). The documents were called for volunteers in IETF to participate and review, why the IETF request that if it does not include them. In any I-D it is a personal statement for the IETF not the authors, this is my beleive, otherwise why I should participate/volunteer if i am not dealing with IETF business (don't want to participate in private or public companies business), AB On 3/25/13, Carsten Bormann c...@tzi.org wrote: Further, the IETF should acknowledge that the contents of Acknowledgments sections varies widely between RFCs. Some are fairly complete, some are fairly vague and incomplete, and some are between. Bingo. It is up to the sole discretion of the document authors what they want to list in the Acknowledgements section. Trying to force people to thank other people strikes me as completely misguided. (That said, as a contributor, I have certain expectations of document authors here, but these are *not* actionable in any sense.) As an author, I sometimes have forgotten to include people who made contributions worth a mention, and I would have been spared the shame if the contributor would have alerted me to that at the right occasion. As a contributor, I have never felt the need to pressure an author to include me, though. It does make sense to relay some common sense of what is expected in an Acknowledgements section to new authors. I don't know we do this at the moment. If you feel like you should be listed in the Acknowledgements section of a WG document due to your contribution, and you're not listed in WG Last Call, ask the WG to be included. 'Nuff said. I'd modify this to ask the authors. Ask, as in shouldn't the Acknowledgement section be updated, not demand as in I have an **g right to be in there. The contents of the Acknowledgment section is about as much subject to WG
Re: Mentoring
Possibly attendance at the newcomers meeting would be something that you could do just once but could be deferred to a later meeting you attend if you miss on the first one for any reasons. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Mar 14, 2013 at 9:55 AM, Pat Thaler ptha...@broadcom.com wrote: At my first meeting, I wasn't able to arrive on Sunday. At that point, I was mainly following work in one working group that was meeting mid-week. At later meetings, I wasn't a newcomer any more so I never attended a Newcomer meet and greet. That is probably pretty common. Pat -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Spencer Dawkins Sent: Thursday, March 14, 2013 5:37 AM To: adr...@olddog.co.uk Cc: John C Klensin; IETF-Discussion list; The IESG Subject: Re: Mentoring On 3/14/2013 7:30 AM, Adrian Farrel wrote: Mary, I need to check but... [MB] What I find interesting is that there was 200+ newcomers, but I certainly didn't find that many at the meet and greet. I have to wonder whether this doesn't have to do with the overlap between Sunday tutorials and this event. I think that needs to be fixed. Very right that it would need to be fixed, but I thought that it was avoided explicitly and deliberately. Anyone got a copy of the agenda in front of them? The second slot for tutorials is listed as 1500-1650. The newcomer's gig is listed as 1600-1700. So, conflicting. Maybe we could do a little research on why newcomers don't show at this meeting. Are they tired? Shy? Unaware? Not perceiving the value? I've been supported by an IETF sponsor who has sent a heck of a lot of new attendees to the IETF since 2005. One point that's come up repeatedly is that people show up on Sunday afternoon and evening because the real IETF meeting starts Monday morning. Some of the newcomers are likely still at the airport during the newcomer's meet and greet. Spencer
Re: Nomcom off in the wilderness: Transport AD
Eric, As far as I know, that's completely wrong. The IETF Chair, sometimes known as the AD for the General Area, is selected by the nomcom and confirmed by the IAB just like all other ADs. They are not elected chair of the IESG by the IESG members. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Wed, Mar 6, 2013 at 9:29 AM, Eric Gray eric.g...@ericsson.com wrote: John, I considered this before making my reply, especially in light of a number of recent events with which I am intimately familiar. To become the Chair of the IESG involves a second level of selection that is much more political. You have to be selected - I believe - for the role by your peers on the IESG. This then is a matter for the IESG, more than the NomCom, or the IETF as a whole. This is - I feel sure - one of the things that a NomCom has to consider in picking folks for IESG membership: there needs to be at least one AD on the IESG that is both willing and able to take on this role. But - let's face it - this should be obvious to any reasonably competent NomCom that is having to replace an outgoing Chair. But it is most definitely NOT something that every AD has to be prepared to do... -- Eric -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: Wednesday, March 06, 2013 9:22 AM To: Eric Gray Cc: ietf@ietf.org Subject: RE: Nomcom off in the wilderness: Transport AD Importance: High --On Wednesday, March 06, 2013 14:16 + Eric Gray eric.g...@ericsson.com wrote: ... So far, it has not been any part of the normal duties of an IESG member or AD to hold press conferences, glad-handing with the masses, baby kissing, etc. ... I can't speak to baby kissing but the above statement is true only if you exclude the IETF Chair from IESG member or AD. Perhaps we could change it if we really wanted to, but we should face the fact --and I hope that Nomcoms understand-- that the IETF Chair role has expanded to include a great deal of public representation of the IETF and, indeed, public politics. john
Re: Internet Draft Final Submission Cut-Off Today
As has been true for a few years, the deadline is midnight UTC Monday and not dependent on any particular United States time zone. The Important Dates information and reminder messages all state this. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, Feb 25, 2013 at 7:47 PM, James Polk jmp...@cisco.com wrote: The ID upload tool says the deadline has passed, yet a decade or more the deadline has been 8pm ET/5pm PT. That's 15 minutes from now. What gives? James At 11:05 AM 2/25/2013, IETF Secretariat wrote: This is a reminder that the Internet Draft Final Submission (version -01 and up) cut-off is today, Monday, February 25, 2013. All Final Version (-01 and up) submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 86 can be found at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-dra...@ietf.org.
Re: back by popular demand - a DNS calculator
Let's see, here is the list of RFCs that the RFC Editor believes update RFC 1035: RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535, RFC 2845, RFC 3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936, RFC 5966, RFC 6604, Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Feb 15, 2013 at 7:48 PM, Joe Touch to...@isi.edu wrote: On 2/15/2013 3:17 PM, John C Klensin wrote: --On Friday, February 15, 2013 14:10 -0800 Joe Touch to...@isi.edu wrote: Let's just say that there doesn't appear to be disagreement that the DNS can handle a-z/0-9/'-'. Other values _may or may not_ be permitted or handled opaquely in the lookup, AFAICT. It remains a question AFAICT. Joe, Except for IDNs (or labels starting with xn-- more specifically), for which there are special rules, it appears to me that the spec is _extremely_ clear that a lookup operation that fails to deal with those other values in labels --including even properly-escaped embedded . characters -- is unambiguously non-conforming. Seems clear to me: RFC1035: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. -- If any label were allowed, then why does IDN conversion go so far out of its way to exclude particular strings, e.g., those beginning/ending with '-' and encodes everything 0..7F into a-z/0-9? (I was focused on looking up A records given FQDNs) Joe
Re: The RFC Acknowledgement
I try to include in the Acknowledgements section of any Internet Drafts I edit the names of anyone who comments on the draft if (1) the comment results in a change in the draft and (2) the commenter does not request that they be left out. If you comment on some draft and the draft is changed as a result and you want to be acknowledged and you are not added to the acknowledgements list, you should complain to the editor / author. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Feb 8, 2013 at 10:11 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi folks, I am wondering how author/ietf-editor fill in the acknowledgement section in the RFCs or I-Ds. Does it make sense in IETF, or left for author opinion? I am getting requests from IETF WGs, IESG, and IAB for comments. My question is do you *make acknowledgements* in I-Ds or just *take comments* for I-Ds? IMO we get last call request for comments because RFC production is all about getting volunteering comments from Internet community to make I-Ds better, so does all I-Ds acknowledge (ACK) to any input comment before the last call and after or it is only before last call?, and if it gets submitted to IESG/IAB, and we comment does that have no ACK in I-D? I sometimes feel discouraged to participate in any world work if the process does not involve my existance, just used with ignoring ACK of the reviewers. IMO any comment has value to the authors (e.g. some think only experts' comments are important to ACK) and to IETF, otherwise, we may delete valuable ACKs in IETF, which is not right. Best Regards AB A participant that still did not complete a year working for IETF, but trying to continue :)
Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt
Hi, Thanks for your comments. See below. On Thu, Feb 7, 2013 at 2:25 AM, SM s...@resistor.net wrote: Hi Donald, At 18:48 06-02-2013, Donald Eastlake wrote: I'm not sure exactly what you mean here. The errata does appear in the references as [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc- editor.org I have been told by an Area Director that this it the format that the RFC Editor likes. You can certainly find the Errata starting with that link and by just linking to the main ref-editor.org web page, it does not constrain the other structure of that web site. [Errata191] was a normative reference. Referencing errata in an intended Proposed Standard might be a trivial matter. There are side effects to that. That may only be apparent in the long term. I hope that the RFC Editor does not plan to turn Standard Track RFCs into living standards. OK. I will move the Errata to the Informational references. See above. I disagree. I believe acknowledgments are very important and should be at the front. I commonly (but not always) put them there in my drafts. I am also not aware of any IETF rule prescribing where Acknowledgements go in Internet Drafts. It is true that the RFC Editor always move them to the end, but that's the way it goes. I noticed that you are one of the rare authors who has the Acknowledgements at the beginning of their document. It was a practice followed in some of the three-digit RFCs. There isn't any requirement in the RFC Style Guide which prohibits the Acknowledgements from being at the front of the document. As I say, although I frequently put them near the front of my Internet Drafts, the RFC Editor always moves them to the end. I don't know whether it is relevant but John Klensin mentioned this a few days ago: One might even suggest that one of the reasons early ARPANET/ Internet developments worked better than the IETF process of today is that there was wide recognition that it was necessarily a collaborative effort with many people contributing ideas and no one wanting to seize credit. I believe there may be some legal requirement to acknowledge those whose contributions have resulted in change in the document, unless they ask not to be listed. Anyway, my practice is not because anyone has asked to be listed nearer the beginning of the document but because I think they deserve to be so listed. Section 5 mentions that This document requires no IANA actions. However, there is another paragraph in the IANA Considerations section which is not even actionable by IANA folks. I am not sure whether the text should go into that section. Well, I could rename Section 5 to be Allocation Considerations and provide two subsection, one 5.1 IANA Considerations and one 5.2 W3C Allocation Considerations or the like and perhaps also move some of the material at the beginning of Section 2 down to 5.2. In Section 1: Note that raising XML Digital Signature to Draft Standard [RFC3275] in the IETF required removal of any algorithms for which there was not demonstrated interoperability from the Proposed Standard document. This required removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest. The URI for Minimal Canonicalization was included in [RFC4051] and is included here. That was the historic rationale for the different levels in the Standards Track. Rumor has it that although the rationale was forgotten, whether intentionally or not, the MUST wars continued. Dave Crocker once raised the question of complexity of a specification. Advancement along the Standards could have been used to make a specification less complex by trimming stuff which has not been implemented (see quoted text above). In Section 2.1.1: The content of the DigestValue element shall be the base64 [RFC2045] encoding of this bit string viewed as a 16-octet octet stream. RFC 4648 could be reference instead of RFC 2045. RFC4648 is Informational, so that would cause yet another downref. RFC 2045 has not bee obsoleted and seems fine to me for this purpose. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Regards, -sm
Re: IMPORANT: Comments on draft-eastlake-additional-xmlsec-uris-08
Hi Frederick, On Thu, Feb 7, 2013 at 4:24 PM, frederick.hir...@nokia.com wrote: Don I've received feedback from XML Security working group members that propose you change the URIs in the draft RFC for AES Key Wrap with Padding to match what is in XML Encryption 1.1, both because we are going to Recommendation and because there is code that currently uses those values. Can you please make the change, using the xmlenc11 URIs I listed below in item 1? Sure, I'll do that. Thanks regards, Frederick Frederick Hirsch Nokia On Feb 7, 2013, at 11:04 AM, wrote: Donald Some additional comments on draft http://tools.ietf.org/pdf/draft-eastlake-additional-xmlsec-uris-08.pdf sorry about the delay getting these comments to you. (1) We have defined different *informative* URIs for AES Key Wrap with Padding in XML Encryption 1.1 [http://www.w3.org/TR/xmlenc-core1/#sec-kw-aes-with-pad] which are different from those in the RFC, namely http://www.w3.org/2009/xmlenc11#kw-aes-128-pad http://www.w3.org/2009/xmlenc11#kw-aes-192-pad http://www.w3.org/2009/xmlenc11#kw-aes-256-pad I suggest we change this informative appendix of XML Encryption 1.1 (and the Security Algorithms Cross-Reference) to match what is in the RFC draft. Thomas, is there any problem with that at this PR stage? Those in the RFC draft are: http://www.w3.org/2007/05/xmldsig-more#kw-aes128-pad http://www.w3.org/2007/05/xmldsig-more#kw-aes192-pad http://www.w3.org/2007/05/xmldsig-more#kw-aes256-pad As above, I'll change the draft to use the ...//2009/xmlenc11#... URIs. (2) ConcatKDF fragment needs fixing in 4.1 and change log Appendix A due to a typo 2009/xmlenc11#ConctKDF [XMLENC] should be 2009/xmlenc11#ConcatKDF [XMLENC] #ConctKDF, should be #ConcatKDF, OK. (3) To some degree the fragment index and URI index replicate the published W3C Note, XML Security Algorithm Cross-Reference and could be incorporated there. If you would like to incorporate this information there, that seems fine. But I'd like to leave it in the draft also. (4) I suggest an update to the Introduction to mention XML Security 1.1 as follows after All of these standards and recommendations use URIs [RFC3986] to identify algorithms and keying information types. add The W3C has subsequently produced updated XML Signature 1.1 [XMLDSIG11] and XML Encryption 1.1 [XMLENC11} versions as well as a new XML Signature Properties specification [XMLDSIG-PROPERTIES]. OK. (5) Typo in introduction Canoncialization should be Canonicalization OK. (6) References Add references to XML Signature 1.1, XML Encryption 1.1, XML Signature Properties, XML Security Algorithm Cross-Reference (all to be updated upon Recommendation publication) The current draft does have references to XML Signature 1.1 and XML Encryption 1.1. The RFC Reference format permits multiple document under a single tag and both 1.0 and 1.1 are included under the [XMLDSIG] and [XMLENC] tags. I'll add the other two documents. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Signature properties has added a namespace: xmlns dsp=http://www.w3.org/2009/xmldsig-properties; [XMLDSIG-CORE1] D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. XML Signature Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL:http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/ [XMLENC-CORE1] J. Reagle; D. Eastlake; F. Hirsch; T. Roessler. XML Encryption Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL:http://www.w3.org/TR/2013/PR-xmlenc-core1-20130124/ [XMLDSIG-PROPERTIES] Frederick Hirsch. XML Signature Properties. 24 January 2013. W3C Proposed Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2013/PR-xmldsig-properties-20130124/ [XMLSEC-ALGS] F Hirsch, T Roessler, K Yiu XML Security Algorithm Cross-Reference, 24 January 2013 W3C Working Group Note http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130124/ regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG
Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt
Hi Bjoern, Thanks for your review and comments. See below. On Wed, Feb 6, 2013 at 6:40 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Hi, In http://www.ietf.org/id/draft-eastlake-additional-xmlsec-uris-08.txt the References have to be checked and updated. For example, the document has a normative reference to http://www.w3.org/TR/2002/WD-xptr-20020816/ which is a Superceded work-in-progress that's over 10 years old. Also, Well, the reference is to the most recent document with the title XML Pointer Language (XPointer). After that it seems to have fissioned into a few different documents The only more recent XPointer things are only from 2003 and seem to be XPointer element() Scheme, XPointer Framework, and XPointer xmlns() Scheme. What do you think this reference should point to? it references RFC Errata, Errata ID 191, RFC 4051 without linking the errata item, and does so normatively even though the document as a whole I'm not sure exactly what you mean here. The errata does appear in the references as [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc- editor.org I have been told by an Area Director that this it the format that the RFC Editor likes. You can certainly find the Errata starting with that link and by just linking to the main ref-editor.org web page, it does not constrain the other structure of that web site. would Obsolete RFC 4051. Just to illustrate, I did not review them all myself. OK. I will move the Errata to the Informational references. The Abstract does not english. How about the following change: OLD This document expands and updates the list of URIs specified in RFC 4051 and intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. NEW This document obsoletes RFC 4051, expanding and updating the list of URIs intended for use with XML Digital Signatures, Encryption, Canonicalization, and Key Management. These URIs identify algorithms and types of information. I don't think it's a good idea to have the Acknowledgements precede even the Introduction as an exception while most other documents put it near the end. I disagree. I believe acknowledgments are very important and should be at the front. I commonly (but not always) put them there in my drafts. I am also not aware of any IETF rule prescribing where Acknowledgements go in Internet Drafts. It is true that the RFC Editor always move them to the end, but that's the way it goes. The XCANON reference does not work, xml-enc-c14n-20020718 is perhaps meant to be xml-exc-c14n-20020718 (enc vs exc). I've not checked other references. http://www.w3.org/TR/REC-xml-enc-c14n-20020718/ is still there from RFC 4051 which this document obsoletes. Reference should be http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/ The document makes reference to Canonical XML 1.0 without referencing, e.g. http://www.w3.org/TR/C14N-issues/ (and RFC 3076 does not seem to have any Errata filed to hint at the problems with it). I'm not sure that's a problem, but it might be better to mention the problems with Canonical XML 1.0 in some form. Well, I would have thought that the issues in C14N-issues would be resolved in Canonical XML 1.1 which is dated later. In any case, problems in Canonical XML 1.0 seem irrelevant to this document which is just about what URIs represent what algorithms or data items. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com regards, -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: When is a 3933 experiment necessary? [Was: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC]
On Wed, Jan 30, 2013 at 1:35 PM, Dave Crocker d...@dcrocker.net wrote: On 1/30/2013 1:15 AM, Adrian Farrel wrote: I do agree with Spencer that getting consensus for a process change always looks like a formidable task. Small changes never address enough of the problem or the right piece of the problem. Large changes are too much in one go. :-) So, it seems to be increasingly hard to make changes to our process. I suspect it's not 'increasingly' but rather that it's always been extremely difficult... Let me suggest a different possibility for the challenge in this topic: We are a diverse community. Absent very, very strong consensus that a problem is serious enough to warrant a change, the community is not likely to line up automatically behind a proposal. We will always have some people who prefer no change and some who offer their different, favorite approaches, or and some who offer a zillion tweaks. In the aggregate, that makes for entropy, not consensus. It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. Niccolo Machiavelli Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com What makes this process different from what we see in successful working groups? I think there are two things: 1. A wg has a committed core of participants who have agreed on a common goal. 2. A wg process is managed. On the average, proposals for IETF process change benefit from neither of these. Hence I suggest that a proposal needs to recruit a committed core /before/ going public, and the discussion needs classic group facilitation, in terms of tracking issues, maintaining focus, and pursuing consensus. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-gp-obsolete-icmp-types-iana-01.txt (Formally Deprecating Some ICMPv4 Message Types) to Proposed Standard
I have a wording problem with this as below: On Thu, Jan 17, 2013 at 10:57 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Formally Deprecating Some ICMPv4 Message Types' draft-gp-obsolete-icmp-types-iana-01.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 ietf@ietf.org mailing lists by 2013-02-14. 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 A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC792 and RFC950, obsoletes RFC1788, and requests the RFC Editor to change the status of RFC1788 to Historic. I'm OK with deprecating these ICMPv4 message types. But this could be said to clean up the IANA registry only, in my opinion, if the entries were removed, which would be a bad idea. But the draft does not remove these entries or simplify the registry, it annotates the entries. I consider the wording clean up, as used here, to be misleading. I suggest the second sentence of the abstract be changed to This document deprecates such ICMPv4 message types and annotates the corresponding IANA registry entries. and that corresponding changes be made elsewhere in the draft where clean up is used. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com The file can be obtained via http://datatracker.ietf.org/doc/draft-gp-obsolete-icmp-types-iana/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gp-obsolete-icmp-types-iana/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]
Another problem is maintenance. Protocols change. Having to maintain a formal specification is commonly at least an order of magnitude more effort than maintaining a prose description. So it doesn't happen and they very rapidly get out of synch in any living protocol. As an example, the IEEE 802.11 (Wi-Fi) standard used to have a normative formal description of the MAC operation (see Annex C of 802.11-1999). By 802.11-2007 this was out of synch but was still included as informational material on the theory it might be of some use and the section began with the words This clause is no longer maintained Although still present as informational in 802.11-2012, the first words of that section are now This annex is obsolete. And, as has been mentioned before, I'd like to emphasize that the IETF experience and principal is that, if you want interoperation, compliance testing is useless. The way to interoperation is interoperation testing between implementations and, to a first approximation, the more and the earlier you do interoperation testing, the better. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Jan 8, 2013 at 9:45 AM, John Day jeanj...@comcast.net wrote: The reasons have been discussed or at least alluded to previously in this thread. The short answer is we have been there and done that: 30 years ago. All those tools were developed and used successfully in the 80s. I know of cases where doing the formal specification alongside the design phase caught lots of problems. However, there are two central problems: First, in general, programmers are lazy and just want to code. ;-) Using a formal method is a lot more work. Second, the complexity of the formal statements that must be written down is greater than the code. So there is a higher probability of mistakes in the formal description than in the code. Admittedly, if those statements are made, one has a far greater understanding of what you are doing. Once you have both, there is still the problem that if a bug or ambiguity shows up, neither the code nor the formal spec nor a prose spec can be taken be the right one. What is right is still in the heads of the authors. All of these are merely approximations. One has to go back and look at all of them and determine what the right answer is. Of course, the more things one has to look at the better. (for a bit more, see Chapter 1 of PNA). John Which raises the obvious question: Why do we not write protocol specs in a formal specification language instead of struggling with the ambiguities of natural language? Theorem provers and automated verification tools could then be brought to bear on both specifiations and implementations. Dick --
Re: travel guide for the next IETF...
Hi, On Mon, Dec 31, 2012 at 3:22 PM, Michael Richardson m...@sandelman.ca wrote: Dave == Dave Crocker d...@dcrocker.net writes: Dave Quick, name five reasons to go to Orlando. Here are mine: Dave Puerto Rican Dave delicacies, alternative cinema, craft beer, African-American Dave history and Dave psychic readings... Good... but how to get there? We appear to be stuck in the middle of a monster hotel with a single boulevard and nothing at all nearby (except that there is a shuttle to Disney) There are some things on the other side of World Drive. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Shoping around for places to stay, there are some 3-star places for $50/night.
Re: Last Call: draft-bonica-special-purpose-03.txt (Special-Purpose Address Registries) to Best Current Practice
How about changing the title from Special-Purpose Address Registries to Special-Purpose IP Address Registries. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Nov 29, 2012 at 3:55 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Special-Purpose Address Registries' draft-bonica-special-purpose-03.txt as Best Current Practice 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-01-02. 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 memo instructs IANA to restructure its IPv4 and IPv6 Special- Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. This memo updates RFC 5736 and RFC 4773, which define the current structure of the IPv4 and IPv6 Special-Purpose Address Registries. It also obsoletes RFC 5735 and RFC 5156 which document special- purpose address blocks that are not currently, but will in the future, be recorded in the IPv4 and IPv6 Special-Purpose Address Registries. The file can be obtained via http://datatracker.ietf.org/doc/draft-bonica-special-purpose/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-bonica-special-purpose/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: [trill] Last Call: draft-ietf-trill-oam-req-04.txt (Requirements for Operations, Administration and Maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links)) to Informational RF
Hi Gayle, On Tue, Dec 11, 2012 at 7:43 PM, gayle noble wind...@skyhighway.com wrote: Very well written!! No spelling errors! No grammatical errors! Only one sentence, in my opinion, could be rephrased for clarity 4.1. Data Plane RBridges MUST have the ability to identify OAM frames destined for them or which require processing by the OAM plane from normal data frames. [Might be clearer if it was [RBridges MUST have the ability to identify OAM frames from normal data frames when the OAM frames are destined for them or require processing by the OAM plane.]] Thanks for the praise! I think that your suggested wording could be improved by replacing the word identify with the word distinguish. Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com gayle
Re: Simplifying our processes: Conference Calls
It's a question of costs and benefits. The cost of the IETF Announce posting is small. There are not that many of them and I don't find them to be a burden. The benefit in openness and transparency is large. Thus the answer is simple and the policy should remain as it is for now. If conditions change, it can certainly be revisited. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Dec 4, 2012 at 12:59 PM, Hannes Tschofenig hannes.tschofe...@nsn.com wrote: The concept is simple: a time-specific gather is a meeting. Meetings require prior announcement beyond the working group. I am not against a meeting announcement. I am suggesting to announce the meeting where the audience is -- in the working group.
Re: IETF work is done on the mailing lists
I generally agree with Joe. There should be discussion but the distribution of that discussion between meeting and mailing list is not significant; however, there must be sufficient opportunity for objection or additional comments on the mailing list and, in the case of discussion at a meeting, the meeting notes should be sufficiently details to give you a feeling for what discussion occurred. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Nov 27, 2012 at 4:20 PM, Joe Touch to...@isi.edu wrote: On 11/27/2012 10:07 AM, Marc Blanchet wrote: Le 2012-11-27 à 13:00, Barry Leiba a écrit : So here's my question: Does the community want us to push back on those situations? Does the community believe that the real IETF work is done on the mailing lists, and not in the face-to-face meetings, to the extent that the community would want the IESG to refuse to publish documents whose process went as I've described above, on the basis that IETF process was not properly followed? no. Our work is done both on mailing lists and f2f meetings. As co-chair of a few wg, we have been doing great progress during f2f meeting with high-bandwidth interactions. RFC2418 says that business happens in either place: ... All working group actions shall be taken in a public forum, and wide participation is encouraged. A working group will conduct much of its business via electronic mail distribution lists but may meet periodically to discuss and review task status and progress, to resolve specific issues and to direct future activities. ... Overall, WG *decisions* are supposed to be consensus of the WG, not just those who happen to be present at a given meeting, so I would expect that such decisions would be confirmed on the mailing list even if initiated at a meeting. At most meetings I've attended, this is how action items were confirmed. So my conclusion is that: - activity/participation can happen in either place - consensus should include mailing list confirmation YMMV. Joe so document shepherd and AD should exercise judgement on how to see the community consensus/participation. Marc. I realize that this question is going to elicit some vehemence. Please be brief and polite, as you respond. :-) Barry, Applications AD
Re: Newcomers [Was: Evolutionizing the IETF]
Right. See RFC 4144. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sat, Nov 10, 2012 at 11:57 AM, Mary Barnes mary.ietf.bar...@gmail.com wrote: On Sat, Nov 10, 2012 at 10:51 AM, Melinda Shore melinda.sh...@gmail.com wrote: I think that we haven't done a sufficiently good job of acculturating newer participants and that can probably make the organization look more opaque and closed than it actually is. Most (but not all) working groups don't have enough help with document review, and I think that's probably the fast path to agency within the IETF. Being a body in a chair at a meeting is not. [MB] Exactly! That's what I did when I first started participating in IETF. I would review documents and comment on the mailing. I also would volunteer to take meeting minutes as that really does force you to pay attention to the meeting and not spend the meeting reading email or playing solitaire. Or, volunteer to at least follow the jabber room. Those are all extremely important for working group effectiveness. [/MB] Melinda
Re: [RFC 3777 Update for Vacancies]
On Mon, Oct 29, 2012 at 9:58 AM, John C Klensin john-i...@jck.com wrote: --On Monday, October 29, 2012 14:06 +0100 Eliot Lear l...@cisco.com wrote: Bob, everyone, As I've mentioned, I'd prefer an alternative to what the authors have written. Call this the let's program ourselves out of a paper bag option, when we all agree. This may be a rule we would wish to generalize. Here is the basis for what I propose: 1. We have existing procedures to resolve contested removals – the recall process. 2. Uncontested essentially means that we as a community are in unanimous agreement that the position is vacant. That means that by definition, any no votes from a body means it's contested. 3. The least amount of power should be delegated to our bodies as is necessary for the organization's smooth operation. 4. Procedural arguments on the IETF list are tiresome, when we all agree on the right outcome ;-) With that in mind, I've attempted to reduce changes to a more simplified form, as follows: ... NEW: When an IETF body unanimously believes that a position on that body has been vacated, they may request confirmation of this by the community through an Extended Last Call with their reasoning. Should no objections be received during that period, the position is said to be vacant. Eliot, I generally like the general direction in which you are headed. On other other hand, your specific proposal creates an opportunity for a single individual, perhaps even one who follows the mailing list but who is not an active participant in the IETF or who just doesn't like the procedure, to disrupt things and throw us back on recalls. Given the number of occasionally-grumpy people in the extended community, that does not seem wise. +1 Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Quick thought and strawman suggestion: how about we take your general model, but instead of using the absence of any objections as the not vacant, requires recall trigger, perhaps we could borrow a little bit from the recall model. For example, we might say that deciding that the procedure doesn't apply when the body thinks the position is vacant requires a petition endorsed by some number of people. The 20 of the recall procedure seems a bit high to me, but you get the general idea. One person claiming the position isn't really vacant could be just a grump; ten or twenty probably indicates that something odd is going on and a more heavyweight procedure is required. john
Re: IETF...the unconference of SDOs
On Sat, Sep 8, 2012 at 12:49 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Randy Bush ra...@psg.com i say scott should teach emacs :) Epsilon, dude! Who the heck wants to write their editor extensions in freaking LISP? :-) http://xkcd.com/297/ Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Noel
Re: Some thoughts about draft-leiba-3777upd-eligibility-02.txt
On Tue, Aug 21, 2012 at 3:34 PM, Barry Leiba barryle...@computer.org wrote: I have one discussion point and a number of small nits... ... There are just two points in your comments that I want to pursue: 15.2. People serving in the IETF Secretariat and the RFC Editor may not volunteer to serve as voting members of the nominating committee. Slight problem with the term RFC Editor since this is a single person and also a service function. I suspect you mean the latter. I do, and I actually had the same problem with it when I wrote it as you do. So help me, please: How *should* this be put? I don't like, and those employed in the RFC Editor function, and I really can't think of a concise, clean, accurate way to write it down, though we all (today) know what it means. Text, please, someone. In particular, I believe the there are Editorial Boards that the various fragments of the RFC Editor appoint and consult which should not be excluded. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com o In bullet 16, to correct an erratum, the last paragraph is replaced by this: One possible selection method is described in RFC 3797 [1]. Perfectly correct, but I don't think this document is the place to correct random errata. I was (and am) ambivalent here. I did not have this in my first version. SM did. When we merged the proposals, I thought it was a good idea to fix that. But you're right that it's rather off topic, and the right place to do that would be 3777bis, which this decidedly is NOT. I'm inclined to pull it out (having not checked that with SM yet, though). Does anyone (including SM) think it definitely needs to be in here? Barry
Re: ITU-T Dubai Meeting and IPv15
One problem with excessively large fields, including variable length addresses with a high maximum length, is that the next time someone wants to encode some additional information, they just tuck it inside that field in some quasi-proprietary way, instead of going to the trouble of actually adding a field. Witness X.509 Certificate serial numbers, which are arbitrary precision integers, but which frequently are used for a variety of information, all BER encoded... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Aug 10, 2012 at 1:35 PM, David Conrad d...@virtualized.org wrote: On Aug 10, 2012, at 10:22 AM, Andrew G. Malis agma...@gmail.com wrote: Another alternative is self-describing variable-length addresses, again do it once and we'll never have to worry about it again. Heretic! That's OSI speak! Why do you hate the Internet you ISO/ITU lackey?!? /flashback Yeah, variable-length addresses would have been nice. There was even working code. Maybe next IPng. Regards, -drc
Re: NomCom 2012-2013: Third Call for Volunteers
(1) Your figures show that it is more likely that a noncom member will be selected from an affiliation listed by only one volunteer then that they are to be selected from any specific affiliation listed by more than one volunteer. (2) Because of appearances of biased voting membership in some early noncoms, the rules were changes to prohibit more than two voting members with the same affiliation. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Wed, Aug 1, 2012 at 6:59 PM, Samuel Weiler wei...@watson.org wrote: On Mon, 30 Jul 2012, NomCom Chair wrote: I am pleased to report at this time we have 98 qualified individuals who have generously volunteer their time to serve on this year's NomCom. Sorting that list by affiliation and counting the number of names from each affiliation, the volunteer list as of Monday included: 16 Huawai 15 Cisco 13 Ericsson 9 Juniper 5 ZTE 4 Nokia/Siemens (debatable; see details) 3 Alcatel-Lucent 3 BBN 3 China Mobile 3 CNNIC 2 Time Warner Cable 1 (22) Total: 98 Observations: the top four companies on this list have contributed more than half of the NomCom volunteers. The top three have contributed twice as many (44) as all of the entities that contributed only one (22). Opinion: the NomCom would benefit from having many independent members. While that could happen (yay, randomness), the odds here don't look great. -- Sam Footnote: I wasn't entirely sure which of the Nokia and Seimens entries (below) to combine. I erred on the side of combining all of them, knowing that there's likely a strong argument to be made for some other treatment. In any case, I don't think it will make much of a difference to the analysis. Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Andrew Hutton, Siemens Enterprise Communications
Re: New Version Notification for draft-leiba-3777upd-eligibility-00.txt
Sees reasonable. While you are at it, you might complete the I* with IANA... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, Jul 30, 2012 at 9:04 PM, Barry Leiba barryle...@computer.org wrote: I have just posted the draft cited below, to adjust the NomCom eligibility rules to make the following change: RFC 3777 excludes from eligibility as NomCom volunteers: - members of the ISOC Board of Trustees - sitting members of the IAB - sitting members of the IESG The IAOC did not exist when that was written, and there are questions about who, exactly, are sitting members. This draft excludes from eligibility as NomCom volunteers: - members of the ISOC Board of Trustees - sitting members of the IAB - sitting members of the IESG - sitting members of the IAOC This draft clarifies that those exclusions: - DO include the ex-officio members - DO NOT include the liaisons (unless, of course, they're excluded by another rule) This draft also excludes from eligibility as NomCom volunteers paid employees: - the Secretariat - the RFC Editor Comments, please. Barry Filename:draft-leiba-3777upd-eligibility Revision:00 Title: Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership Creation date: 2012-07-30 WG ID: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-leiba-3777upd-eligibility-00.txt Status: http://datatracker.ietf.org/doc/draft-leiba-3777upd-eligibility Htmlized: http://tools.ietf.org/html/draft-leiba-3777upd-eligibility-00 Abstract: RFC 3777 specifies that sitting members of the IAB and IESG may not volunteer to serve on the nominating commitee. Since that document was written the IAOC was formed, and that body is not covered by RFC 3777. There is also uncertainty about whether ex- officio members and liaisons are included as sitting members. This document clarifies those situations.
Re: Protocol Definition
How about RFC 1661. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Jun 22, 2012 at 1:17 PM, Tony Finch d...@dotat.at wrote: Randy Bush ra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. what a laugh. try, for example, RFC 826 Perhaps a better example is RFC 6325. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty: Northeasterly backing westerly, 5 or 6. Moderate or rough. Occasional rain. Moderate or poor.
Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
Hi Ben, On Fri, Jun 1, 2012 at 3:18 PM, Ben Campbell b...@nostrum.com wrote: Thanks for the quick response. Further comments inline. I deleted sections that do not appear to need further discussion. Thanks! Ben. On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote: Hi Ben, Thanks for your review. See responses below. On Thu, May 31, 2012 at 6:08 PM, Ben Campbell b...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-trill-rbridge-extension-04 Reviewer: Ben Campbell Review Date: 2012-05-31 IETF LC End Date: 2012-06-07 IESG Telechat date: 2012-06-07 Note: Since this draft is on the agenda of the IESG Telechat on the same day that the IETF last call expires, this review is intended for both purposes. Summary: This draft is almost ready for publication as a proposed standard, but I have some clarification questions and comments that should be considered prior to publication. Major issues: None Minor issues: -- section 2, general: Do the authors assume that all TRILL extensions will follow this spec? Since RFC6325 already specifies an extension mechanism, what stops an extension from ignoring this spec and doing something different? Does it hurt if they do? I am not aware of any conflicts between this draft and RFC 6325. RFC 6325 provides the broadest header option framework, for example specifying the field for the length of the options area and the initial two critical summary bits. This document fills in the structure and allocation mechanism of the remaining bits in the first 4-byte word of the options area, consistent with and repeating some material from RFC 6325, but leaving specification of the remainder of the options area for future documents, which should be consistent with both RFC 6325 and this document. (For example, some future version of draft-ietf-trill-rbridge-options.) I agree there is no conflict--this draft adds details, but doesn't seem to contradict anything in the RFC. However, neither RFC 6325 nor this document can actually actually bind the IETF against adopting future standards describing extensions that do not conform. Certainly. Nothing can do that. The IETF can always update a protocol to change normative language, no matter how strongly it was stated originally :-) If future changes do not follow RFC 6325 or this document, for example changing the location or interpretation of the option length field in the TRILL Header or changing the interpretation of the critical summary bits in the first word of the options area, then this would break hardware and software implementations that depend on RFC 6325 and/or this document. But I trust the IETF to adhere to its usually high standards for backwards compatibility. Perhaps this draft should, in the first page header, say Updates: 6325, not in the sense that it makes a change but in the sense that it fills in more details. Assuming the additional details in this draft comprise preferred extension mechanism, then I think it makes sense to say that somewhere (perhaps a SHOULD strength), and also mark it as updating 6325. Adding details is still an update. OK. -- section 2, 3rd paragraph from end: Non-critical extensions can be safely ignored. Is that intended to be normative? (Seems like it should be, since behavior for critical extensions is normative). I think of it as more like the definition of non-critical. Sure--I mainly mention it to be consistent with the text for critical extensions, since it did use normative language about dropping frames. -- section 2.1, 1st paragraph, last sentence: Redundant with normative language in previous section. ? There is a normative requirement to discard frames with any unimplemented critical hop-by-hop options present, which might be thought to require examination of all options (something manifestly impossible since the format of options beyond the first word of the options area is not yet normatively specified). The sentence to which you refer just clarifies that testing the appropriate crtical summary bit(s) in the first word of the options area, if that word is present, is all that is required. section 2 says Any RBridge receiving a frame with a critical hop-by-hop extension that it does not implement MUST discard the frame Section 2.1 says If an RBridge does not implement all critical flags in a TRILL Data frame, it MUST discard the frame... These really seem like the same MUST (i.e, if you updated one but not the other, you would have an ambiguous state). The same is true for the egress bit. I understand that you want to draw the connection between a critical extension and critical flags, but it's
Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
Hi Ben, Thanks for your review. See responses below. On Thu, May 31, 2012 at 6:08 PM, Ben Campbell b...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-trill-rbridge-extension-04 Reviewer: Ben Campbell Review Date: 2012-05-31 IETF LC End Date: 2012-06-07 IESG Telechat date: 2012-06-07 Note: Since this draft is on the agenda of the IESG Telechat on the same day that the IETF last call expires, this review is intended for both purposes. Summary: This draft is almost ready for publication as a proposed standard, but I have some clarification questions and comments that should be considered prior to publication. Major issues: None Minor issues: -- section 2, general: Do the authors assume that all TRILL extensions will follow this spec? Since RFC6325 already specifies an extension mechanism, what stops an extension from ignoring this spec and doing something different? Does it hurt if they do? I am not aware of any conflicts between this draft and RFC 6325. RFC 6325 provides the broadest header option framework, for example specifying the field for the length of the options area and the initial two critical summary bits. This document fills in the structure and allocation mechanism of the remaining bits in the first 4-byte word of the options area, consistent with and repeating some material from RFC 6325, but leaving specification of the remainder of the options area for future documents, which should be consistent with both RFC 6325 and this document. (For example, some future version of draft-ietf-trill-rbridge-options.) However, neither RFC 6325 nor this document can actually actually bind the IETF against adopting future standards describing extensions that do not conform. If future changes do not follow RFC 6325 or this document, for example changing the location or interpretation of the option length field in the TRILL Header or changing the interpretation of the critical summary bits in the first word of the options area, then this would break hardware and software implementations that depend on RFC 6325 and/or this document. But I trust the IETF to adhere to its usually high standards for backwards compatibility. Perhaps this draft should, in the first page header, say Updates: 6325, not in the sense that it makes a change but in the sense that it fills in more details. -- section 2, 3rd paragraph from end: Non-critical extensions can be safely ignored. Is that intended to be normative? (Seems like it should be, since behavior for critical extensions is normative). I think of it as more like the definition of non-critical. -- section 2.1, 1st paragraph, last sentence: Redundant with normative language in previous section. ? There is a normative requirement to discard frames with any unimplemented critical hop-by-hop options present, which might be thought to require examination of all options (something manifestly impossible since the format of options beyond the first word of the options area is not yet normatively specified). The sentence to which you refer just clarifies that testing the appropriate crtical summary bit(s) in the first word of the options area, if that word is present, is all that is required. -- section 2.3, first paragraph: Is the first sentence intended as normative? Yes. When one is describing part of a protocol and you say that some particular contiguous block of bits is some particular field (and then possibly describe the sub-structure of that field) isn't that always normative? -- section 6, last paragraph: No security implications of this are mentioned. Is it really a security consideration? Also, is this more likely to be set incorrectly than all the other things that some implementation might screw up, so that it warrants special treatment? I tend to think that a discussion of what happens if bits are corrupted or incorrectly set is something reasonable for the Security Considerations section, although it could be elsewhere. The second paragraph/sentence of this section says that security considerations for any bits in the first word of the options area will be in the document specifying those bits. This document specifies the critical summary bits and the RBridge Channel Alert bits so there is text on both of those in its Security Considerations Section. Nits/editorial comments: -- section 1: Please expand TRILL on first mention in the body of the document (i.e. not just in the Abstract.) Sure. And all the other acronym expansions requested below are fine so I won't respond individually to them below although I agree with them. -- section 2: Please expand RBridge and IS-IS on first mention. -- section 2, bullet list, 2nd bullet: ...
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Hey, if people don't like the restrictions of the TXT RR, have I got an answer for you! See http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02 A little out of data but gives you a wide variety of formats :-) Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sat, Mar 3, 2012 at 11:39 AM, Hector sant9...@gmail.com wrote: � wrote: On 3 mar 2012, at 16:56, ned+i...@mauve.mrochek.com wrote: Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. Agree with you but too many people today just program in perl och python where the parsing is just a cast or similar, and they do not understand this argument of yours -- which I once again completely stand behind myself. The original version of Sender-ID (Caller ID Policy) was an XML version of SPF. In fact, the experimental record still exist: nslookup -query=txt _ep.hotmail.com ep xmlns='http://ms.net/1' testing='true' outmindirectlist1._ep.hotmail.com/indirect indirectlist2._ep.hotmail.com/indirect indirectlist3._ep.hotmail.com/indirect/m/out/ep It was introductions like this that raised eyebrows and the need to include a new RR type with the simpler language SPF TXT fallback for SPF and SENDER-ID. If TXT becomes the acceptable norm, than perhaps the XML format cane easily be reconsidered for a DNS TXT storage with a common XML I/O construct. :( -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I also support this draft. Donald On Tuesday, February 14, 2012, Daryl Tanner daryl.tan...@blueyonder.co.uk wrote: I support this updated draft, and I am keen for this to be published as a BCP. I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. Daryl -- Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-xnamercode-00.txt (xNAME RCODE and Status Bits Clarification) to Proposed Standard
Hi, On Mon, Jan 23, 2012 at 2:04 PM, SM s...@resistor.net wrote: At 10:23 23-01-2012, The IESG wrote: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'xNAME RCODE and Status Bits Clarification' draft-ietf-dnsext-xnamercode-00.txt as a 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 ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be From the Introduction Section: This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the (first) xNAME was detected) and subsequent or final query cycles. From Section 2.1: [RFC1035] states that the AA bit is to be set based on whether the server providing the answer with the first owner name in the answer section is authoritative. This specification of the AA bit has not been changed. This specification of the AA bit has not been changed. Actually, the last sentence above is not duplicated in the draft. And Section 2.2: [RFC4035] unambiguously states that the AD bit is to be set in a DNS response header only if the DNSSEC enabled server believes all RRs in the answer and authority sections of that response to be authentic. This specification of the AD bit has not been changed. It is not clear to me what is being clarified about the status bits. This draft brings together the aspects of the AA, AD, and RCODE bits related to xNAME RR query cycles and expresses them clearly and succinctly. As such it has been approved by the DNSEXT WG. I do not believe that text has to make a change to be a clarification. In Section 3: The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response. Shouldn't the BE be lowercased? Yes, thanks for pointing this out. BE should probably be lowercase. The status of the memo suggests sending comments to namedropp...@ops.ietf.org. Is that IETF mailing list still being used by DNSEXT? That was the mailing list at the time of the -00 personal draft version. Sorry I missed updating the mailing list reference somewhere along the way. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
On Tue, Jan 3, 2012 at 4:01 PM, Andy Bierman a...@netconfcentral.org wrote: On 01/03/2012 08:52 AM, George, Wes wrote: Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmas...@concorde-hotels.com I crossed my fingers and clicked 'send' of the PDF with my credit card number in it. I didn't pay enough attention to the no-refund policy. :-( I emailed my reservation on 12/22 and got a confirmation email on 12/26. So far, my credit card has not been charged anything. I think there should always be a full-refund cut-off date for the IETF hotel, even if it is 2 months in advance. I thought the cut-off was 15 days, but that is just for 2 more nights billed in advance, not the first night. Actually, that's unclear. I've read the form several times. It says you lose any non-refudable deposit. And it says the two-day charge is non-refundable. But it never says that the initial one-day charge is non-refundable... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I wish ...
The end of year Holiday season is not generally known as a time when lots of work gets done. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Dec 20, 2011 at 10:21 AM, t.petch daedu...@btconnect.com wrote: .. I knew how to move things forward. Earlier this year, the discussion was about how meetings might be reorganised to make more happen, and I commented that six meetings a year - no need to attend them - might produce six spurts of activity in a 12 month period instead of three. Post-Taipei, most of the WG I track, with the notable exception of the terrible twins of v6, seem to be moribund; WGLC go unanswered, calls for adoption lie fallow, those edits that would be made as soon as the window opened again remain unmade, ... The IESG is evidently working hard, but at the lower strata, ... For Christmas, I wish ... Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gerhards-syslog-plain-tcp-11.txt (Transmission ofSyslog Messages over TCP) to Informational RFC
That's very interesting. I've produced a number of RFCs over the years that reference US-ASCII and, since I had no idea that RFC 20 existed (it wasn't even on line when I started), I've always used the following reference. No one ever pointed out RFC 20 to me... ANSI, USA Standard Code for Information Interchange, X3.4, American National Standards Institute: New York, 1968. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Dec 13, 2011 at 8:03 AM, t.petch daedu...@btconnect.com wrote: I think this a valuable contribution to the work of the IETF and should become an RFC. I wondered if there should be a reference for US-ASCII (such as RFC0020) but on balance I think not; in the context of this I-D, likely different people will be using it to mean different character sets:-( Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Sent: Thursday, November 10, 2011 1:40 AM Subject: Last Call: draft-gerhards-syslog-plain-tcp-11.txt (Transmission ofSyslog Messages over TCP) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Transmission of Syslog Messages over TCP' draft-gerhards-syslog-plain-tcp-11.txt as an 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 ietf@ietf.org mailing lists by 2011-12-07. 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 There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. The aim of this specification is to explain how TCP has been used as a transport for syslog messages. The file can be obtained via http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gerhards-syslog-plain-tcp/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Hi, On Tue, Nov 29, 2011 at 1:38 AM, SM s...@resistor.net wrote: At 10:50 28-11-2011, IETF Chair wrote: The IETF legal counsel and insurance agent suggest that the IETF ought to have an antitrust policy. To address this need, a lawyer is needed. As a way forward, I suggest that IASA pay a lawyer to come up with an initial draft, and then this draft be brought to the community for review and comment (and probably revision). I think a new mail list should be used for the discussion. Once the new mail list reaches rough consensus on the antitrust policy document, I suggest using the usual process for adopting the policy as an IETF BCP. There isn't any information about why an antitrust policy is needed except for a suggestion from an insurance agent. As far as I know: (a) The IETF is not a legal entity No matter now many times people repeat it, the above is just nonsense. At least in common law countries, unincorporated associations are legal entities. Furthermore, the IETF is enough of a separate entity to have legal interests defended by separate legal counsel. (b) The IETF Trust holds and manages rights on behalf of the IETF (c) The IETF does not have any members The governance of the I* is complicated but I don't think any court would have any trouble finding that, for some purposes, the membership of the IETF is those qualified to serve as voting noncom members. (d) People participate in the IETF as individuals (e) This Standard-Setting Organization (SSO) is open (f) The IETF does not vote Legally, I don't think there is much difference between many IETF decision procedures and the voice voting commonly used in various assemblies. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com If decisions are taken by consensus and the decision-making is fair, there isn't a capturing party. Could more information be provided about: (i) Whether the antitrust policy should be applicable for the U.S. and the E.U. (ii) Which insurance triggered the discussion about having an antitrust policy (iii) Which body faces the risk of anti-competitive litigation Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-savi-framework-05 SECDIR review
draft-ietf-savi-framework-05.txt This document is a high level framework for SAVI and references a number of other documents. As such, I think, that the Security Considerations section is probably of adequate depth. However, there are a number of wording problems, both clarity and grammar, that I believe should be fixed, particularly in the Security Consideration section (Section 10) where there is one sentence I really didn't understand. See below. Also, as an Information document, it cannot have Normative References and all such should be reclassified as Informative. In the first sentence of the last paragraph of Section 3.1, it is a bit hard to tell that single is supposed to modify method rather ant IP Address. I suggest replacing each single IP address configuration method with each single method for IP address configuration individually. Unless, of course, I am more confused by this document than I think and single was supposed to modify IP Address. Section 3.2, first bullet, suggest adding a reference to RFC 5342. Section 7, second setence has problems. Suggest replacing with This document suggests 3 prefix configuration mechanisms for SAVI devices:. Section 7, first bullet, the acronym SLACC is used without definition or reference. Since it is only used twice, both instances being in this bullet, I suggest it bet spelled out in full. Section 7, first bullet item, what does feasible mean? Should a feasible by reaplced with an allowed? Section 7, second bullet item, the acronym RA is used without definition or reference. Since it is only used twice, both instances being in this bullet, I suggest it bet spelled out in full. Section 7, third bullet item, the acronym DHCP-PD is used without defintion or reference. Since it is only used twice, both instances being in this bullet, I suggest it bet spelled out in full (not DHCP, just PD). Section 7, last sentence: the word present seems to be used in the sense of displaying to someone. How and to whom is this presentation? Section 10: I was a bit befuddled by the sentence Besides, the binding may not accord with the address management requirement, which can be more specified for each client. The word client is used nowhere else in this document. What does this sentence mean and to what does client refer? Smaller Nits: People will probably figure it out but the first occurrence of Source Address Validation Improvement in the Introduction (and Abstract) should be followed by (SAVI). In the first sentence of Section 3.1, I would replace traces with monitors or snoops. (The word snoop is used elsewhere in the document.) Section 5, third bullet, in hosts to communicate - in hosts communicating. Section 6, first paragraph, last sentence, in mix scenario - in this mixed scenario. Section 6, second paragraph, last three sentences have problems. Suggest Current address assignment method standards documents have implied a prioritized relationship in general cases. However, in some scenarios, the default prioritizing may not be suitable. Configurable prioritization levels should be supported in a SAVI solution for the mixed scenario. Section 7, next to last sentence/paragraph, is - are and insert the after implies. Section 10, last sentence, suggest replacing with Cryptographically based authentication is the only way to meet a requirement for strong security of IP addresses. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The death John McCarthy
I worked at the MIT AI Lab for a number of years and visited SAIL several times. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, Oct 31, 2011 at 5:59 PM, Steve Crocker st...@shinkuro.com wrote: I was at the MIT AI Lab 1967-68 and at ARPA/IPTO 1961-74 where I funded and reviewed the Stanford AI Lab. Later I based my PhD thesis on McCarthy's memo on situational fluents. I also designed but didn't implement Lisp for the Sigma 7. Later I ran research groups and insisted on Lisp as a requirement. Steve Sent from my iPhone On Oct 31, 2011, at 3:44 PM, todd glassey tglas...@earthlink.net wrote: On 10/28/2011 1:25 PM, Randy Bush wrote: First, as someone who chartered the working group, who has implemented Lisp (the programming language) at least four times, and who views Dr. McCarthy as a hero I disagree that name is problematic or disrespectful. And I almost take offense in the claim that this is a generational thing. And frankly, if there's disrespect to be found here, IMO it lies in using this sad event as a proxy to criticize some IETF work some people apparently don't like. So how many people here actually knew or worked with John... or what he was working on? its a relevant question because there seem to be a number of people speaking from authority... so how many of you were around in the 1960's and 1970's at AI (either MIT or SU)? I bring this up as t...@suai.edu... T/// aol ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
+1 Donald On Friday, October 28, 2011, Ray Bellis ray.bel...@nominet.org.uk wrote: On 27 Oct 2011, at 12:03, Richard Kulawiec wrote: I support this concept, although I would go much further and eliminate ALL face-to-face meetings. I absolutely wouldn't. Travel (for meetings) is expensive, time-consuming, energy-inefficient, and increasingly difficult. Your assertions above are all true, but that does not mean that people should be denied the opportunity to meet. Being mostly social animals, I believe it's essential that we *do* get to actually meet our IETF colleagues. Do not underestimate how important it is to actually establish a rapport with other people, and that can really only be achieved face-to-face. This is simple psychology. You simply can't get to know people and work with them effectively if all they are is faceless email accounts or a voice on a crowded conf call. I've met loads of people at my four years of IETF, and many of those I now consider friends. I know what their competences are, and I know which ones I trust and distrust. You just don't get that from remote participation. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
Nothing happens without deadlines. I'd be more in favor of going back to 4 meetings a year than going to 2... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Wed, Oct 26, 2011 at 11:38 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 10/25/11 3:48 PM, John C Klensin wrote: --On Tuesday, October 25, 2011 10:19 -0700 Fred Baker f...@cisco.com wrote: On Oct 25, 2011, at 8:55 AM, Ping Pan wrote: the original issue remains: please make IETF meetings easier and cheaper for us to go to. ;-) I think that a lot of people would like that. There are a number of problems that need to be solved to make them cheaper to attend. One is the issue of air fare and hotel cost; these have been brought up before. 25 years ago, all meetings were in the US, as were most of the participants. People came from Europe and Australia at significantly greater cost, but for the average attendee, putting all meetings in the US reduced meeting cost. It's now 25 years later, and that logic doesn't remotely start to work. ... Ok, Fred, let me enter one suggestion into this discussion that would actually cut total costs, recognize and take advantage of the observation that an increasing number of WGs are holding virtual interim meetings, and reduce pressures on meeting time conflicts and trying to get everything done in 4 3/4 days. Eliminate one of the face to face meetings entirely -- go to two a year and either hold the 4 3/4 day schedule or, better cut it back to four. Reducing the number of meetings a year from three to two makes sense. Naturally, we'd need to work through the implications (e.g., the NomCom schedule is defined in terms of three meetings a year). Plus, it's a natural complement to having reduced the number of maturity levels from three to two. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
2/3rds of the IETF meetings in the USA would exacerbate visa problems for many attendees. I don't mind some amount of regularity in meeting site, like Minneapolis, or going where it's inexpensive (by the way, the Boston area is really cheap in the winter) but I think you need more variety than that. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sun, Oct 23, 2011 at 9:12 AM, Ping Pan p...@pingpan.org wrote: In the past three IETF meetings, I have traveled to Beijing, Prague and Quebec City to meet most who live within a few hours (air, car, walking etc.) from me. The next two will be in Taipei (in Winter) and Paris (in Spring). This is more like a vacation package than a get-together for engineers to solve problems face-to-face. Several of us have chatted about this last week. How about this as a recommendation? We have two meetings in fixed locations each year: Minneapolis in winter, and Phoenix in summer. The other one can be somewhere in Europe or Asia. Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount. Most of all, it encourages the participants who want to do work going there. Make sense? Ping On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger ebur...@standardstrack.com wrote: It gets worse. To attend every IETF meeting costs about $10,000 per year. If we say one has to go to the face-to-face meetings, we limit the IETF to participants from corporations or entities that will sponsor the individual (pay to play?), IETF participants that have independent funds, or people that can generate significantly more than $10,000 per year from their IETF activities. $10,000 per year is not within a typical individual's budget. This is more especially so if the individual comes from a region of the world where the per-capita GDP is below $10,000 per year. Where does the $10,000 figure come from? It is based on the following assumptions: One trip is far, so $2,000 for airfare One trip is near, so $400 for airfare One trip is in between, so $1,200 for airfare Hotel: 6 nights (Sunday - Friday) at $200 average per night (including tax). I know, Taipei is much more than that and Vancouver, including tax, will be exactly that. However, the numbers are nice and round at $200. I often cannot afford to stay at the conference hotel; use your own numbers for your own circumstances. Meals Misc Expenses: $50/day for 6 days So, the calculation is: 3x ($650 registration fee + $1,200 average airfare + $1,200 average hotel cost + $300 meals/other) = $10,050 It is critically important to note the cost is dominated by travel and hotel. The only parameter in IETF's control is the registration fee. Even if ISOC, sponsors, or someone else endowed the IETF so we could drop the registration fee to zero, the annual cost for travel is over $8,000, which is still rather expensive. I do not believe we consciously want to prohibit individuals from participating in the IETF. I do not believe we consciously want to prohibit individuals from outside North America, Europe, and select (wealthy) Asian countries. However, this is one logical result of mandating people go to the face-to-face to get work done. On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote: On 10/21/2011 7:58 PM, Melinda Shore wrote: It's increasingly the case that if you want to do work at the IETF, you need to go to meetings. I'd have considerable reservations about asking for the kind of money you're suggesting. Melinda, I've changed the subject line because the point you raise is orthogonal to the main thread, but since you raise it, it's worth exploring a bit (since I happen to agree with your observation.) The dynamics that make this true seem to have to do with changes in our community rather than in the nature of the technical work or the online tools. So the question is how to move the center of gravity back to mailing lists? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wikis for RFCs
I think a wiki per RFC with any sort of official IETF status is a bad idea that would create many cesspools of controversy. Donald On 9/19/11, Melinda Shore melinda.sh...@gmail.com wrote: On 9/19/11 8:14 AM, Alejandro Acosta wrote: +1 I also support the idea of every RFC havving the associated wiki. I don't. I'm basically in Paul's camp, although I don't think the greatest risk is that there'd be a negative impact on how the organization will be perceived by the community (although I agree that there's considerable risk of that). I wouldn't want to provide a forum for contentious discussions will never, ever end, that nothing will ever be resolved, and that people who can't accept organizational decisions will continue to fight those battles on the wiki. I think there's value in wikis to which people can contribute implementation and deployment notes, but only if there's a way to head off endless wars about stuff that's already been resolved by the IETF. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I do not believe there is any need to change RFC 2119. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Wed, Aug 31, 2011 at 9:28 AM, Scott O. Bradner s...@harvard.edu wrote: I've been traveling so have not had a chance to do anything but watch the discussion on a RFC 2119 update. a few thoughts 1/ I am far from convinced that there is a need to update RFC 2119 there is a bug in the boilerplate (as has been mentioned) and some people seem to have a hard time understanding what (to me) seem like clear descriptions of (for example) MUST SHOULD - but the issues do not seem serious enough to warrant replacing what is, basically, a simple dictionary usage constraint 2/ it seems like a very Bad Idea to move 2119 to historic- we move RFCs to historic when no one uses them or when they are a Bad Idea in light of updated technology - I do not think that makes much sense in this case - in addition it makes the status of RFCs that have a normative reference to a historic document a bit funky - if an update is actually needed there is no reason that I can come up with that it could not just be that -- an update 3/ I doubt that I'll ever catch up with Postel as the most referenced RFC author so that is not a consideration (for me) I wrote RFC 2119 (most using text from RFC 1122) because people were using MUST without saying what they meant, an update, if people think that one is actually needed, will serve that purpose as well as 2119 has. When I posted the original ID it was pointed out that I should also address when such terms should be used (i.e. try to limit the use to where it actually made sense protocol-wise) - I tried to do that but that part may not have been as successful as it might have been - any update might try to be clearer in this area that RFC 2119 is. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On Mon, Aug 29, 2011 at 11:01 AM, Henk Uijterwaal henk.uijterw...@gmail.com wrote: ... Discussions with the hotel starts only 2 years out, so fixing dates 3 years out won't change a thing. There is also the clash list, which limits the weeks when we can have a meeting. If we want more flexibility in order to find better hotel deals, then we have to do something like: dates are fixed approximately 1.5 years out, and we do not mind having meetings back-to-back with other organizations on the clash list. That means that some folks will have to travel around the globe between Friday afternoon and Sunday morning in order to make it from one meeting to another. IETF, more often that not, meets back-to-back with IEEE 802 Plenary meetings. Henk Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Fri, Aug 26, 2011 at 4:39 AM, t.petch daedu...@btconnect.com wrote: - Original Message - From: SM s...@resistor.net To: t.petch daedu...@btconnect.com Cc: IETF Discussion ietf@ietf.org Subject: Re: https Hi Tom, At 00:18 26-08-2011, t.petch wrote: Besides all the usual hassle of TLS, today the certificate is reported by IE as expired, which sort of sums it up. Already reported to ietf-action@. Regards, -sm P.S. My experience of ietf-action@ is that they are responsive and do fix problems that are reported. Yup, but why are we using https at all? Who decided, and please would they undecide? Unexpired certificates can be circumvented, but all too often, the https parts of the web site just do not work and, more importantly, I think it wrong to use industrial grade security where none is called for. The mail archives (and the minutes of the physical meetings) are the official record of the Working Groups, IETF, etc. Those archives should be available with a reasonably high level of integrity and authenticity. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On Wed, Aug 24, 2011 at 4:28 PM, Geoff Mulligan geoff.i...@mulligan.com wrote: ... You could pick Rosemont, IL (next to O'hare) for every meeting (oops, sorry - misses on decent food). Minneapolis or Chicago, one place doesn't make it. The policy of the IETF has been to meet where the attendees come from, although with some projection into the future. So I thought we were currently trying to equalize meetings in North America, Europe, and Asia. So it is an absolute minimum of three places. Donald geoff On Wed, 2011-08-24 at 13:23 -0700, Dave CROCKER wrote: On 8/24/2011 1:18 PM, Peter Saint-Andre wrote: As long as a relatively large percentage of IETF folks see meetings as an opportunity to sight-see, I don't think we'll see much support for rotating among a small set of major hub locations. +1 But it's worse than relatively large percent. There's absolutely no minority constituency that is vocal about wanting this to change. That's why I declared myself giving up on this topic. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Most hotel contracts I've signed have a clause called Attrition which calls for payment if the rooms actually taken fall below some percentage of the room block, like below 90% or the like. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Tue, Aug 23, 2011 at 5:12 PM, Fred Baker f...@cisco.com wrote: On Aug 23, 2011, at 1:37 PM, Worley, Dale R (Dale) wrote: Are we really committing? Yes, the IETF block in the primary hotel fills in my experience, but if it doesn't, is the IETF committing to paying the difference? yes. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New Non-WG Mailing List: happiana -- IETF/W3C/IANA Registry Happiness
Why can't we get informative explanations of what problem non-WG mailing lists are trying to address? Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Wed, Aug 3, 2011 at 2:54 PM, IETF Secretariat ietf-secretar...@ietf.org wrote: A new IETF non-working group email list has been created. List address: happi...@ietf.org Archive: http://www.ietf.org/mail-archive/web/happiana/ To subscribe: https://www.ietf.org/mailman/listinfo/happiana Purpose: This list is for discussion of IANA Registry issues to result in Happy IETF, Happy W3C, and Happy IANA. For additional information, please contact the list administrators. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
On Fri, Jul 15, 2011 at 12:14 PM, ned+i...@mauve.mrochek.com wrote: Obviously we need to take a typical step back first and determine the scope of the problem. We need to commission a requirements for noise ID first. Can we schedule a BOF? Perhaps a symbolic burning of notices? Wouldn't that be a BON rather than BOF? Don't you mean BON-fire... Donald Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
An IETF consensus call is judgement as to rough consensus. There is no mechanical set of rules that can substitute for judgement. WG Chairs judge the consensus of the Working Group. It is reasonable for them to take into account discussions at WG meetings as well as WG mailing list discussions. The IESG judges the consensus of the IETF. It is reasonable for them to take into account discussions on the WG mailing list and on any area mailing list or the like, as well as on the IETF mailing list and discussions at WG, area, and IETF plenary meetings. If polls at area meetings with 100+ people at them at three successive IETF meetings on different continents consistently show, say, a 3 to 1 preference for some proposal but the IETF Last call email has 6 people speaking against and only 4 in favor, what do you think the right judgement would be as to the consensus of the IETF community? Of course, I'm not saying that's what happened hear. But a narrow rules that the IESG is required to put on blinders and only consider the IETF discussion list IETF Last Call email, ignoring previous discussions on other relevant IETF mailing lists and ignoring WG, area, and IETF plenary meeting discussions they have attended, is just arbitrary nonsense. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
Hi Melinda, On Fri, Jun 24, 2011 at 1:57 PM, Melinda Shore melinda.sh...@gmail.com wrote: On 06/24/2011 06:46 AM, Donald Eastlake wrote: If polls at area meetings with 100+ people at them at three successive IETF meetings on different continents consistently show, say, a 3 to 1 preference for some proposal but the IETF Last call email has 6 people speaking against and only 4 in favor, what do you think the right judgement would be as to the consensus of the IETF community? My understanding is that any decisions reached at meetings must be ratified on mailing lists, which seems to me to suggest something about order of precedence. It depends on what you mean by ratified. I suppose a WG meeting could be said to have reached a decision but it isn't a decision of the WG, just the meeting. It must be brought up on the WG mailing list to provide broader opportunity for input, positive or negative. After it has been brought up on the mailing list, then the WG Chair(s) judge what the WG consensus is. It is certainly not required that, in making that judgement, the WG Chairs can only look at WG mailing list postings. Melinda Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
Hi Martin, On Fri, Jun 24, 2011 at 2:27 PM, Martin Rex m...@sap.com wrote: Donald Eastlake wrote: If polls at area meetings with 100+ people at them at three successive IETF meetings on different continents consistently show, say, a 3 to 1 preference for some proposal but the IETF Last call email has 6 people speaking against and only 4 in favor, what do you think the right judgement would be as to the consensus of the IETF community? That is completely missing the point of the IETF consensus process. Sometimes it does and sometimes it doesn't. It depends, as you state below, on the type of issue or issues that are being discussed. I should have stated that it was something like deciding between two methods of accomplishing the same technical goal where neutral observers do not think there is a big difference in the technical effectiveness of the methods, or something like. If there is just one single person that objects during LC, but raises 10 different issues, then it is totally irrelavant how many there are that are in favour. But then you go on, below, to say that the number of supporters really is the most relevant thing if it turns out to be issues of taste... Raised issues have to be processed with the issue resolution process, i.e. drilldown (probably during discussion) into pure matters of taste (where a significant majority decision is OK), procedural issues (which strongly need to be resolved) and technical issues that need to be either resolved or determineddeclared to be out-of-scope (or documented that no practical solution is known to exists but the proposal/document is useful in spite of that). So it really depends on the circumstances. ... -Martin Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] Last Call: draft-ietf-codec-requirements-04.txt (Codec Requirements) to Informational RFC
On Thu, Jun 16, 2011 at 4:42 PM, Christian Hoene ho...@uni-tuebingen.de wrote: Hello, In this draft, the editors of draft are not named as editors but as authors. Thus, I would suggest to follow the example given in http://www.rfc-editor.org/rfc/rfc5620.txt and add an , Ed. behind the names. A list of authors is given in the acknowledgement section of the draft. If everyone listed at the upper right of the first page is going to be an Editor, then adding Ed. after their name is completely superfluous and adds only clutter. Traditionally, those listed at the upper right of the first page of an RFC have been called authors in most cases, regardless of their actual role, and those listed in an Acknowledgements section have frequently been called contributors or the like. So I think it s perfectly fine the way it is in regards to this non-issue. Donald With best regards, Christian Hoene -Original Message- From: codec-boun...@ietf.org [mailto:codec-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, June 16, 2011 9:24 PM To: IETF-Announce Cc: co...@ietf.org Subject: [codec] Last Call: draft-ietf-codec-requirements-04.txt (Codec Requirements) to Informational RFC The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Codec Requirements' draft-ietf-codec-requirements-04.txt as an 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 ietf@ietf.org mailing lists by 2011-06-30. 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 provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet loss robustness, as well as other desirable properties. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/ No IPR declarations have been submitted directly on this I-D. ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
For all those people just dying to know about this character (U+19DA), the latest Unicode code chart listing it is here http://www.unicode.org/charts/PDF/U1980.pdf and the name of the character is NEW TAI LUE THAM DIGIT ONE. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Thu, May 26, 2011 at 7:19 AM, Simon Josefsson si...@josefsson.org wrote: The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'The Unicode code points and IDNA - Unicode 6.0' draft-faltstrom-5892bis-04.txt as a Proposed Standard Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a Updates: header but the draft name suggests otherwise to me, hence my question. If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. If the document updates RFC 5892, in order to remain compliant with the RFCs I would have to modify my implementation and make a backwards incompatible change. Today U+19DA converts to xn--pkf. With this document, I would have to raise an error for that input instead. I believe a case-by-case evaluation for each modified code-point is a good way to determine whether or not to add an exception in the IDNA tables. I haven't seen any discussion why U+19DA is so harmful that it has to be disallowed. On the contrary, everyone appears to agree that the code point is not widely used and the implications of continue permitting it are minor. Thus I would support publication of the document after adding U+19DA to table BackwardCompatible (G) as PVALID. I do realize that I may be in the rough part of the consensus here, which happens, but I want to provide my feedback for the record and allow the decision process to proceed. At least I will be able to shift blame to someone else if/when my users gets confused by this. :-) /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
I think this draft may do a little good, but mostly based on the attention it brings to the issue. If it is actually desired to make it easier to become a Proposed Standard, it would be quite easy and straightforward to take real steps that would make a real different. For example, to *prohibit* the requirement of multiple interoperable implementations, a requirement sometimes applied in an inconsistent and haphazard manner to candidates for Proposed Standard. On STD numbers, they were an interesting experiment but I believe, as currently implemented, they have been proven to add only confusion and bureaucracy. It would be quite easy and straightforward to have a different document sequence for Standards. For success in this, it would be essential to assure that they do *not* have RFC numbers. History shows that, regardless of other labels, if a document has an RFC #, most references to it will be via that number. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Thu, May 5, 2011 at 2:33 PM, Scott O. Bradner s...@harvard.edu wrote: As I have stated before, I do not think that this proposal will achieve anything useful since it will not change anything related to the underlying causes of few Proposed Standards advancing on the standards track. I see it as window dressing and, thus, a diversion from the technical work the IETF should focus on. If it were up to me, I would not approve this ID for publication as a RFC (of any type) Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 83 Venue
I had the impression that it was the International Earth Rotation Service (www.iers.org), also headquartered in Paris, that was in charge of leap seconds, as stated here http://www.iers.org/nn_11252/IERS/EN/DataProducts/EarthOrientationData/bulC__MD.html Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Fri, Jan 21, 2011 at 3:56 PM, Marshall Eubanks t...@americafree.tv wrote: On Jan 21, 2011, at 3:48 PM, Clint Chaplin wrote: Hey, Paris lobbied heavily to have the Prime Meridian be fixed in Paris. That would have really made them the center of the navigational world. Yes, and then they got the BIH, which got them the power to change GMT to UTC. (GMT no longer has any official existence.) Marshall On Fri, Jan 21, 2011 at 12:37 PM, todd glassey tglas...@earthlink.net wrote: On 1/21/2011 10:22 AM, Phillip Hallam-Baker wrote: On Fri, Jan 21, 2011 at 11:10 AM, Ole Jacobsen o...@cisco.com wrote: Does anyone see the irony of us even discussing concerns about, of all things, FOOD when it comes to Paris? What else is there to discuss in Paris? Making Paris the center of the world - ever look at French Navigation Charts - relative to Admiralty charts from any other nation? Todd -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3394 - Release Date: 01/21/11 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Change control
Hi, On Wed, Jan 19, 2011 at 5:20 PM, SM s...@resistor.net wrote: Hello, This is the second time in a year that I came across a case where a non-IETF group sought to maintain change control over a draft. In the first case, several iterations of the draft were posted and the author solicited comments on an IETF mailing list. (a) By making an IETF Submission, is an author allowing the IETF to have change control on the work? It depends. That's why there are different versions of the boilerplate depending on what rights the submitter is granting to the IETF. (b) Is it appropriate to use a WG mailing list to discuss a work on which the IETF does not have change control? Generally, yes. There's nothing wrong is such discussion if there appears to be a WG consensus to do so. You refer to this hypothetical submission as a work, which is a technically correct copyright term, but I believe you are thinking of it as a standards specification or a part of or an amendment to such a specification. But it can just be that the submitter wanted to use the draft format as a convenient way to make a statement to the WG, presumably a statement relevant to what the WG is doing. In such a case, the whole point would be consideration and, if appropriate, discussion of that statement in the WG. (c) If the IETF Submission is covered by the WG Charter, can the WG enhance the original contribution in accordance with the IETF Standards Process by adopting it as a WG work item? It depends. That's why there are different versions of the boilerplate. If the submitter has denied the IETF permission to produce derivative works, then it seems improper to attempt to adopt that draft as a WG draft. That's because being a WG draft implies WG change control. However, the ideas in the draft could be used in a WG draft. Regards, -sm Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Almost all registries I'm familiar with explicitly list unassigned ranges. In some cases, different unassigned subranges have different allocation policies. For example, there may be a small unassigned range of lower values requiring Standards Action with the bulk of the unassigned values allocatable on a less stringent basis. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Wed, Jan 12, 2011 at 9:35 AM, Julian Reschke julian.resc...@gmx.de wrote: On 12.01.2011 15:22, Adrian Farrel wrote: Entirely at random I clicked on: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml http://www.iana.org/assignments/calipso/calipso.xhtml http://www.iana.org/assignments/lmp-parameters Looks like IANA tries to fill up all the blanks with markers of unassigned. Is that harmful? Minimally, it's redundant. Also, it only makes sense on certain types of registries. I just checked the XML version of the first registry, and, indeed, it contains entries for unassigned values. /me shakes head in disbelief. What *should* be done is computing the unassigned ranges for *presentation*; that is, they should not be part of the actual registry. The way it's done currently defeats one of the reasons of having a machine-readable registry (consumers will have to hard-wire knowledge of the specific unassigned entry to make sense of the registry). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
I have also seen attempts to make a standard Historic with the supposed reason being to clear things out for the introduction of some better replacement. That seems like just nonsense to me. If it is so obvious that a replacement is superior, the replacement document can do the move of earlier document to Historic... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA +1-508-634-2066 (home) d3e...@gmail.com On Thu, Jan 6, 2011 at 4:45 PM, Doug Ewell d...@ewellic.org wrote: Lixia Zhang lixia at cs dot ucla dot edu wrote: PS: on the other hand, what would a historical status imply? the ideas obsolete? Every now and then, someone proposes to move a given RFC to Historic, not merely to reflect an observation that a process or protocol is obsolete, but as an active attempt to deprecate it, regardless of its currency or relevance. I remember a few months ago, it was proposed (evidently not for the first time) to move FTP to Historic, on the basis of its lack of airtight 21st-century security features, with no consideration for the innumerable existing systems and processes that have no need for top-notch security, and rely daily on FTP. I often see comments on this list about whether the outside world views the IETF as irrelevant. Declaring a commonly used, core process or protocol as Historic because something better exists might be a perfect example of this. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman hartmans-i...@mit.edu wrote: Radia == Radia Perlman radiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Hi, On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant stbry...@cisco.com wrote: On 20/12/2010 18:43, Donald Eastlake wrote: Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Radia == Radia Perlmanradiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. Thanks, Donald ... as I recall from discussions with the ISIS WG the changes that were made to ISIS for TRILL make it more vulnerable to a hello attack than vanilla ISIS. This I understand is because there is more work to be done in processing a TRILL hello. Is that correct? I think we are talking about Denial of Service due to replay of old Hellos screwing up the state. This is unrelated to the work required to process a Hello. It is true that some processing is required for IS-IS LAN Hellos. One reason for having a protocol like BFD is that you can send BFD messages more frequently because they take less processing than Hellos. But I don't see why there would be that much difference between the work involved in processing a TRILL LAN Hello and a Layer 3 IS-IS LAN Hello. - Stewart Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
My apologies for responding slowly, I was traveling. If it is tolerable to people, I do not mind adding the two sentences requested by Sam to the isis-trill draft. Thanks, Donald PS: It appears to me that the same considerations apply to draft-ietf-isis-ieee-aq. On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman hartmans-i...@mit.edu wrote: Erik == Erik Nordmark nordm...@acm.org writes: Erik Adding just this sentence to draft-ietf-isis-trill (the code Erik point document) seems odd. Your comment is really a comment on Erik the security of IS-IS, and not specific to TRILL and unrelated Erik to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A new version of draft-yevstifeyev-abnf-separated-lists
On Fri, Dec 10, 2010 at 1:02 PM, Doug Ewell d...@ewellic.org wrote: Mykyta Yevstifeyev evnikita2 at gmail dot com wrote: ... Acknowledgments Many thanks to (in alphabetical order): Tony Hansen, Thomson Martin and Barry Leiba for their weighty input to this document. This doesn't look like alphabetical order to me. ... Isn't it obvious? They are in inverse alphabetic order by first name. Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-cheshire-dnsext-multicastdns-12.txt
I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This Standards Track draft specifies a multicast link-local variant of DNS. I previously reviewed the -08 version which was aimed at Informational. SECURITY COMMENTS: The Security Considerations section seems reasonable for a standards track document describing an existing link local usage. The Security Considerations documentation suggestions in my previous review appear to have been adopted. OTHER COMMENTS: The Other Comments in my previous review have been delt with to a greater or lesser extent. TRIVIA All my trivia complaints in the previous review have been fixed. I would suggest that the first word of Section 20, currently The, should be replaced by A major or One of the or the like. For consistency with RFC 5395, all occurrences of pseudo-RR should be replace with meta-RR and it would not hurt to add a reference to RFC 5395 (or the rfc5395bis draft which is being fast tracked). Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An archive for nerdy t-shirts
These are unemployed engineers, right? Donald On Thu, Oct 28, 2010 at 2:23 PM, Lucy Lynch lly...@civil-tongue.net wrote: On Thu, 28 Oct 2010, Paul Hoffman wrote: http://ascii.textfiles.com/archives/2731 Those of you with a good collection of old IETF t-shirts (and other schwag; did anyone keep the phone cards MCI gave us at IETF 34?) might consider having them archived by Jason. I always get a small jolt when I see some homeless guy in Eugene wearing a NANOG or IETF shirt - maybe I should start documenting my sitings? - Lucy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC
If there is something in the IESG write-up that is needed to understand the nature of a document, that material should also appear in the document. Most people looking at RFCs probably don't even know that an IESG write-up might exist or where to find it and even those who do know about the IESG write-up will assume that the RFC (and possibly any Errata) are all they need to look at. This doesn't seem like a big deal. Just take the first two sentences of the Working Group Summary section of the IESG write-up and add them to the Abstract and/or Introduction, or something like that. Thanks, Donald On Tue, Oct 26, 2010 at 12:16 PM, Avygdor Moise a...@fdos.ca wrote: Dear Nikos, I believe that you appropriately addressed the comment and I are in complete agreement with your remarks. I'd would also like to point out that Mr. St. Johns' concerns are also addressed on the IETF data tracker for this RFC (http://datatracker.ietf.org/doc/draft-c1222-transport-over-ip/), on the IESG Write-ups tab. Specifically there is a Technical Summary, a Working Group Summary and a Document Quality section. These sections fully disclose and document the origin and the processes used to produce this RFC Draft and the qualifications of the contributors. Sincerely Avygdor Moise Chair: ASC C12 SC17, WG2 / ANSI C12.19; IEEE SCC31 / WG P1377 Editor: ASC C12 SC17, WG1/ ANSI C12.22; IEEE SCC31 / WG 1703 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Nikos Mavrogiannopoulos Sent: Tuesday, October 26, 2010 11:49 AM To: Michael StJohns Cc: i...@ietf.org; ietf@ietf.org Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC On Mon, Oct 25, 2010 at 7:39 PM, Michael StJohns mstjo...@comcast.net wrote: Hi - I'm confused about this approval. As I read the draft and the approval comments, this document is an independent submission describing how to do C12.22 over IP. But the document is without context for who does this typical to an informational RFC. Is that really typical? Check the MD5 algorithm in [0], I don't see such boilerplates like we at RSA security do hashing like that. I think it is obvious that the authors of the document do that, or recommend that. I pretty like the current format of informational RFCs. [0]. http://tools.ietf.org/html/rfc1321 Is this a) A document describing how the document authors would do this if they were a standards organization? b) A description of how their company does this in their products? Is your question on what informational RFCs are? c) A description of how another standards body (which one) does this? I'd suppose if this was the case it would be mentioned in the document in question. d) A back door attempt to form an international standard within the IETF without using the traditional IETF working group mechanisms? How can you know that? When somebody specifies his way of doing things, is to inform and have interoperability. It might actually happen that industry follows this approach and ends-up in a de-facto standard. I see nothing wrong with that. regards, Nikos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC
Hi Phil, On Tue, Aug 31, 2010 at 11:02 AM, Phillip Hallam-Baker hal...@gmail.com wrote: Whether or not the IAB zone is signed is of negligible consequence. But the fact that the IAB zone signatures had expired is a highly significant data point: DNSSEC administration is not quite as easy as some of the glib claims of its more enthusiastic supporters would lead one to believe. Sounds like a straw man to me. Can you provide a pointer to some of these glib claims? For years I have been hearing, correctly I believe, that lack of logistical and administrative tools and support for DNSSEC was the main problem slowing deployment. Recent developments like RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) have improved things a lot. And, as an original architect of DNSSEC, I admit that the early proposal set was deficient in this area. Donald On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS) g...@amsl.com wrote: Community - The DNS zone files have been re-signed, and we will look into alternatives to the original DNSSEC tools that were in use (which seem to be broken.) And just a reminder that, while posting complaints to this list might feel more therapeutic, the secretariat has an address set up for trouble reports, which is ietf-act...@ietf.org . Sending complaints to that address will generally get much faster results. Thank you! Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On Tue, Aug 31, 2010 at 12:06 PM, Hadriel Kaplan hkap...@acmepacket.com wrote: On Aug 30, 2010, at 6:21 PM, Randall Gellens wrote: Why Kauai? You list detailed reasons why Hawaii is logical and solves for many of the problems, but you don't say why this island. Because it's the nicest, obviously. :) See http://www.pothole.com/~dee3/kauai.html Donald We can even rotate islands if people get bored. Well, there are extensive conference facilities on Oahu, the Big Island, Maui, and Kauai. I have no information as to if they would work for a group of our size and with our need for breakout rooms. I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu) every few years, but they were a smaller group. There aren't many restaurants nearby, but I certainly don't remember anyone ever complaining about it. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Venue Preference Survey
It depends what you want to do. Technical participation in a working group by email works pretty well. But if you want to talk in person to WG chairs of ADs or the IANA or RFC Editor staff or be eligible for NomCom or have more impact at BoFs, etc., being there is important. See also RFC 4144. Donald On Mon, Aug 30, 2010 at 5:24 PM, Doug Ewell d...@ewellic.org wrote: Marshall Eubanks tme at americafree dot tv wrote: However, 90% of life consists of simply showing up, and that is especially true for the IETF; to participate, you have to show up, and that requires travel. I'll have to keep this in mind the next time I feel tempted to participate in a WG on the belief that mailing-list-only participation is important to the IETF. I am neither funded by my company to go on round-the-world junkets, nor wealthy enough to afford them out-of-pocket. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Varying meeting venue -- why?
1) I'm also in favor of Canadian venues for North American meetings. 2) On long term contracts, you can get some saving, but you have to be careful. I have some experience with holding a convention in the same city every year for decades. If you stick with the same facility year after year, you go through a series of phases. The first year things can be a little rough because they don't know your group. The second year they have learned and for the next 2, 3, maybe 4+ years, things usually go very smoothly and you get good rates and service (barring a change in facility ownership/management). But, sooner or later, perhaps around 5+ years, the facility starts to take you for granted, there is turn-over in the facility personnel, whatever concessions they were giving you that were saving you money disappear, the quality of service you get starts going down, and you have to move to re-gain any advantage. Thanks, Donald On Thu, Aug 12, 2010 at 2:05 PM, Spencer Dawkins spen...@wonderhamster.orgwrote: I know you meant it in jest, but to be clear to everyone else, qualifying a new venue is a lot of work. One point raised during the plenary is that we might be able to save money if we regularly return to a given venue. Is it possible to quantify those savings based on experience in, say, Minneapolis? My understanding is that Minneapolis kind of fell off the truck due to problems with IETF attendees getting US visas, and not because of other considerations. We've met there a lot in the past 10 or so years. People complained, but not in ways that prevented us from meeting there repeatedly. So if we were going to quantify savings based on return visits, could I suggest that we pick another place to quantify (perhaps Vancouver - we've been there a couple of times lately, and I happen to be sitting in a hotel right now - but anyplace outside the US would work for the concern I was raising). Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Assuming the very simple model that attendance consists of a fixed number of constant attendees from each continent plus a continentally local variable number that only show up when the IETF meets on their continent and using the very limited data provided, using a rough least squares fit I get the following: Constant Attendees Africa 6 Asia 236 Europe 254 N.America 409 Australia 14 S.America 8 Continentally Local Attendees Asia 333 Europe 173 N.America 232 Thanks, Donald == Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Fri, Aug 6, 2010 at 4:44 PM, Bob Hinden bob.hin...@gmail.com wrote: During my IAOC chair plenary talk at IETF78 (slides are in the proceedings) I asked a question about continuing the current meeting policy (3 in North America, 2 in Europe, 1 in Asia in two year period (3-2-1) ) or changing to a 1-1-1 policy based on current meeting attendance. The talk included a graph of attendance by continent for IETF72-IETF78. I was asked to provide this data to the community. It is attached. It includes the raw data and a new graph that shows attendance by percentage. It appears to me that a 1-1-1 meeting policy is justified by current overall IETF meeting attendance. Your comments are appreciated. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
On Sun, Aug 1, 2010 at 10:08 AM, Joel M. Halpern j...@joelhalpern.comwrote: ... 1) If there is no I-D and no mailing list, then no, you can not have a room suitable for 50+ people. ... +10**10 If there is no ID and no mailing list at least several weeks in advance, you should either have a real bar BoF with a handful of appropriate people, or you can seek opportunities to present at appropriate WG or Area meetings. Yours, Joel Thanks, Donald Yoav Nir wrote: On Aug 1, 2010, at 9:45 AM, Melinda Shore wrote: Yoav Nir wrote: Who's folks? A lot of people come to an IETF meeting, and are only following one or two of the working groups. That does not mean that they sit in their hotel rooms for the rest of the meeting. Instead, they pick what looks like interesting meetings, and go there, with the hope of catching something interesting. That's a really good point, actually. I've also made a point in the past of attending at least one session completely unrelated to what I'm working on, in hopes of learning something or getting new ideas or new associations or something. But still, it seems to me that there are two somewhat but not quite orthogonal questions here: 1) whether or not the increasing formalization of the bar BOF reflects an increased expectation of attendance in order to participate/advance work in the IETF, and 2) what a working group meeting is. I'll pass on answering #2, but as for #1, I think the bar BoF institution is mis-used as a working group of last resort. If I can't present my idea at a regular working group (because of time constraints or because it doesn't fit the charter of any current WG), and I can't present it at the area gathering (for lack of space), adding a bar BoF to the wiki seems to be the only way. In the end we don't get a lot of discussion - merely a presentation + QA session. And still the right people are often not there. So formalizing a bunch of presentations is a good thing, although I think it needs to be done differently. Formalizing a bunch of people throwing ideas around (the true bar BoF) is not a good thing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
I can see the desire to have some more experience on the nomcom. However, I am completely opposed to invidious schemes to divide the nomcom voting members into two (or more) classes. And I think the desired results can be obtained without doing so. The current qualification is attendance 3 out of the last 5 meetings but no one notices or cares whether any particular nomcom volunteer attended 3, 4, or 5 meeting. If you want more experienced members, just tighten the attendance criteria a bit but give points for other experience. As an example, set a threshold of 4 or 5 points where you get one for each meeting you attend out of the last six, one point for being on either of the two most recent nomcoms, and one point for having been a working group chair in the past two years. You could even make the probability of selection non-uniform based on points and I'd be willing to modify the code normally used to allow that, but I don't think it would be necessary. This way you will get more experience without the dominance effects of some nomcom members being labeled Senior and some Junior or whatever. Thanks, Donald = Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
See belos ... On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker hal...@gmail.com wrote: No, if you read my book you would see the scheme I am proposing. The problem with current MAC addresses is that they are not trustworthy. That is accepted. If MAC addresses were not trivially forged then the existing WiFi scheme would work fine. ... Instead every device would have been issued with a device cert to bind the MAC address to a public key during manufacture. This is already a requirement for cable modems. The cost is of the order of cents per device if the certs are installed during manufacture. Maintenance costs get much higher as soon as the device has left the factory. I don't see any need for the MAC address to be bound. If the device has a build in cert, you can use that, regardless of what the MAC address is, to authenticate and secure communications. Isn't this provided by 802.1AR-2009? ( Available from http://standards.ieee.org/getieee802/802.1.html ) The function of the certificate is to stop the MAC address being trivially forged. OK yes, if you design the protocols wrong then you can end up with Cisco being able to intercept on the wire traffic. But if you do the job right you can prevent interception even if the manufacturer defects. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-cooper-privacy-policy-01.txt
The sniffed passwords were sometimes displayed in real time on a monitor facing the audience from the front of the room. This activity was never called research that I can recall. I think the majority reaction was that this was a fine thing to motivate improvements in security practice. Only one person was upset, that I remember. And several people, seeing that this was going on, wrote little network apps to give the appearance to sniffers that plaintext passwords were being sent so use they could display messages on said monitor, like this is not my real password, etc. Thanks, Donald On Fri, Jul 9, 2010 at 1:24 PM, Fred Baker f...@cisco.com wrote: Randy, we have had at least one researcher sniffing passwords in plenary WiFi traffic and posting them, to embarrass people into using more secure technology. I believe he was an Ops AD at the time :-) Agreed that personal net hygiene is the solution there. On Jul 9, 2010, at 5:04 AM, Randy Bush wrote: [ fwiw, i am not bothered if some folk well-versed in such things develop and put forth a policy about how the ietf treats data about members, attendees, network, ... ] And yes we have researchers looking into the traffic, people storing all sorts of data, etc. we do? about our traffic on the ietf meeting network? stuff other than the _ephemeral_ data the noc ops use to manage the network? as far as i know o data collection has been done very rarely. and when it has been, it has been widely announced. o there is no plan known by the net ops to do so in maastricht or beijing at either of those meetings. o aside from issues in the wireless deployment, the data about net use at ietf meeings seems pretty boring to me from a research view o but i am sure there are wifi spies snooping and playing. and i suspect that they will not be very respectful of any policy put in place. given the latter, i focus more on prudent personal net hygene and less on prose. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf http://www.ipinc.net/IPv4.GIF ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: open protocols
It's all bit complicated but, yes, anyone can publish copies of RFCs, including translations into other languages. (See http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.pdffor latest provisions.) Patent questions can be even more complex but, generally speaking, anyone involved in the IETF process should make their claims known. See http://www.ietf.org/ipr/. (It is always possible that there are those not involved with the IETF process who have patent claims.) Depending on your definition of open, no, not all protocols approved by the IETF or documented in RFCs are unencumbered. Thanks, Donald = Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com 2010/5/21 victor nunes victor.re...@gmail.com Hello, I would like to clarify a doubt about the RFCs Copyright The IETF allows you to copy, publish RFCs? All protocols that are part of the architecture of TCP / IP are open? Thanks, Victor -- “Encarada do ponto de vista da juventude, a vida parece um futuro indefinidamente longo, ao passo que, na velhice, ela parece um passado deveras curto. Assim, a vida no seu início se apresenta do mesmo modo que as coisas quando as olhamos através de um binóculo usado ao contrário; mas, ao seu final, ela se parece com as coisas tal qual são vistas quando o binóculo é usado de modo normal. Um homem precisa ter envelhecido e vivido bastante para perceber como a vida é curta”. (Poema de Arthur Schopenhauer) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On Mon, May 10, 2010 at 5:05 AM, Iljitsch van Beijnum iljit...@muada.com wrote: On 10 mei 2010, at 5:01, ty...@mit.edu wrote: I talked to a cab driver in Boston, and he's not very happy with credit cards, because he was forced to use a new system for credit cards, and it takes what he considered an unfairly large percentage when customers pay by credit cards. And that's why credit cards are so evil. I understand there are often provisions that sellers can't charge a premium for credit card payments to make up for the commission so in places where creditcards are common EVERYONE pays more because of credit card commissions. While there might be special rules for taxis and while in the USA most credit card merchant agreements prohibit adding a surcharge for using a credit card, they do not prohibit giving a discount for cash. Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
On Mon, May 10, 2010 at 11:39 AM, Kurt Zeilenga kurt.zeile...@isode.com wrote: ... Well, being such a person, before I registered for a day pass I did not consider the NOMCOM ramifications. If I had, I think it would likely that I would simply have assumed the existing BCP were in force. I agree here. I argue that what the IETF now proposes is not a clarification to the BCP but a change to the BCP. Applying such changes retroactively stinks. I disagree here for the reasons I've already posted. So, with such disagreements, someone has to settle it even if there isn't a clear consensus. Pretty much all the bodies who could possibly make this decision have an extremely remote but theoretically real conflict. I have confidence that if there is a clear consensus that day membership should count as attendance towards NOMCOM qualification, the IESG will see that. But I sure don't see such a consensus against the IESG suggestion so I think it is not only correct but that it should stick. Donald So, I guess I won't have NOMCOM eligible this year (due to the change, assuming I attend the next IETF under a full registration). -- Kurt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
On Mon, May 10, 2010 at 1:33 PM, Ted Hardie ted.i...@gmail.com wrote: ... We need all the volunteers we can get. I think that's nonsense and typical of the fixation in recent years on maximizing the quantity of nomcom volunteers with little apparent concern for their level of interest. As far as I can tell, the nomcom worked fine in its early years when there commonly less than 50 volunteers. We want people willing to put in the time and effort required. I've never understood why some nomcom chairs worry so much if their volunteer pool is a bit smaller than the previous year's or make statements based on the assumption that there is a strong correlation between the quality of a nomcom's work and the percentage of those qualified who volunteer to be members. Donald (A former nomcom voter and nomcom chair recently self-funding my IETF attendance) Just my two cents, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
On Mon, May 10, 2010 at 3:09 PM, Ted Hardie ted.i...@gmail.com wrote: On Mon, May 10, 2010 at 11:05 AM, Donald Eastlake d3e...@gmail.com wrote: On Mon, May 10, 2010 at 1:33 PM, Ted Hardie ted.i...@gmail.com wrote: ... We need all the volunteers we can get. I think that's nonsense and typical of the fixation in recent years on maximizing the quantity of nomcom volunteers with little apparent concern for their level of interest. As far as I can tell, the nomcom worked fine in its early years when there commonly less than 50 volunteers. Burnout risk alone should tell you it isn't nonsense, even if you care absolutely nothing about the diversity of volunteers available to NomCom. Ah, burnout! Thanks for bringing up this point which supports my position. I'd been thinking that the only significant harm of the annual drum-banging to get more volunteers and all the wailing and gnashing of teeth if, say, there are only 70 volunteers, was arm-twisting people who aren't that involved or interested into volunteering. (And I have evidence to support this in that there was usually one deadbeat voting member, who did very little, on nomcoms in which I was involved.) But, of course, it is also a significant harm that it may cause people to volunteer who are burnt out and otherwise would refrain. You know, there is a reason they are called *volunteers*. Lets say there were 50 qualified volunteers each year. If someone volunteered every year, they'd only serve one in five on average, which doesn't sound too bad to me, and if/when they actually serve they don't have to volunteer again until they are ready to. In fact, for years (I just checked the past three), the volunteer pool has been running around 100 people. I just don't see how involuntary burn-out can possibly be a problem. Then there is diversity. Sounds fine, but I do not think it would be a good way to increase diversity by qualifying people who would be, *on average*, less involved and less widely involved in the IETF. The NomCom takes time and energy to do well, and if someone cares enough about the IETF to volunteer it, turning them away because some of their most recent experience was on day passes is silly. I know at It's fine if you think the qualification threshold should be a bit lower than what I think. But to change it, there should be a real WG process. The criteria is that for 3 out of the last 5 meetings, qualify to attend for the week, show up and pick up your badge, and get publicly listed for a while so anyone who thinks you are not qualified can object. I don't think that should be changed due to an IAOC experiment. least two former ADs who attended the last meeting on day passes, and we have seen others who have not met a 3/5 rule only because illness forced them to participate remotely. ... So, do you think that every case should be judged separately and individually? By who? I think you need a simple, easy to objectively enforce, bright-line rule. ... Ted Thanks, Donald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
