RE: NATs as firewalls
The FCC digital TV guideline is a bad example. There is no credibility in a plan that says that the govt. is going to cut off their primary means of outreach to voters. The networks know that and are acting accordingly. -Original Message- From: Nick Staff [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 11:16 PM To: ietf@ietf.org Subject: RE: NATs as firewalls From: David Morris [mailto:[EMAIL PROTECTED] On Fri, 9 Mar 2007, Nick Staff wrote: I think the thing that would help IPv6 the most would be the setting of a hard date when no new IPv4 addresses would be issued. This would make it real for everyone and ignite the IPv6/IPv4 gateway market (I think). Not to mention we'd never have to have another debate over when IPv4 was going to run out which might be benefit enough in itself ;) What a lawsuit mess that would be ... artificial limits would never work. I think the US FCC Digital Broadcast Deadline is a good example - though more drastic than I was suggesting. I think artificial limits are inevitable unless the intention is to support IPv4 until there's no one left in the world who wants to use it (and even that is an artificial limit). I also don't understand what is gained by a sliding doomsday other than procrastination, avoidance, and a neutered stimulus. I mean if IPv4 addresses are going to run out wouldn't it be better to know exactly when? In my opinion you make it real if you give it a date but until then it's like saying smoking may cause cancer. If any smoker knew for a fact that the next drag on a cigarette would give them cancer they'd never smoke again. If a network manager knew that in 7 years all new address space would be IPv6 it would become a consideration from that point forward. In my opinion. Nick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
When considering the Last Call comments, the IESG finally concluded that this document should be published as an ION. Other Last Call comments will result in editorial changes. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NATs as firewalls
On Mar 9, 2007, at 10:17 PM, David Morris wrote: In the low end bandwidth space I play, a extra 192 bits on every packet is significant to end user performance. As others have noted, it seems like the fairly effective anti-spam technique of associating reputations with network addresses will be stressed by exploding the number of addresses ... stressed because the originators of spam will be able to be more agile and because the memory and CPU required to track such reputations explodes. Perhaps by the time IPV4 scarcity is a critical economic issue, the continuing trend of cheaper faster last mile internet connectivity as well as server system capability cost reductions will converge... or perhaps some combination of legal and techical solutions will push spam into the noise level. Etc. Unwanted traffic will likely become much worse. DKIM is an example of how it took years to define a domain-specific cryptographic signature for email. Although defining a signing policy remains, it is doubtful the results will prove practical at controlling cryptographic replay abuse in a diverse network landscape. Where a responsible signer might rate-limit account holders or exclude bad actors, some means is still needed to authorize transmitters to determine whether an assumption of control is still valid. DKIM has no safe provision to authorize transmitters unless within the domain of the signer. It seem unreasonable, when considering how diverse a IPv4/IPv6 landscape will become, to then expect all related network providers will obtain a zone from each of their customer's domains and configure it for each of the protocols. That constraint represents an administrative nightmare. DKIM can be adjusted, but can this be done within a suitable timeframe? Without a name-to-name authorization scheme, controlling abuse will remain by the IP address. When those addresses happen to be gateways into IPv4 space operating as giant NATs, the collateral impacts will make today's problems seem like the good old days. Retaining an open system of communication may then become untenable, and that would be a shame. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments on draft-housley-tls-authz-07
Eric Rescorla wrote: The listed terms are RAND but not necessarily royalty-free. Doesn't RAND mean Royalty-free And Non-Discriminatory ? I tried define:RAND at Google, but didn't get that one. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments on draft-housley-tls-authz-07
Frank Ellermann [EMAIL PROTECTED] writes: Eric Rescorla wrote: The listed terms are RAND but not necessarily royalty-free. Doesn't RAND mean Royalty-free And Non-Discriminatory ? I tried define:RAND at Google, but didn't get that one. Reasonable And Non-Discriminatory. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call Comments on draft-housley-tls-authz-07
R is for Reasonable. http://en.wikipedia.org/wiki/Reasonable_and_Non_Discriminatory_Licensing Dan -Original Message- From: Frank Ellermann [mailto:[EMAIL PROTECTED] Sent: Saturday, March 10, 2007 8:31 PM To: ietf@ietf.org Subject: Re: Last Call Comments on draft-housley-tls-authz-07 Eric Rescorla wrote: The listed terms are RAND but not necessarily royalty-free. Doesn't RAND mean Royalty-free And Non-Discriminatory ? I tried define:RAND at Google, but didn't get that one. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments on draft-housley-tls-authz-07
RANDZ is what you are thinking of. On 3/10/07, Frank Ellermann [EMAIL PROTECTED] wrote: Eric Rescorla wrote: The listed terms are RAND but not necessarily royalty-free. Doesn't RAND mean Royalty-free And Non-Discriminatory ? I tried define:RAND at Google, but didn't get that one. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call Comments on draft-housley-tls-authz-07
EKR wrote: [RAND] Reasonable And Non-Discriminatory. Thanks also to Dan and Clint, apparently I confused it with RANDZ. The rule to expand acronyms on first usage in RFCs is really good for me... :-) Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
