Subject: Stupid NAT tricks and how to stop them.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Mar 2006 08:41:15 -0800

> From: Henning Schulzrinne [mailto:[email-masked]] 

> Trying to devise ever more elaborate NAT traversal mechanisms 
> that include sending keep-alives every few seconds and 
> various "let's try this and then that" algorithms clearly 
> don't scale if we want to get to consumer-grade reliability, 
> not just interesting toys that try to stay one step ahead of 
> the next stupid NAT trick.

The reason for all those 'stupid NAT tricks' is precisely the attitude you
show here

FACT: IPv4 address space is a scarce resource only viable because of NAT.

FACT: People do not want to pay their cable ISP for extra connections.

FACT: Smug exhortations to move to IPv6 ignore the fact that there is no
transition plan.

The obvious way to deploy IPv6 is to leverage the NAT infrastructure. Devise
a protocol suite that allows a NAT box to transparently support IPv4 or IPv6
on either side of the box. Evangelize to the major providers of NAT (Cisco,
Netgear, Microsoft, Belkin...). 

What I would like to come out of the IAB is a stream of documents that 1)
identify pain points that are being felt in the current Internet
architecture, 2) hold solutiourselves.
> 
> We do have a friendly fund-raising body, the ISOC. If full 
> scale technical tutorials are to be sold, ISOC should be the vehicle.
> 
>      Brian
> 
> John C Klensin wrote:
> > --On Sunday, 26 March, 2006 14:50 +0200 "Romascanu, Dan \\(Dan\\)" 
> > <[email-masked]> wrote:
> > 
> > 
> >>I believe that I made this proposal in the past, in a 
> plenary session 
> >>a while ago, when numbers in the IETF particpation were the issue. 
> >>Discussions hold then led to the edu track, which is 
> however focused 
> >>on IETF process and not on technical or tutorial content.
> >>
> >>I do not see why should not the IETF offer a full Sunday track of 
> >>tutorials with technical content. Why should one go to a industry 
> >>conference or trade show to hear what is going on in an 
> IETF WG, when 
> >>the principal contributors (WG chairs,
> >>editors) who usually give these talks are all attending the IETF 
> >>meetings? Having a full Sunday track of tutorials would not only 
> >>attract new people to come to the IETF and help them 
> justify to their 
> >>employers and to themselves the cost of the travel, but 
> also improve 
> >>the level of understanding of the technical material in the WGs, 
> >>increasing the chances that new attendees would become active 
> >>participants in a shorter time.
> >>
> >>We can even play with different fees structure (conference only, 
> >>tutorial only, conference + tutorial) to help people optimize their 
> >>costs.
> >>
> >>The extra money resulting from the tutorial fees and increased 
> >>participation would lower sponsoring costs, and hopefully 
> the meeting 
> >>fees for the technical contributors.
> > 
> > 
> > Dan,
> > 
> > I see one major problem with this.  I tried to raise it 
> with the EDU 
> > team before Dallas but, other than one set of offline 
> comments from an 
> > individual, have gotten no response.
> > 
> > Despite all of the noise in the IPR WG, the biggest risks to a 
> > standards body involve claims that the review and approval process 
> > have been captured or manipulated by particular interests, 
> causing the 
> > documents that are produced to reflect those manipulations 
> rather than 
> > open and balanced community consensus.
> > 
> > A tutorial whose subject matter is how to get things done 
> in the IETF 
> > -- how we are structured, how we do business, the tools we use, and 
> > even what one needs to know technically and structurally to 
> write an 
> > I-D or RFC -- are not problematic.
> > But, as soon as we start giving technical tutorials that related to 
> > areas that are under standardization, there is a risk of 
> someone later 
> > claiming that the tutorial content was biased in one way or another 
> > that impacted the standardization choices we made.  That would be 
> > extremely bad news... possibly of the variety that could 
> have the EDU 
> > team or the IESG neck-deep in lawyers.
> > 
> > So, if there are to be technical tutorials, I suggest that 
> you start 
> > working on an organizational structure that would keep the 
> decisions 
> > about which sessions to hold and their content at arms-length or 
> > further from anyone with decision-making leadership in the 
> IETF.  Even 
> > then, there are risks.  But a decision made by an EDU team that 
> > operates under even general IESG supervision, or with a 
> lecturer who 
> > is involved in the standards process and who is taking 
> positions there 
> > (or is associated with a company that is doing so), are really poor 
> > ideas if we want to preserve both the fact and appearance 
> of fairness 
> > in the standards process.
> > 
> >     john
> > 
> > 
> > _______________________________________________
> > Ietf mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ietf
> > 
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

------=_NextPart_000_000D_01C65191.7DCC8120
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encons workshops leading to architecture documents
that identify proposed solutions together with fair summaries of counter
proposals.

The IRTF was apparently intended to fill this role, given the pace of
Internet development an organization that works even slower than the IETF is
not capable of providing useful input on addressing a pain point.

The IETF has not had a voice in the major issues that the Internet has been
facing. On spam the IETF voice was hijacked. On Internet crime the IETF is
silent.

> Thus, I think we need a separate organization (or work with a separate
> organization) that does branding and certification. It's hard 
> to buy a non-WiFi device in stores today; the equivalent 
> consumer assurance needs to be true for core consumer and 
> small-business network devices, and possibly services.

That is a good idea, but the systems design MUST meet the real needs of
actual customers. The problem with large amounts of IETF design is that
abstract engineering fetish is put ahead of meeting real users needs. 

For such a forum to be viable it would require the active participation of
the application providers. For that to happen the specs would have to result
in a sellable product which means meeting real customer requirements.

Paul Hoffman has in fact created something of the sort, it does not have the
level of consumer recognition that is required and the level of
participation is less than is needed but it could potentially be built on. 
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf