Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'

[Roger Jørgensen]

not replying specific to this mail but to the tons that have arrived
lately, are there some confusion out there that it is the amount of
"votes" on ietf@ that make a do/do not on a draft? ... or just me
missunderstanding this?


anyway, great to see people participate :-)

--- Roger J ---

On Tue, Feb 14, 2012 at 6:19 PM, Erichsen, Kirk
 wrote:
> I fully support this draft and would like to see it progress to conclusion 
> without further delay.
>
> With warm regard,
>
> Kirk Erichsen
> Principle Technology Engineer
> Time Warner Cable
> ATG West
>
>
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject to 
> copyright belonging to Time Warner Cable. This E-mail is intended solely for 
> the use of the individual or entity to which it is addressed. If you are not 
> the intended recipient of this E-mail, you are hereby notified that any 
> dissemination, distribution, copying, or action taken in relation to the 
> contents of and attachments to this E-mail is strictly prohibited and may be 
> unlawful. If you have received this E-mail in error, please notify the sender 
> immediately and permanently delete the original and any copy of this E-mail 
> and any printout.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



-- 

Roger Jorgensen           |
rog...@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Auth48 comments on draft-ietf-pwe3-static-pw-status-10

[Bocci, Matthew (Matthew)]

Greg,

That is fine with me.

Best regards

Matthew

On 15/02/2012 22:14, "Gregory Mirsky" 
mailto:gregory.mir...@ericsson.com>> wrote:

Dear Matthew, Authors, et al.,
I think that new text of fourth para in Section 5.3 adds some confusion. If 
intension is to stop sending 'all clear' after three one-second intervals went 
unacknowledged but before refresh timer expires then perhpas new text can be 
more explicit:
NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent at one second 
intervals and before refresh timer expires. A PW
status message of zero MAY be acknowledged as per the procedures described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the PW status
notification message with a PW status code equal to zero to stop sending
 and to continue normal operation.

Regards,
Greg


From: pwe3-boun...@ietf.org 
[mailto:pwe3-boun...@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, February 15, 2012 7:10 AM
To: p...@ietf.org; ietf@ietf.org
Cc: pwe3-cha...@tools.ietf.org; Stewart 
Bryant
Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10

During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some 
issues with the acknowledgement procedures in Section 5.3 of the draft that we 
feel should be addressed before publication. Since the draft has already been 
through WG and IETF last call, we would like to highlight the proposed changes 
to the working group and solicit feedback.

Best regards,

Matthew

Section 5.3, 3rd paragraph:
Reason for change:
The current suggested default refresh timer value is too short to allow scaling
to very large numbers of PWs while minimising the overhead. It is also 
inconsistent
with the suggested default requested in an ACK packet. Therefore we suggest 
increasing
the default to 600secs.

OLD: The suggested default value for the refresh timer is 30 seconds.

NEW: The suggested default value for the refresh timer is 600 seconds.



Section 5.3, 4th paragraph:
Reason for change:
The current text requires that a receiving PE must acknowledge a PW status 
message
of 'clear all faults' in order to force a transmitter to stop sending PW status
messages at 1 second intervals.  We are concerned that a mandatory 
acknowledgement
adds an unnecessary complexity to the protocol which is inconsistent with
the use of the acknowledgement as per the following section (5.3.1). 
Additionally,
we are also concerned that this may cause problems if a transmitter
is flapping between 'clear all faults' and a non-zero value, and if the
acknowledgement is lost. We therefore suggest that the acknowledgement to
'clear all faults' be made optional, and that  the transmitter behavior be 
changed so
that it sends up to 3 status messages of zero in a row, and then goes silent.

OLD:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however, it MUST be
acknowledged with a packet with a timer value of zero.  This will cause
the PE sending the PW status notification message with a PW status code
equal to zero to stop sending and to continue normal operation.


NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent. A PW
status message of zero MAY be acknowledged as per the procedures described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the PW status
notification message with a PW status code equal to zero to stop sending
 and to continue normal operation.


Section 5.3.1, 1st paragraph:
Reason for change:
The procedures currently defined in this paragraph can lead to a receiver
of the static status message timing out if it requests, throught the use of the
ACK mechanism, a longer refresh timer from the transmitter. This is because the
current text implies that the transmitter change its referesh timer immediately
on receipt of the ack packet from the receiver. The new text clarifies that
the refresh timer be updated at the end of the current refresh interval, as
well as making some other editorial clarifications.

OLD:
The PE re

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Martin Millnert]

On Tue, 2012-02-14 at 19:26 -0600, Pete Resnick wrote:
> On 2/14/12 2:35 PM, Randy Bush wrote:
> 
> > what silliness.  it will be used as rfc 1918 space no matter what the 
> > document
> > says.
> > [...]
> > any thought that this is not just adding to rfc 1918 is pure bs.
> >
> 
> Of course it will be used as 1918 space. That's not the point of the text.

No support.

For the various reasons people have put forth, and my own below, this
draft should not be put through.

> The text is saying, "You could read 1918 to say that we somehow promised 
> that you would never be connected to a network run by someone other than 
> yourself and see 1918 addresses on it. That's not an entirely 
> intelligent reading, but we see how you can read it that way. So, if you 
> built yourself a device where it isn't able to deal with 1918 addresses 
> on its 'outside' interface that you were using on the 'inside' 
> interfaces, we could see how that might happen. It was not at all smart 
> of you to build your device that way, but you probably were technically 
> within spec. Now we're adding some address space to the pool. It's not 
> global and it's not routable, just the same as 1918 space. But we're 
> letting you know right now: You *will* see these addresses on networks 
> that you don't run. If you want to use this space the way that you used 
> 1918 space, peachy, but understand that if you're unable to deal with 
> these addresses duplicating ones you're using, your device is toast. 
> Deal with it."

This is 100% matched by an allocation of globally unique space from a
RIR, shared by whoever the interested parties are. 
  The IETF *need not* specify any BCP on how to improve NAT444
"CGN"-scale alone, because such action is attached with high risk of
leading to a local maximum in a plot of the state of the Internet,
rather than towards a global maximum.

Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
Transition" warns:
   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
   Scale NAT, compounds IPv4 operational problems when used alone but
   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
   NAT444 CGN allows ISPs to delay the transition and therefore causes
   double transition costs (once to add CGN and again to support IPv6).

The draft as written, makes no effort to require the RFC6264 or
equivalent approaches to a IPv6 transition, to the CGN deployments it
specifies v4 address space for. All carrot, no stick.
  I believe the state of the Internet would be much more reliably
improved by the RIRs each having (for the purpose of being able to serve
their own users) one /10 special allocation for this purpose, which they
can assign to multiple users upon demonstrating, under contract, they
are transitioning to IPv6 according to 6264, or equivalent.

As written there is no effort to mitigate the risk mentioned in the
quote above, and I can't support a draft that will hurt the Internet and
neither should you.

Best,
Martin


signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Auth48 comments on draft-ietf-pwe3-static-pw-status-10

[Stewart Bryant]

Having spoken to a number of the authors at length
I think  the text changes that Matthew has proposed
are correct (with Greg's change) and thank the authors
for picking this up.

I propose to let this sit until a week tomorrow (23/Feb)
and provided that there are no technical issues with the
proposed changes I will ask the RFC Editor to make
the changes and to publish the RFC.

- Stewart


On 16/02/2012 10:02, Bocci, Matthew (Matthew) wrote:

Greg,

That is fine with me.

Best regards

Matthew

On 15/02/2012 22:14, "Gregory Mirsky" > wrote:


Dear Matthew, Authors, et al.,
I think that new text of fourth para in Section 5.3 adds some
confusion. If intension is to stop sending 'all clear' after three
one-second intervals went unacknowledged but before refresh timer
expires then perhpas new text can be more explicit:
NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been
sent/_at one second intervals and before refresh timer expires_/. A PW
status message of zero MAY be acknowledged as per the procedures
described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the
PW status
notification message with a PW status code equal to zero to stop
sending
 and to continue normal operation.
Regards,
Greg


*From:* pwe3-boun...@ietf.org 
[mailto:pwe3-boun...@ietf.org] *On Behalf Of *Bocci, Matthew (Matthew)
*Sent:* Wednesday, February 15, 2012 7:10 AM
*To:* p...@ietf.org ; ietf@ietf.org

*Cc:* pwe3-cha...@tools.ietf.org
; Stewart Bryant
*Subject:* [PWE3] Auth48 comments on
draft-ietf-pwe3-static-pw-status-10

During Auth 48, the authors of draft-ietf-pwe3-static-pw-status
found some issues with the acknowledgement procedures in Section
5.3 of the draft that we feel should be addressed before
publication. Since the draft has already been through WG and IETF
last call, we would like to highlight the proposed changes to the
working group and solicit feedback.

Best regards,

Matthew

Section 5.3, 3rd paragraph:
Reason for change:
The current suggested default refresh timer value is too short to
allow scaling
to very large numbers of PWs while minimising the overhead. It is
also inconsistent
with the suggested default requested in an ACK packet. Therefore
we suggest increasing
the default to 600secs.

OLD: The suggested default value for the refresh timer is 30 seconds.

NEW: The suggested default value for the refresh timer is 600 seconds.



Section 5.3, 4th paragraph:
Reason for change:
The current text requires that a receiving PE must acknowledge a
PW status message
of 'clear all faults' in order to force a transmitter to stop
sending PW status
messages at 1 second intervals.  We are concerned that a mandatory
acknowledgement
adds an unnecessary complexity to the protocol which is
inconsistent with
the use of the acknowledgement as per the following section
(5.3.1). Additionally,
we are also concerned that this may cause problems if a transmitter
is flapping between 'clear all faults' and a non-zero value, and
if the
acknowledgement is lost. We therefore suggest that the
acknowledgement to
'clear all faults' be made optional, and that  the transmitter
behavior be changed so
that it sends up to 3 status messages of zero in a row, and then
goes silent.

OLD:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however, it
MUST be
acknowledged with a packet with a timer value of zero.  This will
cause
the PE sending the PW status notification message with a PW status
code
equal to zero to stop sending and to continue normal operation.


NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent.
A PW
status message of zero MAY be acknowledged as per the

IETF Last Calls and Godwin-like rules

[John C Klensin]

A current Last Call has apparently brought on another of the
"please tell all your friends to send in supportive notes, even
if they don't say much of anything substantive" campaigns that
we see from time to time.  When those notes come from people who
do not routinely participate on IETF lists, they provide very
little real information unless we have suddenly taken up voting
or otherwise counting notes.  Whatever we might otherwise think
of company positions, a note that said "I work for  and we
need this and intend to implement and deploy it" would be real
information that the community could consider where "I am an
individual and +1" does not.   Sadly, such endorsements,
especially from people who are not active IETF participants, add
to the noise and might prevent someone who was still genuinely
trying to understand the pros and cons (presumably including all
of the IESG) from seeing a new and substantive argument, no
matter how well-grounded.

I note that there are some folks in the community who seem to
favor these campaigns when they like the cause and not if they
do not.

But I wonder whether, in the interest of noise reduction and/or
support of our "no voting, even by active participants"
position, there be any sympathy for a Godwin-like rule that the
first appearance of many no-information "I support this"
endorsements from people and constituencies who are not regular
participants on the IETF list should immediately trigger a state
in which all further statements from that "side" would be
ignored or would end the discussion entirely?

Yes, I see the difficulties in figuring out the details of such
a rule and implementing it and am mostly joking.   Mostly.

 john


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

Re: IETF Last Calls and Godwin-like rules

[Måns Nilsson]

Subject: IETF Last Calls and Godwin-like rules Date: Thu, Feb 16, 2012 at 
09:04:03AM -0500 Quoting John C Klensin (john-i...@jck.com):

...

> first appearance of many no-information "I support this"
> endorsements from people and constituencies who are not regular
> participants on the IETF list should immediately trigger a state
> in which all further statements from that "side" would be
> ignored or would end the discussion entirely?
> 
> Yes, I see the difficulties in figuring out the details of such
> a rule and implementing it and am mostly joking.   Mostly.

I support this. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
YOW!!  Everybody out of the GENETIC POOL!


signature.asc
Description: Digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Calls and Godwin-like rules

[Yoav Nir]

On Feb 16, 2012, at 4:09 PM, Måns Nilsson wrote:

> Subject: IETF Last Calls and Godwin-like rules Date: Thu, Feb 16, 2012 at 
> 09:04:03AM -0500 Quoting John C Klensin (john-i...@jck.com):
> 
> ...
> 
>> first appearance of many no-information "I support this"
>> endorsements from people and constituencies who are not regular
>> participants on the IETF list should immediately trigger a state
>> in which all further statements from that "side" would be
>> ignored or would end the discussion entirely?
>> 
>> Yes, I see the difficulties in figuring out the details of such
>> a rule and implementing it and am mostly joking.   Mostly.
> 
> I support this. 

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

Re: IETF Last Calls and Godwin-like rules

[Dave CROCKER]

On 2/16/2012 6:09 AM, Måns Nilsson wrote:

Yes, I see the difficulties in figuring out the details of such
a rule and implementing it and am mostly joking.   Mostly.


I support this.



You support the joking?

Or is it that you support vague rules that are unenforceable and will generate 
more heat than light?


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Calls and Godwin-like rules

[Yoav Nir]

On Feb 16, 2012, at 4:04 PM, John C Klensin wrote:

> A current Last Call has apparently brought on another of the
> "please tell all your friends to send in supportive notes, even
> if they don't say much of anything substantive" campaigns that
> we see from time to time.  When those notes come from people who
> do not routinely participate on IETF lists, they provide very
> little real information unless we have suddenly taken up voting
> or otherwise counting notes.  Whatever we might otherwise think
> of company positions, a note that said "I work for  and we
> need this and intend to implement and deploy it" would be real
> information that the community could consider where "I am an
> individual and +1" does not.   Sadly, such endorsements,
> especially from people who are not active IETF participants, add
> to the noise and might prevent someone who was still genuinely
> trying to understand the pros and cons (presumably including all
> of the IESG) from seeing a new and substantive argument, no
> matter how well-grounded.
> 
> I note that there are some folks in the community who seem to
> favor these campaigns when they like the cause and not if they
> do not.
> 
> But I wonder whether, in the interest of noise reduction and/or
> support of our "no voting, even by active participants"
> position, there be any sympathy for a Godwin-like rule that the
> first appearance of many no-information "I support this"
> endorsements from people and constituencies who are not regular
> participants on the IETF list should immediately trigger a state
> in which all further statements from that "side" would be
> ignored or would end the discussion entirely?
> 
> Yes, I see the difficulties in figuring out the details of such
> a rule and implementing it and am mostly joking.   Mostly.

Because we don't vote, the show of support with all the +1s really doesn't 
amount to much. I don't think even promises to implement carry much weight at 
last call. By the time some proposal has gone to last call, especially IETF 
last call, the issue of whether this will be useful to someone should have 
already been settled.

I think that an endorsement like "I work for Cisco and we intend to implement 
this in every one of our products" is useful. But it's not nearly as useful as 
"this is a terrible idea, and doing this will prevent IPv6 from ever gaining 
traction". The objections raised in last call are really the point, not the 
endorsements.

Yoav


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

Re: IETF Last Calls and Godwin-like rules

[Roger Jørgensen]

On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir  wrote:

> I think that an endorsement like "I work for Cisco and we intend to implement 
> this in every one of our products" is useful. But it's not nearly as useful 
> as "this is a terrible idea, and doing this will prevent IPv6 from ever 
> gaining traction". The objections raised in last call are really the point, 
> not the endorsements.


Think I've read somewhere that the ground of good engineering (the E
in IETF) are being able to argue against your own idea, search and
look for flaws in it, and all in the name of testing it to see how it
can be made even better, is it good enough? Or simple to consider the
bigger picture, can my idea hurt the rest no matter how good it is?
There are great and very good ideas out there that isolated are
fantastic, but considered in just a bit bigger picture are horrible,
they've ruin everything around them.

So, when lots of people are all for something without mention or
willing to discusse the bad sides... that's scary as I see it.



-- 

Roger Jorgensen           |
rog...@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Calls and Godwin-like rules

[Yoav Nir]

On Feb 16, 2012, at 4:48 PM, Roger Jørgensen wrote:

> On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir  wrote:
> 
>> I think that an endorsement like "I work for Cisco and we intend to 
>> implement this in every one of our products" is useful. But it's not nearly 
>> as useful as "this is a terrible idea, and doing this will prevent IPv6 from 
>> ever gaining traction". The objections raised in last call are really the 
>> point, not the endorsements.
> 
> 
> Think I've read somewhere that the ground of good engineering (the E
> in IETF) are being able to argue against your own idea, search and
> look for flaws in it, and all in the name of testing it to see how it
> can be made even better, is it good enough? Or simple to consider the
> bigger picture, can my idea hurt the rest no matter how good it is?
> There are great and very good ideas out there that isolated are
> fantastic, but considered in just a bit bigger picture are horrible,
> they've ruin everything around them.

I agree. IPv4 forever using CGNs may work for a lot of people and a lot of 
uses. If people remain double- or triple-natted it won't matter a bit to the 
big web sites. 

It's far more important to hear what is not going to work with this solution.

It's great if you can find such deficiencies in your own ideas, but we still 
need design reviews, code reviews, QA departments and IETF last calls so that 
others can get at your idea.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Calls and Godwin-like rules

[Noel Chiappa]

> From: John C Klensin 

> When those notes come from people who do not routinely participate on
> IETF lists

Well, that's the $64 million question, right? I mean, I don't personally
subscribe to every IETF-related list, so I have no idea if the people who are
posting are active in some subset of the IETF, just not (previously) this
list. And does someone have to have spoken up on a list, to have just as much
right to an opinion as a frequent poster? Some people are just naturally quiet.

I'd say that if anyone has been subscribed to any IETF list _prior_ to the
call to 'join in', their opinion ought to have just as much weight as those
of us who have historically been more wordy on the main list.

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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Chris Grundemann]

On Thu, Feb 16, 2012 at 03:43, Martin Millnert  wrote:

> This is 100% matched by an allocation of globally unique space from a
> RIR, shared by whoever the interested parties are.
>  The IETF *need not* specify any BCP on how to improve NAT444
> "CGN"-scale alone, because such action is attached with high risk of
> leading to a local maximum in a plot of the state of the Internet,
> rather than towards a global maximum.
>
> Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
> Transition" warns:
>   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
>   Scale NAT, compounds IPv4 operational problems when used alone but
>   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
>   NAT444 CGN allows ISPs to delay the transition and therefore causes
>   double transition costs (once to add CGN and again to support IPv6).
>
> The draft as written, makes no effort to require the RFC6264 or
> equivalent approaches to a IPv6 transition, to the CGN deployments it
> specifies v4 address space for. All carrot, no stick.
>  I believe the state of the Internet would be much more reliably
> improved by the RIRs each having (for the purpose of being able to serve
> their own users) one /10 special allocation for this purpose, which they
> can assign to multiple users upon demonstrating, under contract, they
> are transitioning to IPv6 according to 6264, or equivalent.
>
> As written there is no effort to mitigate the risk mentioned in the
> quote above, and I can't support a draft that will hurt the Internet and
> neither should you.

Apologies for my bluntness, but this argument is a complete
misinterpretation of the facts on the ground. This draft is not about
encouraging nor facilitating CGN deployments. Allocating a /10 for
inside CGN addressing use _will not_ make anyone deploy CGN who would
not have otherwise done so. Not allocating a /10 for inside CGN
addressing use _will not_ stop anyone from deploying CGN who would
have otherwise done so. In fact, neither you nor I nor the IETF can
stop operators who must deploy CGN for business continuity from doing
so. What we can do, is ensure that when those folks who must deploy
CGN do so, that they break the Internet as little as possible. And
_that_ is what this I-D seeks to accomplish. And that is why I support
it, and why you should too.

Cheers,
~Chris


> Best,
> Martin
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'

[Chris Grundemann]

On Thu, Feb 16, 2012 at 02:34, Roger Jørgensen  wrote:
> not replying specific to this mail but to the tons that have arrived
> lately, are there some confusion out there that it is the amount of
> "votes" on ietf@ that make a do/do not on a draft? ... or just me
> missunderstanding this?

It is my understanding that the IETF operates in an open, bottom-up,
consensus-based manor and thus that all voices, taken in context, are
important in all decisions made.

> anyway, great to see people participate :-)

It is indeed.
~Chris


> --- Roger J ---
>
> Roger Jorgensen           |
> rog...@gmail.com          | - IPv6 is The Key!
> http://www.jorgensen.no   | ro...@jorgensen.no
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



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

Re: IETF Last Calls and Godwin-like rules

[Alia Atlas]

For what it is worth, those who I've seen commenting in the +1 fashion
recently are primarily people I've known to be active in the IETF for
years - including some WG chairs.

I don't think this is an effort to round up external voters - but
rather encouragement to others inside IETF to publicly speak up.

Alia

who usually doesn't post much on the general IETF list either

On Thu, Feb 16, 2012 at 10:33 AM, Noel Chiappa  wrote:
>    > From: John C Klensin 
>
>    > When those notes come from people who do not routinely participate on
>    > IETF lists
>
> Well, that's the $64 million question, right? I mean, I don't personally
> subscribe to every IETF-related list, so I have no idea if the people who are
> posting are active in some subset of the IETF, just not (previously) this
> list. And does someone have to have spoken up on a list, to have just as much
> right to an opinion as a frequent poster? Some people are just naturally 
> quiet.
>
> I'd say that if anyone has been subscribed to any IETF list _prior_ to the
> call to 'join in', their opinion ought to have just as much weight as those
> of us who have historically been more wordy on the main list.
>
>        Noel
> ___
> 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 Last Calls and Godwin-like rules

[SM]

Hi John,
At 06:04 16-02-2012, John C Klensin wrote:

A current Last Call has apparently brought on another of the
"please tell all your friends to send in supportive notes, even
if they don't say much of anything substantive" campaigns that
we see from time to time.  When those notes come from people who
do not routinely participate on IETF lists, they provide very
little real information unless we have suddenly taken up voting


Letter-writing campaigns occur every now and then.  As there isn't 
any vote count, the effort can end up in a diluted form.



individual and +1" does not.   Sadly, such endorsements,
especially from people who are not active IETF participants, add
to the noise and might prevent someone who was still genuinely
trying to understand the pros and cons (presumably including all
of the IESG) from seeing a new and substantive argument, no
matter how well-grounded.


Last year, someone discussed about how a "+1" could be read and some 
people were offended.   Maybe authors should be given the choice to 
have their proposal evaluated by counting the votes or to have the 
evaluation which is based on substantive comments.  Nobody would be 
offended then.


Regards,
-sm 


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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Martin Millnert]

Dear Chris,

On Thu, 2012-02-16 at 08:43 -0700, Chris Grundemann wrote:
> On Thu, Feb 16, 2012 at 03:43, Martin Millnert  wrote:
> 
> > This is 100% matched by an allocation of globally unique space from a
> > RIR, shared by whoever the interested parties are.
> >  The IETF *need not* specify any BCP on how to improve NAT444
> > "CGN"-scale alone, because such action is attached with high risk of
> > leading to a local maximum in a plot of the state of the Internet,
> > rather than towards a global maximum.
> >
> > Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
> > Transition" warns:
> >   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
> >   Scale NAT, compounds IPv4 operational problems when used alone but
> >   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
> >   NAT444 CGN allows ISPs to delay the transition and therefore causes
> >   double transition costs (once to add CGN and again to support IPv6).
> >
> > The draft as written, makes no effort to require the RFC6264 or
> > equivalent approaches to a IPv6 transition, to the CGN deployments it
> > specifies v4 address space for. All carrot, no stick.
> >  I believe the state of the Internet would be much more reliably
> > improved by the RIRs each having (for the purpose of being able to serve
> > their own users) one /10 special allocation for this purpose, which they
> > can assign to multiple users upon demonstrating, under contract, they
> > are transitioning to IPv6 according to 6264, or equivalent.
> >
> > As written there is no effort to mitigate the risk mentioned in the
> > quote above, and I can't support a draft that will hurt the Internet and
> > neither should you.
> 
> Apologies for my bluntness, but this argument is a complete
> misinterpretation of the facts on the ground. 

Taking:
   This draft is not about encouraging nor facilitating CGN deployments. 
   Allocating a /10 for inside CGN addressing use _will not_ make anyone
   deploy CGN who would not have otherwise done so. Not allocating a /10
   for inside CGN addressing use _will not_ stop anyone from deploying
   CGN who would have otherwise done so. 
+
   What we can do, is ensure that when those folks who must deploy
   CGN do so, that they break the Internet as little as possible. And
   _that_ is what this I-D seeks to accomplish.

you seem to be of the opinion that improving the feasibility of CGN, by
making it suck less, will not have any impact on potential set of
networks who are deploying it, or in what way they will deploy it.

You seem to want me to believe that: 
  - there is a fixed set of networks, who are going to deploy either:
- a sucky IPv4 network, or, 
- a less sucky IPv4 network, 
  - it would be entirely depending on the passing of this draft, 
  - the failure of passing of this draft somehow will exclude from these
networks the possibility of obtaining non-RFC1918 space in another way,
for example as I outlined

The latter two points seem a bit far-fetched.

I'm curious how you can possibly have sufficient knowledge to make those
statements as *facts*, rather than opinions, informed as the may be (but
of limited scope -- I think it unlikely you've spoken to every network
on the planet).

   In fact, neither you nor I nor the IETF can stop operators who must 
   deploy CGN for business continuity from doing so.

I hold no such illusions.  What the IETF ought to do however, IMHO, is
to point them in a good direction. I don't see that happening in this
document.

A less-sucky IPv4-run-out access network is still a local maxima
compared to the global maxima of DS.
  Convince me that our journey to reach the global maxima will not be
negatively affected by this document, and gain my support.

Kind regards,
Martin


signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

draft-weil last call: IANA Reserved IPv4 Prefix for Shared Address Space

[Scott A Griffith]

I support the current draft-weil as recently updated.  I believe the updated 
draft is more flexible, and would satisfy additional use cases that don't work 
with RFC1918 space.

Thanks

Scott Griffith
GCI Product Manager
Anchorage, AK
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

re: [core] Last Call: (CoRE Link Format) to Proposed Standard

[Don Sturek]

This is less a substantive comment but one more on processŠŠ..

Here is the history of WGLC:

http://www.ietf.org/mail-archive/web/core/current/msg02427.html

http://www.ietf.org/mail-archive/web/core/current/msg01414.html

Here is the history:

http://datatracker.ietf.org/doc/draft-ietf-core-link-format/history/


A couple of points:
1)  I work in a commercial group (ZigBee Alliance) using IETF standards for
commercial deployment.  We have several work groups interested in CoAP but
were waiting for a stable version to determine whether it was usable or not
for their application (things like home automation, commercial automation).
We had assumed that since the original WGLC (rev ­02) and since there were
multiple iterations on the document (see the history) that the document was
not final.
2)  The second WGLC was only 1 week in duration and occurred over the US
Thanksgiving holiday.  I completely missed that.  Even so, there were 3 more
revisions after that so not sure it was obvious that this was actually the
final WGLC for the document.

I mention the above since I think it would be useful to actually have a full
1 month last call on this document.  I think there were several of us that
were surprised by the referral of the document to the IESG and who were
planning to do a final review at WGLC (which apparently we missedŠ.).

Also, is it normal to have so many revisions after WGLC?   Having WGLC in
Jan. 2011 on rev ­02 and then the version referred to IESG as rev ­12 a year
later seems strange.

Thanks for your consideration,

Don Sturek




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

RE: Auth48 comments on draft-ietf-pwe3-static-pw-status-10

[Gregory Mirsky]

Dear Matthew, Authors, et al.,
I think that new text of fourth para in Section 5.3 adds some confusion. If 
intension is to stop sending 'all clear' after three one-second intervals went 
unacknowledged but before refresh timer expires then perhpas new text can be 
more explicit:
NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent at one second 
intervals and before refresh timer expires. A PW
status message of zero MAY be acknowledged as per the procedures described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the PW status
notification message with a PW status code equal to zero to stop sending
 and to continue normal operation.

Regards,
Greg


From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Bocci, 
Matthew (Matthew)
Sent: Wednesday, February 15, 2012 7:10 AM
To: p...@ietf.org; ietf@ietf.org
Cc: pwe3-cha...@tools.ietf.org; Stewart Bryant
Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10

During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some 
issues with the acknowledgement procedures in Section 5.3 of the draft that we 
feel should be addressed before publication. Since the draft has already been 
through WG and IETF last call, we would like to highlight the proposed changes 
to the working group and solicit feedback.

Best regards,

Matthew

Section 5.3, 3rd paragraph:
Reason for change:
The current suggested default refresh timer value is too short to allow scaling
to very large numbers of PWs while minimising the overhead. It is also 
inconsistent
with the suggested default requested in an ACK packet. Therefore we suggest 
increasing
the default to 600secs.

OLD: The suggested default value for the refresh timer is 30 seconds.

NEW: The suggested default value for the refresh timer is 600 seconds.



Section 5.3, 4th paragraph:
Reason for change:
The current text requires that a receiving PE must acknowledge a PW status 
message
of 'clear all faults' in order to force a transmitter to stop sending PW status
messages at 1 second intervals.  We are concerned that a mandatory 
acknowledgement
adds an unnecessary complexity to the protocol which is inconsistent with
the use of the acknowledgement as per the following section (5.3.1). 
Additionally,
we are also concerned that this may cause problems if a transmitter
is flapping between 'clear all faults' and a non-zero value, and if the
acknowledgement is lost. We therefore suggest that the acknowledgement to
'clear all faults' be made optional, and that  the transmitter behavior be 
changed so
that it sends up to 3 status messages of zero in a row, and then goes silent.

OLD:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however, it MUST be
acknowledged with a packet with a timer value of zero.  This will cause
the PE sending the PW status notification message with a PW status code
equal to zero to stop sending and to continue normal operation.


NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent. A PW
status message of zero MAY be acknowledged as per the procedures described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the PW status
notification message with a PW status code equal to zero to stop sending
 and to continue normal operation.


Section 5.3.1, 1st paragraph:
Reason for change:
The procedures currently defined in this paragraph can lead to a receiver
of the static status message timing out if it requests, throught the use of the
ACK mechanism, a longer refresh timer from the transmitter. This is because the
current text implies that the transmitter change its referesh timer immediately
on receipt of the ack packet from the receiver. The new text clarifies that
the refresh timer be updated at the end of the current refresh interval, as
well as making some other editorial clarifications.

OLD:
The PE receiving a PW OAM message containing a PW status message
can acknowledge the PW status message by simply building an almost
identical reply packet with the A bit set, and transmitting it on the PW
ACH back to the source of the PW status message.  T

Re: IETF Last Calls and Godwin-like rules

[Melinda Shore]

On 2/16/12 6:59 AM, Alia Atlas wrote:

For what it is worth, those who I've seen commenting in the +1 fashion
recently are primarily people I've known to be active in the IETF for
years - including some WG chairs.


I tend to be involved with different working groups from the ones
John is, and I've assumed (forgive me) that he's seeing something
somewhere that I'm not.  I've certainly seen the behavior he's
describing (flood of non-participants "voting").  I think there's
a difference between someone who's been contributing all along
participating in a consensus call by posting "+1" and someone
whom you can't tell whether or not actually read the draft posting
"+1" and it would be surprising indeed if the person responsible
for determining consensus (the chair) treated them as equal in
weight.

Actually, come to think of it, we've seen a certain amount of this
concerning the draft-weil-shared-transition-space-request draft.

Anyway, I take the situation that John's describing as annoying
but not an actual problem - we don't decide by voting.

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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Nick Hilliard]

On 16/02/2012 16:35, Martin Millnert wrote:
> You seem to want me to believe that: 
>   - there is a fixed set of networks, who are going to deploy either:
> - a sucky IPv4 network, or, 
> - a less sucky IPv4 network, 
>   - it would be entirely depending on the passing of this draft, 
>   - the failure of passing of this draft somehow will exclude from these
> networks the possibility of obtaining non-RFC1918 space in another way,
> for example as I outlined
> 
> The latter two points seem a bit far-fetched.

Martin,

Far-fetched - like all straw men.

> I'm curious how you can possibly have sufficient knowledge to make those
> statements as *facts*, rather than opinions, informed as the may be (but
> of limited scope -- I think it unlikely you've spoken to every network
> on the planet).

More straw men.  Look, we're adults here: please present good arguments.

The bottom line for this ID is that address space will be required for CGN,
and rfc1918 doesn't cut it for reasons described in the ID.  This means
that the address space must come from somewhere else.  The choices are:

1. one or more shared pools allocated by RIRs/IANA/whatever
2. private pools, each of which come from the carriers' own address blocks

option #1 is by definition more efficient than #2.

At least one of the RIRs has indicated that they cannot assign this space
due to charter problems.

There is no particular reason to allocate this space on a regional basis,
unless for some reason you believe that you can force carriers only to use
this shared address space for specific purposes - and I cannot see why you
think that this is remotely feasible for shared address space.  Private
address space, perhaps.  But certainly not shared address space.

The core function of a RIR is to guarantee that if they allocate you a
bunch of numbers, that they haven't allocated the same bunch of numbers to
someone else.  Therefore by definition they have no particular authority
over the way that shared address space might be used internally by a carrier.

Incidentally, I support this draft.

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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Chris Grundemann]

On Thu, Feb 16, 2012 at 09:35, Martin Millnert  wrote:
> Dear Chris,
>
> On Thu, 2012-02-16 at 08:43 -0700, Chris Grundemann wrote:
>> On Thu, Feb 16, 2012 at 03:43, Martin Millnert  wrote:
>>
>> > This is 100% matched by an allocation of globally unique space from a
>> > RIR, shared by whoever the interested parties are.
>> >  The IETF *need not* specify any BCP on how to improve NAT444
>> > "CGN"-scale alone, because such action is attached with high risk of
>> > leading to a local maximum in a plot of the state of the Internet,
>> > rather than towards a global maximum.
>> >
>> > Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
>> > Transition" warns:
>> >   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
>> >   Scale NAT, compounds IPv4 operational problems when used alone but
>> >   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
>> >   NAT444 CGN allows ISPs to delay the transition and therefore causes
>> >   double transition costs (once to add CGN and again to support IPv6).
>> >
>> > The draft as written, makes no effort to require the RFC6264 or
>> > equivalent approaches to a IPv6 transition, to the CGN deployments it
>> > specifies v4 address space for. All carrot, no stick.
>> >  I believe the state of the Internet would be much more reliably
>> > improved by the RIRs each having (for the purpose of being able to serve
>> > their own users) one /10 special allocation for this purpose, which they
>> > can assign to multiple users upon demonstrating, under contract, they
>> > are transitioning to IPv6 according to 6264, or equivalent.
>> >
>> > As written there is no effort to mitigate the risk mentioned in the
>> > quote above, and I can't support a draft that will hurt the Internet and
>> > neither should you.
>>
>> Apologies for my bluntness, but this argument is a complete
>> misinterpretation of the facts on the ground.
>
> Taking:
>   This draft is not about encouraging nor facilitating CGN deployments.
>   Allocating a /10 for inside CGN addressing use _will not_ make anyone
>   deploy CGN who would not have otherwise done so. Not allocating a /10
>   for inside CGN addressing use _will not_ stop anyone from deploying
>   CGN who would have otherwise done so.
> +
>   What we can do, is ensure that when those folks who must deploy
>   CGN do so, that they break the Internet as little as possible. And
>   _that_ is what this I-D seeks to accomplish.
>
> you seem to be of the opinion that improving the feasibility of CGN, by
> making it suck less, will not have any impact on potential set of
> networks who are deploying it, or in what way they will deploy it.

Correct.

> You seem to want me to believe that:
>  - there is a fixed set of networks, who are going to deploy either:
>    - a sucky IPv4 network, or,
>    - a less sucky IPv4 network,
>  - it would be entirely depending on the passing of this draft,
>  - the failure of passing of this draft somehow will exclude from these
> networks the possibility of obtaining non-RFC1918 space in another way,
> for example as I outlined
>
> The latter two points seem a bit far-fetched.

Not quite, let me try again.

I am stating that:
 - Dual-Stack requires both IPv4 and IPv6 addresses
 - There is a non-zero number of networks which will exhaust all
available IPv4 resources before the world is able to fully transition
to IPv6
 - These networks must choose one of either:
  -- Go out of business
  -- Find a new way to provide IPv4 connections to customers
 - NAT44* CGN will be chosen by a non-zero number of these networks
 - This decision is independent of what addresses they will use inside
of the CGN (No one wants to go through two transitions. Folks who
deploy CGN do so because they must. As such, the addresses used are an
afterthought. The cost of CGN and it's alternatives are what drive the
decision, not this I-D or the addresses it seeks to reserve.)

> I'm curious how you can possibly have sufficient knowledge to make those
> statements as *facts*, rather than opinions, informed as the may be (but
> of limited scope -- I think it unlikely you've spoken to every network
> on the planet).

