Re: Network Working Group
On Mon, Mar 10, 2003 12:16:45PM -0800, Fred Baker allegedly wrote: I personally would like to see us stop attributing documents to them. The world has long since moved on, and those who don't recognize it date themselves. I stopped using it on drafts a few years ago. I use the relevant WG.
Re: Network Working Group
At 01:27 PM 3/10/2003 -0800, Bob Braden wrote: The archive of early NWG discussions is the RFC series itself. I started to reply saying that, but I think he's referring to a pointer to the working group's discussions. A pointer to the working group's discussions??? NWG could be replaced by IETF or ISOC, but... Are you all assuming that individuals can not submit RFCs? Masataka Ohta
Re: Network Working Group
I sometimes put the working group name on drafts also. But an RFC is never issued by a working group. It is issued by the I* after IESG review and usually after IETF Last Call. I'm dubious about putting the WG name in the RFC but if that were done, it shouldn't be more than an interior footnote. Thanks, Donald == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Tue, 11 Mar 2003, Scott W Brim wrote: Date: Tue, 11 Mar 2003 09:17:05 -0500 From: Scott W Brim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Network Working Group On Mon, Mar 10, 2003 12:16:45PM -0800, Fred Baker allegedly wrote: I personally would like to see us stop attributing documents to them. The world has long since moved on, and those who don't recognize it date themselves. I stopped using it on drafts a few years ago. I use the relevant WG.
RE: IAB policy on anti-spam mechanisms?
It might be interesting for IAB to think about the estimated half-life of well-known port numbers in the Internet architecture, since we've been seeing (1) firewalls that limit traversal based on port numbers, (2) ISPs that have opinions about what services go where, based on port numbers, (3) URL schemes that support alternate port numbers fairly easily, (4) Mechanisms like SOAP that use HTTP as a substrate (ne: RFC 3205) specifically to avoid (1) and (2), and (5) Servers running at alternate ports specifically to avoid (1) and (2) Knowing what port 25 means seems like something our children won't understand... ... although they may wonder why everything EXCEPT web access is running over port 80! Spencer -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 8:33 AM To: RL 'Bob' Morgan Cc: IETF Subject: Re: IAB policy on anti-spam mechanisms? On Thu, Feb 27, 2003 at 12:41:41AM -0600, RL 'Bob' Morgan wrote: Many sites, including my university, support STARTTLS+AUTH on the Submission port (587, RFC 2476), which I believe is the recommended service for clients to use to submit mail in any case (though not well-supported among MUAs, to my knowledge), and also is effective at getting around ISP blockage of port 25. Of course if it becomes very popular the misguided ISPs will block it too. Yup, the problem with well-known ports is that well-known port numbers get either (a) blocked by misguded ISP's, or (b) transparently proxed by misguided ISP's. Since I have no idea what sort of stupidity I might encounter at various different hotel, conference, or 802.11 hotspot networks, it's more convenient for me to use a non-standard port.
Re: cables
standard time? rather than arguing about standards on ietf? - Original Message - From: shogunx [EMAIL PROTECTED] To: john smith [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 27, 2003 9:43 AM Subject: Re: cables On Thu, 20 Feb 2003, john smith wrote: on ethernet, If all ports were DTE pin configured (same pair everywhere for rx and tx) and all cables were cross life would be simpler. I once built a network using nothing but cross-connects. It was nice. Scott -JS sleekfreak pirate broadcast world tour 2002-3 live from daytona beach http://sleekfreak.ath.cx
unsubscribe
unsubscribe
Re: IAB policy on anti-spam mechanisms?
The nicest solution that I can see is for the ISPs to transparently proxy port 25 to their MTA. They should offer STARTTLS. Assuming you're not pulling my leg, I couldn't disagree more strongly. This is even worse than blocking port 25 outright. I actually encountered an ISP that does this. I can't remember their name, but they provide many of the DSL Ethernet hookups in hotel rooms. I discovered only after I had sent a few messages that they were hijacking (the only correct word) my outbound connections to port 25 and redirecting them to their own mailservers. They didn't support STARTTLS, and even if they did there is no reason I should trust them. It did teach me the importance of protecting against the man-in-the-middle attack. This is not often done, at least not by default, in many STARTTLS implementations. I do agree with you about the utility of IPsec and IPv6 tunneling as ways around this braindamage. TCP connection tunneling over SSH is another good approach. Phil
Re: BLOCK: Abstract of proposed Internet Draft for Best Current Practice
On Sat, 01 Mar 2003 22:22:27 +0700, Dr. Jeffrey Race [EMAIL PROTECTED] wrote: On Sat, 15 Feb 2003 17:34:46 +0700, Gary Feldman [EMAIL PROTECTED] wrote: [snip] ... I want to encompass both webhosting firm and ISP. I agree it is clumsy to introduce a new acronym. Please offer a suggestion here. Personally, I would use ISP as a catchall. Even though I recently used it in a more narrow sense on the spam-l list, I think it works well enough for provider of any general internet services when the context is clear. Alternatively, spell it out. Abbreviating a two word term is overly aggressive abbreviation, in my opinion. Bytes on that scale are cheap. The term abuse is already well-known to describe the entire class of problems; calling it pollution is at best an annoying distraction. Here I have a particular psychological point in mind. I want to I understand that point, and I think it works well in that article you wrote and recently cited (I think in the port 25 thread). I'm less sure about putting it into a BCP/RFC document, at least at this point in time. Besides, abuse carries its own appropriate psychological baggage, especially where I believe we both are (Massachusetts), with regard to other current events that dominated the news media over the last year. I often feel the desire to want to convince the world to change terminology, so I respect your motives here, but I find that fighting such battles to be an inefficient use of energy - at least for me. Gary __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
RE: beauty of freedom
I remember when telephony vendors sold o calling line ID (CLID) as a feature, and then o call blocking based on CLID as a feature, and then o CLID delivery supression as a feature, and then o call blocking for anonymous calls as a feature, and then ... It's great to have guarenteed lifetime employment for software developers, but are we sure spam plus spam supression is making the world a better place? Spencer, half :-} -Original Message- From: Bill Cunningham [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 6:32 AM To: [EMAIL PROTECTED] Subject: beauty of freedom Just something to throw out I was browsing an ftp site a few days ago and came across some interesting downloads that got me thinking. On the same site (and the same page) I saw a piece of software to abtain email addresses to send of spam :O , and on the same page, a filter to block spam. With all this talk of stopping spam, isn't some good spam blocking good enough? ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: [Asrg] SHEESH!
Vernon Schryver wrote: I guess I shouldn't have used the V-word when talking about spam on the IRTF's mailing list about spam. sheesh!--talk about utterly lame and misguided spam filters. But in the case of the V word, it works. The only concern I'd have is whether the rejection message implies that it's far more unnecessarily draconian on other words/phrases. 8+ months of blocking on it, 10's of thousands of rejects, approximately 4 false positives. 5 if Vern had gotten it thru the mailing list. Better than a .01% FP rate. Not bad. IETF mailing lists are particularly prone to high volumes of spam. I for one am particularly glad that they're moving to filters. Takes a _huge_ load of end-user complaints off _my_ head, as well as those of my colleagues running IETF mailing lists of their own. Speaking of which, I should whitelist [EMAIL PROTECTED]
FW: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
Hi, Section 6.1.1 and 6.1.2 mention two very different method for backup path identification and signaling. It is not clear which one should be implemented for compliance to this draft. For interoperability reason ONE of them should be Mandatory and the other one optional. Yours, Shahram Davari -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 2:30 PM To: IETF-Announce Cc: [EMAIL PROTECTED] Subject: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Fast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2003-3-25. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fa streroute-02.txt
RE: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
Hi, Also Facility back-up and Detour both do protection. Which one must be implemented to comply with this draft? For interoperability reasons it seems that one of them should be Mandatory and the other one Optional. Thanks, Shahram Davari -Original Message- From: Shahram Davari Sent: Wednesday, March 05, 2003 4:09 PM To: '[EMAIL PROTECTED]' Subject: FW: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard Hi, Section 6.1.1 and 6.1.2 mention two very different method for backup path identification and signaling. It is not clear which one should be implemented for compliance to this draft. For interoperability reason ONE of them should be Mandatory and the other one optional. Yours, Shahram Davari -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 2:30 PM To: IETF-Announce Cc: [EMAIL PROTECTED] Subject: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Fast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2003-3-25. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fa streroute-02.txt
Re: Last Call: Instructions to Request for Comments (RFC) Authors to BCP
From: Lloyd Wood [EMAIL PROTECTED] Do you like quoting dictionary definitions but don't know the background of how the definitions developed? .. Are you horribly literal-minded but horribly illiterate? Acrynomius, n,; to become acrimonious over the definition of 'acronym'. Anyway, if it's not an acronym if you don't say it as a word, is TLA a self-referential acronym or not? :-) Noel (who still spells colour with a 'u', if you want to know which side of the Atlantic I'm from) PS: Languages aren't static things entirely enclosed in books; if something comes into general use, it *is* a word. If you asked me what the term TCP was, I'd have said acronym, since it's i) not for the purpose of remember ing (which lets out mnemonic), and ii) it's formed from the initial letters. So if everyone thinks acronym means a term derived from the first letters of a group of words, then that's what it means, and the dictionary writers will catch up one day.
Re: [Asrg] SHEESH!
Vernon Schryver wrote: From: Chris Lewis [EMAIL PROTECTED] I guess I shouldn't have used the V-word when talking about spam on the IRTF's mailing list about spam. sheesh!--talk about utterly lame and misguided spam filters. But in the case of the V word, it works. ... I wonder if you'd say that if your employer were in the drug industry. Of course not. So? I'd simply not deploy such a filter. Until the IETF has WGs on pharmaceuticals, I don't think we need to worry about the IETF's filtering in this regard. IETF mailing lists are particularly prone to high volumes of spam. I for one am particularly glad that they're moving to filters. Takes a _huge_ load of end-user complaints off _my_ head, as well as those of my colleagues running IETF mailing lists of their own. There are other things the IETF lists should do instead. To start, they should rejectm mail with MIME content headers declaring mail is not English, and specifically reject JP, KR, and GB character sets. The IETF has no foreign language special interest groups? Like on character sets and internationalization? It would be as dumb as a pharmaceutical company banning the V word. They should probably also reject any MIME multipart mail, That would annoy the Mime, multimedia and other specialized WGs would it not? I think they should also use the DCC to reject all bulk mail, but that's probably only my bias speaking. That's a _much_ better idea than banning specific character sets or mime.
Re: Acronyms Et Al. (was: Last Call: Instructions to Request forComments (RFC) Authors to BCP)
Tomson Eric (Yahoo.fr) wrote: - an acronym is a word composed of initials ; e.g.: ASAP, LASER, NATO, OSI, RADAR, SCUBA, are well-known acronyms. They sound like words, while they are actually groups of initials. - initials are the first letters of words ; e.g.: IETF, CIA, FBI, IBM, RFC, TCP, are well-known initials, too complex to be used as acronyms. I never heard this distinction before today. It seems like a pretty strange hair to split in a written forum like the IETF. It boils down to how hard a series of letters is to pronounce in English; but most of our communication doesn't get pronounced. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |Collect call from reality, will you accept the-- *click*| \==/
Registration silliness
So I'm wondering why, if we're all individuals at the IETF, Company is a required field on the registration form? Mysteriously yours, Spencer
Re: A charter for the IESG
Hello to all, Personally. I think the iesg (and ietf) is a process that seems to be working OK, insofar as it accepts input from any user who cares to subscribe to the relevant groups ... such as me ... I gladly accept 20 - 40 e-mails daily for the opportunity to throw in my comments when they seem relevant, and otherwise to observe when people who know more about the topic debate, and try to learn from same. If anyone cares about my opinion, this arena of opinions is one of the closest approximations to a true democracy i have ever seen, of which i totally approve, wish to see continue, and will gladly support. As responsive to the original post, I support full discussion on the ietf list, and look forward to the debate. I must admit that this is not only in response to this post, but also in more or less ) response to other recent posts re the whole mission of ietf / iesg ... any limitation of this global user input seems unacceptable ... one only need look at ICANN to see my whole point ... Oh well, I have said all I have at this point, let the flame wars begin, Phil - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 07, 2003 19:37 Subject: RE: A charter for the IESG Harald, -Original Message- From: ext Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] Subject: A charter for the IESG Some discussion has taken place on the POISED list ([EMAIL PROTECTED]), but the point has been made that for such a potentially important document, the IETF list may actually be a more appropriate venue for discussion. Hence this note. Could you point to the archive of this list? At least the pointer in the 'Poisson' WG (concluded) (http://www.ietf.org/html.charters/OLD/poisson-charter.html) does not seem to be valid. It would be rather interesting to see what has been discussed. This IESG charter attempts to capture what the IESG has believed that it has been asked to do by the IETF community. Most of the document is simply collecting references to sections of other IETF BCP documents, and attempting to form a coherent picture of what the IESG is supposed to be doing. I do not believe that it shows the IESG to be much different from what the community currently believes it is. Is this view of the IESG share by the whole IESG? What I mean is if you have discussed this within the IESG already? What I hope to do with this document is: - Discuss it on this mailing list and on the POISED mailing list as the community finds appropriate I am not sure what would be the right 'process'. However, at least I personally would find it better to have the discussion in a discussion list that is also officially alive, and has a current archive. This makes it easier for everybody to follow/contribute to the discussion. Cheers, Jonne.
Re: [Asrg] SHEESH!
Vernon Schryver wrote: From: Chris Lewis [EMAIL PROTECTED] Vernon wrote: I think they should also use the DCC to reject all bulk mail, but that's probably only my bias speaking. That's a _much_ better idea than banning specific character sets or mime. Maybe so or maybe not. Using the DCC to reject all bulk mail would prune a lot of conference announcements and calls for papers. I think that would be a good thing, but I know others disagree with me. Not _inbound_ to the IETF. Only if they spammed it, got DCC reports, and then forwarded to the IETF would it get blocked. Which is what you want, no?
Re: [Asrg] SHEESH!
At 1:24 AM -0500 3/7/03, Chris Lewis wrote: I wonder if you'd say that if your employer were in the drug industry. Of course not. So? I'd simply not deploy such a filter. That takes care of some of the incoming. But how do you send email about that drug to anybody outside of your company? (Never mind that some ISPs have egress filters). -- Kee Hinckley http://www.puremessaging.com/Junk-Free Email Filtering http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
PL PMTUD BOF
Are you tired of having your favorite {VPN,tunnel,encapsulation,transition}
protocol get stalled in deployment, because the end systems just can't figure
out the proper path MTU?
We are working on a new Packetization Layer Path MTU Discovery Algorithm,
that might solve your problem. There is a IETF BoF scheduled for 1630 on
Thursday to discuss the formation of a WG.
See http://www.ietf.org/ietf/03mar/plpmtud.txt - This new algorithm does not
rely on ICMP or other messages from the network (so it is not subject to the
problems described in RFC2923). Instead it finds the proper MTU by starting
with relatively small packets and searching up wards by probing with test
packets.
Or read the (very preliminary) draft: draft-mathis-plpmtud-00.txt
One of the agenda items for the BoF is to inventory current protocols and
technologies that are impaired by not having a robust path MTU discovery
algorithm.
BTW, My other agenda (Pushing up the deployed MTU's in the Internet), is out
of scope for this BoF.
Thanks,
--MM--
---
Matt Mathis http://www.psc.edu/~mathis
Work:412.268.3319Home/Cell:412.654.7529
---
Re: Network Working Group
Donald Eastlake 3rd wrote: I sometimes put the working group name on drafts also. But an RFC is never issued by a working group. It is issued by the I* after IESG review and usually after IETF Last Call. I'm dubious about putting the WG name in the RFC but if that were done, As a practical matter, if one wants to find people to discuss an RFC with, knowing what WG it came from (if any) can save steps. The authors' addresses are included, of course, but those sometimes go stale before the WG closes down. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |Diplomacy: The art of letting someone else have your way| \/
Re: Network Working Group
Bob Braden wrote: * Perhaps with a pointer to where the archived discussions of the working * group might be found? The archive of early NWG discussions is the RFC series itself. The other archives, which no doubt existed, were written on DEC tapes, IBM 360 mainframe files, etc. Not too useful today. I believe he meant for new documents. I'm not sure, of course, since he put his comments at the start of his reply instead of alongside the quoted text he was referring to. -- /==\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own.| |==| |Who died and made you king? My father.| \==/
Re: Request to mailing list Asrg rejected (fwd)
which prompts the questions: Why isn't the list set up to appear to be run from the irtf.org vanity domain, where different policies are obviously expected? Because the people concerned with formulating anti-spam policies who set up this list really appreciate the impact of clear expression of policy, right? Because the volunteer who runs irtf.org doesn't have an equivalent mailing list system available nor the cycles to put one up and manage it. If someone wants to volunteer to do this - *on an archival basis*, meaning it really does have to stick around in a permanent fashion, and have timely support/maintenance - please do contact me. Vern
Re: IAB policy on anti-spam mechanisms?
From: [EMAIL PROTECTED] Reply-to: [EMAIL PROTECTED] [EMAIL PROTECTED]? I've been meaning to ask about that. If the goal is to avoid Microsoft out-of-office noise and other hassles, wouldn't [EMAIL PROTECTED] or some other obvious bit bucket be better? ... I actually encountered an ISP that does this. ... Hasn't AOL been running SMTP redirection proxies for their IP customers for years? 25 and redirecting them to their own mailservers. They didn't support STARTTLS, and even if they did there is no reason I should trust them. It did teach me the importance of protecting against the man-in-the-middle attack. This is not often done, at least not by default, in many STARTTLS implementations. Which STARTTLS are those that cannot be told to check certificates? By default sendmail only says verify=FAIL in the received header when the authentication part fails, but I think I recall a sendmail.cf switch that says refuse mail without a good certificate. Vernon Schryver[EMAIL PROTECTED]
Re: beauty of freedom
It's great to have guarenteed lifetime employment for software developers, but are we sure spam plus spam supression is making the world a better place? This is a tremendous problem in firewall-land, where there's a continuing arms race that's moving firewall functionality further and further up the stack. Entities like port numbers and IP addresses are terrible descriptors of higher level policy, but on the other hand increasing use of encryption across firewall traversal points is rendering traffic content inspection useless (that's a good thing). On a third hand, service providers want to be able to concentrate service management function in their own networks, and you'll notice that at this upcoming meeting, in addition to the OPES working group, there are two BOF (pads and intersec) that are dealing with this issue to a greater or lesser extent. The tension between trying to provide those services in a way that's both secure and architecturally sound and trying to maintain some level of end-to-end integrity is a pretty serious problem for the IETF right now. I'd like to hope that any lessons we've learned from firewalls about bad design leading to escalation and ultimately failure in the face of technology short can be applied to spam protection, too. Melinda
RE: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
Please ask your customers on which method they prefer. Both methods and all three path identification have been developed and deployed. We are only describing how protocols suppose to work, not mandating customer requirements. If you have questions on protocol detail issues, please forward them to the MPLS list. Thanks! - Ping Hi, Also Facility back-up and Detour both do protection. Which one must be implemented to comply with this draft? For interoperability reasons it seems that one of them should be Mandatory and the other one Optional. Thanks, Shahram Davari
Re: IAB policy on anti-spam mechanisms?
[EMAIL PROTECTED] writes: It did teach me the importance of protecting against the man-in-the-middle attack. This is not often done, at least not by default, in many STARTTLS implementations. Indeed. The problem is that it's pretty hard to determine a priori what certificate the peer server ought to be offering, due to mail relaying and MX records. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
RE: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
Please ask your customers on which method they prefer. Both methods and all three path identification have been developed and deployed. We are only describing how protocols suppose to work, not mandating customer requirements. I am not sure I agree with you. IESG has repeatedly asked for a single mandatory method. Otherwise IETF RFCs become an archive for peoples implementations. For proof just look at PWE3 ATM-ENCAP draft. Thanks, Shahram If you have questions on protocol detail issues, please forward them to the MPLS list. Thanks! - Ping Hi, Also Facility back-up and Detour both do protection. Which one must be implemented to comply with this draft? For interoperability reasons it seems that one of them should be Mandatory and the other one Optional. Thanks, Shahram Davari
RE: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
Please ask your customers on which method they prefer. Both methods and all three path identification have been developed and deployed. We are only describing how protocols suppose to work, not mandating customer requirements. I am not sure I agree with you. IESG has repeatedly asked for a single mandatory method. Otherwise IETF RFCs become an archive for peoples implementations. Both methods solve different problems, thus, they are mandatory. For proof just look at PWE3 ATM-ENCAP draft. I don't know much about IESG process, but I do know that the proof of the pudding is in the eating. - Ping
RE: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
I am not sure I agree with you. IESG has repeatedly asked for a single mandatory method. Otherwise IETF RFCs become an archive for peoples implementations. Both methods solve different problems, thus, they are mandatory. What are those different problems? As far as I can see they both solve the same problem which is link/node protection. For proof just look at PWE3 ATM-ENCAP draft. I don't know much about IESG process, but I do know that the proof of the pudding is in the eating. Proof of what? I said look at this draft to see that there are 4 methods for transporting ATM over mpls, out of which only one method is mandatory and 3 others are optional. Now what is the relevance of pudding/eating here? -Shahram - Ping
Re: IAB policy on anti-spam mechanisms?
On Thu, 27 Feb 2003 10:15:34 -0600 Spencer Dawkins [EMAIL PROTECTED] wrote: It might be interesting for IAB to think about the estimated half-life of well-known port numbers in the Internet architecture, since we've been seeing It might be interesting to find a way to make port numbers so meaningless that you either have to let them all through or none of them through (which obviously isn't useful). Perhaps the notion of a well known port is a concept whose time has passed. At least for connection oriented protocols, doing away with well known ports might have some good properties for some basic authentication/cookie mechanism as well. Or we could just let HTTP become the transport layer until blocking is done within the content of those messages, but we can just keep building transports on top until some MTU is reached. :-) John
Re: IAB policy on anti-spam mechanisms?
From: Eric Rescorla [EMAIL PROTECTED] Date: 11 Mar 2003 11:21:51 -0800 [EMAIL PROTECTED] writes: It did teach me the importance of protecting against the man-in-the-middle attack. This is not often done, at least not by default, in many STARTTLS implementations. Indeed. The problem is that it's pretty hard to determine a priori what certificate the peer server ought to be offering, due to mail relaying and MX records. This is a bigger problem than just SMTP. Any protocol that uses SRV records has this indirection and this problem. One (poor) solution to this is codified in draft-ietf-ldapext-locate-08: [when using TLS,] if the DN cn=John Doe,ou=accounting,dc=example,dc=net is converted to the DNS name example.net, the server's name MUST match example.net. which means that if an equivalent sort of mapping is done for instant messaging, an organization is going to have many many different servers all with the same certificate name of example.net. This is especially poor when different servers are under different administrative control. Larry
Re: IAB policy on anti-spam mechanisms?
John Kristoff wrote: Perhaps the notion of a well known port is a concept whose time has passed. At least for connection oriented protocols, doing away with well known ports might have some good properties for some basic authentication/cookie mechanism as well. Well, there's SRV records; but that basically pushes the problem up a layer. If services are identified by well-known service names in the SRV record, then people will start filtering at the DNS level. -- /=\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |If God had meant us to be in the Army, we would've been born with| |green, baggy skin. | \=/
beauty of freedom
Perhaps spam is not best for the Internet. It does take up bandwidth that could be used elsewhere. Whatever's best for the net, then the individuals who use it.
Re: Registration silliness
(1) Tradition. (2) To distinguish people with similar names that are affiliated with different organizations. Thanks, Donald == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Wed, 5 Mar 2003, Spencer Dawkins wrote: Date: Wed, 5 Mar 2003 16:39:51 -0600 From: Spencer Dawkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Registration silliness So I'm wondering why, if we're all individuals at the IETF, Company is a required field on the registration form? Mysteriously yours, Spencer
Re: WG Action: Differentiated Services (diffserv) to conclude
On Tue, 11 Mar 2003, The IESG wrote: The Differentiated Services (diffserv) Working Group in the Transport Area of the IETF has concluded. Out of curiousity, is there a particular reason why the subject line says to conclude but the body of the messages has concluded. This is not specific to diffserv, I believe, of course. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IAB policy on anti-spam mechanisms?
On Tuesday, March 11, 2003, at 02:21 PM, Eric Rescorla wrote: [EMAIL PROTECTED] writes: It did teach me the importance of protecting against the man-in-the-middle attack. This is not often done, at least not by default, in many STARTTLS implementations. Indeed. The problem is that it's pretty hard to determine a priori what certificate the peer server ought to be offering, due to mail relaying and MX records. or at least, proper behavior isn't well-defined. IMHO, about the only behavior that is reasonable (assuming a single cert, which IIRC is what TLS assumes) is to have the peer server offer a cert for the domain name associated with the A record, not the one associated with the MX record. this doesn't protect against bogus MX records. but if the site doesn't want to be an MX for that domain then it will refuse the mail - ideally with an enhanced status code that indicates why the mail was refused. it might even be reasonable for MTAs to detect that case and handle it specially.
Re: IETF consensus in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ]
The idea what we can ever proceed without a Last Call strikes me as a fundamental anathema for the IETF. agree entirely Keith
Re: IETF consensus in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ]
Harald, Tuesday, February 18, 2003, 7:30:51 AM, you wrote: HTA Given that a large portion of the IETF does not in fact subscribe to the HTA ietf-announce list, and that in some cases the IETF consensus is pretty HTA obvious (for instance when the decision is just paperwork following up on HTA another IETF consensus decision), I wouldn't even say that a Last Call is HTA always required. That perspective on project management is very different from the one that I have been taught. As Elze notes, obvious to one viewer is obscure to another. Even when authority is essentially dictatorial and project goals and methods are crystal clear, it is essential to poll and review status and needs regularly. In fact it was Cerf who taught me that it is essential to check a situation repeatedly and in different ways, essentially treating such information as statistical. It's not that people want to give bad information -- though of course some do -- it is that human communication is a hugely noisy process. The IETF has extremely diffuse authority, so we need to be extremely careful -- and non-parental -- in assessing and asserting our rough consensus. The idea what we can ever proceed without a Last Call strikes me as a fundamental anathema for the IETF. HTA But it's certainly one tool, and a fairly powerful one, for getting HTA objections out in public. indeed. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301
RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard
Title: RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard I don't know if the pun was intended, but I do like Kireeti's comment about bring them to light. Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-) There is, I think, some commonality in the comments and the reply in that the intent is to generalize the extensions needed for routing to accomodate non-PSC resources. I agree with the first 4 points that Jonathan made in that I think layer information must be included in routing so that important functions can be performed. I believe that the use of one or two bandwidth values was motivated by the desire to use a lowest common denominator attribute to generalize on path computation and avoid extensive details of links. Unfortunately, this can obscure variable adaptation on a link and the ability to determine a path at a particular adaptation (e.g., VC-3). In variable adaptation, multiple layers can be supported on a link (actually a G.805 trail) as mentioned in the 2nd point. When a label (channel) is used at a particular layer, it has the effect of modifying the available labels in other layers supported on the same link. It is important to thus be able to reflect the layer relationship in routing. For the issue of path computation at a particular layer, while bandwidth can give a superset of possible paths, what is needed in many contexts is a path at a specific adaptation. Because different combinations of adaptations can provide the same b/w, the result is that it infeasible paths can be computed because there is no distinction between what type of adaptation can be supported. There are times when for example, you want to have a VC-3 connection end-to-end and not just an LSP with its equivalent bandwidth because the service that was sold was specifically a VC-3. -Original Message- From: Kireeti Kompella [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 01, 2003 14:29 To: Jonathan Sadler Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Hi Jonathan, On Sun, 23 Feb 2003, Jonathan Sadler wrote: Please consider the following comments on these drafts: draft-ietf-ccamp-gmpls-routing-05.txt draft-ietf-ccamp-ospf-gmpls-extensions-09.txt Many of the comments are based on implementation experience. These comments are marked with a (*). Thanks for your comments. Most of these would have more appropriate to raise in the WG Last Call, but it is certainly better to bring them to light now than never. == 1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for Packet Switch Capable (PSC) are defined. Reference is made to Minimum LSP bandwidth for SDH encoding. None of the examples in section 5 of draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled. Note that all possible permutations cannot possibly be addressed; however, we will consider adding some examples here. 2. The mechanism for showing relationships between server and client layers is not generalized*. Specifically: - Relationships between SONET/SDH layers (ISC type: TDM) are implicitly stated based on the Min and Max LSP bandwidth advertised*. To quote draft-ietf-ccamp-gmpls-routing-05.txt: On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p. This requires node doing the route calculation to understand the G.707 multiplexing hierarchy. Since LSP routing is source routed, it could be the node doing the route calculation doesn't understand G.707. This document does *not* cover how path computation is done. Of course, the information is less than useful if it cannot be used effectively. However, it has been pointed out implicitly and explicitly in several documents that the head end does *not* have to do the entire route computation -- this is one reason why there are loose hops in the ERO. See also the various drafts on multi-area TE computation. - Relationships between PSC-n (for IP switching) and SONET/SDH are explicitly specified on the encoding type specified in the PSC-n announcement*. However, SONET/SDH is not a single layer. It must be possible to identify if the PSC-n layer can be carried by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail, or a VC-4-nc trail. Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries to deal with this in the following paragraph: On a PSC interface that supports Standard SDH encoding, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority
Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard
Kireeti, I am trying to understand what you mean about a general document. Does a general document cover only lowest common denominator or define a flexible mechanism that could accommodate various situations? I think it should be the latter. Then, layering and flexible layer adaptation are pretty common, I think this draft should define a general mechanism to deal with it. (and sure, xxx technology specific values can be defined in other xxx specific draft) BTW, could a general document be really general without fully studying/understanding most of xxx specific routings first? Thanks, Yangguang It is also not the intent of this document to provide a full description of routing info for SDH. This is a *general* document. The intent is to provide a code point for SDH to be expanded by another document. This was the model used for signaling as well: a *general* func spec, a *general* doc for each protocol, and *SDH-specific* docs. There is an SDH specific routing doc; detailed comments are better directed there. - Sometimes layer relationships are described in an inverted manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt states: STM-16 POS Interface on a LSR Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 2.5 Gbps, for all p Where PSC-1 is the client of an SDH (sic) server. Section 5.5 states: Interface of an opaque OXC (SDH framed) with support for one lambda per port/interface Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH In this case, SDH is a client of a wavelength server (LSC). However, unlike in section 5.1, the layer relationship is inverted. Is this pointed out as a curiosity, or is there a question that needs to be addressed? 3. Layer specific attributes are not supported*. Specifically: Good points. Please raise this with the SDH routing doc. 4. The TDM Interface Switching Capability presumably includes layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and G.709. The interaction with these layers needs to be defined. Ditto. 5. In many cases, 8 levels of priority are not necessary*. A more compact encoding that has a bitfield stating the priority levels being announced would reduce the size of the announcement. This has been discussed elsewhere. This is the model in the base TE document; it has proven reasonable in practice. If deployment proves otherwise, this is easy to fix. For now, though, I would leave it as is. Thanks again for your comments, Kireeti.
RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard
Title: RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Kireeti, I can provide text but I need about a day to think about it and write it succinctly. On the matter of the limitations of bandwidth value, I can live with your suggestions (a) and (b). -Original Message- From: Kireeti Kompella [mailto:[EMAIL PROTECTED]] Sent: Monday, March 03, 2003 17:40 To: Shew, Stephen [SKY:Q850:EXCH] Cc: Jonathan Sadler; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Hi Stephen, On Mon, 3 Mar 2003, Stephen Shew wrote: I don't know if the pun was intended, but I do like Kireeti's comment about bring them to light. You're laser sharp, Stephen! :-) Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-) After the discussions we've had, I wouldn't dare not comply. There is, I think, some commonality in the comments and the reply in that the intent is to generalize the extensions needed for routing to accomodate non-PSC resources. I agree with the first 4 points that Jonathan made in that I think layer information must be included in routing so that important functions can be performed. Okay. Can you provide text? I believe that the use of one or two bandwidth values was motivated by the desire to use a lowest common denominator attribute to generalize on path computation and avoid extensive details of links. Unfortunately, this can obscure variable adaptation on a link and the ability to determine a path at a particular adaptation (e.g., VC-3). You're right on both counts (about LCD, and about obscuring info). The thinking was (a) let's see how far we can get with just the LCD; (b) as we learn more, we can incorporate them, ideally in the SDH routing doc. Thoughts? Kireeti.
path-decoupled signaling (pads) BOF
We have added a mailing list for this BOF and updated the agenda. Path-decoupled signaling BOF (pads) Thursday, March 20 at 1530-1730 == CHAIRS: Sven Van den Bosch, [EMAIL PROTECTED] Marcus Brunner, [EMAIL PROTECTED] Mailing list: [EMAIL PROTECTED] To subscribe - [EMAIL PROTECTED] Archive - http://psg.com/lists/pads Description The Next Steps in Signaling (NSIS) WG is developing a next-generation general purpose signaling protocol for state installation along the data path. NSIS is currently focusing on an interpretation of 'along the data path' as 'visiting the same routers as the data flow'. This is denoted as path-coupled signaling. For a number of applications, it would be useful to have a somewhat broader interpretation of 'along the data path', e.g. 'visiting the same AS's as the data flow'. This is denoted as path-decoupled signaling. The purpose of the BOF session is to survey and discuss the path-decoupled signaling case. The first part of the discussion should bring forward arguments for path-decoupled signaling and describe use cases for path-decoupled signaling, potentially limiting the scope of the signalling, e.g. to a single AS. The second part deals with the expected impact path-decoupled signaling would have on the NSIS protocol. Proposed Agenda Introduction, Chair Use cases for path-decoupled signaling, Olov Schelen ([EMAIL PROTECTED]), Cedric Aoun ([EMAIL PROTECTED]) Impact on nsis, TBD Discussion and round-up Drafts related to the discussion: draft-schelen-nsis-opopsig-01 draft-geib-sig-guarandif-00.txt draft-ietf-nsis-fw-02.txt draft-declercq-vsn-arch-00.txt
RE: draft-iesg-vendor-extensions-00.txt
I don't mind, but I followed Scott Bradner's advice. Yours, Shahram -Original Message- From: Alex Zinin [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 6:06 PM To: Shahram Davari Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: draft-iesg-vendor-extensions-00.txt Shahram, Since the draft in subject is not specific to the CCAMP or MPLS WGs, or even the SUB-IP area, may I suggest that we don't abuse the mailing lists of these WGs and take the discussion to [EMAIL PROTECTED] -- Alex Thursday, March 6, 2003, 11:35:16 AM, Shahram Davari wrote: Hi All, I would like to make an alternative proposal to what is proposed in this draft. I think that IETF should not prevent other SDOs from developing extensions (minor or major), to IETF protocols, as long as they don't call those extensions being IETF compliant. I think IETF could recommend that the other SDOs present their protocol extensions to IETF (in the form of a draft). The IETF community then has 3 choices: 1) IETF agrees with the requirements and nature of the extensions and find them useful. In that case IETF could engage in technical discussions with the other SDO and reach to a mutually agreeable draft, which could then be advanced to Proposed Standard. 2) IETF agrees with the requirement, but does not agree with the proposed extension, and prefers other solutions/extensions that it thinks meet those requirements. In that case IETF could develop its solution and present it to the requesting SDO. If that SDO is satisfied with IETF's solution, then fine, otherwise nobody can prevent them from developing their own extension. If that happens then there would be two solutions for the same requirements and we should let the Market decide which solution/extension do they prefer. 3) IETF does not agree with the requirement for such extensions at all. In that case, the other SDO should be free to developed their own extension, provided they don't call those extensions to be IETF compliant. Thanks, -Shahram
Re: IAB policy on anti-spam mechanisms?
Keith Moore [EMAIL PROTECTED] writes: or at least, proper behavior isn't well-defined. IMHO, about the only behavior that is reasonable (assuming a single cert, which IIRC is what TLS assumes) is to have the peer server offer a cert for the domain name associated with the A record, not the one associated with the MX record. Just to make sur I understand, do you mean that if someone is sending mail to [EMAIL PROTECTED], and there's an MX for rtfm.com pointing to mail.isp.com, the cert should contain mail.isp.com in the subject name? If so, this really isn't satisfactory, because it allows anyone who can tamper with the DNS to intercept mail destined for any server. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
Re: IAB policy on anti-spam mechanisms?
On Wednesday, March 12, 2003, at 12:27 AM, Eric Rescorla wrote: Keith Moore [EMAIL PROTECTED] writes: or at least, proper behavior isn't well-defined. IMHO, about the only behavior that is reasonable (assuming a single cert, which IIRC is what TLS assumes) is to have the peer server offer a cert for the domain name associated with the A record, not the one associated with the MX record. Just to make sur I understand, do you mean that if someone is sending mail to [EMAIL PROTECTED], and there's an MX for rtfm.com pointing to mail.isp.com, the cert should contain mail.isp.com in the subject name? yes. because mail.isp.com is the name of a server which might support thousands of MXed domains. If so, this really isn't satisfactory, because it allows anyone who can tamper with the DNS to intercept mail destined for any server. I see your point. But I suspect it illustrates a significant limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume that an IP address and port number are used by only one named service. It's been awhile since I looked at the TLS protocol but I don't recall any way for the client to say prove to me that you are authorized to provide the SMTP service associated with DNS name foo.com. or did I just forget that feature?
Re: IAB policy on anti-spam mechanisms?
Keith Moore [EMAIL PROTECTED] writes: yes. because mail.isp.com is the name of a server which might support thousands of MXed domains. That's what I figured. If so, this really isn't satisfactory, because it allows anyone who can tamper with the DNS to intercept mail destined for any server. I see your point. But I suspect it illustrates a significant limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume that an IP address and port number are used by only one named service. It's been awhile since I looked at the TLS protocol but I don't recall any way for the client to say prove to me that you are authorized to provide the SMTP service associated with DNS name foo.com. or did I just forget that feature? This could be conceivably accomplished in two ways: (1) By the application protocol (in this case SMTP) indicating what server the client wanted to talk to. This isn't possible in STARTTLS, but it could easily have been specifid that way. I would have designed things differently. (2) You could use the TLS domain name extension described in draft-ietf-tls-extensions-06.txt, recently approved at Proposed by the IESG. Unfortunately, neither of these fixes solves the real problem, which is that it's impractical for a relaying MTA to have a a certificate for every host it might potentially receive mail for, but that's what's required here. I suppose you could call this as a limitation in TLS, but it's really a basic limitation of pretty much any channel security scheme. If you want to do better, you really need an object security scheme like S/MIME. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
