Re: T-shirts, and some suggestions for future ietf meetings

JORDI PALET MARTINEZ wrote: By the way, the hotel has free IPv6 connectivity in every room, since we installed it in May 2003 (first one in the world as I know). (snip) PS: And yes, we of course plan to provide a nice t-shirt ! OK, I'm convinced. Lets go there as soon as possible. --Jari __

Re: Friday @ IETF61?

Tim Chown wrote: Pretty full? There were two WG meetings and two BoFs... although (for the first time?) there was an afternoon session (with 1 WG!). (snip) IETF 60: 2 WG, 2 BoF Just a small correction: the DNA group had its second session on Friday too, so I believe this makes the total 3 + 2 =

Mobility (Was: Re: A modest proposal for Harald)

Harald Tveit Alvestrand wrote: But on mobility, I think we blew it. I don't know if I agree with this -- most users that I know are pretty mobile and certainly wireless. So I think we do have some kind of a "Mobile Internet" already and there's obviously more to come. I do not want to comment on th

Re: How the IPnG effort was started

Michel Py wrote: I think you missed the point. As of today, IPv6 is in the same situation ISDN has always been: I Still Don't Need. ^ ^ ^ ^ Comparisons to past successes or failures are fun, but not always good indications of future. There are several reasons behind why something takes or d

Re: draft-ietf-iasa-bcp-02: section 3.4 - appeals

Margaret Wasserman wrote: Indeed, I wonder if we have gone too far in limiting the power of appeal in this version (see others' comments). I personally think that we have gone too far. I don't think that we want to set-up a situation where the only way the community can speak forcefully if it doe

Re: Excellent choice for summer meeting location!

IETF destinations are always an interesting discussion, I know this thread is going to generate a lot of fun :-) We have already brought up points about heat waves, terrorists, CO2 emissions, wine, and relative city violence rates. I'm looking forward to the rest of this thread... But I wanted to c

Re: Adminrest: BCP -03: Compensation for IAOC members

Brian E Carpenter wrote: x.x Compensation for IOAC members The IOAC members shall not receive any compensation (apart from exceptional reimbursement of expenses) for their services as members of the IOAC." This text works for me. And I agree with Jonne that it makes sense for the BCP to talk about

Re: Wordsmithed consensus: #771 Powers of the Chair of the IAOC

The text looks fine to me as well. --Jari Brian E Carpenter wrote: Harald Tveit Alvestrand wrote: I have seen very little disagreement on the intent of the words in the paragraphs I quoted, but quite a bit of wordsmithing. So let's try again. The members of the IAOC shall select one of its

Re: Consensus? #770 Compensation for IAOC members

Michael, Your proposed text is OK for me. --Jari Michael StJohns wrote: *bleah* Generally its better to have rules *before* the exceptional events occur. "The IAOC shall set and publish rules covering reimbursement of expenses and such reimbursement shall generally be for exceptional cases only

Re: IASA Finances - an attempt at some uplevelling

