Re: Architecture
On Mar 23, 2013, at 1:02 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 23/03/2013 01:46, Keith Moore wrote: On 03/22/2013 03:03 PM, John Curran wrote: On Mar 22, 2013, at 2:49 PM, Keith Moore mo...@network-heretics.com wrote: I don't think we're in disagreement. I think that more diversity in IETF would help minimize the risk that some interests were shortchanged, but I certainly agree that another factor is a lack of understanding of, and respect for, the effect of certain changes on the Internet architecture. Interesting... that could be the case. Have we even tried to identify and advertise those architectural principles since the early days? It may no longer be achievable, as pressure from vendors for new features and functionality drives new protocols and protocol additions, and while saying no sounds good in theory, the reality is that it probably doesn't really prevent the efforts, as much as cause them to be done as via private vendor=specific efforts... What's necessary, I think, is to respond to pressure for new features and functionality differently. Rather than saying yes or no, say we have noticed that the existing architecture fails to meet needs X, Y, and Z; and we propose to change the architecture in such a way to accommodate those needs while still safeguarding other important features or interests Keith, having been one of the progenitors and the editor of RFC 1958, I hear what you're saying. On the other hand, I have observed with horror the whole clean slate Internet exercise of the last few years. I am not optimistic that we could ever reach consensus. In fact I have been pessimistic about this for years (ever since RFC 2775 in fact). It's rather like trying to design a new global architecture for the road system. Brian there have indeed been many proposals which diverged in all directions, so I can understand the horror feeling about some of them (which, I am afraid, reflects that we have not been doing that well in architecture education). I am optimistic, however, that a right new architecture will emerge. I am not sure whether the road system analogy fits well since we build info highway, not physical highway. Did the old telco system look like the road system many years back? Internet as a different global infrastructure has largely subsumed it, isn't it? Lixia
Re: History of protocol discussion or process in WG
On Feb 3, 2013, at 4:17 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: On 2/2/13, Scott Brim s...@internet2.edu wrote: What? How about RFC 5218? This is done all the time through the WG process, and it changes all the time too, which is appropriate. Many WG open and close in IETF with no history-ID/report of such efforts including success or failur issues. If documents produced, new generation can benefit from these IDs AB +1 5218 is a general document; I believe what AB suggested is a historical record specifically for each WG: what you started with, what you went through, how you ended, what you have learned, both principles and lessons. Lixia
Re: History of protocol discussion or process in WG
got several quick replies! a few points: 1/ there seem 2 separable issues: - whether AB's suggestion is something worth considering doing - whether one believes it is feasible to do it. Lets not mix the two. 2/ there seems an implicit assumption that, if a history record is written, it'd only document one view (hence all the concerns about not being able to agree)? Maybe it is best to document different opinions if different opinions exist? Some time down the road IETF can look back, not only see which opinion has a better match to the reality (or even none of them), but also (hopefully!) understand better where our thought has gone right/wrong. 3/ no question that doing this would take time and effort, just like anything else that is worth doing. So the real question is: would this be worth trying? Lixia PS: would very much like to, but probably wont be able to keep up with this discussion (and will miss next IETF to chat with people in person) On Feb 3, 2013, at 10:28 AM, Sam Hartman hartmans-i...@mit.edu wrote: Lixia == Lixia Zhang li...@cs.ucla.edu writes: Lixia 5218 is a general document; I believe what AB suggested is a Lixia historical record specifically for each WG: what you started Lixia with, what you went through, how you ended, what you have Lixia learned, both principles and lessons. I'm not sure I've ever been involved with a WG where you could have gotten consensus on any of the above enough to publish it. Nor can I think of many WGs that have the excess energy to do this work. Even getting consensus on a summary of where you ended up is quite tricky. Because of who I'm responding to I'm imagining getting consensus on a summary of where the RRG ended up on the discussion of well whatever it is that they were discussing regarding id/loc split and all that stuff. WGs aren't particularly easier in this regard. You could probably get consensus on which set of documents a WG published in most cases, but if you added any context, say a discussion about whether those documents are still good ideas, it becomes a lot harder. This has value. I've supported certain aspects of the ISD proposals, of some things coming out of newtrk, etc. One aspect I've always disagreed with is proposals of this type that proposed to be generally applicable across the IETF. I agree that writing down where we were, where we are, what happened in between can be valuable. However it is quite expensive, and we need to balance that.
Re: 30th Anniversary of Transition to TCP/IP
On Dec 31, 2012, at 11:27 AM, Noel Chiappa wrote: From: IETF Chair ch...@ietf.org The ARPANET transitioned to TCP/IP on 1 January 1983. That was 30 years ago, It's very hard indeed to fully grasp that it's only been 30 years. My kids (now roughly 20) live in what is in some ways an entirely different world to the one I grew up in. Many technologies have had profound impacts in a short time (my parents were born shortly after the dawn of flight, and in their late middle age saw people landing on the Moon); and train, telegraph and telephone all each had tremendous impact, but I'm not sure any have had quite as much as this internetting stuff. agree, both in terms of how much impact, and how big part of the society impacted. It's been quite a ride. Noel
Re: In Memoriam IETF web page -- a modest proposal
On Oct 22, 2012, at 1:25 PM, Steve Crocker wrote: After watching the traffic on this, I'm thinking a memorial page is perhaps not the first place to focus attention. Instead, write a memorial RFC for each person you think made a significant contribution to the IETF. The RFC Editorial process will provide some vetting on quality. Use Informational, Historic(!) or create a new class. like this idea, with a new category. The memorial page can then list those who have memorial RFCs written for them. or we no longer need such a page, just an index to RFCs in this category. Lixia PS: Noel mentioned a few old names, like Licklider (maybe less than handful people on this list knew him), or Coya (unclear whether more people showing at Atlanta know the name, or the other way around) -- life moves forward fast, history fading away quickly, if we dont make an effort to put it in record.
Re: [IAB] Last Call: Modern Global Standards Paradigm
On Aug 12, 2012, at 10:51 AM, Stewart Bryant wrote: Dave If I interpret what you seem to be saying, it is that you care more for the micro-observance of IETF protocol, than taking steps to avoid Internet governance being transferred by government decree to a secretive agency of the UN that runs by government majority. Is that a correct assessments of your priorities? Stewart Personally I do not feel the tone of this message is most appropriate in this ongoing discussion. Lixia
Re: Proposed IETF 95 Date Change
On Jul 20, 2012, at 9:06 AM, IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director 2016 is far away but UCLA has calendars that far out ;) The new dates (20 - 25 March 2016) are much better, that is our spring break week. Our spring 2016 teaching starts Monday 3/28/2016 (for all UC campuses except Berkeley, and perhaps other schools running quarter system), making it almost impossible to travel. Lixia
Re: Making the Tao a web page
On Jun 3, 2012, at 6:34 PM, John C Klensin wrote: ... I further guess that on an ongoing basis will be better for the document than getting a new snapshot out as an RFC and seeing how long it takes to get stale and how long after that it takes the community to notice. ... I second the above statement (my apology to John for quoting this single sentence out of his whole msg) Lixia
Re: Issues relating to managing a mailing list...
On Mar 15, 2012, at 6:47 AM, John C Klensin wrote: --On Thursday, March 15, 2012 00:00 -0400 Ross Callon rcal...@juniper.net wrote: I don't like this proposal for two reasons: I frequently read email while not connected; When connected, bandwidths have gotten high enough that attachments on the most part are not slowing things down in an uncomfortable way. It might be okay for really large attachments, as long as only a few messages are affected. Borrowing a bit from Randy, the solution to really large attachments is to ban them. +1 Lixia
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
hmm... since when did IETF last call start soliciting *company* support? I had thought the rule says that we all participate as individuals. confused, Lixia On Dec 21, 2011, at 2:22 PM, Keyur Patel wrote: Folks, I like to voice my support (on behalf of Cisco Systems) as well. Cisco Systems has recently shipped RPKI Router protocol implementation (in IOS software release). Our implementation has been tested with two different RPKI cache implementations (RIPE, RPKI.NET) and is currently going through lab tests with our customers. We are also in process of writing an implementation survey for this protocol. Regards, Keyur On 12/20/11 11:27 PM, Hannes Gredler han...@juniper.net wrote: hi, hereby i want to declare (by myself and on behalf of Juniper Networks Inc.), support for the the rpki-rtr protocol. Juniper Networks Inc. has got an implementation of the protocol based on, draft-ietf-sidr-rpki-rtr-19. Our implementation passed interop testing with 3 different rpki caches (BBN, RIPE, ISC) and got a exposure to a couple of our tier-1 SP customers for labe test purposes. thanks ! /hannes ___ 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: voting system for future venues?
top posting to make a small point: for the many IETF meetings I've gone to over the years, reserving hotel room took less than 10min in general. For this Taipei meeting however, because the primary hotel price is way above US federal allowance (that's how my employer reimburses me), and the only overflow host is about equally pricy, for the first time I have to find lodging myself--this has taken me hours and still not settled yet (even with a local helper from Taiwan). Wonder whether this time cost should also be considered. On Aug 29, 2011, at 8:19 AM, Iljitsch van Beijnum wrote: On 29 Aug 2011, at 17:01 , Henk Uijterwaal wrote: 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. Is this so bad that $300/night room prices for hundreds of participants to avoid this issue is a good deal? One potential solution could be to select two or three weeks that don't clash or only minimally clash and then start the negotiations with a few more options, fixing the date a year or so out. ___ 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 Aug 22, 2011, at 12:17 PM, Michael StJohns wrote: Hi folks - I just reserved with the hotel and was quite surprised at the cancellation policy. Could you please confirm - Cancel before 1 Nov - no charge, 1-7 Nov 1 night, after 7 Nov full amount? Seriously? This is extreme. I can understand a 1 day fee up to the date of the reservation and maybe even charging the full amount if I don't cancel, but paying $1500+ because I had to cancel at the last moment seems a bit confiscatory. Mike Since you brought up the subject of hotel: up to now IETF hotel prices have been within the federal per diem allowance, but IETF82 seems an exception by a pretty big gap (see http://aoprals.state.gov/web920/per_diem_action.asp?MenuHide=1CountryCode=1142, lodging allowance $186/day, a single room at Hyatt is $263/day with 10% tax) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-zhu-mobileme-doc-04
On Mar 4, 2011, at 6:01 AM, Roni Even 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-zhu-mobileme-doc-04 Reviewer: Roni Even Review Date:2011–3–4 IETF LC End Date: 2011–3–18 IESG Telechat date: Summary: This draft is almost ready for publication as Informational RFC. Major issues: Minor issues: In section 5 and in section 6.1 second bullet you mention that the end to end connection is TCP while in other places like section 3, 4th paragraph you mention that UDP is used to tunnel packet end to end. So what are the TCP connections used for? section 3 talks about the use of UDP encapsulation for end host's data packets. section 5 and section 6.1 refer to TCP connections used by user applications running on end hosts. Nits/editorial comments: ___ 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: MHonArc mail archive line wrapping
good catch of the problem. I suffered when I read IETF email on the web. Would be great to see this fixed. Lixia On Feb 15, 2011, at 12:46 PM, Stuart Cheshire wrote: In the MHonArc mail archive there are often super-long lines, which would be wrapped to the window width when viewing in most mail clients, but when viewed in a web browser they appear as long single lines which take a lot of left-to-right scrolling to read them. For example: http://www.ietf.org/mail-archive/web/renum/current/msg00060.html This appears to be due to MHonArc's use of the PRE tag, which tells the web browser to display the literal text exactly as given, in a fixed-width font. The MHonArc FAQ suggests a couple of solutions to this problem: Can long lines be wrapped in converted messages? http://www.mhonarc.org/MHonArc/doc/faq/mime.html#lineclip Can the PRE tags be removed from converted messages? http://www.mhonarc.org/MHonArc/doc/faq/mime.html#removepre Can we consider using either of these options? Using maxwidth=xxx would solve this problem, though of course it opens the debate about what's the right value for xxx. Using nonfixed has the nice property of letting the web browser wrap the text to the window width, but might break ASCII-art diagrams. Perhaps that could be fixed by making the default font a fixed-width one (e.g. via style sheet) and using the keepspace option, which would give us monospaced text while still allowing the web browser to wrap the text to the current window width. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ 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-D Action:draft-white-tsvwg-netblt-00.txt
On Jan 11, 2011, at 1:09 AM, John C Klensin wrote: --On Saturday, January 08, 2011 07:37 -0800 Lixia Zhang li...@cs.ucla.edu wrote: I am not sure why this rush to get a new internet draft out, without consultation to any of its original authors, and given the rough consensus on ietf mailing list discussion is to keep NETBLT RFC as is (experimental). Lixia, I'm not sure there is any rush. I'm also not sure that the effort that is going into this could not be better spent in other ways. I'm also not sure about the opposite of either -- I actually don't have a strong opinion one way or the other. However, it seems to me that... (i) It has been a very long time since we published specifications that might now be considered Experimental with disclaimers that said, more or less, don't even think about implementing this without a discussion with, and maybe permission from, the author. If a spec is published as Experimental, then people are assumed to be free, modulo any IPR issues, to implement and test it. Hi John, I could see that my earlier msg could be read in a wrong way. The reason for contacting original authors is to find out what are the things that they know about the protocol (that were not mentioned in the specification), so one can either save the time to reinvent the wheel or even overlook problems/solutions that were discovered earlier. As I said in my earlier msg (http://www6.ietf.org/mail-archive/web/ietf/current/msg65063.html), ... unless there is clearly identified need for a protocol like NETBLT (as its name suggested, it is a specialized protocol for bulk data transfer only), I do not see the need to move NETBLT to standard. In case such a need is identified, personally I think we need a clear problem statement first, so that we better understand the context the protocol will be applied to. We (the MIT crew at the time) did various trials of NETBLT after the RFC998's publication, and collected a list of issues for further investigation. For example, one issue I can still recall clearly is NETBLT's congestion control design and the interaction with TCP traffic (I cannot recall the whole list on top of my head now after all these years, though there may still be old notes around). But I would like to pop up a level here: this thread started with a notion that rfc2026 was wrong regarding experimental rfcs so actions are taken now to do something with these rfcs. I agree with Bob's comment that (http://www6.ietf.org/mail-archive/web/ietf/current/msg65072.html), Hi, I think that the author of RFC2026 was wrong while writing the definition of Historic status. This document says that Historic should be assigned only to that documents that were standards and now are obsolete. But why do we need such narrow definition? Non-standards RFCs are not made Historic while obsoleting, according to 2026. Moreover, such status will just duplicate the obsoleted-by one. When there will be the attempt to revise RFC 2026, we should put there that Historic status is to be assigned to that documents that are considered to be deprecated. I fully share the opinion of Doug here. If you think RFC20206 is wrong, then propose changes to it and see if people agree with the changes. Until it is changed, IMHO you should not propose actions based on what you as an individual think is incorrect. There needs to be a community consensus that RFC2026 is wrong before any action should be taken. Bob Lixia___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-white-tsvwg-netblt-00.txt
I am not sure why this rush to get a new internet draft out, without consultation to any of its original authors, and given the rough consensus on ietf mailing list discussion is to keep NETBLT RFC as is (experimental). Lixia On Jan 8, 2011, at 3:00 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Block Transfer Protocol (NETBLT) Author(s) : J. White, M. Yevstifeyev Filename: draft-white-tsvwg-netblt-00.txt Pages : 34 Date: 2011-01-08 This document is a specification of version 5 of Network Block Transfer Protocol (NETBLT). This protocol was firstly specified in RFC 969, that has been made obsolete by RFC 998. Nevertheless, none of these documents match current Internet Standards and are deprecated. This document aligns the NETBLT specification with the most current Internet Standards and obsoletes RFC 998. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-white-tsvwg-netblt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Mail Attachment___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
On Jan 6, 2011, at 10:01 PM, Mykyta Yevstifeyev wrote: 06.01.2011 23:45, Doug Ewell 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. I think that the author of RFC2026 was wrong while writing the definition of Historic status. This document says that Historic should be assigned only to that documents that were standards and now are obsolete. But why do we need such narrow definition? My understanding is that we want a well defined set of Internet standard protocols, with minimal ambiguity. Non-standards RFCs are not made Historic while obsoleting, according to 2026. that is correct. and I do not see anything wrong with it. Moreover, such status will just duplicate the obsoleted-by one. When there will be the attempt to revise RFC 2026, we should put there that Historic status is to be assigned to that documents that are considered to be deprecated. I fully share the opinion of Doug here. As for NETBLT, I am strongly against moving it to Historic, rather than specifying by Standards Track Document. unless there is clearly identified need for a protocol like NETBLT (as its name suggested, it is a specialized protocol for bulk data transfer only), I do not see the need to move NETBLT to standard. In case such a need is identified, personally I think we need a clear problem statement first, so that we better understand the context the protocol will be applied to. We (the MIT crew at the time) did various trials of NETBLT after the RFC998's publication, and collected a list of issues for further investigation (of course we did not do it, as everyone moved on to other burning fires, and NETBLT served its purpose of proof-of-concept). There has been one attempt to do that by John White in 1995 (see draft-white-protocol-stack), but IMO (that likes strange, but...) we can align this document with the most current needs of Internet and publish. Mykyta -- 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: Old transport-layer protocols to Historic?
On Jan 7, 2011, at 9:13 PM, Mykyta Yevstifeyev wrote: 07.01.2011 21:53, Bob Hinden wrote: Mykyta, On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote: Hello all, There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. I see little value even thinking about this. It's looks like a make work project to me. Just because something is old, doesn't mean it is historic in the sense the label is used in the IETF. Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental. I do not see any reason to change that. Bob Dear all, RFC2026 mentions: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted (superseded) or 2) obsolete. Obsoleted = made obsolete. This is obvious. When one RFC replaces another, it obsoletes it, and second becomes obsolete. What is obsolete (adj.)? Obsolete = deprecated, outdated, out of use, non-current, etc. Moreover, RFC2026 does not set any other guidelines for setting the Historic status. that is because only standard track protocols need such guidelines That is why if the protocol is out of use, even specified by Experimental RFC, it is a reason to move its spec. to Historic, in accordance with RFC2026. First, you said RFC2026 did *not* say anything on moving non-standard protocols to Historic status. Then you said Experimental RFCs need to move to Historic, in accordance with RFC2026. Doesn't this sound self-conflicting to you? Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-white-tsvwg-netblt-00.txt
On Jan 8, 2011, at 7:46 AM, Mykyta Yevstifeyev wrote: 08.01.2011 17:37, Lixia Zhang wrote: I am not sure why this rush to get a new internet draft out, without consultation to any of its original authors, and given the rough consensus on ietf mailing list discussion is to keep NETBLT RFC as is (experimental). First of all, I've consulted the initial author of it, John White, and some other people off-list. With all the respect to John, he is not among the original authors of NETBLT RFC. Wonder if you can tell me who are the other people that you contacted? The NETBLT spec found in RFC998 *as is* could not be appropriate for current Internet, It was not meant to. It's for discussion and comment. As I already quoted this in my earlier msg: RFC998 stated clearly that This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. so there is a need for another one. In the next 3 months, I think, we will be a work on it. Moreover, we plan to submit it as Independent Submission as Experimental RFC, despites it mentions the Standards Track one. Mykyta I am confused here: in your message posted on Jan 7 (2 days ago), http://www.ietf.org/mail-archive/web/ietf/current/msg65041.html you said As for NETBLT, I am strongly against moving it to Historic, rather than specifying by Standards Track Document. There has been one attempt to do that by John White in 1995 (see draft-white-protocol-stack), but IMO (that likes strange, but...) we can align this document with the most current needs of Internet and publish. Mykyta but now you changed your mind? Lixia Lixia On Jan 8, 2011, at 3:00 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Block Transfer Protocol (NETBLT) Author(s) : J. White, M. Yevstifeyev Filename: draft-white-tsvwg-netblt-00.txt Pages : 34 Date: 2011-01-08 This document is a specification of version 5 of Network Block Transfer Protocol (NETBLT). This protocol was firstly specified in RFC 969, that has been made obsolete by RFC 998. Nevertheless, none of these documents match current Internet Standards and are deprecated. This document aligns the NETBLT specification with the most current Internet Standards and obsoletes RFC 998. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-white-tsvwg-netblt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Mail Attachment___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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: Old transport-layer protocols to Historic?
On Jan 6, 2011, at 12:40 PM, Bob Braden wrote: Historic might imply that they were once in service, but have later been replaced/deprecated. In fact, these protocols were always, and are still, *experimental*. It would seem logical to assign them the Experimental category and be done with it. Bob Braden I would like to second Bob's position here. as a co-author for NETBLT (RFC998): NETBLT was out of a research effort to answer the question: can we *fully* utilize long delay, high bandwidth (and potentially error prone) networks? NETBLT says and here is one way to do it. Over the years (it's published in 1987) I have received comments from many people saying that they learned something interesting or even useful from NETBLT. The NETBLT paper (SIGCOMM 1987) got cited over 200 times. As RFC998 stated clearly: This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. I don't see any harm to keep it as is. Lixia PS: on the other hand, what would a historical status imply? the ideas obsolete? On 1/5/2011 9:44 PM, Mykyta Yevstifeyev wrote: Hello all, There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic: https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use? Please copy tour answer to ts...@ietf.org All the best, Mykyta Yevstifeyev ___ 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: IETF Logo Wear
On Aug 18, 2010, at 8:28 AM, Ole Jacobsen wrote: But his T-shirt says IP *on* Everything which makes it funnier. http://jboss-uat.crn.com/channel-encyclopedia/definition-print.htm?term=IP+on+EverythingprintType=image Ole my english is not good, but doesn't on carry more significant meaning over over? over only means that ip pkts get carried over (so the everything here only means different carrier) with on, everything can have a much broader range, from your toaster to mars On Tue, 17 Aug 2010, John C Klensin wrote: --On Monday, August 16, 2010 14:39 -0700 Dave CROCKER d...@dcrocker.net wrote: On 8/16/2010 2:30 PM, Fred Baker wrote: or http://www.pdphoto.org/PictureDetail.php?mat=pg=7634 Given that the pun is based on Vint's observing that we had IP running over all sorts of different media, as I recall his comment was IP over Everything. Yes. His comment and his tee-shirt. john ___ 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
On Aug 7, 2010, at 4:15 PM, Michael StJohns wrote: Fred said this much more eloquently than I could. On the IETF78 attendees list there's been a lot of discussion about where to meet - with the primary consideration seeming to be pretty and small.I may be in the minority, but I'd really rather the IETF go places where the ability to get work done is the primary consideration. I'd like to second Mike here. admittedly I'm a boring type, my preference is a more or less fixed set of meeting locations (Minneapolis is just fine), one knows exactly what to expect, easy to plan. Perhaps easier on IAOC as well. However one of the few fundamental truths about Internet is its diversity, that applies to the community as well, hence those who desire pretty and small. I expect we end up in some kind of engineering decisions, trying best to accommodating different interest with well informed tradeoffs. Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On Jul 17, 2010, at 8:48 AM, Dave CROCKER wrote: Folks, Nomcom has been an integral part of the IETF for nearly 20 years. A number of us have been developing a set of recommendations designed to adapt the Nomcom process to better match current realities of the IETF community. The draft has progressed far enough to call for public consideration. Some of the proposal's recommendations require no changes in formal rules. They can be adopted immediately, possibly by the current Nomcom, should it so choose. Others require a formal development and approval cycle. At: http://www.bbiw.net/recent.html#nomcom2010 there is a copy of the Full Proposal, and a Summary which primarily contains just the recommendations. .. Please feel free to discuss the proposal with any of the authors or folks listed in the Acknowledgments section, or on this list. I read the summary version of it: seems to me a timely effort in improving our process. it'd be great if we could do this for next nomcom:) One comment, then one new suggestion for you to consider. The comment: I support the idea of having a second 'expertise' pool of volunteers, but I wonder where comes this suggestion of selecting *3* members from this pool. A few random questions: - Do we know what is this number for the last several NOMCOMs? - Assuming ISOC keeps the records of NOMCOM volunteers over time: what percentage of volunteers that would fall into this second pool? - Did this number 3 come from a rough expectation on how many NOMCOM members should have this direct involvement in the process of IETF leadership (IAB/IESG/WG chair)? e.g. say you expect total 5 people with experience, you pick 3 from 2nd pool first, then expect 2 more from the bigger pool ... Personally I feel (1) there should be a expected low threshold of NOMCOM member with this direct IETF leadership experience, and (2)this threshold should be higher than 3. Now the suggestion: Since some of the suggested enhancements would require modifications to 3777, I'd like to bring up another thought I've had for a long time: the current NOMCOM eligibility requirement (3 of the last 5 IETF meetings) seems a bit low, I feel that a longer experience with IETF process than 2 years (as minimum) requirement could help NOMCOM's decision process, as IETF is already over 24 years old now with a pretty long and rich history. Take into account the fact that many people probably do not attend all IETF meetings, as a strawman for a longer IETF experience, what about attending 5 of the last 8 or 10 meetings? that's all for now, and thanks to all for doing this important work! Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom Enhancements: Improving the IETF leadership selection process
On Jul 18, 2010, at 2:06 PM, Dave CROCKER wrote: Lixia, On 7/18/2010 1:14 PM, Lixia Zhang wrote: The comment: I support the idea of having a second 'expertise' pool of volunteers, but I wonder where comes this suggestion of selecting *3* members from this pool. A few random questions: - Do we know what is this number for the last several NOMCOMs? The last two Nomcom Chairs were part of the design team for the proposal. As I recall, Joel actually ran some of these kinds of numbers. I don't remember the details he produced, but they were part of our consideration and we definitely all haggled quite a bit about the number to recommend. If Joel already got the numbers, it seems useful to know. What about my other question, what percentage of volunteers over the last few years that would fall into this second pool? This would help understand the feasibility of the idea (i.e. the 2nd pool still needs to be large enough) There was a remarkable amount of support for 3, bordering on unanimity. (Exercise to the reader: take a guess who was the odd one out...) The reason for preferring 3 was balancing a desire to ensure a /minimum/ level of knowledge but also to limit the amouont of /dominance/ of old-timers. So the feeling was that two was not enough to meet the minimum, but requiring four would start feeling like dominance among the voting members. four is still less than half of voting members, not dominance? Take into account the fact that many people probably do not attend all IETF meetings, as a strawman for a longer IETF experience, what about attending 5 of the last 8 or 10 meetings? Speaking only for myself, I'll say that it's quite easy to go to many IETF meetings, but never learn anything about IETF process. the above statement applies in general, independent from the NOMCOM eligibility criteria. When someone has the responsibility for choosing the people who manage the process, we ought to focus on ensuring that level of knowledge. Hence the second pool. and I support the second pool idea I've been on 3 Nomcoms. Some of the folk who did not know much IETF process were nonetheless very strong contributors. Some weren't. The key argument for retaining this less experienced criterion is that it tends to add some fresh perspective (along with the naivete... so it's a mixed benefit.) - definitely people can all be strong contributors, with or without much IETF knowledge. - I think an effective NOMCOM does require some minimal IETF knowledge from its members. - fresh blood is always important. Even 5 out of last 8 meetings allows one with just 2-year IETF experience. Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
On May 14, 2010, at 12:48 PM, The IESG wrote: This is an update to the Last Call that is currently in progress. The IESG is considering the following Statement on the Day Pass Experiment. The IESG plans to make a decision in the next few weeks on this statement, and the IESG actively solicits comments on this statement. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-20. 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. I support the IESG statement below. In particular, I note that this statement is specifically regarding the NOMCOM volunteer eligibility for meeting participants with day-pass registrations; it's not about participants with student status. I believe student participants should continue to follow the current rule regarding their NOMCOM volunteer eligibility. Lixia PS: Full disclosure: I was a graduate student in my first few years of IETF meetings. PPS: My understanding is that, as of now, IETF meetings have very small number of student participants (Ray can correct me here if I get it wrong). If this number ever goes up significantly, it may deserve a reconsideration. = = = = = = = = RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings. The IAOC is conducting a day pass experiment, making it necessary to clarify the NomCom eligibility rules to address IETF participants that make use of a day pass. An update to RFC 3777 will be needed to address this situation if at the end of the experiment the IAOC decides to make day passes a regular meeting registration alternative. This statement provides guidance until an update to RFC 3777 is proposed, reviewed, and approved. The eligibility requirements of volunteers for NomCom voting member positions are provided in RFC 3777, which includes: 14. Members of the IETF community must have attended at least 3 of the last 5 IETF meetings in order to volunteer. In the context of the day pass experiment, this is interpreted to mean: 14. IETF participants must have attended at least 3 of the last 5 IETF meetings in order to volunteer. Use of a day pass for meetings prior to April 2010 counts as IETF meeting attendance; however, use of a day pass for meetings after to April 2010 will not count as IETF meeting attendance. ___ 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: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
On Jun 11, 2009, at 11:45 AM, Bob Hinden wrote: Joe, 1) exposing the full list to the entire community invites lobbying the nomcom This probably already happens to some extent, but do we really want to encourage this? It's not clear this will lead to more lobbying than we have now. I think lobbying happens a lot now and is driven by the candidate him/ herself, or the many people who get the secret lists. I think it would be more balanced if everyone knew. Belated, I too agree that the change to publicizing nominee list is a better way for the community. I would add that the current system gives a greater ability to comment on candidates to the leadership (IAB/IESG/WG Chairs) because they get the many of the secret nomcom candidate lists. well, the names they got were also padded up for the protection purpose, and the padding caused some confusions too. The nomcom might get broader feedback if the lists are open. Bob well said. Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Christian, I want to say thank you for the comments! In fact I wondered whether people noticed this draft as there had been no comment till this msg showed up. On Mar 18, 2009, at 9:44 AM, Christian Vogt wrote: Lixia, David, and all - I think it is very useful that IAB is taking position on the issue of NAT in IPv6. And it is great that you, Lixia and David, have documented this position. Below I have one comment on the document. I admit that the comment is a bit hypothetical, but I do believe it is worthwhile to be considered in the discussion around IPv6 NAT. On page 9, you state, based on a citation from RFC 4924: We believe that providing end-to-end transparency [...] is key to the success of the Internet. I think this statement needs elaboration. Let me first quote the RFC4924 text here so people can see the context of this discussion: As [RFC4924] states: A network that does not filter or transform the data that it carries may be said to be transparent or oblivious to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success. To me this essentially stated that network, please let users data go end-to-end and stay intact End-to-end transparency is not a reason for the success of the Internet. Instead, it is a requirement that follows from the overloading of identification and location semantics onto IP addresses: It is exactly those applications that pursue this overloading, in form of address referrals, which have difficulties with the lack of end-to-end transparency. I believe that people in general agree that applications should not use IP address for referrals. As RFC1958 Architectural Principles of the Internet (June 1996) stated: 4.1 Avoid any design that requires addresses to be hard coded or stored on non-volatile storage (except of course where this is an essential requirement as in a name server or configuration server). In general, user applications should use names rather than addresses. Maybe it's too late so my brain got foggy, however between these two issues, (1) keeping user packets intact as they transit through the network, and (2) applications using address for referral I do not see that (2) is a consequence of (1), as you seem to believe. Since the comments below seem trying to justify for IPv6 NAT, I would also like to point out the following text in draft-iab-ipv6-nat-00: If we accept the view that some, but not all, parties want IPv6 NAT, then the real debate should not be on what benefits IPv6 NAT may bring. As every coin has two sides, it is undeniable that network address translation can bring certain benefits to its users. However the real challenge we should address is how to design IPv6 NAT in such a way that it can hide its impact within some localized scope. If IPv6 NAT design can achieve this goal, then the Internet as a whole can strive for (re-installing) the end-to-end reachability model. The draft did not take any position on 1:1 NAT; it simply stresses the importance to strive for (re-installing) Internet's end-to-end reachability model, if/when one designs IPv6 NAT. And I believe you too agree with this. Lixia (no hat on) Of course, this is not to mean that NAT, as used in IPv4 today, would be a harmless technology if we had a clean identifier-locator separation. But this is because IPv4 NAT does more potentially harmful things apart from removing end-to-end transparency. The reason for the harmfulness of IPv4 NAT is not the address rewriting by itself; it is that IPv4 NATs multiplex multiple internal addresses onto a single external address. This address overloading is causing problems that wouldn't go away even if we had a clean identifier-locator separation -- problems in terms of reduced host reachability, reduced network robustness, and a limitation to connection types with en-route-modifiable port numbers. The reason why address overloading causes these problems is that it (a) makes addresses ambiguous and, for the purpose of disambiguation, (b) adds per-connection state to the network. Now, assuming we had a large enough number of addresses for a one-to- one mapping between the internal and external addresses of a NAT, the NAT could do simple address rewriting without address overloading, hence avoiding aforementioned problems. If we further assume that we had a clean identifier-locator separation, then why would it matter that simple address rewriting causes a loss of end-to-end transparency? Why would it matter if a locator changes en route for a packet if both the old and the new locator map unambiguously to the same identifier? I
Re: Comment on draft-iab-ipv6-nat-00
On Mar 18, 2009, at 5:07 PM, Christian Vogt wrote: Scott - Feynman is absolutely right, and certainly a network should enable future, unknown applications. But your conclusion that end-to-end locator transparency is a requirement to build such a network does not convince me. This said, there is no question that end-to-end locator transparency is a critical property in the Internet we have. (And this was, after all, was the point that Lixia and Dave were making.) Hi Christian, I will get back to your original comments in the next msg, but I feel the need to first correct potentially a very big error in the above: would you please kindly point to the exact text in draft-iab-ipv6- nat-00 that either stated or implied end-to-end *locator* transparency, as you attributed to the draft? I do not recall the draft mentioned the word locator at all. Lixia My point was that end-to-end locator transparency is not the /reason/ for the Internet's success, because you could build networks that function perfectly fine without it. E.g., a network with identifier-locator separation. - Christian On Mar 18, 2009, Scott Brim wrote: I invoke Feynman and the philosophy of ignorance. The reason you want e2e transparency is because you do not know what it might enable, and we want that. We _want_ to have uncertainty about what the future of the Internet is. We do not know what advantages or restrictions our decisions will bring in the future. The richness of the Internet experience has come about because we have given end users the capability to develop new ways of using it, and somehow managed to have got out of the way, so far. Feynman said (among other things -- search for it): Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our responsibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that will stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, proclaiming “This is the answer, my friends; man is saved!” we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination. It has been done so many times before. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] SAVI/SHARA/BEHAVE/AUTOCONF/LISP conflicts (Was: Re: 74th IETF - Agenda)
On Mar 5, 2009, at 12:47 PM, Dave Thaler wrote: I would expect a big overlap in interest in SHARA vs V6OPS too (for example I need to be in both). So even if you move any one of SHARA/V6OPS/SAVI, there'll still be issues. scheduling is hard... if I could get my wishes: I wish to resolve the overlap between 6AI and GROW, both are scheduled Thu 9-11:30AM at this time. -Original Message- From: iab-boun...@iab.org [mailto:iab-boun...@iab.org] On Behalf Of Fred Baker Sent: Wednesday, March 04, 2009 12:42 AM To: Jari Arkko Cc: wgcha...@ietf.org; i...@isi.edu; Autoconf Chairs; bofcha...@ietf.org; Behave Chairs; IETF Agenda; savi- cha...@tools.ietf.org Subject: Re: [IAB] SAVI/SHARA/BEHAVE/AUTOCONF/LISP conflicts (Was: Re: 74th IETF - Agenda) SAVI/v6ops on Monday is also a problem. I chair one and am a draft author in the other. On Mar 3, 2009, at 5:53 AM, Jari Arkko wrote: Monday: SAVI and SHARA conflict is bad from my perspective, but I could live with it by skipping SAVI :-( if needed. However, Marcelo is the key author of SAVI, and also a chair of SHARA. This conflict needs to be resolved... Tuesday: AUTOCONF and BEHAVE is bad from my perspective, but I can live with it if the BEHAVE IPv4-IPv6 work is not in this slot. Wednesday: LISP and BEHAVE are in the same slot. I'm the AD for LISP, and if the Behave guys are discussing IPv4-IPv6 in this slot, that's bad. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
adm plea: avoid/reduce massive cross-posting? (was: Can we have on NAT66 discussion?)
this thread has been posted to *4* mailing list. not sure whether other list adm had the same issue, but rrg adm keeps getting lots non-member posting warnings ... so the msg would not get delivered without manual intervention (i.e. defeating the intention of cross posting) wonder if there is a better way out... Lixia (not complaining, just raising an awareness:) On Nov 13, 2008, at 8:51 AM, Scott Brim wrote: On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on. That's not the problem. The issue is location. Once we have established a session then how the packets are labeled for network layer purposes doesn't matter much (modulo security) but how do we get communications set up in the first place? Suppose I want to reach foo. Who do I ask to find a locator for him? Split DNS works fine when there are just two states, inside and outside -- a DNS server can be configured to know how to respond in each case. But if you were to sprinkle NATs all over the Internet there would be no place that could give a confident answer about how I, over here, should name foo in the network layer in order to get a packet to him, and have that answer get to me in the correct form. So it is very important to understand where we think it might be safe to put what kinds of NATs. swb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: MP3 support for Friday afternoon
On Aug 3, 2008, at 9:39 AM, Marshall Eubanks wrote: MP3 service was lost during the RRG meeting Friday after lunch. There were several remote attendees, and they complained on jabber, so this was loss was felt. It really doesn't matter now whether this was planned or an accident, but I would urge either that meetings held on Friday afternoon have this support (even if it has to be run from someone's laptop), or that meetings not be held Friday afternoon. Regards Marshall I'd second this request for paying more attention to Friday meeting arrangement in general. Not only the MP3 was gone in the afternoon, but also the hotel people turned off the meeting room microphone during the afternoon break. Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: About IETF communication skills
On Jul 31, 2008, at 9:52 AM, JORDI PALET MARTINEZ wrote: I understand that IETF has not done a good job in communicating about our work and I appreciate that this is being improved, however I think we need to be very careful. Yesterday, during dinner, one of the discussions with my colleagues, was about this topic. Some considered that part of the delay of the IPv6 deployment was due to the lack of communication effort from IETF. I'm not really sure about that, however I agree that everything helps, of course. My consideration is on the other way around about the latest press about IPv6 and NAT. Obviously the press is not presenting the info in the right way, but this is our fault. I don't think anybody from the community, or the IETF organization has the right to do and interview, and speak on behalf of the community and NOT make sure to review the interview BEFORE it is published. In my opinion is a big mistake and a lesson to learn, because in this case the damage to IPv6 deployment is possibly much higher than what we as engineers could foresee. I'd like to share my own experience here: I was interviewed by exactly the same reporter some time ago, and I requested to review the article before publication. But the very next thing I learned was that the article had been published, and the interview misquoted. I questioned the reporter why she ignored my request, the reply was that it was the magazine's policy not allowing preview --- something they never told me beforehand. One lesson learned. Lixia ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Mar 17, 2008, at 11:38 PM, Fred Baker wrote: On Mar 17, 2008, at 10:05 PM, Lixia Zhang wrote: Call me an idealist:), I personally believe, generally speaking, it is better to put everything on the table, rather than partial info, between nomcom and confirming body. Step up a level: wonder where this discussion is leading to? Exactly how to revise 3777? It sounds like you would rather get rid of the nomcom and have the confirming body do the work from the start. Actually to the opposite: I firmly believed it is the nomcom who makes the selection. If you quote my full messages, I said First of all, I fully agree with others it should be the candidate's choice about what to disclose to whom. Just that personally and for myself, I would not mind whoever I had concern with to know about it. I have heard it said that the IETF, in the most recent discussion that failed up update that portion of what we now call 3777, had a 90/10 consensus and didn't come to a perfect consensus. I did not participate in 3777 formation. If above is the case, my own vote would be that 90/10 is a lot more than a rough consensus, and we should just write down precisely what that is. I think we have to say what the role and reach of the confirming body is, which may require us to think hard about what it means to have rough consensus. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Mar 17, 2008, at 7:08 PM, Steven M. Bellovin wrote: On Mon, 17 Mar 2008 18:44:49 -0700 Christian Huitema [EMAIL PROTECTED] wrote: And in order to make the confidentiality issue more concrete (ie, real) would folks offer some examples of what falls under it. I accept the nomination of area director. The current area director, Mr. J. Sixpack, has been attempting to impose his opinion that beer should contain rice. This is causing a rift in the working groups within the area. I would follow the area consensus that we should outlaw rice in beer and thus my appointment as new area director would achieve peace and harmony within the area. Why should such a statement be confidential? Try this one, quite non-hypothetical: a candidate for the IESG is contemplating switching jobs. His or her current employer does not yet know this. It has a clear bearing on whether or not that person can do the job of AD, but equally clearly should not be broadcast to the world. - it could be the case that one of NOMCOM members were in the same company withe the candidate - and the confidentiality rule protects the candidate, right? - shouldn't/isn't the confirming body bounded by the same confidentiality rule? Lixia ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Dec 15, 2007, at 6:59 AM, Stewart Bryant wrote: What's the worst that can happen - we have to listen to the plenary speakers without jabber sessions? That would be pretty major! We have had PWE3 contributors who were unable to be present in the meeting, listen on audio and use IM for questions. Lets do the experiment, but lets not run it in prime time until we know how it will impact productivity. I thought the main point is to do it in prime time. By giving such an advanced notice, the hope is probably to get more v6 work done to get ready, as a push towards IP6 deployment. Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
On Dec 2, 2007, at 9:49 AM, Frank Ellermann wrote: John C Klensin wrote: Of course, YMMD and, in particular, you might consider this potential problem to be important enough to have other criteria. The enhanced NOOP discussion on the SMTP list just reminded me that we're talking about protecting IANA, RFC editor, and Trust from legal enforcement. Frank I'm late getting into this discussion, but also have the advantages of seeing arguments on all side at once :-) it seems to me that the final decision on this issue would be a tradeoff in a multi-dimension space: - how much gain vendors/users may get from publishing an RFC at time=T vs at (T + 2 months) in particular if the publication is tagged with some provisional clause. - how strong is the desire of wanting the published RFCs to be stable (i.e. minimizing the chances of reclassification, with an understanding that we cannot completely eliminate the chance) - As pointed out above, what may be the legal complication, if there is any, in handling appeals against a published RFC, and remedy the situation when an appeal succeeds. I too first thought that the process ought to be optimized for the majority cases. I now realized that the optimization should be based on the weighted percentages: (% of no-appeal cases) X (gains from publishing 2-month earlier) versus (% of appeal cases) X (chance of an appeal succeeded) X (cost from any potential legal complications and remedy) The remedy here may also include the cost to those people who acted on a published RFC in its first 2 months. so the question to me is really: can we quantify the values of those weight factors? (as an academic I dont have a lot clue here) Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Daily Dose version 2 launched
Hi Henrik, here is my 2 cents: every time when I go to tools page is because I'm looking for some tools, but not news. Assuming others go there for the same purpose, then one main goal is to ease the tool searching, right? instead of daily dose being the front page, what about treating the daily dose just as an item (that's a tool in some sense:), and make the content of http://tools.ietf.org/tools/ the front page? for me that can be a speedup Lixia Hi Joel, On 2007-11-02 18:00 Joel M. Halpern said the following: I second John's note. When I saw Pasi's note, I had assumed that he was referring to a link off of the tools page. Replacing the tools page with an activity summary is quite surprising. Joel Hmm. I'm not sure exactly what's the issue here, so let's try to explore this and see what we can find out. Essentially, the change is two-fold: 1. The old lefthand list of links have been replaced by the same lefthand list of links which appear on all the WG and other tools pages, making for one less list of links to keep up-to-date manually. This has been in the works for quite some time; I've tried to poll people on it, and most people seem to be happier with the lefthand menu on the WG pages than the front page menu. 2. Replacing the static text on the first page with a news item page. The static text that was replaced was as follows: -- - Welcome to the IETF Tools Pages These pages are maintained by the IETF Tools Team. The aim of these web-pages is to help the IETF community as follows: * Make it easy to find existing tools * Provide means of feedback on existing and new tools (wiki and mailing list) * Provide information on new and updated tools If you have comments on these pages, or ideas for new tools or for refinement of current tools, please send them to tools- [EMAIL PROTECTED] For current tools, there may also be a page in the IETF tools wiki (in addition to the tools page you can reach through the menu to the left) which summarises proposals and known deficiencies - feel welcome to check this out, and contribute your information! -- - The way I see it, replacing that with a news summary would be a good idea. The text above was appropriate when the tools pages were being established; they are now used by a lot of people, and the text above seems to be a bit superfluous. I could be wrong about that, and if so, an indication of how you feel about the old and new page would be good. Some options are: - You would specifically like to keep the text above (or some modification of it). - You agree that it's time for a re-working of the front page, but you don't want to have the latest happenings on the front page, you want them as a separate news page. - You don't care too much what's at the front page, as long as it's not too heavy-weight -- the major objection isn't to the news page as such, but to the increased size of the page *for you personally as a consumer of the page* - Some other option which I haven't understood the importance of yet, which you will be able to formulate better than I can here :-) Please speak up and indicate as specifically as you can what's good and bad about the change, and how we can improve it; and we'll try to make it so! Regards, Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Sep 18, 2007, at 8:09 AM, Tony Hain wrote: Jari Arkko wrote: Lixia, I'm just catching up with this thread today: If I summarize my understanding from the above in one sentence: there seems a perceived difference between PI and ULA-C prefixes, which, as far as I can see, does not exist. Whether a unique prefix is/not globally routable is determined by whether it gets injected into the routing system, no matter how it is labeled. Right. Or we can try to label it, but that labeling may not correspond to what is actually done with it. If you don't label it there is no clearly agreed way to filter these out if you don't want them. I'd agree that, ideally speaking, one would prefer using simple filtering rules. However as Jari already pointed out, whatever label one puts on a prefix may not correspond to what is done with it, *especially* as time goes. (a motto I heard from my high school son, the only thing that does change in life is change :-) and I would not attempt to bundle opinions regarding UCL-C and PI (I saw Ted already showed an example). Furthermore, we are all in this continuing process of understanding their implications in this complex, exciting, and constantly changing Internet. The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Sep 13, 2007, at 3:16 AM, Jari Arkko wrote: Roger, On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it ... The question on the table (and also part of 6man charter) is whether we need an additional type of ULAs, one that is centrally allocated. Such addresses might be useful for a couple of reasons. One reason is that we could guarantee uniqueness, which might be important, e.g., for a company that is running a lot of small company networks as a business, and wants to ensure the address spaces do not collide. But another, more important stated reason was that we should have a way give people address space that is different from PI in the sense that those addresses are not recommended to be placed in the global routing table. Arguments against such address space relate to the following issues: - The costs for any centrally allocated space are likely going to be the same, so what is the incentive for the customers to allocate ULA-C instead of PI? - There is no routing economy that would push back on advertising more than the necessary prefixes, so what is the incentive that keeps the ULA-C out of the global routing table as years go by? (When the companies that allocated ULA-C grow, merge, need to talk with other companies, etc.) The end result of our discussions was that we clearly do not have agreement on the way forward, and we settled for writing a draft about the issues instead. That is still in the works. I'm just catching up with this thread today: If I summarize my understanding from the above in one sentence: there seems a perceived difference between PI and ULA-C prefixes, which, as far as I can see, does not exist. Whether a unique prefix is/not globally routable is determined by whether it gets injected into the routing system, no matter how it is labeled. Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of running code (was Re: Do you want to have more meetings outside US ?)
.. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). forgive me for jumping into the middle of a discussion (and I did not know which of the lemonade doc's the above referred to), but my past experience seems suggesting that an attempt to implement a not well understood idea is a good way towards a better understanding of how to make the idea work, or what can be potential issues. IMHO, running code gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. running code was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. it seems to me the above argues that running code is necessary, but not sufficient as evidence of a sound design. (well, that is the interpretation; I have not seen anywhere a claim that running code is sufficient, but rather simply to filter out the weed) Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: e2e
On Jul 26, 2007, at 4:37 PM, Scott Brim wrote: On 07/26/2007 19:20 PM, John Kristoff allegedly wrote: Responding to something just overheard in the plenary... No, it's not about complexity, but nor is it about robustness. It's about functionality and where to place it. A simple word search should help highlight this point. I'm not there this time but ... where you place functionality has a direct impact on complexity and robustness. Scott is right. Where to place functionality has an impact on complexity, in addition to robustness. BTW for everyone's convenience, here are the pointers to the two Clark papers mentioned: End-to-End arguments in System Design ACM Transactions in Computer Systems 2, 4, November, 1984 http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The Design Philosophy of the DARPA Internet Protocols http://nms.csail.mit.edu/6829-papers/darpa-internet.pdf SIGCOMM '88 Could it be that whoever it was was making an inference? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Audio streaming and slides suggestion
On Nov 15, 2005, at 10:27 AM, Joel Jaeggli wrote: Of course, I have suggested before on this list that the IETF consider using some sort of on-line whiteboard technology, which would allow for real time viewgraph production and annotating, which also has its uses. Whiteboard sounds good idea to me, but maybe new undesirable things come with it (variable RTT per user is one). As Joel mentioned below, wb was in use for a few years back in early/ mid 90's. In addition to IETF we used it extensively in research discussions among remote collaborators. Variable RTT did not seem to be an noticeable issue. Back when things were being multicast with vic and vat we used wb as well though as far as I recall it was used almost eclusively by the remote participants (though that does predate the significant use of wireless at the IETF). the display device at the meeting location might be the issue. Sitting in the office individual can use his/her desktop/laptop to draw/type/input PS files to the wb, but the meeting room needs a big size display that everyone can see (this was before the day of projectors). Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
a msg to someone who may not see it
starting Thursday 3PM I stopped receiving messages from all ietf- related mailing list. Turned out this was a result of megatron.ietf.org getting on spamcop's black list. I doubt our dept is the only place using spamcop's black list, wonder who else may be missing email without knowing it. Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Suggest new mailing list for IASA stuff
On Dec 9, 2004, at 8:41 AM, Michael StJohns wrote: The IASA, AdminRest et al discussions appear to be proceeding well, but perhaps it might make sense to craft a mailing list specifically for those discussions ? I would like to second this suggestion. Its possible the recent (last 2 week) upswing in the number of related posts to the ietf mailing list will die down shortly, but my guess is not. Later, Mike ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Datagram? Packet? (was : APEX)
Lets just get some FACTS straight out On 9/28/02 3:29 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 06:20:59 +0859, Masataka Ohta said: RSVP establishes the per-flow state before the packets can flow. I missed Ohta Son's original post, thanks to Valdis for catching this incorrect statement. IP packets can flow anytime. If/when deployed, the existence of an RSVP reservation is expected to improve the delivery quality of those IP packets, and the lack or breakdown of that reservation simply leaves the packets with their regular best effort delivery. It is just a minor engineering decision to allow optional circuit switched service over a best-effort-capable network. 1) I wasn't aware that RSVP caused packets to be routed according to a flow ID contained in the packet rather than the IP address in the packet. 2) If an intermediate router handling an RSVP connection decides to die an interesting death, packets can still be sent (assuming things like multihoming and BGP convergence) and successfully arrive before a new RSVP setup completes. It doesn't sound like a circuit-switching scheme, it sounds like a resource reservation scheme to guarantee sufficient bandwidth. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Re: Bandwidth? BANDWIDTH. We don't need no stinking bandwidth
On 1/21/02 3:00 PM, Dan Kolis [EMAIL PROTECTED] wrote: Of course its true: no amount of QOS can generate any additional bandwidth (That's what Multi Protocol Labeling Switching is for!) Hmm, wonder if QOS here might imply different things ... Put aside the history where it came from, MPLS finally did find a need for it: as the Internet topology gets more and more richly connected, there is a need to spread out traffic over all existing connectivities in some controlled way. There is the adm-control and BW reservation side of QOS, but in case of MPLS, it also helps with the above issue. Note I am not saying MPLS is the right solution for the problem. To me the right solution to the above mentioned problem should be a multi-path routing protocol. My 2 cents (and stop, don¹t mean to join another round of MPLS bashing) Lixia
Re: comments on Friday scheduling (was Plenaries at IETF 53)
On 1/17/02 12:03 PM, Michael Mealling [EMAIL PROTECTED] wrote: ... The two negatives are that a) some people do not work on Sunday, and 2) those currently traveling to the IETF on Sunday would be forced to do it on Saturday. That said, there are enough people who take advantage of the Saturday fare benefit to make it worth considering using Sunday for WG meetings. But most of those who do this also use Sunday to have pre-IETF meetings. I've known several folks who have Sunday booked solid with business/design-team/etc meetings weeks before the actual IETF begins. I would personally prefer extending into Friday... -MM If talking personal preference... I would rather prefer not to have anything officially scheduled on Sunday since that fundamentally requires we leave for the trip one day earlier. Friday is not too good either. How about moving the social to Monday evening, and have Tue and Wed evening for the two plenaries? Lixia
Re: Helping the research community
At 02:32 PM 8/29/00, Beni Arazi wrote: Somebody just made a comment: "While the last thing I want to do is promote the use of the IETF list as a network help line..." There is nothing wrong in giving, for free, good professional advices to research students and start-up personnel, as a service to the community. This is especially true when observing that many of us have all the time in the world to discuss, in dozens of mails, much more important issues like how to number elevator buttons. That might be true for some, but I believe that is NOT true for many more others. For those research students: at the SIGCOMM executive committee meeting yesterday we talked about exactly this need for developing an online community to help students, and anyone else interested, with information/discussion/advice on networking and related research. I hope that will help remove the "help-line" function away from ietf list. Actions will be taken quickly, stay tuned. Lixia (when we are ready, would we be allowed for just one announcement on ietf list? :-)
