RE: IETF-ad-hominem (Was: Re: US DoD and IPv6)

[Michel Py]

Keep your head in the sand. Efforts towards convergence to a post mortem
are rarely fast and rarely painless.

-Original Message-
From: Richard L. Barnes [mailto:rbar...@bbn.com] 
Sent: Wednesday, October 06, 2010 10:05 PM
To: Michel Py
Cc: Keith Moore; Noel Chiappa; ietf@ietf.org
Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)

NEW NON-IETF LIST ANNOUNCEMENT

IETF Ad Hominem Discussions

This group is dedicated to the discussion of the personal flaws of  
IETF participants.
-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies






On Oct 6, 2010, at 9:29 PM, Michel Py wrote:

>> Michel Py wrote:
>>> Has it occurred to you that, if it was not for your
>>> blind opposition to NAT, we could be living in a world
>>> of 6to4 implemented in the ubiquitous NAT box?
>
>> Keith Moore wrote:
>> Why do you think I proposed 6to4 in the first place? There
>> was no vendor interest in putting 6to4 in NAT boxes.
>
> They got tired of systematic torpedoing of anything that looked like
> NAT, walked like NAT, quacked like NAT and being told relentlessly  
> that
> their product was crap in a plastic box and decided that it was less
> trouble and more profit to build a NAT box without 6to4.
>
>
>>> Look what you have done: not only we have more NATv4 than ever,
>>> but now we also have NAT46, NAT64, NAT464...whatever and all of
>>> these with heavy ALG layers to make it more palatable.
>
>> I think you give me far more "credit" than I'm due.
>
> Maybe, and I certainly deserve some "credit" myself; nevertheless  
> some,
> (rather large) amount of some flavor of NAT was unavoidable and I  
> still
> believe that it would have been more productive to accept that fact
> instead of trying to get rid of any kind of any NAT altogether.
>
>
>
>> Noel Chiappa wrote:
>> in some sense the real guilty party in the IPv6 choice is the IETF
>> at large, the ordinary members - for accepting what was basically
> 'IPv4
>> with a few more bits', instead of a fundamentally revised  
>> architecture
>> that would provided real benefits in the form of major new
> capabilities
>> (e.g. separation of location and identity), thereby giving actual
>> operational incentives to drive migration.
>
> Problem is that IPv6 is much more than IPv4 with more bits. Please  
> note
> that this is not a "I told you so" post; I would certainly have  
> opposed
> what I will suggest below.
>
> In the end though, we would be better off now if we had gone the road
> "it's all the same just pad some extra zeroes" instead of this  
> grandiose
> solve-it-all almost-perfect protocol we all dreamed of.
>
> As of ID/LOC separation, the sad truth is that we both tried, and we
> both failed. And we're not the only ones or the first ones or the last
> ones to try either.
>
> Our collective failure is that we have launched a protocol with "to be
> delivered soon" advanced features that unfortunately have proved to be
> impossible to deliver. Such as, {cough} PA-based multihoming.
>
> Now, what we have on our hands is a mess with a protocol in state of
> "non-deployment" that is not advanced enough to justify a large scale
> deployment (especially with Moore's law still going), but WAY more
> costly to deploy than a dumb "just more bits" upgrade.
>
> Michel.
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF-ad-hominem (Was: Re: US DoD and IPv6)

[Michel Py]

Fine, remove me.

-Original Message-
From: JORDI PALET MARTINEZ [mailto:jordi.pa...@consulintel.es] 
Sent: Wednesday, October 06, 2010 11:02 PM
To: rbar...@bbn.com; Michel Py
Cc: ietf@ietf.org; Keith Moore; Noel Chiappa
Subject: Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)

Yes, please, stop immediately this thread (at least the "personal" way
it is
going on) or I will be forced as sergeant-at-arms to remove the
participants
from the IETF mail exploder.

Regards,
Jordi




> From: "Richard L. Barnes" 
> Reply-To: 
> Date: Wed, 6 Oct 2010 22:04:46 -0700
> To: Michel Py 
> Cc: , Keith Moore , Noel
Chiappa
> 
> Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)
> 
> NEW NON-IETF LIST ANNOUNCEMENT
> 
> IETF Ad Hominem Discussions
> 
> This group is dedicated to the discussion of the personal flaws of
> IETF participants.
> -- Airing of old grievances
> -- Arguments about who gets credit for what
> -- Revelation of hidden conflicts of interest / conspiracies
> 
> 
> 
> 
> 
> 
> On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
> 
>>> Michel Py wrote:
 Has it occurred to you that, if it was not for your
 blind opposition to NAT, we could be living in a world
 of 6to4 implemented in the ubiquitous NAT box?
>> 
>>> Keith Moore wrote:
>>> Why do you think I proposed 6to4 in the first place? There
>>> was no vendor interest in putting 6to4 in NAT boxes.
>> 
>> They got tired of systematic torpedoing of anything that looked like
>> NAT, walked like NAT, quacked like NAT and being told relentlessly
>> that
>> their product was crap in a plastic box and decided that it was less
>> trouble and more profit to build a NAT box without 6to4.
>> 
>> 
 Look what you have done: not only we have more NATv4 than ever,
 but now we also have NAT46, NAT64, NAT464...whatever and all of
 these with heavy ALG layers to make it more palatable.
>> 
>>> I think you give me far more "credit" than I'm due.
>> 
>> Maybe, and I certainly deserve some "credit" myself; nevertheless
>> some,
>> (rather large) amount of some flavor of NAT was unavoidable and I
>> still
>> believe that it would have been more productive to accept that fact
>> instead of trying to get rid of any kind of any NAT altogether.
>> 
>> 
>> 
>>> Noel Chiappa wrote:
>>> in some sense the real guilty party in the IPv6 choice is the IETF
>>> at large, the ordinary members - for accepting what was basically
>> 'IPv4
>>> with a few more bits', instead of a fundamentally revised
>>> architecture
>>> that would provided real benefits in the form of major new
>> capabilities
>>> (e.g. separation of location and identity), thereby giving actual
>>> operational incentives to drive migration.
>> 
>> Problem is that IPv6 is much more than IPv4 with more bits. Please
>> note
>> that this is not a "I told you so" post; I would certainly have
>> opposed
>> what I will suggest below.
>> 
>> In the end though, we would be better off now if we had gone the road
>> "it's all the same just pad some extra zeroes" instead of this
>> grandiose
>> solve-it-all almost-perfect protocol we all dreamed of.
>> 
>> As of ID/LOC separation, the sad truth is that we both tried, and we
>> both failed. And we're not the only ones or the first ones or the
last
>> ones to try either.
>> 
>> Our collective failure is that we have launched a protocol with "to
be
>> delivered soon" advanced features that unfortunately have proved to
be
>> impossible to deliver. Such as, {cough} PA-based multihoming.
>> 
>> Now, what we have on our hands is a mess with a protocol in state of
>> "non-deployment" that is not advanced enough to justify a large scale
>> deployment (especially with Moore's law still going), but WAY more
>> costly to deploy than a dumb "just more bits" upgrade.
>> 
>> Michel.
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



**
The IPv6 Portal: http://www.ipv6tf.org

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be
aware that any disclosure, copying, distribution or use of the contents
of this information, including attached files, is prohibited.



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF-ad-hominem (Was: Re: US DoD and IPv6)

[JORDI PALET MARTINEZ]

Yes, please, stop immediately this thread (at least the "personal" way it is
going on) or I will be forced as sergeant-at-arms to remove the participants
from the IETF mail exploder.

Regards,
Jordi




> From: "Richard L. Barnes" 
> Reply-To: 
> Date: Wed, 6 Oct 2010 22:04:46 -0700
> To: Michel Py 
> Cc: , Keith Moore , Noel Chiappa
> 
> Subject: IETF-ad-hominem (Was: Re: US DoD and IPv6)
> 
> NEW NON-IETF LIST ANNOUNCEMENT
> 
> IETF Ad Hominem Discussions
> 
> This group is dedicated to the discussion of the personal flaws of
> IETF participants.
> -- Airing of old grievances
> -- Arguments about who gets credit for what
> -- Revelation of hidden conflicts of interest / conspiracies
> 
> 
> 
> 
> 
> 
> On Oct 6, 2010, at 9:29 PM, Michel Py wrote:
> 
>>> Michel Py wrote:
 Has it occurred to you that, if it was not for your
 blind opposition to NAT, we could be living in a world
 of 6to4 implemented in the ubiquitous NAT box?
>> 
>>> Keith Moore wrote:
>>> Why do you think I proposed 6to4 in the first place? There
>>> was no vendor interest in putting 6to4 in NAT boxes.
>> 
>> They got tired of systematic torpedoing of anything that looked like
>> NAT, walked like NAT, quacked like NAT and being told relentlessly
>> that
>> their product was crap in a plastic box and decided that it was less
>> trouble and more profit to build a NAT box without 6to4.
>> 
>> 
 Look what you have done: not only we have more NATv4 than ever,
 but now we also have NAT46, NAT64, NAT464...whatever and all of
 these with heavy ALG layers to make it more palatable.
>> 
>>> I think you give me far more "credit" than I'm due.
>> 
>> Maybe, and I certainly deserve some "credit" myself; nevertheless
>> some,
>> (rather large) amount of some flavor of NAT was unavoidable and I
>> still
>> believe that it would have been more productive to accept that fact
>> instead of trying to get rid of any kind of any NAT altogether.
>> 
>> 
>> 
>>> Noel Chiappa wrote:
>>> in some sense the real guilty party in the IPv6 choice is the IETF
>>> at large, the ordinary members - for accepting what was basically
>> 'IPv4
>>> with a few more bits', instead of a fundamentally revised
>>> architecture
>>> that would provided real benefits in the form of major new
>> capabilities
>>> (e.g. separation of location and identity), thereby giving actual
>>> operational incentives to drive migration.
>> 
>> Problem is that IPv6 is much more than IPv4 with more bits. Please
>> note
>> that this is not a "I told you so" post; I would certainly have
>> opposed
>> what I will suggest below.
>> 
>> In the end though, we would be better off now if we had gone the road
>> "it's all the same just pad some extra zeroes" instead of this
>> grandiose
>> solve-it-all almost-perfect protocol we all dreamed of.
>> 
>> As of ID/LOC separation, the sad truth is that we both tried, and we
>> both failed. And we're not the only ones or the first ones or the last
>> ones to try either.
>> 
>> Our collective failure is that we have launched a protocol with "to be
>> delivered soon" advanced features that unfortunately have proved to be
>> impossible to deliver. Such as, {cough} PA-based multihoming.
>> 
>> Now, what we have on our hands is a mess with a protocol in state of
>> "non-deployment" that is not advanced enough to justify a large scale
>> deployment (especially with Moore's law still going), but WAY more
>> costly to deploy than a dumb "just more bits" upgrade.
>> 
>> Michel.
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



**
The IPv6 Portal: http://www.ipv6tf.org

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

IETF-ad-hominem (Was: Re: US DoD and IPv6)

[Richard L. Barnes]

NEW NON-IETF LIST ANNOUNCEMENT

IETF Ad Hominem Discussions

This group is dedicated to the discussion of the personal flaws of  
IETF participants.

-- Airing of old grievances
-- Arguments about who gets credit for what
-- Revelation of hidden conflicts of interest / conspiracies






On Oct 6, 2010, at 9:29 PM, Michel Py wrote:


Michel Py wrote:

Has it occurred to you that, if it was not for your
blind opposition to NAT, we could be living in a world
of 6to4 implemented in the ubiquitous NAT box?



Keith Moore wrote:
Why do you think I proposed 6to4 in the first place? There
was no vendor interest in putting 6to4 in NAT boxes.


They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly  
that

their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.



Look what you have done: not only we have more NATv4 than ever,
but now we also have NAT46, NAT64, NAT464...whatever and all of
these with heavy ALG layers to make it more palatable.



I think you give me far more "credit" than I'm due.


Maybe, and I certainly deserve some "credit" myself; nevertheless  
some,
(rather large) amount of some flavor of NAT was unavoidable and I  
still

believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.




Noel Chiappa wrote:
in some sense the real guilty party in the IPv6 choice is the IETF
at large, the ordinary members - for accepting what was basically

'IPv4
with a few more bits', instead of a fundamentally revised  
architecture

that would provided real benefits in the form of major new

capabilities

(e.g. separation of location and identity), thereby giving actual
operational incentives to drive migration.


Problem is that IPv6 is much more than IPv4 with more bits. Please  
note
that this is not a "I told you so" post; I would certainly have  
opposed

what I will suggest below.

In the end though, we would be better off now if we had gone the road
"it's all the same just pad some extra zeroes" instead of this  
grandiose

solve-it-all almost-perfect protocol we all dreamed of.

As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.

Our collective failure is that we have launched a protocol with "to be
delivered soon" advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.

Now, what we have on our hands is a mess with a protocol in state of
"non-deployment" that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb "just more bits" upgrade.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: existing (and questionable) application designs [was Re: US DoD and IPv6]

[Arnt Gulbrandsen]

The problem with such opinions is that a bunch of purple are deploying ipv6, so 
that in a couple of years you will have to extend your NAT draft to cover 
communicating with v6 nodes anyway, and what's the point then?

Arnt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: US DoD and IPv6

[Michel Py]

> Michel Py wrote:
>> Has it occurred to you that, if it was not for your
>> blind opposition to NAT, we could be living in a world
>> of 6to4 implemented in the ubiquitous NAT box?

> Keith Moore wrote:
> Why do you think I proposed 6to4 in the first place? There
> was no vendor interest in putting 6to4 in NAT boxes.

They got tired of systematic torpedoing of anything that looked like
NAT, walked like NAT, quacked like NAT and being told relentlessly that
their product was crap in a plastic box and decided that it was less
trouble and more profit to build a NAT box without 6to4.


>> Look what you have done: not only we have more NATv4 than ever,
>> but now we also have NAT46, NAT64, NAT464...whatever and all of
>> these with heavy ALG layers to make it more palatable.

> I think you give me far more "credit" than I'm due.  

Maybe, and I certainly deserve some "credit" myself; nevertheless some,
(rather large) amount of some flavor of NAT was unavoidable and I still
believe that it would have been more productive to accept that fact
instead of trying to get rid of any kind of any NAT altogether.



> Noel Chiappa wrote:
> in some sense the real guilty party in the IPv6 choice is the IETF
> at large, the ordinary members - for accepting what was basically
'IPv4
> with a few more bits', instead of a fundamentally revised architecture
> that would provided real benefits in the form of major new
capabilities
> (e.g. separation of location and identity), thereby giving actual
> operational incentives to drive migration.

Problem is that IPv6 is much more than IPv4 with more bits. Please note
that this is not a "I told you so" post; I would certainly have opposed
what I will suggest below.

In the end though, we would be better off now if we had gone the road
"it's all the same just pad some extra zeroes" instead of this grandiose
solve-it-all almost-perfect protocol we all dreamed of.

As of ID/LOC separation, the sad truth is that we both tried, and we
both failed. And we're not the only ones or the first ones or the last
ones to try either.

Our collective failure is that we have launched a protocol with "to be
delivered soon" advanced features that unfortunately have proved to be
impossible to deliver. Such as, {cough} PA-based multihoming.

Now, what we have on our hands is a mess with a protocol in state of
"non-deployment" that is not advanced enough to justify a large scale
deployment (especially with Moore's law still going), but WAY more
costly to deploy than a dumb "just more bits" upgrade.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: existing (and questionable) application designs [was Re: US DoD and IPv6]

[Masataka Ohta]

Brian E Carpenter wrote:

> The problem is that the creation of disjoint addressing realms
> (due to NAT and to IPv4/IPv6 coexistence) has made distributed
> application design almost impossible without kludges.

That's why we shouldn't use IPv6.

With port restricted IPv4 (such as A+P, E2ENAT, PE-ARP), the
addressing realm of address+port is identical as the current
IPv4 Internet that there are no kludges necessary.

Application protocols and programs, including but not limited
to FTP, are working as is without ALG kludges.

As PR-IP effectively expands IPv4 address space by a factor
of 100 or 1000, there is no point to migrate to old and poor
IPv6, even if we need a long term solution.

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

existing (and questionable) application designs [was Re: US DoD and IPv6]

[Brian E Carpenter]

On 2010-10-07 13:57, Fernando Gont wrote:
> On 06/10/2010 05:40 p.m., Keith Moore wrote:
> 
 It's perfectly reasonable for applications to include IP
 addresses and port numbers in their payloads, as this is the only
 way that the Internet Architecture defines to allow applications
 to make contact with particular processes at particular hosts.
 Some might see this as a deficiency in the Internet Architecture,
 but that's the best that we have to work with for now.
>>> If anything, the fact that "this is is the only way that the
>>> Internet Architecture defines..." doesn't make it reasonable.
>> So basically you're arguing to impair the ability of applications to
>> function, just so that network operators can futz around with
>> addresses.
> 
> No. I'm arguing that you should not blame NATs for broken application
> designs, and that you should not assess reasonable-ness based on
> existing (and questionable) application designs.

The problem is that the creation of disjoint addressing realms
(due to NAT and to IPv4/IPv6 coexistence) has made distributed
application design almost impossible without kludges.

See draft-carpenter-referral-ps-01

  Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Fernando Gont]

On 06/10/2010 05:40 p.m., Keith Moore wrote:

>>> It's perfectly reasonable for applications to include IP
>>> addresses and port numbers in their payloads, as this is the only
>>> way that the Internet Architecture defines to allow applications
>>> to make contact with particular processes at particular hosts.
>>> Some might see this as a deficiency in the Internet Architecture,
>>> but that's the best that we have to work with for now.
>> 
>> If anything, the fact that "this is is the only way that the
>> Internet Architecture defines..." doesn't make it reasonable.
> 
> So basically you're arguing to impair the ability of applications to
> function, just so that network operators can futz around with
> addresses.

No. I'm arguing that you should not blame NATs for broken application
designs, and that you should not assess reasonable-ness based on
existing (and questionable) application designs.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] [certid] review of draft-saintandre-tls-server-id-check-09

[Peter Saint-Andre]

Double sorry, I meant to sent this only to the cer...@ietf.org list:

https://www.ietf.org/mailman/listinfo/certid

On 10/6/10 2:53 PM, Peter Saint-Andre wrote:
> Sorry about the delayed reply, still catching up on list traffic here...
> 
> On 9/22/10 4:11 PM, Henry B. Hotz wrote:
>>
>> On Sep 22, 2010, at 10:09 AM, Peter Saint-Andre wrote:
>>
>>> 2.  A human user has explicitly agreed to trust a service that 
>>> provides mappings of source domains to target domains, such as a 
>>> dedicated discovery service or an identity service that securely 
>>> redirects requests from the source domain to a target domain 
>>> (however, such an arrangement is not encouraged and if a client 
>>> supports such a service then it needs to disable it by default and
>>> carefully warn the user about the possible negative consequences of
>>> trusting such a service).
>>
>>
>> Pure wordsmithing.  Make sure this still says what you want:
>>
>> 2.  A human user has explicitly agreed to trust a service that
>> provides mapping of source domains to target domains.  For example
>> the user may trust a dedicated discovery service or identity service
>> that securely redirects requests from the source to a target domain.
>>
>>
>> Such an arrangement is not encouraged.  If a client supports such a
>> service then it needs to disable it by default, and it MUST carefully
>> warn the user about the possible negative consequences of trusting
>> such a service.  
> 
> Just to close the loop, I think we had agreement to remove that
> paragraph, so no further wordsmithing required.
> 
> Peter
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [certid] review of draft-saintandre-tls-server-id-check-09

[Peter Saint-Andre]

Sorry about the delayed reply, still catching up on list traffic here...

On 9/22/10 4:11 PM, Henry B. Hotz wrote:
> 
> On Sep 22, 2010, at 10:09 AM, Peter Saint-Andre wrote:
> 
>> 2.  A human user has explicitly agreed to trust a service that 
>> provides mappings of source domains to target domains, such as a 
>> dedicated discovery service or an identity service that securely 
>> redirects requests from the source domain to a target domain 
>> (however, such an arrangement is not encouraged and if a client 
>> supports such a service then it needs to disable it by default and
>> carefully warn the user about the possible negative consequences of
>> trusting such a service).
> 
> 
> Pure wordsmithing.  Make sure this still says what you want:
> 
> 2.  A human user has explicitly agreed to trust a service that
> provides mapping of source domains to target domains.  For example
> the user may trust a dedicated discovery service or identity service
> that securely redirects requests from the source to a target domain.
> 
> 
> Such an arrangement is not encouraged.  If a client supports such a
> service then it needs to disable it by default, and it MUST carefully
> warn the user about the possible negative consequences of trusting
> such a service.  

Just to close the loop, I think we had agreement to remove that
paragraph, so no further wordsmithing required.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 1:46 PM, David Conrad wrote:

> On Oct 6, 2010, at 7:43 AM, Keith Moore wrote:
>> DNS has never been, and never will be, suitable as a general endpoint naming 
>> mechanism.  
> 
> What do you mean by "a general endpoint naming mechanism"?

It's a good question, but it might take an internet-draft to answer that 
question in sufficient detail for this environment.   The services required 
aren't hard to describe, but it's hard to get the definitions of the terms 
right.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 3:38 PM, Fernando Gont wrote:

> On Wed, Oct 6, 2010 at 2:43 PM, Keith Moore  
> wrote:
> 
>>> When applications that e.g. include point of attachment addresses in the
>>> app protocol break in the presence of NATs, one should probably ask
>>> whether the NAT is breaking the app, or whether the NAT is making it
>>> clear that the app was actually already broken.
>> 
>> It's perfectly reasonable for applications to include IP addresses and port 
>> numbers in their payloads,
>> as this is the only way that the Internet Architecture defines to allow 
>> applications to make contact
>> with particular processes at particular hosts.  Some might see this as a 
>> deficiency in the Internet
>> Architecture, but that's the best that we have to work with for now.
> 
> If anything, the fact that "this is is the only way that the Internet
> Architecture defines..." doesn't make it reasonable.

So basically you're arguing to impair the ability of applications to function, 
just so that network operators can futz around with addresses. 

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 1:59 PM, Phillip Hallam-Baker wrote:

> And what would we say of architects who continued to build to their original 
> plan after the bombs had been flying for twenty years and showed no sign of 
> stopping?

which architects would those be?  I see little sign of architectural 
development in the Internet anymore.   and some of the damage isn't from bombs, 
it's from lack of maintenance.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [ietf] DNS spoofing at captive portals

[Rich Kulawiec]

On Sat, Sep 25, 2010 at 10:34:15PM -0400, John R. Levine wrote:
> >Hmm.  Are you talking about SiteFinder-like services?
> 
> Not really.  There turn out to be a significant number of domains,
> in the hundreds of thousands at least, that are purely evil. 

IMHO, "tens of millions" is closer to reality.

(This of course depends on what one's definition of "purely evil" is,
but mine includes "anything set up solely for spam, attacks, malware,
or resource exploitation".)

But your [larger] point remains: while you and I and others are skilled
at spotting such domains and at handling them appropriately, we're
a tiny fraction of "all Internet users", so it's arguably a service
to prevent all of those from blithely accessing the web sites/mail
servers/DNS servers/etc. associated with those domains.

---rsk
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Phillip Hallam-Baker]

And what would we say of architects who continued to build to their original
plan after the bombs had been flying for twenty years and showed no sign of
stopping?

I would prefer the architects with the plans for a bomb shelter.


On Wed, Oct 6, 2010 at 1:53 PM, Keith Moore wrote:

>
> On Oct 6, 2010, at 1:45 PM, Phillip Hallam-Baker wrote:
>
> On Wed, Oct 6, 2010 at 12:43 PM, Keith Moore 
> wrote:
>
>> The central problem with the Internet seems to be that nearly everybody
>> who routes traffic thinks it's okay to violate the architecture and alter
>> the traffic to optimize for his/her specific circumstances - and the end
>> users and their wide variety of applications just have to cope with the
>> resulting brain damage.
>
>
> Objective observation suggests that the Internet architecture *is* that
> anyone who wants to can molest traffic in any way they feel fit.
>
>
> If a bomb hits a famous building, we don't generally call the resulting
> rubble part of the building's architecture.
>
> (unless, maybe, it's the Hiroshima Peace Dome, which was repurposed to
> commemorate perhaps the worst man-made disaster in history.)
>
> But really, I do not understand why people have to fetishize the constancy
> of IP addresses end to end. IP addresses are not particularly interesting to
> look at.
>
>
> It's one of the two fundamental principles on which the Internet is based.
>  Universal packet format, universal address space.  That's IP in a nutshell.
>
>
> Keith
>
>
>
>


-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Phillip Hallam-Baker]

On Wed, Oct 6, 2010 at 12:43 PM, Keith Moore wrote:

> The central problem with the Internet seems to be that nearly everybody who
> routes traffic thinks it's okay to violate the architecture and alter the
> traffic to optimize for his/her specific circumstances - and the end users
> and their wide variety of applications just have to cope with the resulting
> brain damage.


Objective observation suggests that the Internet architecture *is* that
anyone who wants to can molest traffic in any way they feel fit.

Thats the 'Twits on the Wire' model in a nutshell.


But really, I do not understand why people have to fetishize the constancy
of IP addresses end to end. IP addresses are not particularly interesting to
look at.

-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: US DoD and IPv6

[Fleischman, Eric]

Gentlemen:

The IPv6 deployment is what it is and nobody is to blame that it isn't greater 
or less than it is. It should not surprise anybody that IPv6 hasn't been more 
widely deployed to date, because, after all, I explained back in 1993 in RFC 
1687 why that would happen. 

Going forward, there are many business reasons why IPv6 will increasingly 
become deployed and many business reasons why IPv4 use will actually grow. 
Thus, we can be assured that the Internet will be a mixed environment for the 
next many years to come. We have many existing technologies and approaches that 
handle such mixed environments. There is no reason to be upset -- this is the 
most probable result to the IPv4 address depletion problem. No surprises here.

