On Jul 28, 2011, at 1:30 AM, james woodyatt wrote:
> I think the measurements we've all seen at the technical plenary show that
> 6to4 is a small percentage of the total world IPv6 traffic now, which again
> is an embarrassingly small fraction of global Internet traffic.
What I saw from differ
Hi Alexa,
At 04:51 PM 7/27/2011, Alexa Morris wrote:
First, I want to reassure you that there is no plan to discontinue the
regular audio streaming at meetings; indeed, there was every intention
Thanks.
Sorry for any inconvenience. Please also understand that the Meetecho
staff intended to pr
James,
If I remember correctly, you mentioned a bit ago that your job required
you had native IPv6 at home.
Question: Does an ISP providing you IPv6 out of the CPE box (meaning,
without any software other than dual-stack on the hosts) qualify as
native IPv6 if, behind the scenes, they use a tunn
Unfortunately Dan cannot accept that there may be objective, non
political reasons for the group not to adopt his work. Which is the
reason why three alternative proposals were published several months
after his proposed PAKE solution.
As co-chairmen of ipsecme, Paul and I did our best to get
On Jul 27, 2011, at 11:12 PM, Michel Py wrote:
>
> According to this:
> http://www.pam2010.ethz.ch/papers/full-length/15.pdf
> Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig
> 3); about 90% MacOS hits is 6to4, which possibly means (to me) that this
> piece of 6to4 MacOS soft
Hello,
The new version is obviously shorter, but it omits some points. With
eliminating of DS level, RFC 5657 makes no sense more. It should be
obsoleted and moved to Historic by your document, if IESG decides to
eliminate the requirement for interoperability documentation, which I am
oppos
Paul,
The existence of this draft shows a failure of YOUR leadership (and
that of your co-chairman) of the working group. Consensus was achieved
to add an authentication method based on a simple password yet you
seemingly worked to do everything possible to create division in the
working grou
To be fair - I don't think anyone is saying "We should totally encourage
6to4!", even in the short-term ... or any other auto-tunneling transition
mechanism, really.
In fact, I think the debate here largely stems from a valid desire to
discourage 6to4.
Note: That goal, I am in favor of (recommendi
>From an operators point of view, specifically one that has deployed 6to4
relays, use of the same should not be encouraged.
I fully hope and expect the use of 6to4 to systematically decrease over
time so the associated infrastructure can be decommissioned.
While we have seen issues related to 6to
Likewise...
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Thursday, July 28, 2011 9:25 AM
To: Brian E Carpenter
Cc: IETF discussion list
Subject: Re: Why the IESG needs to review everything...
I believe we agree.
On Ju
At dinner today it was suggested that the right course of action is:
leave rfc3056 (6to4) as it is.
mark rfc3068-only (anycast) as historic.
It is the availability of anycast that permits 6to4 to be on by default.
Turn off the anycast, and now 6to4 is simply a useful tool for people
who kno
In message <201107272350.p6rnodka019...@fs4113.wdf.sap.corp>, Martin Rex writes
:
> Mark Andrews wrote:
> >
> > Dave Cridland writes:
> > >
> > > Happy eyeballs - try everything as soon as you can, in parallel. Drop
> > > everything else when one does.
> >
> > More correctly it is try the fir
On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:
>
> So I think it would be quite weird to keep 6to4 at standards track just to
> prevent some vendors from dropping 6to4 support.
As one of those implementers-- as in, it will probably be *my* commit to the
repository that does "rm $XNU/bsd/ne
On 2011-07-28 09:46, Jari Arkko wrote:
> After extensive discussion on this list and in the IESG Russ has decided
> to make a reduced proposal. I am now initiating a new Last Call to gauge
> consensus on the new version.
Thankyou. I fully support this version.
Brian Carpenter
_
Brian E Carpenter wrote:
>
> And certainly the Meetecho service has its value - although those of us
> on the end of a very long, thin glass fibre in the South Pacific may
> not be able to get the full benefit.
Admittedly there was an improvement to previous IETFs.
Running Meetecho in a virtual
I believe we agree.
On Jul 27, 2011, at 9:13 PM, Brian E Carpenter wrote:
>> My suggestion: Talk to the Nomcom if you think that certain ADs treated you
>> in an unfair way.
>
> Absolutely agreed. The NomCom needs an overview of this.
___
Ietf mai
On 2011-07-28 12:51, Hannes Tschofenig wrote:
> So, you arguing that all DISCUSSes by ADs are indeed justified and necessary.
No. I said exactly the opposite: "Sometimes there are inappropriate DISCUSSes
and those need to be pointed out when they happen."
> It is great to hear that our leadership
Thanks Alexa!
And certainly the Meetecho service has its value - although those of us
on the end of a very long, thin glass fibre in the South Pacific may
not be able to get the full benefit.
Regards
Brian Carpenter
On 2011-07-28 11:51, Alexa Morris wrote:
> Brian, SM,
>
> First, I want to r
So, you arguing that all DISCUSSes by ADs are indeed justified and necessary.
It is great to hear that our leadership is completely unbiased with regard to
technology, does not follow their own (or a company) agenda, misjudge their
expertise in a certain area, showed long delays in responding, et
On 2011-07-28 10:34, Dave CROCKER wrote:
>
>> Firstly, not all ADs review all drafts - that's why you will see
>> numerous "no objection" or missing ballot responses.
>
> Brian,
>
> I've been repeatedly hearing from IESG folk for some year -- and seeing
> reports relating to Nomcom -- that, in
On 2011-07-28 11:13, Martin Rex wrote:
> Brian E Carpenter wrote:
>> Responding to Glen Zorn's question in plenary:
>>
>> Firstly, not all ADs review all drafts - that's why you will see
>> numerous "no objection" or missing ballot responses.
>
> I can understand the resource contention when readi
Dear all,
the full recording (synchronized video, audio, slides and jabber room)
of today's Operations and Administration Plenary is available at the following
URL:
http://www.meetecho.com/ietf81/recordings
In case of problems with the playout, just drop an e-mail to
ietf-supp...@meetecho.com
On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote:
> I think this is a terrible idea.
+.5. I think is is a bad idea.
> IKEv2 has a way for mutual authentication with a shared key.
>
> A concern was raised that this method was vulnerable to guessing if trivial
> shared keys were configured.
>
> T
Dear all,
as a representative of the Meetecho team, let me jump into this discussion.
First, about the quality of the audio stream. Our system provides two
different real-time (and when I say "real-time" I mean "real-time")
streams: the former is a standard VoIP (Asterisk-based) GSM stream; th
Brian, SM,
First, I want to reassure you that there is no plan to discontinue the
regular audio streaming at meetings; indeed, there was every intention
of providing regular audio streaming for IETF 81, in parallel with the
support provided by the Meetecho volunteers, but there was some
m
Mark Andrews wrote:
>
> Dave Cridland writes:
> >
> > Happy eyeballs - try everything as soon as you can, in parallel. Drop
> > everything else when one does.
>
> More correctly it is try the first address and if that doesn't
> connect in a short period (150...250ms) start a second connection
In message <4e305e3e.2040...@unfix.org>, Jeroen Massar writes:
> On 2011-07-27 20:21 , Keith Moore wrote:
> > On Jul 27, 2011, at 11:35 AM, Tim Chown wrote:
> >
> >> I suspect, but have no proof, that the huge majority of 6to4 users don't u
> se it intentionally, and the content they are trying t
After reading your text, let me share my experience:
I struggled hard to get a class C w/o NAT. As hard as that was it was
still easier than obtaining native IPv6. I wont struggle to get native
ipv6 too.
We use 6to4 on a frontend machine, and we use native IPv6 out of that
6to4 on several subn
Brian E Carpenter wrote:
>
> Responding to Glen Zorn's question in plenary:
>
> Firstly, not all ADs review all drafts - that's why you will see
> numerous "no objection" or missing ballot responses.
I can understand the resource contention when reading drafts
brought to the IESG. I would not e
In message <9031.1311786432.357811@puncture>, Dave Cridland writes:
> On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote:
> > On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
> > > > SRV provides load-balancing and failover. I never said that SRV
> > is a
> > > > solution for temporal
Hi,
> I don't know about the codecs, but there is a wireless hop. I'm getting
> frequent very short drops as well as slightly buzzy sound and less fidelity
> than the parallel session streaming. The voices of people I know well are
> harder to recognise.
one aspect to consider is that long play-o
Firstly, not all ADs review all drafts - that's why you will see
numerous "no objection" or missing ballot responses.
Brian,
I've been repeatedly hearing from IESG folk for some year -- and seeing reports
relating to Nomcom -- that, in fact, ADs are expected (and maybe required) to
read ev
I think this is a terrible idea.
IKEv2 has a way for mutual authentication with a shared key.
A concern was raised that this method was vulnerable to guessing if trivial
shared keys were configured.
There were several proposals for a better cryptographic method.
The IPsecME working group fail
Hi Alexa,
At 02:42 PM 7/27/2011, Brian E Carpenter wrote:
Writing from Auckland NZ, I wish to object to the fact that the regular
audio streaming is not avaialble for the plenaries. It's a signficant
inconvenience.
I would like to add my voice to Brian's objection. Can the usual
audio stream
> "Roger" == Roger Jørgensen writes:
>> We want normal users to move past "experimental IPv6" towards "production
>> IPv6".
Roger> Exactly, we should focus on doing production IPv6, not wasting our
Roger> time on something that run on top of something else, whatever
Roge
Responding to Glen Zorn's question in plenary:
Firstly, not all ADs review all drafts - that's why you will see
numerous "no objection" or missing ballot responses.
Secondly, the drafts are de facto reviewed by review teams
these days (gen-art, security area, etc.). This serves to alert
the ADs i
The second byte in an IPv4 header is called the Differentiated Services Field.
Quoting RFC 2474:
2. Terminology Used in This Document
...
Differentiated Services Field: the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in conformance with the
definition given in
Brian E Carpenter wrote:
>
> Writing from Auckland NZ, I wish to object to the fact that the regular
> audio streaming is not avaialble for the plenaries. It's a signficant
> inconvenience.
Full ACK.
Although there are rtsp-URLs available for the meetecho audio streams
(which you can only find a
On 2011-07-28 09:48, Gonzalo Camarillo wrote:
> Hi,
>
> per the discussion in the jabber room, one issue is that the rtsp, sip,
> and tel URIs were not available at the ietf page. They should be made
> available so that people can use them without accessing the meetecho web
> page if they want.
>
Hi,
per the discussion in the jabber room, one issue is that the rtsp, sip,
and tel URIs were not available at the ietf page. They should be made
available so that people can use them without accessing the meetecho web
page if they want.
With respect to the audio quality, I have not checked which
After extensive discussion on this list and in the IESG Russ has decided
to make a reduced proposal. I am now initiating a new Last Call to gauge
consensus on the new version. I believe this version is more focused,
narrower, and removes many of the parts that people had problems with in
the pr
Alexa,
Writing from Auckland NZ, I wish to object to the fact that the regular
audio streaming is not avaialble for the plenaries. It's a signficant
inconvenience.
Meetecho requires login and is picky about browser versions and Java versions,
forced me to blindly accept a security certificate, ta
Keith Moore wrote:
>> It means it's IPv6 which is damaging the Internet.
>
> Except that the (v4) Internet is already doing its best to damage
> itself. So the choice is between a thoroughly brain-damaged
> v4 Internet that is continually getting worse, and a somewhat
> less brain-damaged v6 In
Support, A+++, would by from again, etc.
On Jul 26, 2011, at 7:54 PM, Randy Bush wrote:
> i do not care what the draft is called.
> i do not care whether it is info, experimental, or an IEN
> i do care that is says 6to4 MUST be off by default
>
Arguing about the label feels like rearranging dec
If you are participating in IETF 81 from outside of Quebec City, this
is a reminder that Meetecho is providing remote participation support
for tonight's Administrative Plenary. Starting at 16:20, you can view
the plenary content here: http://www.meetecho.com/ietf81/adminplenary.
Regards,
A
Le 27/07/2011 21:25, Roger Jørgensen a écrit :
On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) wrote:
[ And that native dual-stack is a replacement for both. ]
We want normal users to move past "experimental IPv6" towards "production
IPv6".
Exactly, we should focus on doing production IPv6
On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) wrote:
> [ And that native dual-stack is a replacement for both. ]
> We want normal users to move past "experimental IPv6" towards "production
> IPv6".
Exactly, we should focus on doing production IPv6, not wasting our
time on something that run
On Jul 27, 2011, at 2:42 PM, Masataka Ohta wrote:
> Keith Moore wrote:
>
>>> I see clear evidence that 6to4 is damaging the Internet and although there
>>> are
>>> those who can use it without causing damage, I believe that the principle is
>>> 'First, do no harm'
>
>> I put the word "feature"
On Wed, Jul 27, 2011 at 14:18, Keith Moore wrote:
> So essentially, the argument that "6to4 damages the Internet", is
> tantamount to "having multiple addresses for hosts damages the Internet".
>
> *And this is an explicitly chosen architectural "feature" of IPv6.*
>
Having multiple addresses for
Thank you Keith for restating the problem.
> "Keith" == Keith Moore writes:
Keith> So essentially, the argument that "6to4 damages the
Keith> Internet", is tantamount to "having multiple addresses for
Keith> hosts damages the Internet".
+1
...
Keith> People who are entire
Keith Moore wrote:
>> I see clear evidence that 6to4 is damaging the Internet and although there
>> are
>> those who can use it without causing damage, I believe that the principle is
>> 'First, do no harm'
> I put the word "feature" in quotes because this can be a pain in the a**
It means it'
On Jul 27, 2011, at 11:12 AM, Erik Kline wrote:
> Moving 6to4 to historic does not in any way impact your ability to use
> it as you wish.
False. Moving 6to4 to Historic is inviting people to mount denial of service
attacks on things that actually work for people today. Moving 6to4 to Historic
On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:
> In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote:
>> In message <4e2f4491.30...@gmail.com>, Brian E Carpenter writes:
>>> Of course, if implementors choose to drop the code you might not be
>>> able to upgrade software versions - b
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Hannes Tschofenig
> Sent: Wednesday, July 27, 2011 1:52 PM
> To: ietf@ietf.org IETF
> Subject: RFC 6302: "Internet-Facing Server Logging": No Word about
> Privacy?
>
> Hi all,
>
> I just notic
On Jul 27, 2011, at 11:35 AM, Tim Chown wrote:
> I suspect, but have no proof, that the huge majority of 6to4 users don't use
> it intentionally, and the content they are trying to reach is also available
> over IPv4. But for people who want to develop and use new IPv6-specific apps,
> then eit
On Jul 27, 2011, at 3:32 AM, t.petch wrote:
> I oppose this action.
>
> I see clear evidence that 6to4 is damaging the Internet and although there are
> those who can use it without causing damage, I believe that the principle is
> 'First, do no harm'
> so the IETF has a responsibility to discour
Hi all,
I just noticed this document about "Internet-Facing Server Logging":
http://tools.ietf.org/html/rfc6302
It does not contain any privacy considerations even thought it would be a very
natural thing to do.
Does anyone know the history of this document?
Ciao
Hannes
___
On 27 Jul 2011, at 17:03, Mark Andrews wrote:
> 0d20eb6-78c9-415d-9493-3aa08faac...@ecs.soton.ac.uk>, Tim Chown writes:
>>
>> a) use 6to4 anyway on an open platform like OpenWRT
>
> Which may or may not still have the code. OpenWRT could remove
> support just the same as another source could.
On Jul 27, 2011, at 7:31 AM, Mark Townsley wrote:
>
> On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
>
>>
>> On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
>>
>>> Since 6to4 is a transition mechanism it has no long term future *by
>>> definition*. Even if someone chooses to design
On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote:
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
> > SRV provides load-balancing and failover. I never said that SRV
is a
> > solution for temporaly put in maintenance a server.
>
> Happy eyeballs however does allow you to take a s
On 7/23/2011 3:13 AM, Mykyta Yevstifeyev wrote:
Hello,
The new registry says:
System Ports are assigned by IETF
process for standards-track protocols, as per [RFC1340]. User Ports
are assigned by IANA using the "Expert Review" process, as per
[RFC5226]. Dynamic Ports are not assign
In message
, Cameron Byrne writes:
> On Jul 27, 2011 8:16 AM, "Mark Andrews" wrote:
> >
> >
> > In message <968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com>, Ted Lemon
> writes
> > :
> > > If you have a reason to install and enable 6to4, why would the nominal
> > > status of a couple of RFCs ma
On 7/27/11 4:31 AM, Mark Townsley wrote:
On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
Since 6to4 is a transition mechanism it has no long term future *by
definition*. Even if someone chooses to design a v2, who is going to implement
it?
> From: Philip Homburg
> I think it would be quite weird to keep 6to4 at standards track just to
> prevent some vendors from dropping 6to4 support.
There have been suggestions that it might be more appropriate to reclassify
it as Experimental, and I think that makes a lot of sense -
In message , Tim Chown writes:
>
> On 27 Jul 2011, at 16:15, Mark Andrews wrote:
> >
> > Because it will come down to "run 6to4 and be exposed to some bug"
> > or "not run 6to4 but be safe from the bug". We already have vendors
> > saying they are thinking about pulling 6to4 from their code bas
On Wed, Jul 27, 2011 at 05:19:30PM +0200, Iñaki Baz Castillo wrote:
> Well, I understand (and agree) most of your text, but I still think
> that the URI resolution mechanism is something transparent for an
> end-user. This is not like having FlashPlayer for showing annoying and
> dancing menus in a
2011/7/27 Willy Tarreau :
>> I don't think home users (neither professional users) has nothing to
>> decide here, they will not "resolve" the WS URI retrieved from a
>> webpage.
>
> I think you're wrong. Those are these users which ask for feature XXX or
> YYY that they like because it brings them
Moving 6to4 to historic does not in any way impact your ability to use
it as you wish.
6to4 support is not part of the IPv6 node requirements, as I
understand it. Therefore I believe that any vendor (OS, router,
otherwise) could deleted 6to4 support in any release and be in
violation of anything,
If you have a reason to install and enable 6to4, why would the nominal
status of a couple of RFCs make you do anything different?
This seems like an easy question to answer. You'd implement and use 6to4v2
because it works better than the historic 6to4 protocol.
On Wed, Jul 27, 2011 at 03:45:38PM +0200, Iñaki Baz Castillo wrote:
> 2011/7/27 Willy Tarreau :
> > Once again, the goal to make SRV adopted BY USERS is not to ensure that
> > it tries to cover all the server-side needs, but that it offers better
> > quality of service to USERS. That way USERS will
2011/7/27 Willy Tarreau :
> Once again, the goal to make SRV adopted BY USERS is not to ensure that
> it tries to cover all the server-side needs, but that it offers better
> quality of service to USERS. That way USERS will massively adopt it and
> server will one day be able to safely rely on it.
Hi,
On 27 July 2011 22:15, Keith Moore wrote:
>
> On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
>
> >
> > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
> >
> >> Since 6to4 is a transition mechanism it has no long term future *by
> definition*. Even if someone chooses to design a v2, who
On Wed, Jul 27, 2011 at 12:46:28PM +0200, Iñaki Baz Castillo wrote:
> Hi Willy, as I've explained several times in these threads, if a WS
> client is not mandated to perform SRV given a WS URI domain, then the
> service provider cannot rely on SRV records. This is, let's assume
> that a WS service
On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
>
> On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
>
>> Since 6to4 is a transition mechanism it has no long term future *by
>> definition*. Even if someone chooses to design a v2, who is going to
>> implement it?
>
> Actually, I think one
2011/7/27 Willy Tarreau :
> That's where I think you're mistaken. As long as you think of it as mandatory
> this will not be possible.
Hi Willy, as I've explained several times in these threads, if a WS
client is not mandated to perform SRV given a WS URI domain, then the
service provider cannot r
On Wed, Jul 27, 2011 at 11:43:58AM +0200, Iñaki Baz Castillo wrote:
> 2011/7/26 Willy Tarreau :
> > if you want to have any chance of making SRV *usable* with WS (or
> > HTTP), you have to motivate both sides by showing them that :
> > - it's better for them to use it than not to use it (both serv
2011/7/26 Willy Tarreau :
> if you want to have any chance of making SRV *usable* with WS (or
> HTTP), you have to motivate both sides by showing them that :
> - it's better for them to use it than not to use it (both servers and
> browsers)
> - the additional cost of using it is negligible
>
In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote:
>In message <4e2f4491.30...@gmail.com>, Brian E Carpenter writes:
>> Of course, if implementors choose to drop the code you might not be
>> able to upgrade software versions - but hopefully by that time you
>> will have native IPv6 ser
* Ronald Bonica
> After some discussion, the IESG is attempting to determine whether there is
> IETF consensus to do the following:
>
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>
> draft-ietf-v6ops-6to4-to-historic w
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
> > SRV provides load-balancing and failover. I never said that SRV is a
> > solution for temporaly put in maintenance a server.
>
> Happy eyeballs however does allow you to take a server out of production
> and not really notice it. N
Hi Folks,
All of the Voting Members chosen by the random selection have been
contacted and have confirmed their willingness and ability to serve on the
2011-2012 Nomcom. There have been no challenges to the selection of the
voting Members of this Nomcom and the challenge deadline has now passed.
Hi Iñaki,
On Tue, Jul 26, 2011 at 11:58:41AM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau :
> > To ensure nobody gets me wrong, I'm certain this can help solve issues
> > *if this is optional*. If it becomes a MUST, then the negative effects
> > will override the positive ones. In my
Hi Stephen,
The example given below illustrates also what I'm thinking. And please forgive
me if I miss something below.
IMHO, what you are saying about the SIP-Resource-Priority is true for any other
QoS parameters carried over the Diameter QoS application. It is therefore why
I'm assuming th
On 27 Jul 2011, at 16:15, Mark Andrews wrote:
>
> Because it will come down to "run 6to4 and be exposed to some bug"
> or "not run 6to4 but be safe from the bug". We already have vendors
> saying they are thinking about pulling 6to4 from their code bases
> if it becomes historic.
I would note t
On Jul 27, 2011 8:30 AM, "Michel Py"
wrote:
>
> >>> Brian E Carpenter wrote:
> >>> Since 6to4 is a transition mechanism it has no long
> >>> term future *by definition*. Even if someone chooses
> >>> to design a v2, who is going to implement it?
>
> free.fr, which is a third of the worldwide IPv6
>>> Brian E Carpenter wrote:
>>> Since 6to4 is a transition mechanism it has no long
>>> term future *by definition*. Even if someone chooses
>>> to design a v2, who is going to implement it?
free.fr, which is a third of the worldwide IPv6 traffic.
>> Fred Baker wrote:
>> Actually, I think one c
On Jul 27, 2011, at 10:37 AM, Cameron Byrne wrote:
>
> On Jul 27, 2011 7:20 AM, "Ted Lemon" wrote:
> >>>
> >>> If you have a reason to install and enable 6to4, why would the nominal
> >>>
> >>> status of a couple of RFCs make you do anything different?
> >
> >
> > This seems like an easy questi
On Jul 27, 2011 8:16 AM, "Mark Andrews" wrote:
>
>
> In message <968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com>, Ted Lemon
writes
> :
> > If you have a reason to install and enable 6to4, why would the nominal
> > status of a couple of RFCs make you do anything different?
>
> Because it will com
In message <968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com>, Ted Lemon writes
:
> If you have a reason to install and enable 6to4, why would the nominal
> status of a couple of RFCs make you do anything different?
Because it will come down to "run 6to4 and be exposed to some bug"
or "not run 6t
In message
, Cameron Byrne writes:
>
> On Jul 27, 2011 4:32 AM, "Mark Townsley" wrote:
> >
> >
> > On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
> >
> > >
> > > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
> > >
> > >> Since 6to4 is a transition mechanism it has no long term future *b
On Jul 27, 2011 7:20 AM, "Ted Lemon" wrote:
>>>
>>> If you have a reason to install and enable 6to4, why would the nominal
>>>
>>> status of a couple of RFCs make you do anything different?
>
>
> This seems like an easy question to answer. You'd implement and use
6to4v2 because it works better t
On 27/07/2011 16:22, Peter Saint-Andre wrote:
> Dear Presenters,
>
> Please include slide numbers in your presentations. This makes life much
> easier for remote participants and jabber scribes.
And also when you are presenting, please say on which slide you are.
Henk
--
On Jul 27, 2011 4:32 AM, "Mark Townsley" wrote:
>
>
> On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
>
> >
> > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
> >
> >> Since 6to4 is a transition mechanism it has no long term future *by
definition*. Even if someone chooses to design a v2, who
I have considered the issues I had facing 6to4 deprecation, and in the light of
what you propose here, and other discussions, I support this course of action.
-George
On 25/07/2011, at 10:30 AM, Ronald Bonica wrote:
> Folks,
>
> After some discussion, the IESG is attempting to determine whethe
Dear Presenters,
Please include slide numbers in your presentations. This makes life much
easier for remote participants and jabber scribes.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf
On 7/27/2011 4:46 AM, Stephane Bortzmeyer wrote:
I am very pleased to report that the IETF is now applying DKIM signatures
to all outgoing list email from mailman.
What about a RFC 5617 published signing practice?
ADSP only works when the domain in the From: field is the same as the signer
On Jul 27, 2011, at 9:07 AM, John Mann (ITS) wrote:
>
> > Actually, I think one could argue pretty effectively that 6rd is 6to4-bis.
>
> only if you're confused about the use cases for each.
>
> In my opinion:
>
> 6to4 use case
> - D.I.Y setup - no ISP involvement
> - depend upon kindness of
>> I am very pleased to report that the IETF is now applying DKIM signatures
>> to all outgoing list email from mailman.
>
>What about a RFC 5617 published signing practice?
That RFC is only useful for a narrow range of heavily phished domains
like Paypal's. Fabulous though the IETF is, it's not
On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
>
> On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
>
>> Since 6to4 is a transition mechanism it has no long term future *by
>> definition*. Even if someone chooses to design a v2, who is going to
>> implement it?
>
> Actually, I think one
On 7/25/11 2:01 PM, Dave CROCKER wrote:
On 7/25/2011 1:17 PM, Glen wrote:
I am very pleased to report that the IETF is now applying DKIM signatures
to all outgoing list email from mailman.
I'll be presumptuous and speak on behalf of the DKIM operations
community, rather than just myself:
C
1 - 100 of 108 matches
Mail list logo
