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 wrote: > Maybe we should reser

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, Michae

Re: Remote participants, newcomers, and tutorials

nroff still works fine for me. It's already there in Mac OS X. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sat, Jul 27, 2013 at 9:28 PM, Phillip Hallam-Baker wrote: > > > > On Sat, J

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 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

Re: [trill] Last Call: (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, Ju

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 wrote: > Hi Simon, > > >

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 3

Re: Final Announcement of Qualified Volunteers

Hi Brian, On Tue, Jul 9, 2013 at 4:40 PM, Brian E Carpenter 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

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 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 t

Re: NOMCOM 2013-14 Volunteering - 3rd and Final Call for Volunteers

Hi, On Mon, Jul 1, 2013 at 7:40 PM, NomCom Chair 2013 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, mo

Re: Part of Improving IETF Electronic Diversity [was: RFC 6234 code]

Hi Hector, On Fri, Jun 28, 2013 at 11:56 AM, Hector Santos 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 issu

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: Gen-ART review of draft-eastlake-rfc5342bis-03

Hi David, On Sun, Jun 9, 2013 at 1:47 PM, Black, David 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

Re: Last Call: (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 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' >>

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 wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comment

Re: Last Call: (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 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

Re: Last Call: (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

Re: IETF Meeting in South America

On Thu, May 23, 2013 at 4:39 PM, Arturo Servin 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 messa

Re: Last Call: (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 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 c

Re: Last Call: (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 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 f

Re: Last Call: (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

Re: Last Call: (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 wrote: > --On Monday, May 20, 2013 07:53 -0700 joel jaeggli > 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 be

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

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 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 p

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

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 = Do

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) 15

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 596

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 r

Re: IMPORANT: Comments on draft-eastlake-additional-xmlsec-uris-08

Hi Frederick, On Thu, Feb 7, 2013 at 4:24 PM, 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

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 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 >> >>

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 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 refe

Re: When is a 3933 experiment necessary? [Was: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC]

On Wed, Jan 30, 2013 at 1:35 PM, Dave Crocker 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

Re: Last Call: (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 wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Formally Deprecating Some ICMPv4 Message Types' >as Proposed Standard > > The IESG plans t

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

Re: travel guide for the next IETF...

Hi, On Mon, Dec 31, 2012 at 3:22 PM, Michael Richardson wrote: > >> "Dave" == Dave Crocker 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

Re: Last Call: (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:5

Re: [trill] Last Call: (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 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 > whic

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 chan

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

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 wrote: > > > On Sat, Nov 10, 2012 at 10:51 AM, Melinda Shore > wrote: >> >

Re: [RFC 3777 Update for Vacancies]

On Mon, Oct 29, 2012 at 9:58 AM, John C Klensin wrote: > > > --On Monday, October 29, 2012 14:06 +0100 Eliot Lear > 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" opt

Re: IETF...the unconference of SDOs

On Sat, Sep 8, 2012 at 12:49 AM, Noel Chiappa wrote: > > From: Randy Bush > > > 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. E

Re: Some thoughts about draft-leiba-3777upd-eligibility-02.txt

On Tue, Aug 21, 2012 at 3:34 PM, Barry Leiba 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

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

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 earl

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 wrote: > I have just

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 wrote: > Randy Bush wrote: > >> > All protocols in IETF are based on the Inte

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 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: >

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 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 dir

Re: Future Handling of Blue Sheets

On Tue, Apr 24, 2012 at 3:12 AM, Fernando Gont wrote: > On 04/24/2012 03:40 AM, Brian E Carpenter wrote: >>> * What about the case in which the same person must be in two meetings >>> that overlap? (e.g., I've *presented* at overlapping meeting) What >>> should they do in that that case? Sign all

Re: Future Handling of Blue Sheets

email addresses have the virtual of uniqueness so I believe they should be retained. Thanks, Donald =  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)  155 Beaver Street, Milford, MA 01757 USA  d3e...@gmail.com On Sun, Apr 22, 2012 at 10:31 AM, IETF Chair wrote: > At

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-33

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

I also support this draft. Donald On Tuesday, February 14, 2012, Daryl Tanner 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 >

Re: Last Call: (xNAME RCODE and Status Bits Clarification) to Proposed Standard

Hi, On Mon, Jan 23, 2012 at 2:04 PM, SM 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' >>   as a Proposed Standard >> >> The IESG plans

Re: primary Paris hotel booking

On Tue, Jan 3, 2012 at 4:01 PM, Andy Bierman 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 rec

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 wrote:

Re: Last Call: (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 I

Re: An Antitrust Policy for the IETF

Hi, On Tue, Nov 29, 2011 at 1:38 AM, SM 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

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

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 wrote: > I wa

Re: Requirement to go to meetings

+1 Donald On Friday, October 28, 2011, Ray Bellis 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-consum

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,

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

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 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

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 wrote: > I've been traveling so have

Re: voting system for future venues?

On Mon, Aug 29, 2011 at 11:01 AM, Henk Uijterwaal 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 ord

Re: https

On Fri, Aug 26, 2011 at 4:39 AM, t.petch wrote: > - Original Message - > From: "SM" > To: "t.petch" > Cc: "IETF Discussion" > 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

Re: Hyatt Taipei cancellation policy?

On Wed, Aug 24, 2011 at 4:28 PM, Geoff Mulligan 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, alth

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 Beave

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 Sec

Re: Confidentiality notices on email messages

On Fri, Jul 15, 2011 at 12:14 PM, 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

Re: Why ask for IETF Consensus on a WG document?

Hi Martin, On Fri, Jun 24, 2011 at 2:27 PM, Martin Rex 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 prop

Re: Why ask for IETF Consensus on a WG document?

Hi Melinda, On Fri, Jun 24, 2011 at 1:57 PM, Melinda Shore 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 &

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. T

Re: [codec] Last Call: (Codec Requirements) to Informational RFC

On Thu, Jun 16, 2011 at 4:42 PM, Christian Hoene 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 auth

Re: Last Call: (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

Re: Last Call: (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* t

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

Re: Change control

Hi, On Wed, Jan 19, 2011 at 5:20 PM, SM 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

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 allocatab

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 do

Re: [secdir] Secdir review of draft-ietf-isis-trill

Hi, On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant wrote: > On 20/12/2010 18:43, Donald Eastlake wrote: >> >> Hi, >> >> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman >>  wrote: >>>>>>>> "Radia" == Radia Perlman  writes: &g

Re: [secdir] Secdir review of draft-ietf-isis-trill

Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote: >> "Radia" == Radia Perlman 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

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

Re: A new version of draft-yevstifeyev-abnf-separated-lists

On Fri, Dec 10, 2010 at 1:02 PM, Doug Ewell wrote: > Mykyta Yevstifeyev 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

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-loca

Re: An archive for nerdy t-shirts

These are unemployed engineers, right? Donald On Thu, Oct 28, 2010 at 2:23 PM, Lucy Lynch wrote: > On Thu, 28 Oct 2010, Paul Hoffman wrote: > >> >> >> Those of you with a good collection of old IETF t-shirts (and other >> schwag; did anyone keep the pho

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 wr

Re: Optimizing for what? Was Re: IETF Attendance by continent

On Tue, Aug 31, 2010 at 12:06 PM, Hadriel Kaplan 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. :) S

Re: DNSSEC

Hi Phil, On Tue, Aug 31, 2010 at 11:02 AM, Phillip Hallam-Baker 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

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. Don

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

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 t

Re: Ad Hoc BOFs

On Sun, Aug 1, 2010 at 10:08 AM, Joel M. Halpern wrote: > ... > 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 wi

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

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 > 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

Re: Comments on

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 on

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, anyo

Re: Last Call: Policy Statement on the Day Pass Experiment

On Mon, May 10, 2010 at 3:09 PM, Ted Hardie wrote: > On Mon, May 10, 2010 at 11:05 AM, Donald Eastlake wrote: >> On Mon, May 10, 2010 at 1:33 PM, Ted Hardie wrote: >>> >>> ... >>> >>> We need all the volunteers we can get. >> >> I th

  1   2   >