Best wishes,

--Eric



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

[Les Ginsberg (ginsberg)]

Ben -

The points you make below make sense to me - but I am not sure how we
get the stronger review process associated w "Expert Review" and at the
same time require that some public document exist for each application.
Are you saying that we can require both? I actually thought that was the
intent of "Specification Required" - but your comments suggest
otherwise.

I really wish RFC 5226 addressed this more robustly...

   Les

> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Wednesday, October 06, 2010 8:55 AM
> To: Les Ginsberg (ginsberg)
> Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
> Team; The IETF
> Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-
> 03.txt
> 
> 
> On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote:
> 
> 
> [...]
> 
> >>>
> >>> From RFC 5226:
> >>>
> >>> "Specification Required - Values and their meanings must be
> >>>   documented in a permanent and readily available public
> >>>   specification, in sufficient detail so that
> >> interoperability
> >>>   between independent implementations is possible.  When
> >> used,
> >>>   Specification Required also implies use of a Designated
> >>>   Expert, who will review the public specification..."
> >>>
> >>> We deliberately chose "Specification Required" because:
> >>>
> >>> a)It requires a public specification
> >>> b)It allows the public specification to be other than an RFC
> >>> c)It requires expert review
> >>
> >> Completing the sentence in your quote: "who will review the public
> >> specification and evaluate whether it is sufficiently clear to
allow
> >> interoperable implementations."
> >>
> >> My understanding of "Specification Required" is that the expert
> review
> >> is merely to ensure that the documentation is sufficiently complete
> > and
> >> readable to implement in an interoperable way. That review is not
> >> intended to ensure compliance to other criteria specified in the
> > draft.
> >>
> >> However, the draft includes some specific criteria for GENINFO
> >> applications. If you want the reviewer to enforce those criteria,
> then
> >> I think you need at least "Expert Review". OTOH, in RFC5226, the
> >> "expert review" policy has less to say about the required level of
> >> documentation, so the draft might require some more meat in that
> area.
> >>
> >
> > This is a bit distressing - because you are suggesting that RFC 5226
> > doesn't define a category which is appropriate for our usage - which
> > means we have to try to define a unique policy. I am not quite sure
> how
> > to do that with sufficient authority and minimal controversy.
> >
> > My understanding is that RFC 5226 is specific to IANA considerations
> -
> > so we have attempted to define a clear policy as to how the review
of
> > code point assignments is done.
> >
> > Beyond that, it seems clear that a given Application specification
> could
> > specify behavior that might be seen as undesirable e.g. it could
> specify
> > some extremely high rate of updates. Given that we allow application
> > specification to be defined in public documents from a variety of
> > sources, I don't see how we could define an enforceable review
policy
> > for the application specifications. It is at the IANA codepoint
> > allocation that we have control - and certainly it seems within the
> > purview of an expert to say "I think your specification is flawed
and
> I
> > won't approve the allocation of codepoints until the issues of
> concern
> > are addressed".
> >
> 
> 
> Yes, both "specification required" and "expert review" involve expert
> review. But they have significant differences in the scope of the
> review. "Specification required" means that the expert should review
to
> make sure the specification is clear enough to be implemented in an
> interoperable fashion. It doesn't in any way indicate that the expert
> thinks the code point is "good", or that it conforms to the purpose of
> the registry. Certainly, the expert could offer advise on issues, but
> the registrant would not be under any obligation to follow the advise.
> 
> "Expert Review" means that the expert should review a registration to
> make sure that it conforms to the criteria set forth in the document
> that defined the registry. I really think that is what you are looking
> for, particularly from your last sentence above about the expert being
> able to block allocation of a flawed code point.
> 
> For example, RFC 3563 calls out "Expert Review", and sets a number of
> criteria, one of which is the assertion that registrations require
> standards actions, or that they require publications from  ISO/IEC
> JTC1/SC6 that meant the normal requirements for an RFC.
> 
> In your case, I think you need Expert Review, with criteria along the
> lines that registrants must meet the requirements of "specification
> required", that it must describe its expected rate of updates (and
tha

Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

[Ben Campbell]

On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote:


[...]

>>> 
>>> From RFC 5226:
>>> 
>>> "Specification Required - Values and their meanings must be
>>>   documented in a permanent and readily available public
>>>   specification, in sufficient detail so that
>> interoperability
>>>   between independent implementations is possible.  When
>> used,
>>>   Specification Required also implies use of a Designated
>>>   Expert, who will review the public specification..."
>>> 
>>> We deliberately chose "Specification Required" because:
>>> 
>>> a)It requires a public specification
>>> b)It allows the public specification to be other than an RFC
>>> c)It requires expert review
>> 
>> Completing the sentence in your quote: "who will review the public
>> specification and evaluate whether it is sufficiently clear to allow
>> interoperable implementations."
>> 
>> My understanding of "Specification Required" is that the expert review
>> is merely to ensure that the documentation is sufficiently complete
> and
>> readable to implement in an interoperable way. That review is not
>> intended to ensure compliance to other criteria specified in the
> draft.
>> 
>> However, the draft includes some specific criteria for GENINFO
>> applications. If you want the reviewer to enforce those criteria, then
>> I think you need at least "Expert Review". OTOH, in RFC5226, the
>> "expert review" policy has less to say about the required level of
>> documentation, so the draft might require some more meat in that area.
>> 
> 
> This is a bit distressing - because you are suggesting that RFC 5226
> doesn't define a category which is appropriate for our usage - which
> means we have to try to define a unique policy. I am not quite sure how
> to do that with sufficient authority and minimal controversy.
> 
> My understanding is that RFC 5226 is specific to IANA considerations -
> so we have attempted to define a clear policy as to how the review of
> code point assignments is done.
> 
> Beyond that, it seems clear that a given Application specification could
> specify behavior that might be seen as undesirable e.g. it could specify
> some extremely high rate of updates. Given that we allow application
> specification to be defined in public documents from a variety of
> sources, I don't see how we could define an enforceable review policy
> for the application specifications. It is at the IANA codepoint
> allocation that we have control - and certainly it seems within the
> purview of an expert to say "I think your specification is flawed and I
> won't approve the allocation of codepoints until the issues of concern
> are addressed".
> 


Yes, both "specification required" and "expert review" involve expert review. 
But they have significant differences in the scope of the review. 
"Specification required" means that the expert should review to make sure the 
specification is clear enough to be implemented in an interoperable fashion. It 
doesn't in any way indicate that the expert thinks the code point is "good", or 
that it conforms to the purpose of the registry. Certainly, the expert could 
offer advise on issues, but the registrant would not be under any obligation to 
follow the advise.

"Expert Review" means that the expert should review a registration to make sure 
that it conforms to the criteria set forth in the document that defined the 
registry. I really think that is what you are looking for, particularly from 
your last sentence above about the expert being able to block allocation of a 
flawed code point.

For example, RFC 3563 calls out "Expert Review", and sets a number of criteria, 
one of which is the assertion that registrations require standards actions, or 
that they require publications from  ISO/IEC JTC1/SC6 that meant the normal 
requirements for an RFC.

In your case, I think you need Expert Review, with criteria along the lines 
that registrants must meet the requirements of "specification required", that 
it must describe its expected rate of updates (and that this not be excessive), 
that it must address any security considerations, etc.

> 
>> I note that while RFC3563, which established the IS-IS TLV Codepoint
>> registry, says "Expert Review", the review criteria is pretty much
>> equivalent to "standards action". I'm guessing the only reason it was
>> not "standards action" was to allow ISO/IEC JTC1/SC6 to submit
>> specifications, which are to be held to the same standard as a
>> standards-track RFC, but do not actually get published as such. So for
>> practical purposes, the proposed policy for GENINFO is significantly
>> weaker than for the parent registry--more so than one might think from
>> just looking at the registry itself.
> 
> I am not clear on why "Expert Review" is seen as a stronger review
> criteria than "Specification Required" - which includes expert review as
> well as a requirement for a public specification.

Actually, "expert rev

Re: US DoD and IPv6

[Phillip Hallam-Baker]

On Tue, Oct 5, 2010 at 8:16 PM, Noel Chiappa wrote:

>> From: RJ Atkinson 
>
>> It seems so incredibly unlikely that end-to-end connectivity (i.e.
>> without NAT, NAPT, or other middleboxes) is going to increase in
> future.
>
> Indeed. It seems that the likelihood of IPv6 being used ubiquitously to
> provide end-end IPv6-IPv6 connectivity, as originally envisioned, is fairly
> small; instead, it seems we are headed for a future of various kinds of
> lash-ups (e.g. the scenario you posited with content providers, or with
> IPv6
> being used between the cable modem and some sort of CGN IPv6/IPv4 NAT, with
> IPv4 on the other pieces of the path, as one large ISP has proposed).
>
> The interesting question, of course, is whether (and if so, when) the IETF
> will deign to notice this reality - or will it continue to prefer to stick
> its collective fingers in its ears and keep going 'neener-neener-neener'.


Application designers who produce designs that rely on IP addresses being
end-to-end are going to find their work fails.

Since the one legacy protocol that has a dependency on IP address constancy
is FTP, it would seem to me to be much easier to upgrade FTP to remove the
dependency than to try to control the network.

Since FTP is layered on Telnet (no really, it is) it would seem that the
more sensible approach would be to standardize the file handling extensions
to SSH and move FTP to historic status.


At the moment we have a situation where everything layers over HTTP or HTTPS
because they provide NAT passthrough.

-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

[Les Ginsberg (ginsberg)]

Ben -

> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Wednesday, October 06, 2010 7:10 AM
> To: Les Ginsberg (ginsberg)
> Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
> Team; The IETF
> Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-
> 03.txt
> 
> Thanks for the quick response. Comments inline:
> 
> On Oct 6, 2010, at 7:55 AM, Les Ginsberg (ginsberg) wrote:
> 
> > Ben -
> >
> > Thanx for the review.
> > Inline.
> >
> >> -Original Message-
> >> From: Ben Campbell [mailto:b...@nostrum.com]
> >> Sent: Tuesday, October 05, 2010 12:06 PM
> >> To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
> > Team
> >> Cc: The IETF
> >> Subject: Gen-ART LC/Telechat Review of
draft-ietf-isis-genapp-03.txt
> >>
> >> I am the assigned Gen-ART reviewer for this draft. For background
on
> >> Gen-ART, please see the FAQ at
> >> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >>
> >> Please wait for direction from your document shepherd
> >> or AD before posting a new version of the draft.
> >>
> >> Document: draft-ietf-isis-genapp-03.txt
> >> Reviewer: Ben Campbell
> >> Review Date: 05 Oct 2010
> >> IESG Telechat date: 07 Oct 2010
> >>
> >> Summary:
> >>
> >> The draft is almost ready for publication as a proposed standard,
> but
> > I
> >> have some concerns that I think should be addressed first.
> >>
> >>
> >> Major issues:
> >>
> >> -- This draft creates an "expansion" code point in an IANA
registry,
> >> where the expansion registration requirements are weaker than those
> of
> >> the parent registry. This always makes me nervous, as it opens the
> >> window for end-runs around the registration requirements of the
> > parent.
> >>
> >> In this particular instance, the parent registry policy is "expert
> >> review" while the proposed expansion registry policy is
> "specification
> >> required". This draft puts normative requirements on the content of
> > the
> >> required specifications, and makes additional non-normative
> statements
> >> about the intended use of the GENINFO code point. This implies to
me
> >> that the review process needs to do more than determine that
> > sufficient
> >> specification exists. Rather, it needs to determine that the
> criteria
> >> in this draft are met by that specification. Therefore, I think
that
> > it
> >> would be appropriate for the GENINFO registry to use the "expert
> >> review" policy.
> >
> > From RFC 5226:
> >
> > "Specification Required - Values and their meanings must be
> >documented in a permanent and readily available public
> >specification, in sufficient detail so that
> interoperability
> >between independent implementations is possible.  When
> used,
> >Specification Required also implies use of a Designated
> >Expert, who will review the public specification..."
> >
> > We deliberately chose "Specification Required" because:
> >
> > a)It requires a public specification
> > b)It allows the public specification to be other than an RFC
> > c)It requires expert review
> 
> Completing the sentence in your quote: "who will review the public
> specification and evaluate whether it is sufficiently clear to allow
> interoperable implementations."
> 
> My understanding of "Specification Required" is that the expert review
> is merely to ensure that the documentation is sufficiently complete
and
> readable to implement in an interoperable way. That review is not
> intended to ensure compliance to other criteria specified in the
draft.
> 
> However, the draft includes some specific criteria for GENINFO
> applications. If you want the reviewer to enforce those criteria, then
> I think you need at least "Expert Review". OTOH, in RFC5226, the
> "expert review" policy has less to say about the required level of
> documentation, so the draft might require some more meat in that area.
> 

This is a bit distressing - because you are suggesting that RFC 5226
doesn't define a category which is appropriate for our usage - which
means we have to try to define a unique policy. I am not quite sure how
to do that with sufficient authority and minimal controversy.

My understanding is that RFC 5226 is specific to IANA considerations -
so we have attempted to define a clear policy as to how the review of
code point assignments is done.

Beyond that, it seems clear that a given Application specification could
specify behavior that might be seen as undesirable e.g. it could specify
some extremely high rate of updates. Given that we allow application
specification to be defined in public documents from a variety of
sources, I don't see how we could define an enforceable review policy
for the application specifications. It is at the IANA codepoint
allocation that we have control - and certainly it seems within the
purview of an expert to say "I think your specification is flawed and I
won't approve the allocation of codepoints 

Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

[Ben Campbell]

Thanks for the quick response. Comments inline:

On Oct 6, 2010, at 7:55 AM, Les Ginsberg (ginsberg) wrote:

> Ben -
> 
> Thanx for the review.
> Inline.
> 
>> -Original Message-
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Tuesday, October 05, 2010 12:06 PM
>> To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
> Team
>> Cc: The IETF
>> Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>> 
>> Document: draft-ietf-isis-genapp-03.txt
>> Reviewer: Ben Campbell
>> Review Date: 05 Oct 2010
>> IESG Telechat date: 07 Oct 2010
>> 
>> Summary:
>> 
>> The draft is almost ready for publication as a proposed standard, but
> I
>> have some concerns that I think should be addressed first.
>> 
>> 
>> Major issues:
>> 
>> -- This draft creates an "expansion" code point in an IANA registry,
>> where the expansion registration requirements are weaker than those of
>> the parent registry. This always makes me nervous, as it opens the
>> window for end-runs around the registration requirements of the
> parent.
>> 
>> In this particular instance, the parent registry policy is "expert
>> review" while the proposed expansion registry policy is "specification
>> required". This draft puts normative requirements on the content of
> the
>> required specifications, and makes additional non-normative statements
>> about the intended use of the GENINFO code point. This implies to me
>> that the review process needs to do more than determine that
> sufficient
>> specification exists. Rather, it needs to determine that the criteria
>> in this draft are met by that specification. Therefore, I think that
> it
>> would be appropriate for the GENINFO registry to use the "expert
>> review" policy.
> 
> From RFC 5226:
> 
> "Specification Required - Values and their meanings must be
>documented in a permanent and readily available public
>specification, in sufficient detail so that interoperability
>between independent implementations is possible.  When used,
>Specification Required also implies use of a Designated
>Expert, who will review the public specification..."
> 
> We deliberately chose "Specification Required" because:
> 
> a)It requires a public specification
> b)It allows the public specification to be other than an RFC
> c)It requires expert review

Completing the sentence in your quote: "who will review the public 
specification and evaluate whether it is sufficiently clear to allow 
interoperable implementations."

My understanding of "Specification Required" is that the expert review is 
merely to ensure that the documentation is sufficiently complete and readable 
to implement in an interoperable way. That review is not intended to ensure 
compliance to other criteria specified in the draft.

However, the draft includes some specific criteria for GENINFO applications. If 
you want the reviewer to enforce those criteria, then I think you need at least 
"Expert Review". OTOH, in RFC5226, the "expert review" policy has less to say 
about the required level of documentation, so the draft might require some more 
meat in that area.

I note that while RFC3563, which established the IS-IS TLV Codepoint registry, 
says "Expert Review", the review criteria is pretty much equivalent to 
"standards action". I'm guessing the only reason it was not "standards action" 
was to allow ISO/IEC JTC1/SC6 to submit specifications, which are to be held to 
the same standard as a standards-track RFC, but do not actually get published 
as such. So for practical purposes, the proposed policy for GENINFO is 
significantly weaker than for the parent registry--more so than one might think 
from just looking at the registry itself.


> 
>> 
>> Minor issues:
>> 
>> -- section 4.2, 2nd paragraph: "Where this is not possible, the two
>> affected LSPs SHOULD be flooded as an atomic action"
>> 
>> Any reason that this is not a MUST, since it seems like the safety-net
>> behavior for when the aforementioned SHOULD is not  possible to
> follow?
>> 
> 
> It is a recommended behavior. If an implementation does not do this it
> does not create an interoperability issue - but it may create
> sub-optimal behavior. 

Okay.

> 
>> -- Section 4.3: "When information in the two GENINFO TLVs conflicts
> i.e
>> there are different settings for a given attribute, the procedure used
>> to choose which copy shall be used is undefined."
>> 
>> Should their be normative requirement not to create this undefined
>> condition in the first place?
> 
> If the revised version of a GENINFO TLV is sent in an LSP with a
> different number from the previous version there can be transient
> window

RE: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

[Les Ginsberg (ginsberg)]

Ben -

Thanx for the review.
Inline.

> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Tuesday, October 05, 2010 12:06 PM
> To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review
Team
> Cc: The IETF
> Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-isis-genapp-03.txt
> Reviewer: Ben Campbell
> Review Date: 05 Oct 2010
> IESG Telechat date: 07 Oct 2010
> 
> Summary:
> 
> The draft is almost ready for publication as a proposed standard, but
I
> have some concerns that I think should be addressed first.
> 
> 
> Major issues:
> 
> -- This draft creates an "expansion" code point in an IANA registry,
> where the expansion registration requirements are weaker than those of
> the parent registry. This always makes me nervous, as it opens the
> window for end-runs around the registration requirements of the
parent.
> 
> In this particular instance, the parent registry policy is "expert
> review" while the proposed expansion registry policy is "specification
> required". This draft puts normative requirements on the content of
the
> required specifications, and makes additional non-normative statements
> about the intended use of the GENINFO code point. This implies to me
> that the review process needs to do more than determine that
sufficient
> specification exists. Rather, it needs to determine that the criteria
> in this draft are met by that specification. Therefore, I think that
it
> would be appropriate for the GENINFO registry to use the "expert
> review" policy.

>From RFC 5226:

"Specification Required - Values and their meanings must be
documented in a permanent and readily available public
specification, in sufficient detail so that interoperability
between independent implementations is possible.  When used,
Specification Required also implies use of a Designated
Expert, who will review the public specification..."

We deliberately chose "Specification Required" because:

a)It requires a public specification
b)It allows the public specification to be other than an RFC
c)It requires expert review

> 
> Minor issues:
> 
> -- section 4.2, 2nd paragraph: "Where this is not possible, the two
> affected LSPs SHOULD be flooded as an atomic action"
> 
> Any reason that this is not a MUST, since it seems like the safety-net
> behavior for when the aforementioned SHOULD is not  possible to
follow?
> 

It is a recommended behavior. If an implementation does not do this it
does not create an interoperability issue - but it may create
sub-optimal behavior. 

> -- Section 4.3: "When information in the two GENINFO TLVs conflicts
i.e
> there are different settings for a given attribute, the procedure used
> to choose which copy shall be used is undefined."
> 
> Should their be normative requirement not to create this undefined
> condition in the first place?

If the revised version of a GENINFO TLV is sent in an LSP with a
different number from the previous version there can be transient
windows where other systems have two copies of information regarding the
same application. This may be unavoidable. For completeness we specify
that the choice of what to do in such transient situations is
implementation specific (undefined). This section does specify ways to
minimize the occurrence/duration of such transient periods.

> 
> 
> 
> -- Security Considerations:
> 
> This seems too lightweight. Is it impossible for GENINFO applications
> to include sensitive information? Are there no security guidelines
that
> should apply to GENINFO application specifications?

We have no way of knowing what type of information might be advertised
by a given application - and we are not limiting what may be advertised.
Clearly the public document which specifies the application would need
to address the security issues it introduces. We cannot do that here.

> 
> Even if the answer is that the underlying IS-IS protocol provides
> sufficient security for any reasonable use of the GENINFO code point,
> it would be worth saying that explicitly.
> 
> Nits/editorial comments:
> 
> -- section 2
> 
> Please expand IS-IS and PDU on first mention.

OK

> 
> -- section 6, last paragraph:
> 
> Expected/desired by whom?

Well, at least by the authors. :-)

> 
> -- Outdated reference for draft-ietf-isis-mi

It was current at the time the draft was written.


   Les

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-isis-genapp-03.txt
Reviewer: Ben Campbell
Review Date: 05 Oct 2010
IESG Telechat date: 07 Oct 2010

Summary:

The draft is almost ready for publication as a proposed standard, but I have 
some concerns that I think should be addressed first.


Major issues:

-- This draft creates an "expansion" code point in an IANA registry, where the 
expansion registration requirements are weaker than those of the parent 
registry. This always makes me nervous, as it opens the window for end-runs 
around the registration requirements of the parent. 

In this particular instance, the parent registry policy is "expert review" 
while the proposed expansion registry policy is "specification required". This 
draft puts normative requirements on the content of the required 
specifications, and makes additional non-normative statements about the 
intended use of the GENINFO code point. This implies to me that the review 
process needs to do more than determine that sufficient specification exists. 
Rather, it needs to determine that the criteria in this draft are met by that 
specification. Therefore, I think that it would be appropriate for the GENINFO 
registry to use the "expert review" policy. 

Minor issues:

-- section 4.2, 2nd paragraph: "Where this is not possible, the two affected 
LSPs SHOULD be flooded as an atomic action"

Any reason that this is not a MUST, since it seems like the safety-net behavior 
for when the aforementioned SHOULD is not  possible to follow?

-- Section 4.3: "When information in the two GENINFO TLVs conflicts i.e there 
are different settings for a given attribute, the procedure used to choose 
which copy shall be used is undefined."

Should their be normative requirement not to create this undefined condition in 
the first place?



-- Security Considerations:

This seems too lightweight. Is it impossible for GENINFO applications to 
include sensitive information? Are there no security guidelines that should 
apply to GENINFO application specifications?

Even if the answer is that the underlying IS-IS protocol provides sufficient 
security for any reasonable use of the GENINFO code point, it would be worth 
saying that explicitly.

Nits/editorial comments:

-- section 2

Please expand IS-IS and PDU on first mention.

-- section 6, last paragraph:

Expected/desired by whom?

-- Outdated reference for draft-ietf-isis-mi

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Fernando Gont]

On Wed, Oct 6, 2010 at 2:43 PM, Keith Moore  wrote:

>> When applications that e.g. include point of attachment addresses in the
>> app protocol break in the presence of NATs, one should probably ask
>> whether the NAT is breaking the app, or whether the NAT is making it
>> clear that the app was actually already broken.
>
> It's perfectly reasonable for applications to include IP addresses and port 
> numbers in their payloads,
> as this is the only way that the Internet Architecture defines to allow 
> applications to make contact
> with particular processes at particular hosts.  Some might see this as a 
> deficiency in the Internet
> Architecture, but that's the best that we have to work with for now.

If anything, the fact that "this is is the only way that the Internet
Architecture defines..." doesn't make it reasonable.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 1:45 PM, Phillip Hallam-Baker wrote:

> On Wed, Oct 6, 2010 at 12:43 PM, Keith Moore  
> wrote:
> The central problem with the Internet seems to be that nearly everybody who 
> routes traffic thinks it's okay to violate the architecture and alter the 
> traffic to optimize for his/her specific circumstances - and the end users 
> and their wide variety of applications just have to cope with the resulting 
> brain damage.  
>  
> Objective observation suggests that the Internet architecture *is* that 
> anyone who wants to can molest traffic in any way they feel fit. 

If a bomb hits a famous building, we don't generally call the resulting rubble 
part of the building's architecture.  

(unless, maybe, it's the Hiroshima Peace Dome, which was repurposed to 
commemorate perhaps the worst man-made disaster in history.)

> But really, I do not understand why people have to fetishize the constancy of 
> IP addresses end to end. IP addresses are not particularly interesting to 
> look at. 

It's one of the two fundamental principles on which the Internet is based.  
Universal packet format, universal address space.  That's IP in a nutshell.  

Keith



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[David Conrad]

On Oct 6, 2010, at 7:43 AM, Keith Moore wrote:
> DNS has never been, and never will be, suitable as a general endpoint naming 
> mechanism.  

What do you mean by "a general endpoint naming mechanism"?

Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 1:22 PM, Fernando Gont wrote:

> On 06/10/2010 01:43 p.m., Keith Moore wrote:
> 
>> Honestly, I don't think we can tell.  In the short term, it certainly
>> doesn't look good for end-to-end transparency.But unlike 10 years
>> ago, today there's a widespread understanding of the problems caused
>> by lack of transparency, and much less denial about it.
> 
> It's not clear to me what you mean by "end to end transparency". If you
> mean "end to end connectivity", then I'd say that quite a few people are
> actually *concerned* about going back to end-to-end connectivity.

I mean having the sender's packets delivered to the receiver, completely intact 
except for ordinary TTL and IP option processing, with "best effort" or better 
reliability, delay, and jitter, except when prohibited by explicit 
end-user-specified policy.

