Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt
tion; we also need to agree as a community that the proposed usage will not be a cause of collateral damage to the Internet. There's every reason that the same standard should apply to specifications developed outside the IETF exactly as to IETF documents. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science 292 Lindley Hall, Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)
Margaret, my concerns (and those of others) are a bit different I think. Again, I see what happened as: 1. A non-IETF standard is being developed. 2. The standard is being reviewed by another organization. 3. The group working on the standard requests a code point from IANA The "IESG review" is the only available process since no technical review is requested within the IETF (both of the other options would seem to imply such a review). The IESG seems to have reacted by assuming that it had to substitute its judgment for the technical review which is not part of the request, and I think _that was wrong_. If the IESG concluded that a technical review was needed, then _IETF consensus_ would be appropriate. BUT, in this case my read is that the IESG should _not_ have conducted a technical review, but rather should have limited the review only on whether a code point was available, and whether a hop-by-hop option unknown to most devices would cause any foreseeable problems. That last point bothers me the most; if a standard is being developed within the framework of another known standards organization and on top of this (in this case) by a known set of engineers, should the IETF not focus on interoperability instead of second-guessing the outside work? I could see how an unknown IPv6 option header could possibly become a problem (although that would point to bad protocol design or implementation, IMHO), so interoperability should be reviewed, but otherwise I _cannot_ see how the _content_ of the option could harm a device that does not want to deal with it. On Jun 29, 2005, at 17:39, Margaret Wasserman wrote: I agree that this would be a reasonable process, but wouldn't that be "IETF Consensus" (an entirely separate choice in RFC 2434 from IESG Approval)? I said that I was confused... and this is the main point that is confusing me. The arguments against what the IESG has done seem, mostly, to be that we should have gotten IETF consensus before making a decision. But, if the IESG isn't supposed to make any decisions without IETF consensus, then why are these two separate choices in RFC 2434? Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)
But the refusal of a code point is not effective, and in fact counter-productive (since the option will indeed be deployed, you just won't know what code point it self-assigned). On Jun 28, 2005, at 23:10, Keith Moore wrote: those are both valid concerns, but relatively minor concerns compared to the potential for poorly designed IP options to have an adverse effect on Internet interoperation, at any layer from 3 up. and one stops that by refusing a unique codepoint? one stops it by any means that is effective and available. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science 292 Lindley Hall, Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)
Just a quick (one-time I plan) note in support of John's position. I, too, think it is counterproductive to avoid/deny registration in this case. Maybe a slightly different way of saying it: - A group of folks has designed an IP _option_ they intend to use - They have documented the option (albeit not in IETF format) - They are asking, in fact, "We are going to deploy this option, what code point would you like us to use?" The IETF/IESG have two choices IMHO: A. Assign a code point. If someone later says "hey, that option doesn't play well on my part of the network", you know _exactly_ what code point to filter (drop packets) on. In a good community spirit one might also write this up as an "option XYZ considered harmful" ID. B. Deny the assignment of the code point, and forever wonder which unknown code in an inbound packet might correspond to this option. I suggest choice A. above is the better one of the two. Also note that "C. Prevent the deployment of the option" does not exist. On Jun 28, 2005, at 16:32, John C Klensin wrote: Sigh. I'm going to try one last time. Probably I should just give up. Bob and Keith, As far as protocol changes, adding stuff to IP, etc., I am 100% in agreement with you. We should be cautious, we should exercise considerable diligence, we should not approve anything without considerable evidence of informed IETF consensus. I can't figure out how to say that more clearly. _However_ if some rogue group comes along (and I hope that we are a long distance from where Larry Roberts would be considered a "rogue group", even though I have disagreed about some things he has advocated in the past and may do so in the future) and has the resources and commitment to deploy an IP option, I think we need to register it to protect the community from the bad option, not pretend that not registering it will somehow prevent them from deploying their ideas. And then, if we are convinced the idea is bad enough, we need to do what _will_ prevent the bad idea from being actively used, which is to do, and write up the analysis of why it is bad and what problems it will cause. But the notion that the IETF can prevent something from happening or being deployed by declining to register it, or by turning our collective backs on it without any real explanation -- even at the waist of the hourglass-- is, in this world, just delusional. And, if that delusion prevents the IETF community from explaining, carefully and in public why the idea is a bad one, then it is we who are putting the Internet at risk. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science 292 Lindley Hall, Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: reduce jitter in routed network for voip applications
That establishment/reservation phase is RSVP; as others have said, available in theory, but cannot be assumed to exist in the network in general. On Mar 28, 2005, at 13:26, Daniele Giordano wrote: CoS, ToS, QoS work on the information units queued in a buffer of a device. I think that, in the same way of a circuit switched network, an establishment phase could exist. In this phase the network could reserve the right resources. i.e. virtual circuit, bandwidth, Thanks. - Original Message - From: "Mike S" <[EMAIL PROTECTED]> To: "Daniele Giordano" <[EMAIL PROTECTED]> Cc: Sent: Monday, March 28, 2005 1:40 PM Subject: Re: reduce jitter in routed network for voip applications At 06:09 AM 3/28/2005, Daniele Giordano wrote... RTP is transparent at the transport layer. We analyse TCP and UDP: TCP is connection oriented and so the communication begins with the definition of a virtual circuit. A virtual circuit is a temporary connection of sequence nodes with relative reservation of bandwidth. A connection oriented service gives the certainty that all information units use the same nodes with a same medium latency. Same latency maintains reduced the jitter. That is incorrect unless _other_, stateful protocols (ex. RSVP, integrated services) are in use throughout the entire network. That is not the general case. IP routes on a per hop basis, whether TCP or UDP. There is no "virtual circuit" created, except at the endpoints. I think that RTP should use a layer 4 connection oriented protocol (like TCP) but without retransmissions of information units with excessive delay or errors (like UDP). What do you think about this? You're trying to solve a problem which is incorrectly defined, and therefore doesn't exist. Diffserv already provides a QoS mechanism for VoIP and does not require gateways to maintain state for each connection. It, like Intserv, cannot be assumed to exist through any random Internet path. RFC2474, RFC2475. ___ 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 Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science 292 Lindley Hall, Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
Technically true, of course. However, most SOHO sites look for a zero-order level of protection against the random worm trying to connect to an open TCP port on the average windows machine (especially one set up for file/print sharing on the SOHO network), and NAT does that just fine. IPv6 marketing has to take this into account, with a deliberate "here is why the IPv6 gateway provides the same default protection as NAT..." FAQ entry. On Nov 22, 2004, at 18:00, Fred Baker wrote: would that it were true. In fact, it is pretty easy to breech. All one has to do is ddos with a the right port prefix, observe a response of any kind, and you can ddos right through it. An actual stateful firewall is a good thing. NAT mostly has the effect of deluding the person behind it into thinking they have a security solution. Screen doors are a good thing. They should be confused neither with storm doors nor effective insect inhibitions in the home... Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science 292 Lindley Hall, Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: list address for MASS
This is what I found: http://www.imc.org/ietf-mailsig/index.html On Aug 6, 2004, at 0:47, Andrew Newton wrote: Can anyone provide the list/subscription address for MASS: http://www.ietf.org/ietf/04aug/mass.txt -andy ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Netmeeting - NAT issue
OK, but that does not solve the problem where the NATs are mostly deployed -- home and SOHO -- until all internet servers of interest to those users speak IPv6. "Can be upgraded to do so" is great if you control the server, but these users don't. So Yahoo, Google, etc can be pursuaded to upgrade, maybe... and the home/SOHO user using the setup below does a search. Many of the hits will be IPv4 only sites, and we are back to NAT. Don't get me wrong, this is a good migration path and should be pushed as much as possible, but it is not as fast as your message implies. --On Tuesday, March 19, 2002 11:37 -0500 Keith Moore <[EMAIL PROTECTED]> wrote: >> Maybe IPv6 will fix all that . . . . we can only pray . . . > > easily fixed. > > get a single IPv4 address, assign it to a 6to4 router that's installed > at your border, and put up to 2**80 hosts (okay, 2**16 hosts if > you use stateless autoconfig) behind it. you can then get to any of > those hosts from any another machine that speaks IPv6. if those > machines don't speak IPv6, they can often be upgraded to do so. > if they don't have IPv6 connectity, they can get it using 6to4. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax
Re: Why IPv6 is a must?
The discrepancy in opinions below seems to me to point towards the deployment path for IPv6. Corporate users and those with very large address space needs (wireless handhelds) will deploy IPv6 and in effect "pay" for the engineering cost of building IPv6 into operating systems and network elements. Once the costs come down, home users, small businesses, and their ISPs will follow. (Note that I do think IPv6 is inevitable and that is a Good Thing; I also think that it is unrealistic to expect the low-end/cost-driven user to jump into the conversion; telling them their (temporary) solution is "evil" does not make them move any faster). --On Monday, November 05, 2001 14:40 -0500 Thomas Narten <[EMAIL PROTECTED]> wrote: > "J. Noel Chiappa" <[EMAIL PROTECTED]> writes: >> (This message coming to you via the NAT box I bought in the >> hole-in-the-wall computer store in the little strip mall right down the >> street, here in Podunksville. > > Lucky you. > > If I had a NAT box at home, and I tried to connect to my corporate > network through it, I would quickly learn two things: > > 1) It doesn't work (it's an IPsec based solution) > > 2) If I then called the Help Desk, their response would be "we don't >support that configuration". > > YMMV. > > Thomas > Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax
