Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
C. M. Heard wrote: How does one tell, in principle, that the source IP address (ar$spa) in an ARP packet is in fact spoofed? Not without cryptographic authentication, in general. But for this particular issue, not updating the local cache based on snooped ARP exchanges (i.e. what Linux does) may make sense. Also, under this particular misconfiguration, there'll very likely be two ARP responses for a lookup of the IP address in question, so maybe could be used as an indicator that there's a problem. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Jabber BOF afterthoughts
At 1:06 PM -0500 7/20/02, Pete Resnick wrote: Anyway, given that they actually want to get work done under the auspices of the IETF, I see no justification for turning them away. Given that this is a deployed product, I tend to agree. The work is going to get done; we may as well help it to get done as well as possible.
Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
From: Lars Eggert [EMAIL PROTECTED] How does one tell, in principle, that the source IP address (ar$spa) in an ARP packet is in fact spoofed? Not without cryptographic authentication, in general. But for this particular issue, not updating the local cache based on snooped ARP exchanges (i.e. what Linux does) may make sense. Also, under this particular misconfiguration, there'll very likely be two ARP responses for a lookup of the IP address in question, so maybe could be used as an indicator that there's a problem. If you ignore gratuitous ARP, then what happens when a station goes down and then comes back up with a different MAC address? That happens when the station is given new hardware or in some fail-over schemes. Vernon Schryver[EMAIL PROTECTED]
Re: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
On 7/23/02, Vernon Schryver wrote: From: Lars Eggert [EMAIL PROTECTED] How does one tell, in principle, that the source IP address (ar$spa) in an ARP packet is in fact spoofed? Not without cryptographic authentication, in general. But for this particular issue, not updating the local cache based on snooped ARP exchanges (i.e. what Linux does) may make sense. Also, under this particular misconfiguration, there'll very likely be two ARP responses for a lookup of the IP address in question, so maybe could be used as an indicator that there's a problem. If you ignore gratuitous ARP, then what happens when a station goes down and then comes back up with a different MAC address? That happens when the station is given new hardware or in some fail-over schemes. There are some simple confidence counter techniques that would filter out most spoofs but still allow fail-overs. Basically, you use some simple counters and state variables to detect when an IP address is being repeatedly switched to one MAC address, and then back to the original value. When this is detected the original mac address could then be queried to confirm that it indeed thought it was the IP address in question (just in case this is some sort of migration feature and the flip-flopping was valid). You could probe the original MAC address on *any* change, but that could prove nasty on a large subnet. Having a designated ARP validator on a subnet might make sense if a network administrator was trying to prevent unauthorized use of IP addresses on their network. It's much easier to deal with spoofed source IP addresses on a network basis than from inside one host. At the network level the source IP address can be cross-checked against the physical link it arrived on. Even with automatic fail-over, the network administrator should know where an IP address *could* come from. This is especially true of the IP addresses most worth stealing.
Re: Jabber BOF afterthoughts
Anyway, given that they actually want to get work done under the auspices of the IETF, I see no justification for turning them away. Given that this is a deployed product, I tend to agree. The work is going to get done; we may as well help it to get done as well as possible. i have no useful knowledge or opinion on the actual technical subject, so my points may already have been answered. but the reasons given above seem sufficient to put us in the paperclip standards making business. i submit that relevance, expertise, non-conflict with other standards groups, change control, etc. are important criteria. randy
Re: Jabber BOF afterthoughts
At 08:18 AM 7/23/2002 -0700, Randy Bush wrote: Anyway, given that they actually want to get work done under the auspices of the IETF, I see no justification for turning them away. Given that this is a deployed product, I tend to agree. The work is going to get done; we may as well help it to get done as well as possible. but the reasons given above seem sufficient to put us in the paperclip standards making business. Indeed. Proven technical base, motivated workers and ready market for products using a specification. Those certainly are a lousy basis for forming an IETF working group. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
the way an I-D takes
Hi, what further way goes a submitted and published internet draft after a short period of discussion? In mid may we published a draft named draft-kretschmann-kai- sighttp-00.txt and got at least some responses. After waiting for 6 month the draft vanishes from the ietf sites, am I right? So what can one do to get this or any draft some steps forward? I heared there is/was a ietf meeting, are there indepenend drafts discussed, too? Any further ideas welcome, either by email or via our small discussion board below to limit the traffic here. Thanks, -- http://www.sighttp.org/
RE: ARPOP_REQUEST with spoofed IP address (joe, turn it off!)
How does one tell, in principle, that the source IP address (ar$spa) in an ARP packet is in fact spoofed? Not without cryptographic authentication, in general. But for this particular issue, not updating the local cache based on snooped ARP exchanges (i.e. what Linux does) may make sense. Also, under this particular misconfiguration, there'll very likely be two ARP responses for a lookup of the IP address in question, so maybe could be used as an indicator that there's a problem. If you ignore gratuitous ARP, then what happens when a station goes down and then comes back up with a different MAC address? That happens when the station is given new hardware or in some fail-over schemes. Let's face it: ARP in insecure. The proposed heuristic don't really help: there is no way to tell which of several ARP responses is the real one. Not using gratuitous ARP helps somewhat, in the sense that an attacker will have to expend more resources, but it also hurts, because there will be no way to flush erroneous values from the ARP cache. In any case, an attacker, or a misconfigured node, can easily send ARP responses to ARP requests for a target address; indeed, it can just as well respond to ping and other requests for that address. The attacker's MAC address will end up in the cache, which won't be flushed for some time... Bottom line: if we want to run ARP in networks that are not protected by some form of physical security, then we need to secure the protocol. I don't know whether expending that energy on ARP is in fact a good idea, since ARP is almost as old as IPv4, and we are moving to IPv6. But for IPv6, there is no question: we should certainly develop a secure vbersion of neighbor discovery. -- Christian Huitema
Re: Jabber BOF afterthoughts
Anyway, given that they actually want to get work done under the auspices of the IETF, I see no justification for turning them away. Given that this is a deployed product, I tend to agree. The work is going to get done; we may as well help it to get done as well as possible. but the reasons given above seem sufficient to put us in the paperclip standards making business. Proven technical base, motivated workers and ready market for products using a specification. Those certainly are a lousy basis for forming an IETF working group. you have an impressive talent for omitting text, twisting people's words, etc. you should run for political office. i also said i submit that relevance, expertise, non-conflict with other standards groups, change control, etc. are important criteria. randy
Re: the way an I-D takes
Kai Kretschmann wrote: what further way goes a submitted and published internet draft after a short period of discussion? urn:ietf:rfc:2026 In mid may we published a draft named draft-kretschmann-kai- sighttp-00.txt and got at least some responses. ...mostly negative, IIRC. -- /\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: Jabber BOF afterthoughts
I certainly agree that relevance, expertise, change control, etc. are important criteria for the IESG to review. I believe a review of the discussion here and the minutes of the BOF session will reveal that each of those criteria are well met cool! However, I'm not clear why non-conflict with other standards groups is a criteria. Care to explain? sure. i'll even do it for free! :-) we don't make ethernet standards, ieee does. we don't make sdh standards, itu does. etc. etc. in this case, i would be careful not to encroach on w3's toes. i have no idea if we would be or not. as to why we are careful not to step on other sdos' toes, well we do not want them to step on ours. there have been incidents of this kind of issue with other sdos, and we try to be careful. make sense? randy
Re: Jabber BOF afterthoughts
At 10:01 AM 7/23/2002 -0700, Randy Bush wrote: Proven technical base, motivated workers and ready market for products using a specification. Those certainly are a lousy basis for forming an IETF working group. you have an impressive talent for omitting text, twisting people's words, etc. you should run for political office. i also said i submit that relevance, expertise, non-conflict with other standards groups, change control, etc. are important criteria. Randy, Thanks for the ad hominem. For my own part, I had refrained from noting your own accomplishment at invention. There was nothing in the note you were supposedly responding to that hinted at the IETF's being a rubber stamp, yet that is the interpretation that you chose to create for it. And you forgot to note that besides being ignorant of the technical issues, you apparently had no knowledge of the process-related history of this and were, therefore, ignorant of the fact that all of the issues you were voicing concern about had been addressed quite thoroughly. Yet still you chose to post such a constructive, informed note. Silly me, I thought area directors were expected to be careful about their activities concerning a matter they will be expected to pass judgement on, especially one about which there has already been such stellar, public IETF process achievement. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
Re: Jabber BOF afterthoughts
thanks for your ever-constructive contribution dave. for actual content, see my conversation with pete. randy
Re: Jabber BOF afterthoughts
At 08:18 AM 7/23/02 -0700, Randy Bush wrote: ... i submit that relevance, expertise, non-conflict with other standards groups, change control, etc. are important criteria. Mostly, that seems quite reasonable. But I'm interested to understand what constitutes non conflict here. #g --- Graham Klyne [EMAIL PROTECTED]
Re: Jabber BOF afterthoughts
Mostly, that seems quite reasonable. But I'm interested to understand what constitutes non conflict here. was my reply to pete on this sufficiently helpful? if not, i will beg the help of our sdo lawyers like scott, so you had better be happy with what i said :-). sometimes we have X come to us to move their work through our process after they have not gotten what they wanted from the more appropriate sdo. so, if we were to take it on, we could be badly stepping on someone else's turf. what goes around comes around, and we don't want sdo turf wars. do we want itu to 'help' with smtp? i have no idea if this is an issue here, as i am not in contact with w3c or whomever else. i expect you, pete, etc. will know far better than i if we are nearing hot water here. i am just asking you to please be conscious of the issue. fwiw i have nothing against jabber. some of my best friends jabber :-). i am even trying to get a secure jabber server working (and am hitting problems). i am just concerned about process and precedent. randy
Re: Jabber BOF afterthoughts
Randy Bush wrote: we don't make ethernet standards, ieee does. we don't make sdh standards, itu does. etc. etc. in this case, i would be careful not to encroach on w3's toes. What would Jabber have to do with the W3C? It's a protocol, not a document format. Furthermore, we already have two efforts in this space; if the W3C were likely to object, they would've by now. -- /\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: the way an I-D takes
John Stracke wrote: Kai Kretschmann wrote: In mid may we published a draft named draft-kretschmann-kai- sighttp-00.txt and got at least some responses. ...mostly negative, IIRC. checks archive OK, this was an unworthy bit of snideness, since nearly all the previous comments came from me. Sorry. -- /\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |This is the .sig that says... Ni! | \/
Re: Jabber BOF afterthoughts
randy - hi. i'm a little confused about the exchanges this morning, so bear with me. i have no idea if this is an issue here, as i am not in contact with w3c or whomever else. i expect you, pete, etc. will know far better than i if we are nearing hot water here. i am just asking you to please be conscious of the issue. this is a fair point. there is no w3c effort on instant messaging, while soap is certainly a w3c effort, i think most folks would be hard-pressed to find much overlap between it and jabber, other than the fact that they both use xml at different points in their stack. fwiw i have nothing against jabber. some of my best friends jabber :-). i am even trying to get a secure jabber server working (and am hitting problems). i am just concerned about process and precedent. send me a private note explaining the difficulty, and maybe i can help. /mtr
Re: Jabber BOF afterthoughts
On this point I'm in total agreement with Randy ... I've still have a problem with this ...why come to IETF with this work ? note that i do not have the expertise to have a position on this with respect to jabber. this whole sub-thread was really my *process* reaction to randall's Given that this is a deployed product, I tend to agree. The work is going to get done; we may as well help it to get done as well as possible. being quite unbounded. and i suggested some bounds relevance, expertise, non-conflict with other standards groups, change control, etc. are important criteria. i was merely raising a formal process issue, and not necessarily an issue i have with jabber per se. it is perfectly reasonable to kill off or delay WG charting because of the current IESG work load, especially in the applications area. i don't buy this. if the wannabe-wg is appropriate ietf work, the folk are there with their homework done and ready to roll, the drafts are in play with change control in the ietf, there is an active constructive mailing list, and a charter is close to being good, then iesg load is no excuse. if this is a problem, then we need to, and will, fix it. randy
Re: Jabber BOF afterthoughts
we don't make ethernet standards, ieee does. we don't make sdh standards, itu does. etc. etc. in this case, i would be careful not to encroach on w3's toes. What would Jabber have to do with the W3C? It's a protocol, not a document format. Furthermore, we already have two efforts in this space; if the W3C were likely to object, they would've by now. i do not know how much clearer i could be than i have no idea if this is an issue here, as i am not in contact with w3c or whomever else. i expect you, pete, etc. will know far better than i if we are nearing hot water here. i am just asking you to please be conscious of the issue. randy
Re: the way an I-D takes
At 06:25 PM 7/23/2002 +0200, Kai Kretschmann wrote: what further way goes a submitted and published internet draft after a short period of discussion? That largely depends on you. If it goes into a working group, it becomes a working group document which you might be the editor of or a contributor to. If it remains a personal submission, you can ask the IESG to publish it as an informational RFC. But yes, if you do nothing, it will age out in time. Question for you on the content of the draft. What you are proposing is, I think, signing web pages as a way to detect when they have been hacked. You state that the public key needs to come through a third party. I'm not sure I buy that. If you have a business relationship, you could transfer the public key (in a certificate) during the process of setting it up. You are concerned about transfer of the key at the time because the hacker might substitute a different public key. What I would worry about is the system signing dynamic pages on the fly and therefore using its private key to sign hacked files. How would you address that?
Re: Jabber BOF afterthoughts
On 7/23/02 at 10:09 AM -0700, Randy Bush wrote: we don't make ethernet standards, ieee does. we don't make sdh standards, itu does. etc. etc. Ah, you're talking about competing with other standards bodies, not groups within the IETF! OK, that I understand. in this case, i would be careful not to encroach on w3's toes. i have no idea if we would be or not. Everything that I've seen indicates nothing in any of the potential work items which would step on any W3C toes. So I think Jabber is cool there too. as to why we are careful not to step on other sdos' toes, well we do not want them to step on ours. there have been incidents of this kind of issue with other sdos, and we try to be careful. make sense? Absolutely. pr -- Pete Resnick mailto:[EMAIL PROTECTED] QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Re: Jabber BOF afterthoughts
At 10:43 AM 7/23/02 -0700, Randy Bush wrote: fwiw i have nothing against jabber. some of my best friends jabber :-). i am even trying to get a secure jabber server working (and am hitting problems). i am just concerned about process and precedent. In the IETF that I know, the issue is not so much one of process and precedent, but core competence. And if that isn't clear, or is distributed across organizations, there are plenty of examples of collaborative efforts. #g --- Graham Klyne [EMAIL PROTECTED]
Re: Jabber BOF afterthoughts
sometimes we have X come to us to move their work through our process after they have not gotten what they wanted from the more appropriate sdo. so, if we were to take it on, we could be badly stepping on someone else's turf. what goes around comes around, and we don't want sdo turf wars. do we want itu to 'help' with smtp? On this point I'm in total agreement with Randy ... I've still have a problem with this ...why come to IETF with this work ?... this is XML messaging ...why didnt the Jabber community choose OASIS or W3C..which strikes me as a more logical home for these kind of things and there is a larger community of XML expertise there. Just because there is a community that has a good idea and wants to work on it does not mean the IETF should take it on. Randy is right about process and precedent. we kill off BOF's all the time for any number of irrational reasons even when there is a strongly committed core or people willing to work the issue. And, contrary to popular opinion, it is perfectly reasonable to kill off or delay WG charting because of the current IESG work load, especially in the applications area. That said ..at the BOF the Jabber folks remarked and I pointed out that there may be a larger issue of asynchronous XML messaging that may or may not have relevance in the IETF. Patrik's comments at the plenary were quiet appropriate that we are beginning to deal with lots of XML things and how we move these things around and where these fit into the general IETF view of Architecture is rather relevant. Jabber MAY or MAY NOT be part of that ..I don't know and I say that as a certifiable SIP bigot and on that basis I'm personally willing to keep a open mind on the issue. I'm still trying to discover how Jabber might be complimentary to SIMPLE in much the same way IMAP is complementary to POP3. ( ok maybe a bad analogy). But I wish that those proponents of a Jabber WG would understand that some of us in the SIP community have some real concerns about the effect or perceptions in the marketplace that chartering this work in the IETF might have. They are real and probably cloud our thinking ..but simply dismissing them as irrelevant or stupid is not going to help gain consensus on chartering this work. I'll be real blunt here the difference between asynchronous XML messaging and asynchronous XML signalling is really fine and that really worries me. fwiw i have nothing against jabber. some of my best friends jabber :-). ditto ...blabber, slobber depending on time of day.. i am even trying to get a secure jabber server working (and am hitting problems). i am just concerned about process and precedent. Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 mailto: [EMAIL PROTECTED] or mailto: [EMAIL PROTECTED] http://www.neustar.biz http://www.enum.org
Re: Jabber BOF afterthoughts
[ lots of stuff deleted that was designed to distract... ] But I wish that those proponents of a Jabber WG would understand that some of us in the SIP community have some real concerns about the effect or perceptions in the marketplace that chartering this work in the IETF might have. They are real and probably cloud our thinking ..but simply dismissing them as irrelevant or stupid is not going to help gain consensus on chartering this work. richard - whether simple succeeds or fails will have nothing to do with whether the ietf helps out the jabber folks. each will succeed or fail on their own merits. i am at a loss to understand the extraordinary amount of fear and loathing from the simple camp that i witnessed in the jabber bof. i could be more unkind here, but i'm making an extraordinary effort to be inoffensive. regardless, there are numerous precedents to invalidate your position that we can work on only one. the most obvious is cpim, which explicitly acknowledges the existence of many. however, if you insist that there can be only one, then perhaps the logical thing to do is for the iesg to put eveything on hold while we do a detailed analysis of the technical merits of the various approaches. oh, wait, we already did that, and the result was that we did cpim. go back two paragraphs. for myself, i think that the simple folks would be much better served by focusing on their work product than on political posturing. /mtr
how to take minutes
Hi - Relatively few WG minute takers pay much attention to the Mortimer/Agnes/Duane bullet in http://www.ietf.org/instructions/minutes.html Is it time to update the web page to reflect actual practice? Might it be easier to get people to take minutes if they realized that we're not asking for blow-by-blow transcripts? Some of these meeting notes that capture (some of) the words but miss the point of the discussion. -- Randy Presuhn BMC Software, Inc. 1-3141 [EMAIL PROTECTED] 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA -- My opinions and BMC's are independent variables. --
Re: Jabber BOF afterthoughts
On Tue, 23 Jul 2002 23:21:40 BST, Lloyd Wood said: XML! XML! it's XML! whatever happened to Java? Any hammer, once it's used for pounding enough screws and bolts, starts looking rather dented and abused. The obvious solution is to buy an new bright shiny hammer with which to pound screws and bolts. (Note - I think XML and Java are both *wonderful* for certain tasks - but if there's anything I've learned in 20+ years of this, it's that *nothing* is The Next Great Thing To Fix Everything) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg08899/pgp0.pgp Description: PGP signature
ECN and ISOC: request for help...
In its great wisdom, the IETF has divised a system to control congestion over the Internet called ECN [RFC3168], unfortunately there are still some routers out there which are Explicit Congestion Notification (ECN) broken: http://urchin.earth.li/cgi-bin/ecn.pl One of this router leads to the ISOC web site. what is funny is to see the above RFC is copyright ISOC. Could someone located in the Washington DC area please contact the ISOC people and help them to be RFC compliant... I have highlighted to ISOC the problem, they are aware, but understaffed and this is a little bit tricky, but it should be a piece of cake for the IETF members. More info on ECN: http://urchin.earth.li/ecn/ http://www.icir.org/floyd/ecn.html http://www.rfc-editor.org/rfc/rfc3168.txt Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC.
Re: how to take minutes
On Tue, Jul 23, 2002 05:54:25PM -0700, Randy Presuhn allegedly wrote: Hi - Relatively few WG minute takers pay much attention to the Mortimer/Agnes/Duane bullet in http://www.ietf.org/instructions/minutes.html Is it time to update the web page to reflect actual practice? Might it be easier to get people to take minutes if they realized that we're not asking for blow-by-blow transcripts? Some of these meeting notes that capture (some of) the words but miss the point of the discussion. That last point is a useful one, but when I can't be at a meeting I strongly prefer blow-by-blow transcripts, even babbling, over just results. I want Meeting Notes with enough detail that I can pick out the motivations and other nuances. Minutes, for the Proceedings, should not exclude them. Sure, let's update some web page, and perhaps an RFC. Thanks ... Scott
RE: ECN and ISOC: request for help...
Yo Christian! Actually, RFC 3168 has nothing to do with it. The issue is RFC 793. RFC 793 is a Standard, not a Proposed Standard RFC 793 lists the bits later used by ECN as Reserved. Computer programs are supposed to ignore Reserved bits unless they really know what they are doing. If a router treats bits in the header as required by the STANDARD RFC 793 then RFC 3168 will cause no harm.I do not have a copy of Baker handy, but I bet it agrees. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 23 Jul 2002, Christian Huitema wrote: So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995.
RE: ECN and ISOC: request for help...
One of this router leads to the ISOC web site. what is funny is to see the above RFC is copyright ISOC. Could someone located in the Washington DC area please contact the ISOC people and help them to be RFC compliant... Your reference to RFC compliance is somewhat mistaken. First, it misrepresents what RFC compliance means: the FOO explains how to do FOO; a system is compliant if it chooses to do FOO in a manner compatible with the RFC, and non compliant if it chooses an incompatible variant; however, a system that does not do FOO is neither compliant nor non-compliant, it just does not do it. There is absolutely no IETF mandate that all systems implement all RFC. Second, RFC 3168 is a Proposed Standard. To quote RFC 2026: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995. -- Christian Huitema
RE: ECN and ISOC: request for help...
I'm not in a campaign to promote ECN, or anything... I'm saying that ISOC web site is not reachable if you enable ECN, which RFC793(standard) or RFC3168(proposed Standard) talk about. I don't want to talk about what is a standard or what is not... What is compliant or not... Will there be anybody to volunteer and fix the routers leading to ISOC web site, mailing lists, e-mail addresses and so on? This is what my message is all about. Please IETF members in Washington DC, Area, please give a call to ISOC and offer some help... This is embarrassing, that's all Cheers. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ Certificate: https://www.sopac.org/ssl/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC. -Original Message- From: Gary E. Miller [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 24 July 2002 3:02 To: Christian Huitema Cc: ietf Subject: RE: ECN and ISOC: request for help... Yo Christian! Actually, RFC 3168 has nothing to do with it. The issue is RFC 793. RFC 793 is a Standard, not a Proposed Standard RFC 793 lists the bits later used by ECN as Reserved. Computer programs are supposed to ignore Reserved bits unless they really know what they are doing. If a router treats bits in the header as required by the STANDARD RFC 793 then RFC 3168 will cause no harm.I do not have a copy of Baker handy, but I bet it agrees. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Tue, 23 Jul 2002, Christian Huitema wrote: So, if you are on a campaign to promote ECN, then maybe you should first try to promote this specification to the next standard level... You may also want to take a stab at revising the Requirements for IP Version 4 Routers; the last edition, RFC 1812 by Fred Baker, dates from June 1995.
Re: how to take minutes
On Tue, 23 Jul 2002, Scott Brim wrote: On Tue, Jul 23, 2002 05:54:25PM -0700, Randy Presuhn allegedly wrote: Hi - Relatively few WG minute takers pay much attention to the Mortimer/Agnes/Duane bullet in http://www.ietf.org/instructions/minutes.html Is it time to update the web page to reflect actual practice? Might it be easier to get people to take minutes if they realized that we're not asking for blow-by-blow transcripts? Some of these meeting notes that capture (some of) the words but miss the point of the discussion. That last point is a useful one, but when I can't be at a meeting I strongly prefer blow-by-blow transcripts, even babbling, over just results. I want Meeting Notes with enough detail that I can pick out the motivations and other nuances. Minutes, for the Proceedings, should not exclude them. I haven't written minutes for any IETF meeting myself, so perhaps I shouldn't comment. But on the page: 'They should not follow a Mortimer said, then Agnes said, then Duane said, format, nor should they contain a detailed list of changes to a document. While these forms may be helpful to the folks who actually attend the sessions, they are less helpful to those who have a more general interest in the groups' activities.' This makes an implicit assumption that anyone reading minutes is only generally interested in the group's activities. I thought attendance in meetings for w.g. members was not supposed to be necessary in the IETF? -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