>> The central problem with the Internet seems to be that nearly
>> everybody who routes traffic thinks it's okay to violate the
>> architecture and alter the traffic to optimize for his/her specific
>> circumstances - and the end users and their wide variety of
>> applications just have to cope with the resulting brain damage.
> 
> When applications that e.g. include point of attachment addresses in the
> app protocol break in the presence of NATs, one should probably ask
> whether the NAT is breaking the app, or whether the NAT is making it
> clear that the app was actually already broken.

It's perfectly reasonable for applications to include IP addresses and port 
numbers in their payloads, as this is the only way that the Internet 
Architecture defines to allow applications to make contact with particular 
processes at particular hosts.  Some might see this as a deficiency in the 
Internet Architecture, but that's the best that we have to work with for now.

DNS has never been, and never will be, suitable as a general endpoint naming 
mechanism.   And so far nobody has managed to implement and deploy a better 
system for endpoint naming.  If and when someone manages to do this, there will 
still be a need for old applications to use IP addresses.

Meanwhile, those who insist on corrupting other parties' traffic and harming 
their applications are very good examples of the kind of short-term, 
self-serving harm to which I was referring.  

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Fernando Gont]

On 06/10/2010 01:43 p.m., Keith Moore wrote:

> Honestly, I don't think we can tell.  In the short term, it certainly
> doesn't look good for end-to-end transparency.But unlike 10 years
> ago, today there's a widespread understanding of the problems caused
> by lack of transparency, and much less denial about it.

It's not clear to me what you mean by "end to end transparency". If you
mean "end to end connectivity", then I'd say that quite a few people are
actually *concerned* about going back to end-to-end connectivity.

I think that even without NATs (which is *not* going to be the case, as
it has already been pointed out), we can expect that at the edge,
firewalls that "only allow return traffic" will be the common case, even
for v6.



> The central problem with the Internet seems to be that nearly
> everybody who routes traffic thinks it's okay to violate the
> architecture and alter the traffic to optimize for his/her specific
> circumstances - and the end users and their wide variety of
> applications just have to cope with the resulting brain damage.

When applications that e.g. include point of attachment addresses in the
app protocol break in the presence of NATs, one should probably ask
whether the NAT is breaking the app, or whether the NAT is making it
clear that the app was actually already broken.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 11:00 AM, Noel Chiappa wrote:

>> From: Keith Moore 
> 
>> Do you actually have a point to make
> 
> That depends. Are you still of the opinion that IPv6 will, in our lifetimes,
> become ubiquitously deployed, thereby restoring us to a world of transparent
> end-end, or do you think we should acknowledge that that's not going to
> happen, and start to think about how to design for a permanently mixed
> Internet - and actually have that model in mind when doing protocol work?

Honestly, I don't think we can tell.  In the short term, it certainly doesn't 
look good for end-to-end transparency.But unlike 10 years ago, today 
there's a widespread understanding of the problems caused by lack of 
transparency, and much less denial about it.

The central problem with the Internet seems to be that nearly everybody who 
routes traffic thinks it's okay to violate the architecture and alter the 
traffic to optimize for his/her specific circumstances - and the end users and 
their wide variety of applications just have to cope with the resulting brain 
damage.   (Admittedly there's a wide variation in _how much_ these people think 
it's okay to mess with transparency.)  

But I am not sure that that's the fault of the current Internet architecture, 
or that a different architecture would fare better.  I think it's fairly 
inherent in that people can always understand their specific circumstances 
better than they can see the big picture, and that most of the world's 
economies are biased toward short-term thinking (and thus, hill climbing / dead 
ends).

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Noel Chiappa]

> From: Keith Moore 

> Do you actually have a point to make

That depends. Are you still of the opinion that IPv6 will, in our lifetimes,
become ubiquitously deployed, thereby restoring us to a world of transparent
end-end, or do you think we should acknowledge that that's not going to
happen, and start to think about how to design for a permanently mixed
Internet - and actually have that model in mind when doing protocol work?

Because there are clearly a lot of people who don't buy into that (viz. this
recent comment "Now is not the point to invest time fixing the ipv4
internet.").

>> Look what you have done: not only we have more NATv4 than ever, but
>> now we also have NAT46, NAT64, NAT464

> I think you give me far more "credit" than I'm due.

I have to agree. In some sense, NAT became inevitable way back in 1976 (or
so, don't recall the exact date of this), when variable length addresses were
removed from IPv3 (I think it was) in favour of the 32-bit fixed-length
addresses. (The failue to differentiate between interface names and endpoint
names also was a factor, but somewhat tangential.)

The reason is simple: i) 32 bits would eventually be too few for naming
endpoints, and ii) when that happened, since no evolutionary path to a larger
namespace had been defined, naming domains separated by translators were
driven by economics as the cheapest way forward.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: US DoD and IPv6

[Noel Chiappa]

> From: "Michel Py" 

> you are one of the main persons behind the failure of IPv6. 

I think that's unfair. To my mind (when I sat and did a long post-mortem
after the IETF adopted IPv6 almost two decades ago, trying to understand why
I hadn't been able to convince people to do something different), in some
sense the real guilty party in the IPv6 choice is the IETF at large, the
ordinary members - for accepting what was basically 'IPv4 with a few more
bits', instead of a fundamentally revised architecture that would provided
real benefits in the form of major new capabilities (e.g. separation of
location and identity), thereby giving actual operational incentives to drive
migration.

"We have met the enemy, and he is us."

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pigeon flies past broadband in data speed race

[Richard Bennett]

 Actually nobody's shooting Google's fiber, the NANOG story was 
"clarified" by Google HQ: http://bit.ly/ds512g


RB

On 9/23/2010 12:49 PM, Jorge Amodio wrote:

Reminds me of an implementation report of RFC1149 Firewalling way back at IETF 
55 (see http://bert.secret-wg.org/Trips/IETF55/ middle of the page)

Ha !! Now we know who is shooting Google's fiber (reported via NANOG&
http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx)

BTW, I really like Bert's reports and pics at
http://bert.secret-wg.org/, you should ask him to post some new ones
:-)

Cheers
Jorge
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


--
Richard Bennett

<>___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Keith Moore]

On Oct 6, 2010, at 1:10 AM, Michel Py wrote:

>>> Noel Chiappa wrote:
>>> The interesting question, of course, is whether (and if so, when) the
> IETF
>>> will deign to notice this reality - or will it continue to prefer to
> stick
>>> its collective fingers in its ears and keep going
> 'neener-neener-neener'.
> 
>> Keith Moore wrote:
>> Do you actually have a point to make, Noel, or are you just
>> taking pot shots at IETF again?
> 
> Look who's talking. Despite a brilliant mind and sometimes significant
> contributions, you are one of the main persons behind the failure of
> IPv6. The living example of the IETF ivory tower.
> 
> Has it occurred to you that, if it was not for your blind opposition to
> NAT, we could be living in a world of 6to4 implemented in the ubiquitous
> NAT box?

Why do you think I proposed 6to4 in the first place?   There was no vendor 
interest in putting 6to4 in NAT boxes.

For that matter, I also proposed a mechanism to allow applications to better 
cope with NAT between v4 and v6  (and by extension between v4 and v4) by making 
the NATs explicitly controlled by the endpoints.  There was no interest in that 
either.

> Look what you have done: not only we have more NATv4 than ever, but now
> we also have NAT46, NAT64, NAT464...whatever and all of these with heavy
> ALG layers to make it more palatable.

I think you give me far more "credit" than I'm due.  

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf