Subject: Re: draft-ietf-v6ops-natpt-to-historic-00.txt

From: [email-masked] (Noel Chiappa)
Date: Mon, 2 Jul 2007 09:07:48 -0400 (EDT)

> From: [email-masked] (Jun-ichiro itojun Hagino)

    > if NAT-PT is to be made historic due to the claims presented in the
    > draft, all of the NAT related documents have to be made historic
    > ...
    > and all of the NAT traversal documents .. has to be banned at once.

    > itojun@fahrenheit 911

The irony of that email address, appended to that message, is pretty good.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Christian Huitema <[email-masked]>
Date: Mon, 2 Jul 2007 09:43:30 -0700

From: Noel Chiappa, Monday, July 02, 2007 6:08 AM
> The irony of that email address, appended to that message, is pretty

:-)

Maybe someone should pause and consider why the IETF publishes
specifications, or informational documents. Over the last 15 years, I
have seen a drift of attitude, basically from engineering to a policy
making. 

In the old engineering attitude, working groups were created because
several like-minded engineers wanted to develop some function, or
protocol. It was important for them to get together, so they could
voluntarily agree on the details. If they did not, each would develop
their own version, and there will be no interoperability. The result was
documented in a set of RFC, so that whoever wanted to develop a
compatible product could. IANA registries are used to ensure that when
options arise, the options are numbered in an orderly manner. 

In the policy making attitude, working groups are created to control
evolution of a particular function. The working group members are
concerned that someone else might be implementing something harmful to
the Internet. Their goal is not so much to develop products as to ensure
that non-conforming products do not get developed. IANA registries are
used to control extensibility of the resulting protocols, to make sure
that "bad" options never get a number.

In short, the IETF evolved from an informal gathering where engineers
will agree on how to do things, to a reactive body that mostly aims at
controlling evolution of the Internet. Is that really what we want?

-- Christian Huitema

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 10:42:33 -0700

This is a very important point.

If you want to do policy then you have to do accountability. The IETF organization structures are not designed to support policy work. They might even be designed to stop people from trying to do policy work.

For an organization to do policy work it has to have mechanisms for accountability and representation of the key interests. That is not compatible with an organization which has no members, rejects voting and who selects the nomination committee by lottery.
 
What seems to be irritating some people here is a perceived unilateral decision 'hey we don't like NAT so lets go trash the NAT-PT docs'. That might be the right call but I do not get any sense from the draft that the authors seriously considered the reasons why people are deploying NAT today as being valid.

That may or may not be the right thing to do here. But we seem to have a constitution that only allows negative policy statements to come out. The Internet is not asking the IETF for guidance on what not to do. What people want is a positive architectural vision that they can plan to.

This is the type of work product I would like to see the IAB deliver. 

But in order to make such statements stick there would have to be a lot more outreach built into the process than there is today.

At the moment we have three Internet standards organizations that are dimly aware of the existence of each other and no more. And none of those organizations has a real interaction with organizations like AntiPhishing Working Group, MAAWG, ASC etc.

We have three grand challenges for the next generation internet: security, cost of administration and IPv6. 

In order to drive change across the Internet we need to have contact between some of these groups. How about holding meetings between the IETF IAB, OASIS Architecture board, W3C TAG and representatives from groups like MAAWG, ASC, APWG etc?

I would like to see statements from the IAB of the form 'we have talked to representatives of ISPs and in their view this IPv6 thing is not going to happen unless A, B and C happen first'. 

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 12:44 PM
> To: Noel Chiappa; [email-masked]
> Subject: RE: draft-ietf-v6ops-natpt-to-historic-00.txt
> 
> >     > if NAT-PT is to be made historic due to the claims 
> presented in 
> > the
> > The irony of that email address, appended to that message, 
> is pretty 
> > good.
> > 
> > 	Noel
> 
> :-)
> 
> Maybe someone should pause and consider why the IETF 
> publishes specifications, or informational documents. Over 
> the last 15 years, I have seen a drift of attitude, basically 
> from engineering to a policy making. 
> 
> In the old engineering attitude, working groups were created 
> because several like-minded engineers wanted to develop some 
> function, or protocol. It was important for them to get 
> together, so they could voluntarily agree on the details. If 
> they did not, each would develop their own version, and there 
> will be no interoperability. The result was documented in a 
> set of RFC, so that whoever wanted to develop a compatible 
> product could. IANA registries are used to ensure that when 
> In the policy making attitude, working groups are created to 
> control evolution of a particular function. The working group 
> members are concerned that someone else might be implementing 
> something harmful to the Internet. Their goal is not so much 
> to develop products as to ensure that non-conforming products 
> do not get developed. IANA registries are used to control 
> extensibility of the resulting protocols, to make sure that 
> "bad" options never get a number.
> 
> In short, the IETF evolved from an informal gathering where 
> engineers will agree on how to do things, to a reactive body 
> that mostly aims at controlling evolution of the Internet. Is 
> that really what we want?
> 
> -- Christian Huitema
> 
> 
> 
>

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 02 Jul 2007 18:46:44 +0100