Harald Tveit Alvestrand wrote: The IASA model of finances, as presented in the BCP, is this one: Money comes from a number of places, which can be grouped roughly as: (snip) Similarly, the money goes to just a few places X - Money spent in support of the IETF Y - Money left by the end of the year (

Re: Consensus? #733 Outsourcing principle

Harald Tveit Alvestrand wrote: John Klensin suggested the following text for the first sentence, and Scott Bradner supported the idea: In principle, IETF administrative functions should be outsourced. Decisions to perform specific functions "in-house" should be explicitly justified by the IAOC an

Re: Consensus search: #725 3.4b Appealing decisions

Harald Tveit Alvestrand wrote: Does this seem like a reasonable point on the various scales of concern? I think so. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: What? No PPT or wireless? [Re: IETF63 wireless]

Melinda Shore wrote: However, while slides do tend to lead to a presentation-type meeting format, I think there are other factors substantially contributing to that, as well. Yes. Another factor is the ratio of work items to meeting time. If there are 5-6 or even more items per a two-hour slot ther

Re: Voting Idea? (Was: Last Call: 'Requirements for IETF DraftSubmission Toolset' to Informational RFC)

Hi Pekka, Maybe a part of the issue is that when the minute-taker is not a chair, it may be more difficult to document the result of the consensus call. The chairs should really be making the call, announcing it in the room "looks like we have consensus on X", and asking the note takers to recor

Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC

[EMAIL PROTECTED] wrote: I wonder how many of those have actually written a draft using both? Let's see. I've done lots of drafts with both, using (in the nroff case) several different macro packages. I have also produced several very large non-RFC documents (in the thousand page range) using

Re: What's been done [Re: Voting (again)]

I would like to support Brian's point that we have actually done quite a lot in recent years to improve the IETF. Not saying that we shouldn't do more -- we really need to -- but at least from my perspective there has been a significant, observable change for the better. --Jari Brian E Carpenter wr

Re: Complaining about ADs to Nomcom (Re: Voting (again))

Hi Lakshminath, As the title indicates, it is not sufficient to just complain about an AD (I guess it might be sufficient in the "Recall" process), it is also necessary to provide a pool of, or just one for that matter, candidates who are interested and qualified. Yes, I have real examples. (

Re: improving WG operation (was Re: Voting (again))

Keith, John C, John L, I am in agreement with you that the main issue is how well WGs operate in terms of their timeliness, quality, and relevance. Just by observing what happens around, you can see that most of the wall time spent in the creation of specifications goes to the WG. Or at least that

Re: Complaining about ADs to Nomcom (Re: Voting (again))

John, Spencer, The issue you raise about different people having different amount of information is a valid one. I originally thought of this problem mainly from the point of view of an individual being able to provide good input, but it would indeed be fair that all IETFers have the same ability t

Re: text suggested by ADs

Hi Ralph, I would actually feel more comfortable with ADs providing their technical judgment with the rest of us, through the same mechanism: WG or IETF last call. And that technical judgment should be expressed openly, in an archived WG mailing list, where everyone's technical input can be review

Re: improving WG operation (was Re: Voting (again))

Hi Keith, Keith, you have been advocating a model where the IETF would be stricter in allowing what work be taken up, in order to ensure that we can actually deliver. But I share the same opinion as John L that we should rather try to shape the IETF so that it can deliver what the world needs.

Re: text suggested by ADs

Hi Phillip, This information is on the 'Working Group Chairs' page, not the 'ID authors' page or more usefully the Internet drafts page. The I-D tracker *is* actually on the Internet drafts page (I think this was a recent change): http://www.ietf.org/ID.html But in general, yes, we could use m

Re: Complaining about ADs to Nomcom (Re: Voting (again))

Hi Brian, Please understand the argument that was made strongly while RFC 3777 was in WG discussion: there is reason to believe that a substantial fraction of the potential candidates would *not* volunteer if they were entering a public race. It's hard to judge the validity of that argument, but it

Re: Polling for feedback (Re: Complaining about ADs to Nomcom (Re: Voting (again)))

Hi Lakshminath, Good point. Its possible that you would get (some) more input with the new system. My guess is though that you'd still need to poll specific groups to get the input, because people are typically not very eager to do things unless you remind them. But its likely that if you get very

Re: Complaining about ADs to Nomcom (Re: Voting (again))

I tend to agree with Leslie that it would be better to update the BCP. (I can volunteer to edit an update, if there are no other takers.) But I believe the update should simply allow the nomcom to publish this information. As has been stated before, a lot of this information is already around us, s

Re: Proper WG chairs (Re: Voting (again))

John, I would add one, which is the consequence of your "known enough to the AD..." observation. There is a completely natural tendency, whether it causes this problem or others, for the ADs to keep going back to the same well of people who have known abilities, especially abilities to handle thi

Re: Complaining about ADs to Nomcom (Re: Voting (again))

Hi John, So, those of you who strongly advocate a public list... What percentage of the already-too-small potential candidate pool are you willing to lose? Are you convinced that anyone with sensitivities or conditions similar to those outlined above would make a bad AD if selected? Do you thi

Re: Complaining about ADs to Nomcom (Re: Voting (again))

This is a good suggestion in the sense that as far as I can see, it would fall within the current BCP rules, and could be implemented easily soon. Then we could take a bit more time to update the BCP in parallel, while perhaps also getting some early experiences on how well the new model works. --J

Re: Complaining about ADs to Nomcom (Re: Voting (again))

Brian E Carpenter wrote: As Leslie noted (...) another tricky point is exactly when the list is published and how nominations after that date are handled. Agreed. If you make the publication at the end of the nominations period then its not useful as a tool for other potential candidates to decide

Re: Complaining about ADs to Nomcom (Re: Voting (again))

Brian E Carpenter wrote: Actually, I think there is a slightly better way, somehow analagous to the 'petition period' used by the ISOC NomCom process. On day N, publish the list of willing nominees so far and invite further nominations before day N+14. On day N+28, publish the final list of willing

Re: IETF Newsletter: What's cooking?

This is a great idea. Good to hear that its already on the works. Information distribution and (I'm almost afraid to say this) marketing are important. And lets not forget other mediums either, e.g., if you are a chair of WG make sure that the industry forums, other SDOs etc that depend on your re

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

Harald, I have no strong opinion about the IPv6 hop-by-hop header in question. But I don't want to (effectively) remove the ability to refuse registration - I think we'll pay a high price for that later. I tend to agree. To me, "IESG Approval" in an IANA considerations text means that we expec

Re: S stands for Steering [Re: Should the IESG rule or not?]

Scott W Brim wrote: On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote: My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with t

Moving forward with the option (Was: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

Hi Margaret, And thanks for posting constructive suggestions for moving forward on this issue! What you say below makes sense. However, it occurs to me that there's also another possibility which has perhaps more commonly been used when IETF works together with other standards bodies, and has g

Re: Recording discussion

Iljitsch van Beijnum wrote: You can't do a text search on MP3s, listening is slower than reading and language issues tend to be tougher with spoken language than they are with written language. An advantage would be that spoken language conveys sarcasm better. :-) And that people don't

Re: Keeping this IETF's schedule in the future...?

Joerg Ott wrote: At this IETF, we have done a nice experiment with the modified schedule of our meetings for the purpose of dealing with restaurant hours. From the first 2.5 days, I find this an extremely useful thing and we should consider to organize out future meetings in a similar fashion.

Re: "IETF servers aren't for testing"

Bill Sommerfeld wrote: While the availability and stability of the IETF infrastructure is important, an engineering organization which declines to "eat its own dog food" sends a message about its suitability for widespread deployment. Agreed. --Jari ___

Re: Why have we gotten away from running code?

Iljitsch van Beijnum wrote: There are also specifications that would have been good to have implementations before leaving the WG, because they are not implemented-able as is (spkm). Is that because the designers did a bad job or because there was no way to anticipate the implementation dif

Re: Why have we gotten away from running code?

C Wegrzyn wrote: Hey, we not only had code that ran we also had "bake-offs" to make sure all the stuff worked together. The idea was to work out the nuances (the 20% of the inaccuracies) and produce a damn good system. Today the idea is to slap something together - damn the interop - and get out

Re: what is a threat analysis?

David Hopwood wrote: RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", may also be helpful (although it does not use the exact term "threat analysis"). All RFCs must contain a Security Considerations section (RFC 2223, section 9). That RFC indeed has some very sensible

Re: IETF 63 On-line Survey

Spencer Dawkins wrote: Would you prefer longer meetings or shorter meetings? Shorter meetings with more overlaps No change Longer meetings with fewer overlaps means! I'm answering it, assuming that it refers to the one-hour sessions that sometimes get doubled-up into two-hour sessions, but if

Re: regarding IETF lists using mailman: nodupes considered harmful

Folks, I realize that this is something that could happen. Interesting attack! But I missed the part where its somehow news to us that e-mail system can be tricked in various ways. And: Most of the time in important discussions it does not matter if some messages get lost. People have lengthy de

Re: ISMS working group and charter problems

Juergen Quittek wrote: The main goal of the ISMS WG is finding a solution that integrates SNMP into existing user and key management systems. Yes. Eliot's request is adding a new goal to the ISMS charter: extending SNMP such that it operates well across NATs and firewalls. I am not sure that

Re: ISMS working group and charter problems

Juergen Quittek wrote: In which scenarios do you consider it very useful? Management of devices when you are outside the network. E.g., managing my home network when I'm at the office. And outsourced management services -- my employer does a lot of this. Or central management of large networks

Re: IETF64 hotel already full?

Just had nearly the same experience. Interestingly, if you book through phone then there IS space but at a higher rate. I got IETF rate only until the 10th, but thereafter it was $265. (Registrations in the web appear to work too, if you depart on the 10th or earlier.) --Jari Pekka Savola wrote

Re: IETF64 hotel already full?

Pekka Savola wrote: Just had nearly the same experience. Interestingly, if you book through phone then there IS space but at a higher rate. I got IETF rate only until the 10th, but thereafter it was $265. (Registrations in the web appear to work too, if you depart on the 10th or earlier.) Th

Re: IETF64 hotel already full?

Here's an update. This is what Amy Blackstock, Reservation Agent at The Westin Bayshore Resort and Marina told me: My apologies for the confusion about the rates but the group is sold for Nov. 11 & 13th so the higher rates apply to these days. (This probably means that you'll have to call, not u

Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol

standards bloat solution: anyone proposing a new feature has to propose two features to be retired. anyone proposing a new standard has to propose two standards to be retired. This is a fun thread, but if we ever decide to get serious about complexity, we can't assume a static Internet or st

Re: Possible new Real-Time Applications and Infrastucture (RAI)Area

Hi Lakshminath, The end result is that we have documents in the RFC Ed queue with another document in the wings called draft-blah-clarifications I'm plotting the growth rate of draft-blah-clarifications, and my current estimate is that it will exceed the size of draft-blah-original before dr

Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area

Margaret Wasserman wrote: Mobility is quite close to the core of the Internet area, with close tie-ins to IP, addressing/address selection, multihoming, IP-in-IP tunneling, etc. I would personally object to the idea of trying to separate IP and Mobility into separate areas. I agree with this

Re: IETF Meeting Venue Selection Criteria

Everyone seems to be pointing to the wrong version of the document. Here's the correct URL: http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection-criteria-01.txt The -01 version is a major improvement from the initial ocument, I at least found it useful. Some comments belo

Re: IETF Meeting Venue Selection Criteria

Elwyn Davies wrote: There is some logic in this.. Participants need to be able to get from airport to hotel to venue on foot/public transport without needing to bring excessive personal protection gear that they might not otherwise own, or experiencing heat stroke because they aren't used to t

Re: IETF Meeting Venue Selection Criteria

I think we should expect a working environment that enables us to do our business withour too much hassle. For instance, toughness of visa criteria and/or length of process, excluded contributors are factors. I wouldn't consider just the need to apply for a visa as a show stopper, however. The d

Re: IETF Meeting Venue Selection Criteria

Dave, Unfortunately, the ultimate and practical meaning, of these kinds of conclusions about venue selection, is that we do not place productivity as a high priority. We have a collection of other priorities that take precedence, for a collection of reasons. This means that the impact of fac

Re: IETF Meeting Venue Selection Criteria - weather conditions and related

My reading of the original thread was that outdoor temporary was really a non-issue to almost everyone. Delete 1. 2 is obvious, delete. We had some discussion about 3, but I think it could be better summarized as "Ensure that the site under consideration has adequate air-conditioning and/or heat

Re: IETF Meeting Venue Selection Criteria - Other health risks

Like John said, I think this is overspecifying. And we really shouldn't be in the business of providing vaccination recommendations. Check with your doctors instead. And yes, I'd be willing to travel to places that may need an additional vaccination. We've probably been to a place like that alread

Re: Diagrams (Was RFCs should be distributed in XML)

Andrew Sullivan wrote: What I find strange about this, though, is the reluctance to adopt PDF. It's a well-known open standard. There are plenty of free software interpreters and writers around, and Ghostscript passed the threshold for good output 2 or 3 versions ago. I understand the difficu

Re: Diagrams (Was RFCs should be distributed in XML)

Dave Crocker wrote: Folks might want to take a look at the latest xml2rfc capabilities. See . Besides making it far easier to include the correct boilerplate, it has the option of including pretty graphics for the PDF version, while using the ASCII form for the ASCI

Re: On revising 3777 as in draft-klensin-recall-rev-00

I am not convinced that we need to do any change in this area. First, I think we have higher priority items to worry about. The IETF really needs to spend its process change cycles on things that provide a measureable effect and that has a real impact on timeliness/quality/openess/your favorite cr

Re: On revising 3777 as in draft-klensin-recall-rev-00

John, Lakshminath, I mostly agree with everything that you wrote and the nature of the recall process. Nevertheless, as the central proposal in John's draft appears to be the inclusion of IESG/IAB in the potential signing members I still fail to see why this is necessary. If the issue is of wide

Re: On revising 3777 as in draft-klensin-recall-rev-00

Hi Lakshminath, The argument has been around why if anyone needs to be excluded from signing a recall petition. I have made a case to exclude the current nomcom members and liaisons, but can't think of a reason to exclude IAB and IESG members. Good question. But I'm thinking that its simply

Re: On revising 3777 as in draft-klensin-recall-rev-00

John C Klensin wrote: Sunshine just seems a lot healthier to me than forcing people to organize conspiracies. I am in full agreement. So what was the issue we needed to solve again? Are we solving the case where there's sunshine but no one else than people in the IESG/IAB are convinced, so t

Re: Need to know the procedure

ChandraMohan wrote: Hi I would like to know the procedure for sending internet drafts. See http://www.ietf.org/ietf/1id-guidelines.html http://www.ietf.org/ID-Checklist.html http://tools.ietf.org/inventory/author-tools Hope this helps, Jari Arkko

Re: Alternative formats for IDs

I am in favor of enhancing graphics formats that we allow for normative versions of our drafts and RFCs. (Note that this is already allowed for non-normative things, such as a graphic state machine descriptions in a .pdf when .txt has a state table.) However, I would like to limit a new graphic

Re: Alternative formats for IDs

John, I've still got some misgivings about PDF because one of my requirements is to be able to extract things from documents and mark them up. Good question. I do think that we need the ability to extract material for various purposes, including o Comparisons (rfcdiff etc) o Bis-constructio

Diff tools (Was: Re: Alternative formats for IDs)

Yaakov, Try CVS or SVN and diff - works for everyone. Sorry, although I have such toys on my home computer I am not allowed to install such unsupported SW on my work computer. Fortunately, there's still a solution for you. You can run the diff tools even in the web, e.g., http://tool

Re: Alternative formats for IDs

Yaakov, > Word is of course out of the question since it is proprietary, > undocumented, and unstable. I hope we have consensus on that. Sorry, no such consensus. If you truly want to improve the IETF document format, may I suggest that we drop the fighting on formats that are known to be con

Re: IETF Last Call: draft-salowey-tls-ticket-06.txt

Pasi, The MAC will check out only if the servers are using the same key. If the servers regularly generate new keys (as is suggested in the Yes. But perhaps the document should contain more explicit requirements about key management (e.g. the keys used to protect the tickets must not be u

Re: WG Review: EAP Method Update (emu)

Clint Chaplin wrote: Has an email list been set up for this effort yet? We are currently operating under the "secmech" list: General Discussion: [EMAIL PROTECTED] To Subscribe: https://www1.ietf.org/mailman/listinfo/secmech Archive:http://www.ietf.org/mail-a

Re: WG Review: EAP Method Update (emu)

Pekka, Is there a particular reason why the proposed charter does not mention EAP-TTLS? I know very little about different EAP types, but as a potential operator and user of EAP, I'd definitely want to see focus on something like EAP-TTLS. Given that EAP-TTLS seems to be becoming an indust

Re: objection to proposed change to "consensus"

Yaakov Stein wrote: > However, the text objected to in this case argues that this process should be extended by a process of counting the people who don't publicly participate in the discussion (snip) We proposed gauging interest by a show of hands at a plenary meeting, rather than by the

Re: Last Call: draft-ietf-netlmm-proxymip6-10.txt to Proposed Standard

Allison, Thank you for the review. These seem valid issues that we need to talk about and/or resolve. Jari Allison Mankin kirjoitti: > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written primarily fo

Re: Last Call: draft-ietf-mip6-hiopt (DHCP Options for Home Information Discovery in MIPv6) to Proposed Standard

FYI -- this draft is being Last Called for the second time, due to having changed substantially as a result of earlier reviews. > The IESG has received a request from the Mobility for IPv6 WG (mip6) to > consider the following document: > > - 'DHCP Options for Home Information Discovery in MIPv6

Re: Hasty attempt to create an IDN WG (Was: WG Review: Internationalized Domain Name (idn)

Stephane, >> In addition, experience has shown a number of real or perceived >> defects or inadequacies with the protocol. >> > > Hold on. Is the WG really supposed to work on "perceived" defects? > Either these defects are real or they are not. If they are not real, > for instance, if they a

Re: IONs & discuss criteria

It is my experience as well that Gen-ART or other organized reviews are not given any more weight than other Last Call comments. However, I at least weight different comments in different ways, based on whether I agree with the issue, whether I believe the issue is a major problem or a minor nit, w

Re: IETF Last Call on Walled Garden Standard for the Internet

Bernard, For what it is worth, this ex-EAP co-chair also thinks that the use of EAP keys for applications is a very bad idea. And I too am concerned about introducing walled gardens through this. Having said that, I think there are legitimate uses of EMSK in the area of network access, such as va

EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)

Avi, >> For what it is worth, this ex-EAP co-chair also thinks that >> the use of EAP keys for applications is a very bad idea. >> > > Why? > For a number of reasons. Take this from someone who has actually tried to do this in the distant past and has realized that it was a bad idea. But

experiments in the ietf week

I really enjoyed the IPv6 experiment, thanks to everyone who was involved. Obviously, the experiment and a couple of other recent things (like moving to AMS service) made things move forward in a number of different places, our own computers, IETF computers, various people's own and company sites,

Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)

Lakshminath, > Why would we force the hotel to provide multiple sets of credentials > for each additional service/application that they want to provide? Credentials can still be the same. We're not really arguing against that. It would indeed be silly if you had to have more credentials. In some

Re: Thoughts on the nomcom process

Spencer, Laksminath, > You did something very GOOD this time - you invoked the never-before-invoked > arbitration process, instead of secretly resolving an "irresistable force > meets immovable object" dispute. Please accept credit for this good > judgement +1 INDEED. Thanks, Laksminath. And

Re: experiments in the ietf week

Eric, > I was referring to Iljitsch's suggestion about SSL and IPsec, not > the suggestion about DNSSEC. > Yes. FWIW, I don't think that would be interesting. DNSSEC experiments by itself might be interesting, particularly if they could be combined with some movement in getting the root signed.

Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

Just FYI, this draft is being AD sponsored as a report of a research effort that certain people have done in the source address validation space. To quote my ballot explanation: This draft documents an experimental design implemented in a research network for source address validation. The d

Re: experiments in the ietf week

Yes, that's excellent. In particular, I like your approach of making things available for the IETF crowd, delivered by the folks who are also delivering the standards. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-funk-eap-ttls-v0 (EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)) to Informational RFC

> The IESG has received a request from an individual submitter to consider > the following document: > > - 'EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on

Re: Scheduling unpleasantness

Iljitsch, Tell me about it... I had more than one WGs of my own meeting at the same time (6MAN and MEXT), triple booked on slots like the Tuesday morning slot where we had MEXT, V6OPS, and RRG at the same time, etc. INT has for years generally met (at least!) twice on every slot, and the ADs typic

TLS vs. IPsec (Was: Re: experiments in the ietf week)

Phillip, Iljitsch, > If you beleive that there is an attack that SSL is vulnerable to you > should bring it up in TLS. I think Iljitsch meant that TLS cannot protect against TCP vulnerabilities, such as spoofed connection resets. This is obviously well known. The upside of TLS has of course bee

Re: Write an RFC Was: experiments in the ietf week

Phillip, > write an Internet Draft prior to the experiment, > +1 > *IPv6 Next Steps* > > The Philadelphia IPv6 outage tested one specific aspect of the > transition - is there an IPv6 network on the other side to connect to > in due course, is it possible to run a pure IPv6 network? > > I think

reminder for people working on -bis documents

I have seen a number of problems recently with bis documents accidentally ignoring changes introduced by the RFC Editor to the original RFC. In some cases this has gone unnoticed all the way until IETF Last Call. The problem is that authors start with THEIR version of the source code for the docum

Re: reminder for people working on -bis documents

Stewart, Adrian, > Of course you mean the *relevant* errata Right. Generally speaking, I would go over the reported erratas and see which ones of them need to be adopted. Some might even need WG discussion. Jari ___ IETF mailing list IETF@ietf.org h

Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

Thanks for your review, Pekka. A few notes: > it doesn't go into much detail on how they solved > difficult and more interesting issues, for example: > - how they solved MTU problems caused by adding hop-by-hop header > - given their deployment model, why didn't they try inserting a destinati

Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

> For issues noted, for each I'd like to ask quostions such as: > - was this noticed in the testbed? how? > - was the issue relevant in that context; if not, why not? > - if the issue was noticed, how was it worked around? which >approaches worked (in that restricted context), which did n

Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

Marshall, Pekka, Pekka, you wrote: > I do not understand an errata that suggests changing the defined > process should be Archived. Shouldn't this be flat out Rejected? Right, this seems to be a bug in the text. > The problem I see with this proposed errata process is that "Archived" > tries to

Re: IETF Last Call on draft-funk-eap-ttls-v0-04.txt

Thanks for your review, Bernard. Paul is about to prepare a new version based on IESG review comments. Can you take care of Bernard's suggestions at the same time? Jari Bernard Aboba kirjoitti: > Overall this document looks good. I only have two minor comments. > > Section 12.2 > > "For EAP-

Re: IETF Website Outage

Alexa, First: thanks for getting the system up and running again. Then a small addition to what you said: > Many of you in Europe attempted to notify us of the outage and were unsure > of how to reach us, or what number to call. Thank you to everyone who > attempted to notify us, and I apologize

Measuring IETF and IESG trends (Was: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis)

Bernard, Russ, I changed the subject line, I think the thread has continued long enough :-) Indeed, I collect a set of measurements. These are based on pulling information from the tracker and the documents. The reason for setting this up was to try to better understand what is happening in t

Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)

Lakshminath, Better understanding of the type of behaviors in this space would certainly be useful. And I don't want to disagree with your assessment of the behaviors; many of them sound like something that appears in practice. In particular, the shepherds are far less involved in the Discuss

Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)

Laksminath, My point was this: if a WG actually missed anything substantial and that comes out during an IETF last call, and the shepherding AD agrees, the document gets sent back to the WG. If the shepherding AD also misses or misjudges, any member of the IESG can send it back to the WG for

Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)

Ted, The big problem others have been pointing to is that DISCUSSes are not being used to say "here is a technical issue, for which any solution acceptable to the community is fine", but are instead being used to say "here is a technical issue, and here's what it would take to satisfy me that it

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

Joel, In many locations this may preclude departure until saturday which effectively makes the meeting longer by a day. Hmm. The likelihood of having to depart the next day increases, but the question is by how much. For the record, my flights out of Minneapolis leave 15:20, 17:30, or 19:15. T

Conference calls (Was: Re: Proposed Experiment: More Meeting Time on Friday for IETF 73)

Spencer, IMO, since we see author/editor/review/design team teleconferences in a fair number of working groups, and these teleconferences aren't covered by the rules, I'd be in favor of revisiting the rules... Lets be clear about the different types of calls people might have. A design team

  1   2   3   4   5   6   >