You are again correct, I have not spoken to every network on the
planet. I have spoken to many. Several in the Asia/Pacific region have
already experienced the chain of events I outlined above.

Further, my job is to understand the IPv6 transition and as such, much
of my time is dedicated to creating this understanding. I do not make
these claims lightly.

>   In fact, neither you nor I nor the IETF can stop operators who must
>   deploy CGN for business continuity from doing so.
>
> I hold no such illusions.  What the IETF ought to do however, IMHO, is
> to point them in a good direction. I don't see that happening in this
> document.
>
> A less-sucky IPv4-run-out access network is still a local maxima
> compared to the global maxima of DS.
>  Convince me that our journey to reach the global maxima will n

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Martin Millnert]

Hi Nick,

On Thu, 2012-02-16 at 16:58 +, Nick Hilliard wrote:
> There is no particular reason to allocate this space on a regional
> basis, unless for some reason you believe that you can force carriers
> only to use this shared address space for specific purposes - and I
> cannot see why you think that this is remotely feasible for shared
> address space.  Private address space, perhaps.  But certainly not
> shared address space. 

I'm not sure why a contract with a RIR would be less enforceable than
this I-D. On the contrary, I think the chances of correct use are higher
in that scenario than the other.

It's just bits, you know. IPv4-code on the general internet certainly
won't care about these bits. Routing policy however, may.  I do not see
how having the BCP makes any difference, if the allocation comes from
the RIR in either case, provided there is at least one RIR which can
assign address space to an entity who will share it.

Best,
Martin


signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Thomas Narten]

Hi John.

Turns out Jari sent a message with an overview of the changes. But it
only went to the lisp mailing list, to which I'm not subscribed. 

See http://www.ietf.org/mail-archive/web/lisp/current/msg03674.html

That is the sort of explanation I was looking for.

But since re-chartering is an IETF-wide discussion, I think it would
be helpful that these sorts of things get mentioned in the "WG Review"
messages. That would be helpful to the broader community.

Thomas

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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Martin Millnert]

Hi Chris,

On Thu, 2012-02-16 at 10:09 -0700, Chris Grundemann wrote:
> On Thu, Feb 16, 2012 at 09:35, Martin Millnert  wrote:

> > you seem to be of the opinion that improving the feasibility of CGN, by
> > making it suck less, will not have any impact on potential set of
> > networks who are deploying it, or in what way they will deploy it.
> 
> Correct.

.. except for the part of actually changing what addresses they put on
the inside, which the I-D is about.  Perhaps it's splitting hairs
whether that constitutes a "change" or not, but if it's not a change,
it's weird that it would improve the quality of the network. :-)



> I am stating that:
>  - Dual-Stack requires both IPv4 and IPv6 addresses
>  - There is a non-zero number of networks which will exhaust all
> available IPv4 resources before the world is able to fully transition
> to IPv6
>  - These networks must choose one of either:
>   -- Go out of business
>   -- Find a new way to provide IPv4 connections to customers
>  - NAT44* CGN will be chosen by a non-zero number of these networks
>  - This decision is independent of what addresses they will use inside
> of the CGN (No one wants to go through two transitions. Folks who
> deploy CGN do so because they must. As such, the addresses used are an
> afterthought. The cost of CGN and it's alternatives are what drive the
> decision, not this I-D or the addresses it seeks to reserve.)

In the end, I suppose, networks who do not also roll-out DS in
combination with NAT44* CGN, are a blessing for their competition...
where such competition physically exists.

> > I'm curious how you can possibly have sufficient knowledge to make those
> > statements as *facts*, rather than opinions, informed as the may be (but
> > of limited scope -- I think it unlikely you've spoken to every network
> > on the planet).
> 
> You are again correct, I have not spoken to every network on the
> planet. I have spoken to many. Several in the Asia/Pacific region have
> already experienced the chain of events I outlined above.

Check. (I'm aware, as well.)

> Further, my job is to understand the IPv6 transition and as such, much
> of my time is dedicated to creating this understanding. I do not make
> these claims lightly.

Cool. I haven't/certainly didn't mean to suggest you did.

> >   In fact, neither you nor I nor the IETF can stop operators who must
> >   deploy CGN for business continuity from doing so.
> >
> > I hold no such illusions.  What the IETF ought to do however, IMHO, is
> > to point them in a good direction. I don't see that happening in this
> > document.
> >
> > A less-sucky IPv4-run-out access network is still a local maxima
> > compared to the global maxima of DS.
> >  Convince me that our journey to reach the global maxima will not be
> > negatively affected by this document, and gain my support.
> 
> Once an operator has decided that they have no other choices remaining
> and that they must deploy CGN, they then have to decide how to
> architect that deployment. One of the architectural decisions to be
> made (and the one we are concerned with here) is what addresses to use
> within the CGN. They have several options:
> 
> - Globally Unique "Public" Addresses
> This option burns addresses that they or others could use to number
> devices that actually require a unique address, this is a net loss to
> the Internet.
> 
> - RFC 1918 "Private" Addresses
> The chance for collision and the low margins of residential broadband
> make this option a non-starter. Nothing any of us say will convince
> any substantial number of operators to shoot themselves in the foot in
> this way.
> 
> - Class E Addresses
> Too much equipment is hard coded to reject these addresses. It simply
> will not work in time to make a difference.
> 
> - "Squat" Addresses
> Without a shared address space, this is the likely winner. Squatting
> on someone else's address space works and is free. A misconfigured
> filter allows these to leak however, another net loss to an un-borked
> Internet.
> 
> - "Shared" Addresses
> This is the solution put forth in the I-D under discussion here. This
> allows an alternative that is attractive to operators and can be
> managed (since it is a known prefix). If one operator leaks routes,
> others will have filters in place. This option removes the least
> amount of addresses from the remaining free pools thus allowing
> Dual-Stack to work in the most possible networks. All in all, this is
> the best way to ensure a less broken Internet than any of the other
> options can provide.

Not seeing a limitation to NAT444, you left out various alternatives
which have integrated IPv6/DS. Alternatives which, once installed, will
lead to a steady (comparing with the v4-only case) reduction in load on
the CGN equipment, as the world increasingly moves towards DS/v6-only. 

Such alternatives may not apply to the CGN variant NAT444, which I ACK
the I-D addresses.

> Again, we are not talking about encouraging or disc

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[John Scudder]

Hi Thomas,

On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote:

> A WG Review message for this WG already went out a month ago.
> 
> What has changed to necessitate another Last Call?
> 
> Could the-powers-that-be please make it easier for those who might
> care to understand if there is something here that we should know and
> possibly comment about?
> 
> A simple explanation, or a pointer to diffs, etc. would do the job
> nicely.

Good question! I did go back and diff the last couple of versions and though 
this isn't the exhaustive diff, these are the key changes that caught my eye:

This text was lost from the previous draft charter:

This analysis will explain what
role LISP can play in scalable routing. The analysis should also look at
scalability and levels of state required for encapsulation,
decapsulation, liveness, and so on as well as the manageability and
operability of LISP. Specifically, the group will work on:

- documenting areas that need experimentation
- summarizing the results of implementation, experiments, and deployment
  experience
- describing the implications of employing LISP
- operational guidance for using LISP

And so were these Goals and Milestones:

Jun 2012Forward to the IESG an operational document which should
   include cache management and ETR synchronization
   techniques (draft-ietf-lisp-deployment).

Dec 2013Publish an example cache management specification.

Jun 2014Summarize results of specifying, implementing, and testing
   LISP and forward to IESG and/or IRTF.

Jun 2014Analyze and document the implications of LISP deployments in
   Internet topologies and forward to IESG for publication.

I'm not sure why these were removed, and I would like to see them reinstated or 
at least have a discussion about their removal.

Thanks,

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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[John G. Scudder]

Thanks, Thomas. In case it's not obvious, Jari's message isn't responsive to 
the points I raised in my own message so I'll look forward to discussing those. 

--John

On Feb 16, 2012, at 12:10 PM, Thomas Narten  wrote:

> Hi John.
> 
> Turns out Jari sent a message with an overview of the changes. But it
> only went to the lisp mailing list, to which I'm not subscribed. 
> 
> See http://www.ietf.org/mail-archive/web/lisp/current/msg03674.html
> 
> That is the sort of explanation I was looking for.
> 
> But since re-chartering is an IETF-wide discussion, I think it would
> be helpful that these sorts of things get mentioned in the "WG Review"
> messages. That would be helpful to the broader community.
> 
> Thomas
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

SEARS - Search Engine Address Resolution Service (and Protocol)

[Todd Glassey]

So SEARS is a method of replacing the DNS roots with a well-known
service portal providing a Google or other SE based access model.  The
session can interface with traditional HTTP or DNS-Lookup Ports to
deliver content or addresses to a browser in the form of a HTTP redirection.

The protocol specification is almost done and is intended to make
threats of attacks against the DNS roots less of an issue.

Todd

-- 
Todd S. Glassey - CISM CIFI
CTO Certichron Inc

This message contains information which may be confidential and/or
privileged. Unless you are the intended recipient (or authorized to
receive for the intended recipient), you may not read, use, copy or
disclose to anyone the message or any information contained in the
message. If you have received the message in error, please advise the
sender by reply e-mail and delete the message and any attachment(s)
thereto without retaining any copies.

Further we have a formal OPT OUT Policy posted on our website pertaining
to the use of any Email Addresses gleaned or taken from any source, web,
mailing lists, previous customer lists etc. In all instances we choose
to formally OPT OUT and this notice constitutes formal disclosure that
you may not collect, buy or sell or provide access to this email address
or any pertaining to our DNS MX Record Publication License posted on the
web at http://www-wp.certichron.com/?page_id=3947.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[james woodyatt]

everyone--

My position on this draft remains unchanged.  It is far too forgiving of the 
6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] proposal, which I 
regard as abominable.  That reason alone, in my judgment, is sufficient grounds 
that it should not be published.  I also share the concerns of most of the 
opponents of this draft.

My recommendation regarding this draft, to the people inside Apple who 
implement customer-edge router functions, is to ignore it.  It is too late to 
add the shared transition space to the list of special-use addresses excluded 
from use as 6to4 tunnel endpoints in all the units already deployed in the 
field.  Such a disruption to existing customer configurations is generally 
unacceptable behavior for software updates.  Also, while it might seem 
reasonable to add the new space to the list of special-use addresses only in 
*forthcoming* products that support a 6to4 tunnel router feature, that too is 
unlikely ever to happen. (Note well: we don't comment publicly about the 
features of unreleased products.)

Shorter james: this draft is a bad idea; please don't publish it.


--
james woodyatt 
member of technical staff, core os networking



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

Re: [core] Last Call: (CoRE Link Format) to Proposed Standard

[Carsten Bormann]

Hi Don,

thanks for the feedback.

link-format has been essentially stable for the better part of a year now (as 
the result of dispatching of the comments on the first WGLC in -03, IIRC).  It 
has been used in a number of informal interop events, and the feedback always 
was that it did its job and there were few, if any, problems.

Yes, there have been many minor revisions since, mostly on the editorial front.
There is a difference between a spec implementers close to the WG process can 
use and the one you want in the permanent record for everybody to use.
We also needed to get the ABNF right to cover some fringe cases.

When these small fixes were completed in response to the results of the second 
WGLC, I had briefly planned to do a third WGLC, but then I didn't really see a 
reason any more to do so.  (BTW, I'm not aware of a concept of "final WGLC", 
and I have never qualified a WGLC as such.  The "L" in WGLC already means 
"last", as in final.)

As a general observation on the IETF WG process: the increase of the number on 
the document does not mean there is substantial change.  In particular during 
what I'm referring to as the "ID-nits phase" when a document is getting dressed 
up for going forward, it may take a couple of small editorial rounds to get all 
the various classes of things crossed and dotted.  
Please do avail yourself of the tools pages to review the diffs to see whether 
there still is substantial change or just Brownian motion.  On a more general 
note, WGLC is not the only time WG members need to look at a document.

Putting WGLCs on top of distracting events like IETF meetings or important 
holidays is something most WG chairs actively try to avoid.  I already put in 
an allowance for the November IETF in the second WGLC, and I'm sorry if I 
forgot about adding more allowance for US Thanksgiving Day.  (There has been 
ample time since to submit any late feedback.)

All that said, we're in luck and have an IETF last call that follows the WG 
consensus process in the procedures, and this is a great opportunity for 
additional input.  
I'm certainly looking forward to yours.

Grüße, Carsten

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

Re: IETF Last Calls and Godwin-like rules

[John C Klensin]

--On Thursday, February 16, 2012 07:49 -0900 Melinda Shore
 wrote:

> On 2/16/12 6:59 AM, Alia Atlas wrote:
>> For what it is worth, those who I've seen commenting in the
>> +1 fashion recently are primarily people I've known to be
>> active in the IETF for years - including some WG chairs.

> I tend to be involved with different working groups from the
> ones
> John is, and I've assumed (forgive me) that he's seeing
> something
> somewhere that I'm not.  I've certainly seen the behavior he's
> describing (flood of non-participants "voting").  I think
> there's
> a difference between someone who's been contributing all along
> participating in a consensus call by posting "+1" and someone
> whom you can't tell whether or not actually read the draft
> posting
> "+1" and it would be surprising indeed if the person
> responsible
> for determining consensus (the chair) treated them as equal in
> weight.

Exactly.   I've also seen very clear situations in the past in
which people who haven't participated and haven't studied the
drafts have been rounded up on a mailing list associated with a
non-IETF body to "vote" in a particular way (fwiw, the worst
example I recall was with an IPR issue).
 
> Actually, come to think of it, we've seen a certain amount of
> this
> concerning the draft-weil-shared-transition-space-request
> draft.

As you point out, I'm not in a good position to judge and was
trying to not do so.  However, I did see a piece of a note to
what appeared to be a non-IETF list suggesting that people go
record their endorsements on the grounds that numbers count.
The note that started this thread was intended, in part, to
point out that numbers of otherwise-content-free endorsements
don't count very much (or shouldn't).  I hoped to make that
point before someone in the opposing group made an effort to
round up all of his friends and acquaintances.

> Anyway, I take the situation that John's describing as annoying
> but not an actual problem - we don't decide by voting.

And the particular thread started by
draft-weil-shared-transition has gone on long enough that I
assume that every IESG member, and especially the ADs who are
most relevant, are painfully aware of the issue.

There is one sense in which it is maybe an actual problem but it
isn't the voting issue (or lack thereof).  IMO, there are two
reasons why it is beneficial to have Last Call discussions on
the IETF list, rather than predominantly in private notes to the
IESG.  One is that we all get to know what the IESG is getting
told (except when the exceptions mentioned in the Last Call
announcement applies -- cases that I think it is important to
preserve).  But the other and IMO far more important reason is
that it is educational for the community: it may help people who
haven't made up their minds to do so and help others to better
understand the tradeoffs.But, for both of those groups of
people, notes that are high in information content --
considerations and perspectives that have not appeared on the
list before, new facts and arguments-- are very useful.  People
repeating themselves and their positions are not and simply
endorsements aren't much more so - from the standpoint of
someone trying to read the discussions to build a better
understanding, both are pretty much noise (and bogus arguments
aren't much better).  And, since all of us are busy noise in a
long thread does tend to cause some messages that might contain
signal to get lost.

I don't believe anything can be "done about" the more noisy
behavior.  I can, however, hope that raising sensitivity to it
might help, if only a little, to reduce the rate at which it
increases.

john

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

RE: SEARS - Search Engine Address Resolution Service (and Protocol)

[Worley, Dale R (Dale)]

How do you find the "well-known service portal" if DNS isn't working?

Dale


From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Todd Glassey 
[tglas...@certichron.com]
Sent: Thursday, February 16, 2012 7:30 AM
To: dn...@ietf.org; IETF Discussion Mailing List
Subject: SEARS - Search Engine Address Resolution Service (and Protocol)

So SEARS is a method of replacing the DNS roots with a well-known
service portal providing a Google or other SE based access model.  The
session can interface with traditional HTTP or DNS-Lookup Ports to
deliver content or addresses to a browser in the form of a HTTP redirection.

The protocol specification is almost done and is intended to make
threats of attacks against the DNS roots less of an issue.

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

Re: IETF Last Calls and Godwin-like rules

[Noel Chiappa]

> From: John C Klensin 

> people who haven't participated and haven't studied the drafts

This isn't exactly about a complicated protocol: it's about whether to assign
an address block or not.

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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[David Conrad]

On Feb 16, 2012, at 8:58 AM, Nick Hilliard wrote:
> The bottom line for this ID is that address space will be required for CGN,
> and rfc1918 doesn't cut it for reasons described in the ID.  This means
> that the address space must come from somewhere else.  The choices are:
> 
> 1. one or more shared pools allocated by RIRs/IANA/whatever
> 2. private pools, each of which come from the carriers' own address blocks

3. private pools, independently chosen by ISPs using some method from allocated 
space (aka squat space).

> option #1 is by definition more efficient than #2.

and option #1 is safer than option #3.

> There is no particular reason to allocate this space on a regional basis,

I'd say it would be silly to do so -- what would be the point?

> Incidentally, I support this draft.

One implication of draft-weil not being accepted is that it will likely 
accelerate IPv4 free pool exhaustion as the folks interested in draft-weil will 
simply go out and get blocks from their RIRs while they still can.  I will 
admit a small part of me finds this appealing as it would end the seemingly 
interminable rearrangement of deck chairs on the IPv4 address policy-wonk 
Titanic.

Regards,
-drc

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

Re: [core] Last Call: (CoRE Link Format) to Proposed Standard

[Carsten Bormann]

On Feb 16, 2012, at 19:52, Don Sturek wrote:

> Hi Carsten,
> 
> Somehow, luck is not how I would have described the process.
> 
> I think if you thought it important enough to do a WGLC in November 2011,
> you maybe should have made it for longer than a week

I did.

> and avoided the US
> Thanksgiving holiday.

As I said, I didn't have that on the radar, so I didn't compensate for both the 
IETF and the US Thanksgiving Day.
Sorry about that.
Not including the winter holidays, there were two more months for making 
comments since.

> We had several groups interested in possibly using CoAP but I was holding
> off looking at the draft until WGLC.  I guess with the response below, the
> guidance will be to use what is there else find another solution

Wait a minute, maybe there is some underlying confusion here.

This last-call is about the CoRE link-format.  
The link-format spec and the CoAP protocol are rather loosely coupled, 
technically speaking.

CoAP is not even in first WGLC yet (but getting close).

If you do need some time beyond the usual two-week WGLC to review the CoAP 
documents, now probably would be a good time to start the review for

  "Constrained Application Protocol (CoAP)", 31-Oct-11, 


  "Blockwise transfers in CoAP", 15-Feb-12, 

  "Observing Resources in CoAP", 14-Feb-12, 

The core-coap spec hasn't been updated recently and therefore carries the bulk 
of the remaining open tickets (six); please review them at
http://trac.tools.ietf.org/wg/core/trac/report
(I recommend the format of report 9.)
There are proposals for resolution of most of the remaining tickets, and we 
would love to receive your input so we can make good technical decisions even 
before the documents go to WGLC.

It is worth pointing out that the main technical substance of the documents has 
been stable since about March 2011 (core-coap) and since mid-2011 (-observe, 
-block).  Feedback from the multiple implementations has been quite positive, 
so this should all be stable enough for a thorough review. 

> (fortunately, the work you are doing can be replaced with other solutions
> if does not map to our commercial needs).

Why the sour grapes?

This WG has a history of being very open and supportive for all technical input 
received.
There is no take-it-or-leave-it at all.
But you do have to speak up, or you won't be heard.

The best way to contribute to IETF WG work is, indeed, taking part in the work 
before WGLC.

> I think I will have a look at the diffs.  I was on the reflector and seem
> to recall more than just editorials going in to the specification after
> the first WGLC (which I recall at the time being wildly premature with
> respect to the maturity of CoAP.)

We did the link-format WGLC in January 2011 because the author thought it was 
ready and nobody in the WG spoke up to stop it.
The feedback was quite positive, and the changes resulting from the review were 
useful but small.
It probably was right to wait for November for the 2nd WGLC because CoAP was 
still stabilizing, but it turns out there was no impact.

I don't understand the comment about maturity, but maybe again you are 
referring to CoAP -- a WGLC for CoAP in January 2011 might have been rather 
early indeed.

But for now let's stick to the link-format document -- this is what's being 
last-called this month.
It is a short document, and it is mainly about making an existing RFC (RFC 
5988) accessible to the CoRE space.

Grüße, Carsten

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

Re: IETF Last Calls and Godwin-like rules

[Mark Andrews]

In message <9bbaf712-d199-4950-a516-33c830756...@checkpoint.com>, Yoav Nir 
writes:
> 
> On Feb 16, 2012, at 4:48 PM, Roger J=F8rgensen wrote:
> 
> > On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir  wrote:
> > 
> >> I think that an endorsement like "I work for Cisco and we intend to impl=
> ement this in every one of our products" is useful. But it's not nearly as =
> useful as "this is a terrible idea, and doing this will prevent IPv6 from e=
> ver gaining traction". The objections raised in last call are really the po=
> int, not the endorsements.
> > =
> 
> > =
> 
> > Think I've read somewhere that the ground of good engineering (the E
> > in IETF) are being able to argue against your own idea, search and
> > look for flaws in it, and all in the name of testing it to see how it
> > can be made even better, is it good enough? Or simple to consider the
> > bigger picture, can my idea hurt the rest no matter how good it is?
> > There are great and very good ideas out there that isolated are
> > fantastic, but considered in just a bit bigger picture are horrible,
> > they've ruin everything around them.
> 
> I agree. IPv4 forever using CGNs may work for a lot of people and a lot of =
> uses. If people remain double- or triple-natted it won't matter a bit to th=
> e big web sites. =
> 
> 
> It's far more important to hear what is not going to work with this solutio=
> n.
> 
> It's great if you can find such deficiencies in your own ideas, but we stil=
> l need design reviews, code reviews, QA departments and IETF last calls so =
> that others can get at your idea.

To all of you saying that this only supports IPv4 only boxes.  How
do I connect up my Windows XP (with IPv6 enabled) or later box,
Linux box (from anywhere in the last decade), *BSD box (from anywhere
in the last decade), Apple box (from anywhere in the last decade)
and get both IPv4 and IPv6 without being handed a IPv4 address via
DHCP.  That list pretty much covers the home computer space of dual
stack computer space.

People keep saying IPv6 provides additional solutions, and it does,
however there is a enormous dual stack legacy device problem out
there and saying "go IPv6 only" just isn't a viable for those devices
yet.  They still need a IPv4 address via DHCP which has all the
issues a IPv4-only box has.

There are dual stack CPE routers today that won't provide IPv4
unless there is address space provided via DHCP.  I've got one and
at some point my ISP will need to go the CGN route for IPv4.  I
don't know if there will be a firmware update to support IPv4 over
IPv6 or if there is it will match the solution my ISP will choose.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Nick Hilliard]

On 16/02/2012 19:42, David Conrad wrote:
> One implication of draft-weil not being accepted is that it will likely
> accelerate IPv4 free pool exhaustion as the folks interested in
> draft-weil will simply go out and get blocks from their RIRs while they
> still can.  I will admit a small part of me finds this appealing as it
> would end the seemingly interminable rearrangement of deck chairs on the
> IPv4 address policy-wonk Titanic.

This deck-chair rearrangement stuff is as predictable as it is pointless.
The only good point about the ID is that at least it puts most carriers on
the same footing and gives them some level of ability to continue to
support their customers' ipv4 connectivity requirements.  In its absence, a
lot of providers will end up using even worse alternatives.

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

Re: IETF Last Calls and Godwin-like rules

[Nick Hilliard]

On 16/02/2012 19:42, Noel Chiappa wrote:
> This isn't exactly about a complicated protocol: it's about whether to assign
> an address block or not.

It's a quintessential bike-shed problem.  The only reason that people are
moaning about it so much is that they understand the concept of address
allocation.  If the ID concerned a more difficult but important topic, it
would have been waved through hundreds of emails ago.

If every draft got this much attention, we'd still be arguing about X.400
to SMTP gateways.

Nick

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

IRTF IPR Disclosure Rules

[Eggert, Lars]

Until now, the IRTF didn't have a clearly formulated statement of how IPR is 
handled by the organization. For the last year, the IRSG has been discussing 
this topic with the IETF's legal counsel and other community members with a 
deep understanding of the issues.

The result of this discussion is a short statement describing the IRTF's IPR 
disclosure rules, which you can find below as well as online at 
http://irtf.org/ipr. The short version is: the IRTF follows the IETF's IPR 
disclosure rules. Because researchers participating in the IRTF may not be very 
familiar with the IETF's rules, the IRTF IPR disclosure rules describe what is 
required of the individual participant in the most common cases.

Just as the IETF, the IRTF expects participants to be familiar with these rules 
and follow them when they make contributions.

Please email any comments or questions to irtf-disc...@irtf.org.

Lars Eggert
IRTF Chair

---

IRTF IPR Disclosure Rules

The IRTF follows the IETF IPR disclosure rules. This is a summary
of these rules as they relate to IRTF research group discussions,
mailing lists and Internet Drafts:

- If you include your own or your employer's IPR in a contribution
  to an IRTF research group, then you must file an IPR disclosure
  with the IETF.

- If you recognize your own or your employer's IPR in someone else's
  contribution and you are participating in the discussions in the
  research group relating to that contribution, then you must file
  an IPR disclosure with the IETF. Even if you are not participating
  in the discussion, the IRTF still requests that you file an IPR
  disclosure with the IETF.

- Finally, the IRTF requests that you file an IPR disclosure with
  the IETF if you recognize IPR owned by others in any IRTF
  contribution.

You may file an IPR disclosure here:
http://www.ietf.org/ipr/file-disclosure

See RFC 3979 (BCP 79) for definitions of "IPR" and "contribution"
and for the detailed rules (substituting "IRTF" for "IETF").



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: SEARS - Search Engine Address Resolution Service (and Protocol)

[Masataka Ohta]

Todd Glassey wrote:

> So SEARS is a method of replacing the DNS roots with a well-known
> service portal providing a Google or other SE based access model.  The
> session can interface with traditional HTTP or DNS-Lookup Ports to
> deliver content or addresses to a browser in the form of a HTTP redirection.

It's no different from plain search engine with "I'm feeling
lucky" turned on.

> The protocol specification is almost done and is intended to make
> threats of attacks against the DNS roots less of an issue.

I heard that Anonymous is planning to attack root servers.

Is it google who hired them to promote SEARS. :-)

Anyway, root servers are (or will be) anycast with a lot less
centralized management than google servers that they are more
resistant against attacks.

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

Re: Variable length internet addresses in TCP/IP: history

[Masataka Ohta]

Steven Bellovin wrote:

>> Thus, IPv6 was mortally wounded from the beginning.
> 
> The history is vastly more complex than that.  However, this particular 
> decision
> was just about the last one the IPng directorate made before reporting back to
> the IETF -- virtually everything else in the basic IPv6 design had already
> been agreed-to.

I understand that, unlike 64 bit, 128 bit enables MAC based
SLAAC with full of states, which is as fatal as addresses
with 32 hexadecimal characters.

> I don't think this was "the" wrong decision.

Isn't it obvious that, with a lot more than 1% penetration of the
Internet to the world today, we don't need address length much more
than 32 bits?

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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Joel M. Halpern]

If I may separate issues for a moment,
the absence of milestones is because Terry and I have to come up with a 
proposal for them which matche sthe revised goals.


If you read the rest of the differences, you will see that the general 
question of what LISP is aimed at providing is indeed still there.


The largest single difference is the addition of the architecture draft, 
which the IESG considers a gating item for any of the longer term work 
(such as the security solutions or the additional mapping system.


Some of the apparent removal is because, as Jari stated, the IESG has 
requested that the working group focus on fewer deliverables.


Yours,
Joel

On 2/16/2012 12:00 PM, John Scudder wrote:

Hi Thomas,

On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote:


A WG Review message for this WG already went out a month ago.

What has changed to necessitate another Last Call?

Could the-powers-that-be please make it easier for those who might
care to understand if there is something here that we should know and
possibly comment about?

A simple explanation, or a pointer to diffs, etc. would do the job
nicely.


Good question! I did go back and diff the last couple of versions and though 
this isn't the exhaustive diff, these are the key changes that caught my eye:

This text was lost from the previous draft charter:

This analysis will explain what
role LISP can play in scalable routing. The analysis should also look at
scalability and levels of state required for encapsulation,
decapsulation, liveness, and so on as well as the manageability and
operability of LISP. Specifically, the group will work on:

- documenting areas that need experimentation
- summarizing the results of implementation, experiments, and deployment
   experience
- describing the implications of employing LISP
- operational guidance for using LISP

And so were these Goals and Milestones:

Jun 2012Forward to the IESG an operational document which should
include cache management and ETR synchronization
techniques (draft-ietf-lisp-deployment).

Dec 2013Publish an example cache management specification.

Jun 2014Summarize results of specifying, implementing, and testing
LISP and forward to IESG and/or IRTF.

Jun 2014Analyze and document the implications of LISP deployments in
Internet topologies and forward to IESG for publication.

I'm not sure why these were removed, and I would like to see them reinstated or 
at least have a discussion about their removal.

Thanks,

--John

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

Re: Variable length internet addresses in TCP/IP: history

[Steven Bellovin]

On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote:

> Steven Bellovin wrote:
> 
>>> Thus, IPv6 was mortally wounded from the beginning.
>> 
>> The history is vastly more complex than that.  However, this particular 
>> decision
>> was just about the last one the IPng directorate made before reporting back 
>> to
>> the IETF -- virtually everything else in the basic IPv6 design had already
>> been agreed-to.
> 
> I understand that, unlike 64 bit, 128 bit enables MAC based
> SLAAC with full of states, which is as fatal as addresses
> with 32 hexadecimal characters.

That decision came later.  In fact, the deficiencies of relying on MACs were
discussed quite frequently in the directorate.
> 
>> I don't think this was "the" wrong decision.
> 
> Isn't it obvious that, with a lot more than 1% penetration of the
> Internet to the world today, we don't need address length much more
> than 32 bits?

No.  I did and I do think that 64 bits was inadequate.

Why?  Apart from the fact that if this transition is painful, the next
one will be well-nigh impossible, having more bits lets us find creative
ways to use the address space.  Stateless autoconfig is one example,
though I realize it's controversial.  ID/locator split, which I've been
a proponent of for very many years, works a lot better with more bits,
because it allows topological addressing both within and outside an
organization.


--Steve Bellovin, https://www.cs.columbia.edu/~smb





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

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 227 messages in the last 7 days.
 
script run at: Fri Feb 17 00:53:02 EST 2012
 
Messages   |  Bytes| Who
+--++--+
  7.49% |   17 |  5.04% |94840 | j...@mercury.lcs.mit.edu
  7.05% |   16 |  4.74% |89192 | mo...@necom830.hpcl.titech.ac.jp
  5.73% |   13 |  5.01% |94286 | do...@dougbarton.us
  3.08% |7 |  6.99% |   131545 | ra...@psg.com
  3.96% |9 |  3.35% |63069 | mansa...@besserwisser.org
  3.96% |9 |  3.23% |60665 | brian.e.carpen...@gmail.com
  3.08% |7 |  3.07% |57656 | cgrundem...@gmail.com
  2.64% |6 |  3.04% |57137 | presn...@qualcomm.com
  3.08% |7 |  2.60% |48838 | d...@dcrocker.net
  3.08% |7 |  2.29% |43115 | m...@sap.com
  2.64% |6 |  2.65% |49796 | s...@resistor.net
  2.64% |6 |  2.52% |47425 | ma...@isc.org
  2.64% |6 |  2.49% |46889 | john-i...@jck.com
  2.64% |6 |  2.22% |41802 | rog...@gmail.com
  2.20% |5 |  2.52% |47443 | mar...@millnert.se
  1.76% |4 |  2.21% |41620 | b...@nostrum.com
  1.32% |3 |  2.43% |45792 | s...@harvard.edu
  1.76% |4 |  1.58% |29728 | y...@checkpoint.com
  1.76% |4 |  1.55% |29083 | d...@virtualized.org
  1.76% |4 |  1.49% |27990 | s...@cs.columbia.edu
  0.88% |2 |  2.26% |42482 | matthew.bo...@alcatel-lucent.com
  1.32% |3 |  1.64% |30892 | ted.le...@nominum.com
  1.32% |3 |  1.61% |30321 | cb.li...@gmail.com
  1.32% |3 |  1.23% |23046 | adr...@olddog.co.uk
  1.32% |3 |  1.14% |21411 | nar...@us.ibm.com
  1.32% |3 |  1.06% |19853 | n...@inex.ie
  1.32% |3 |  1.02% |19227 | lsaw...@gci.com
  1.32% |3 |  0.93% |17492 | ned+i...@mauve.mrochek.com
  0.88% |2 |  1.36% |25618 | to...@isi.edu
  0.88% |2 |  1.24% |23419 | rcal...@juniper.net
  0.88% |2 |  1.24% |23394 | o...@delong.com
  0.88% |2 |  1.24% |23361 | roberta.magli...@telecomitalia.it
  0.44% |1 |  1.68% |31609 | stbry...@cisco.com
  0.88% |2 |  0.86% |16132 | c...@tzi.org
  0.88% |2 |  0.85% |15910 | j...@joelhalpern.com
  0.88% |2 |  0.81% |15241 | tglas...@earthlink.net
  0.88% |2 |  0.78% |14663 | victor.kuarsi...@gmail.com
  0.44% |1 |  1.21% |22716 | gregory.mir...@ericsson.com
  0.88% |2 |  0.76% |14386 | joe...@bogus.com
  0.88% |2 |  0.75% |14098 | st...@shinkuro.com
  0.88% |2 |  0.70% |13233 | j...@juniper.net
  0.44% |1 |  1.03% |19345 | s...@sobco.com
  0.44% |1 |  0.78% |14652 | jason_living...@cable.comcast.com
  0.44% |1 |  0.77% |14430 | l...@netapp.com
  0.44% |1 |  0.66% |12403 | d.stu...@att.net
  0.44% |1 |  0.60% |11291 | step...@sprunk.org
  0.44% |1 |  0.58% |10948 | wesley.geo...@twcable.com
  0.44% |1 |  0.52% | 9869 | sant9...@gmail.com
  0.44% |1 |  0.52% | 9867 | tnad...@lucidvision.com
  0.44% |1 |  0.51% | 9604 | rdroms.i...@gmail.com
  0.44% |1 |  0.41% | 7791 | sagriff...@gci.com
  0.44% |1 |  0.40% | 7540 | gda...@au.logicalis.com
  0.44% |1 |  0.39% | 7426 | c.don...@cablelabs.com
  0.44% |1 |  0.39% | 7281 | bch...@ncta.com
  0.44% |1 |  0.38% | 7082 | d3e...@gmail.com
  0.44% |1 |  0.37% | 6994 | bob.hin...@gmail.com
  0.44% |1 |  0.37% | 6988 | hans.thienpo...@staff.telenet.be
  0.44% |1 |  0.37% | 6892 | j...@apple.com
  0.44% |1 |  0.36% | 6749 | o...@cisco.com
  0.44% |1 |  0.36% | 6740 | bra...@isi.edu
  0.44% |1 |  0.35% | 6608 | akat...@gmail.com
  0.44% |1 |  0.35% | 6569 | melinda.sh...@gmail.com
  0.44% |1 |  0.35% | 6510 | morrowc.li...@gmail.com
  0.44% |1 |  0.34% | 6449 | arturo.ser...@gmail.com
  0.44% |1 |  0.34% | 6304 | dwor...@avaya.com
  0.44% |1 |  0.33% | 6263 | amor...@amsl.com
  0.44% |1 |  0.33% | 6250 | wbee...@cisco.com
  0.44% |1 |  0.33% | 6153 | nomcom-ch...@ietf.org
  0.44% |1 |  0.32% | 6072 | kirk.erich...@twcable.com
  0.44% |1 |  0.32% | 6014 | tglas...@certichron.com
  0.44% |1 |  0.31% | 5756 | daryl.tan...@blueyonder.co.uk
  0.44% |1 |  0.30% | 5684 | rbar...@bbn.com
  0.44% |1 |  0.30% | 5658 | wch.i...@gmail.com
  0.44% |1 |  0.29% | 5494 | lea.robe...@stanford.edu
  0.44% |1 |  0.26% | 4970 | jeff.finkelst...@cox.com
+--++--+
100.00% |  227 |100.00% |  1881061 | Total

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

Re: IETF Last Calls and Godwin-like rules

[Randy Bush]

> It's a quintessential bike-shed problem.  The only reason that people are
> moaning about it so much is that they understand the concept of address
> allocation.

exactly.  they understand the concept.  and, like many things where the
surface seems easy, everyone thinks they're an expert.

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