>> The irony of that email address, appended to that message, is pretty
:-) :-)

Firstly, let's be clear that there is a difference between NAT and 
NAT-PT.  The draft makes it clear that a major reason for not wanting 
NAT-PT deployed is that it effectively ties many of the characteristics 
of a developing IPv6 network to those of the existing IPv4 network.  
Whether there would actually be real differences remains to be seen but 
clamping IPv6 through a transition mechanism seems very short sighted, 
whatever the technical shortcoming of NAT-PT (or NAT) might be, and the 
draft tries to stop NAT-PT getting any further deployment because of this.

For better or for worse IPv4 NATs are here already and a.s. here to 
stay.  Trying to toss the specifications on the book bonfire is 
pointless and  counterproductive.  Likewise trying to kill off the NAT 
traversal industry would require a suitable Hydra-slaying superhero: 
"Volunteers, two paces forward... wait for it!" Maybe IPv6 will do the 
trick but even there we will require considerable vigilance.

However I have a good deal of sympathy for Christian's remarks below.  
The NAT/traversal industry has many of the hallmarks of the 'new IETF'.
> controlling evolution of the Internet. Is that really what we want?
I hope not, but I fear you are correct.  IMO Much of this stems from the 
ossification and 'lowest common denominator' nature of the deployed 
network,  Arguably, the network/protocol suite is senile and truly 
novel, architecturally valid improvements are close to impossible 
because the network cannot adapt to them. The IETF is trying to prevent 
death rather than enhance life.

/Elwyn

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Jul 2007 14:07:39 -0700

> From: Elwyn Davies [mailto:[email-masked]] 

> I hope not, but I fear you are correct.  IMO Much of this 
> stems from the ossification and 'lowest common denominator' 
> nature of the deployed network,  Arguably, the 
> network/protocol suite is senile and truly novel, 
> architecturally valid improvements are close to impossible 
> because the network cannot adapt to them. The IETF is trying 
> to prevent death rather than enhance life.

The ossification is not necessary. There are technical reasons and political reasons but both are fixable.

The technical issue is that we lack a network policy layer so there is no way to code the statement 'I support legacy SMTP and Multi-media messaging protocol 2.3' or statements of the form 'all SMTP mail from this address is signed using S/MIME'.

That is what domain centric is all about addressing in the general case.

The political issue is that changing the infrastructure takes a lot of buy in and has to be driven by a deployment plan that addresses the pain points recognized by the people being asked to buy in. NAT and IPv6 are not recognized as critical pain points by any people I know of outside the IETF. I don't think you will find anyone else who puts them in their top five list of things they need to get done.

That is an unfortunate situation but not an impossible one. What we need to do is to devise a technical infrastructure which addresses at least one of the top two pain points that specific parties recognise and also addresses the issues that we think need to be addressed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jul 2007 09:25:10 +0200

BTW, people who want to help fix this topic could usefully
hop over to v6ops and comment constructively on
draft-ietf-v6ops-cpe-simple-security-00.txt and
draft-woodyatt-ald-01.txt.

     Brian

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Jul 2007 12:21:23 -0700

> controlling evolution of the Internet. Is that really what we want?

Hi Christian,

I'm not sure that we have much of a choice.  If there is no control  
over how the technology is used, then forces that see an advantage in  
doing something harmful to the Internet will come into play.  A fine  
example of this already exists with address space.  We understand  
that address space, while large, is finite, and we've created policy  
(delegated to the RIRs) to ensure that address space requests are  
duly justified.

We have created the ultimate Commons, and it is up to us to create  
the policy to prevent the associated tragedy.

Regards,
Tony