In addition, RFC 5014 (IPv6 Socket API for source address selection) would be
useful to include into the next POSIX revision. This document allows
applications to choose a source address when default source address selection
is in place at the IP stack.
Thanks,
-Samita
-Original Message--
But the original destroyed signature from the author is not stripped.
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=fail policy=all author.d=isdg.net asl.d=ietf.org (unauthorized
signer);
dkim=fail (DKIM_SIGNATURE_BAD) header.d=
Hello,
I am not an expert in the questions of 6to4, but unless there are strong
arguments claiming that this technology is not used any more,
reclassification isn't appropriate. Discouraging implementation/use of
the protocol is not a purpose of Historic, it is to mark what already
no-one us
Cool beans. Message as verified here. The good thing is that it
finally resolved the corruption of distributed original signed mail on
the ietf list server with its extra line at the top!
Glen wrote:
All -
I am very pleased to report that the IETF is now applying DKIM signatures
to all outg
26.07.2011 1:05, Noel Chiappa wrote:
> From: Ronald Bonica
> While it clarifies the meaning of "HISTORIC" in this particular case, it
> does not set a precedent for any future case.
In other words, this document is doing something with "HISTORIC" that isn't the
normal, this is
Could the IESG please negotiate with Opengroup to get the IPv6
Advanced Socket API included into the next POSIX revision.
RFC 2133 "Basic Socket Interface Extensions for IPv6" (now RFC 2553)
and RFC 2292 "IPv6 Advanced Socket API" (now RFC 3542) were designed
to work together as a single API. PO
Hi -
> From: "Noel Chiappa"
> To:
> Cc:
> Sent: Monday, July 25, 2011 3:05 PM
> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
...
> I think we should only mark things as HISTORIC as a recognition of _what has
> already happened_ out in the world, not as an attempt to _make somethin
Brian,
> Brian E Carpenter wrote:
> To be clear, I'd like to see exact proposed text before
> expressing support for the proposal. The trick is to get
> 6to4 disabled by default at the user end, without disabling
> it for users who are getting good service from it.
Although I commend Ron from try
To be clear, I'd like to see exact proposed text before expressing
support for the proposal. The trick is to get 6to4 disabled by default
at the user end, without disabling it for users who are getting good
service from it.
Regards
Brian
On 2011-07-26 09:49, Brian E Carpenter wrote:
>> Likewi
On Mon, Jul 25, 2011 at 06:05:12PM -0400, Noel Chiappa wrote:
> > From: Ronald Bonica
>
> > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> > convert their status to HISTORIC.
>
> I think we should only mark things as HISTORIC as a recognition of _what has
>
I approve of this approach.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
In message
<22f6318e46e26b498abc828879b08d4f1d2...@tk5ex14mbxw651.wingroup.windeploy.ntdev.microsoft.com>,
Christian Huitema writes
:
> > 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
> 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 will obsolete RFCs 3
Willy Tarreau wrote:
> What are you saying ? Your browser embeds the resolved as a library, so when
> I'm saying that "the browser has to retry", I mean the resolver part of the
> browser has to retry.
You should mean that the browser can control behavior of the
resolver.
If the resolver in the
Ronald Bonica wrote:
>
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC. It will also contain a new section
> describing what it means for RFCs 3056 and 3068 to be classified
> as HISTORIC.
I'm strongly opposed. Discussion is in the arch
In message <20110725045821.gn22...@1wt.eu>, Willy Tarreau writes:
> On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote:
> > [I haven't been following hybi and haven't read the draft, but as
> > this is posted to the ietf list and there are a bunch of assertions
> > here about the DNS I c
Ronald Bonica wrote:
>
> 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
Clearly, this is an honest ef
> From: Ronald Bonica
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC.
I think we should only mark things as HISTORIC as a recognition of _what has
already happened_ out in the world, not as an attempt to _make something
ha
> Likewise, operators will decide whether/when 6-to-4 relays will be removed
> from their networks.
This is, of course, an undeniable statement of fact (as it is for any other
feature
of the Internet). However, it needs to be made clear that doing so *prematurely*
would penalise existing succes
Greetings,
For those interested in the MILE side meeting, it will take place right after
the plenary, 19:30, in room 301A.
Best regards,
Brian
Begin forwarded message:
> From:
> Date: July 25, 2011 12:03:01 PM EDT
> To: , , ,
>
> Subject: RE: [mile] MILE side meeting, IETF81 in Quebec, Mon
If you are participating in IETF 81 from outside of Quebec City, this
is a reminder that Meetecho is providing remote participation support
for both the technical and administrative plenaries. You can find more
information online at http://www.ietf.org/meeting/81/remote-participation.html
> Ronald Bonica wrote:
> 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
Opposed. I will pass on details, as I
I'm in favor of the proposed action and the clarification of historic,
suggested in the new section.
(I could be in _strong_ favour to nullify Keith's 'vote', although I hope we're
not counting. ;-)), .
cheers,
Ole
On Jul 25, 2011, at 10:30 , Ronald Bonica wrote:
> Folks,
>
> After some discu
> "Keith" == Keith Moore writes:
Keith> I remain strongly opposed to reclassifying 6to4 as Historic
Keith> unless/until a better alternative appears. Putting an
Keith> explanation inside an informational document doesn't change
Keith> that opposition.
+1
I note that multicas
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:
Cool! Thanks.
d/
--
Dave Crocker
All -
I am very pleased to report that the IETF is now applying DKIM signatures
to all outgoing list email from mailman.
Many thanks to Murray Kucherawy, lead author of OpenDKIM, for doing the work
to set up OpenDKIM on the IETF servers and getting it to work. He made the
process painless, and w
I remain strongly opposed to reclassifying 6to4 as Historic unless/until a
better alternative appears. Putting an explanation inside an informational
document doesn't change that opposition.
I also continue to believe that the -historic draft has too many misstatements
and misleading statement
Folks,
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 will obsolete RFCs 3056
On Mon, Jul 25, 2011 at 11:12:46AM +1000, Mark Andrews wrote:
> > > But, do current webbrosers resolve names using anything but DNS A?
> > > (well, I know that they use /etc/hosts). Anyhow, WINS / NIS /etc/hosts
> > > and such stuff just maps a hostname into a single IP. It's the
> > > equivalent o
On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote:
> [I haven't been following hybi and haven't read the draft, but as this is
> posted to the ietf list and there are a bunch of assertions here about the
> DNS I consider ... odd, I thought I'd chime in]
>
> On Jul 24, 2011, at 8:59 AM
On Mon, Jul 25, 2011 at 02:50:37PM +1000, Mark Andrews wrote:
>
> In message <20110725042921.gj22...@1wt.eu>, Willy Tarreau writes:
> > On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote:
> > > Adding a SRV lookup should add 0ms if it isn't there as you should be
> > > making A, and
On Mon, Jul 25, 2011 at 10:46:58AM +1000, Mark Andrews wrote:
> Adding a SRV lookup should add 0ms if it isn't there as you should be
> making A, and SRV lookups in parallel.
This does not work for a simple reason : you have to perform the lookups
on the SRV response just as you would do with
On Sun, Jul 24, 2011 at 8:46 PM, Mark Andrews wrote:
> Adding a SRV lookup should add 0ms if it isn't there as you should be
> making A, and SRV lookups in parallel. Non-existance is as
> cachable as existance is.
>
But you have to wait until the SRV returns even if the A/ response com
On 25 July 2011 05:11, Richard L. Barnes wrote:
> It seems like this gets you around the threat that masking is supposed to
> address -- the proxy won't see anything mid-stream that looks like HTTP,
> since it's just acting as a tunnel at that point. It's a little weird to use
> CONNECT end-to
Dear IETFers,
There was one case on the nomination process where we did not receive
a submitted nomination.
Therefore, we decided to extend nomination time until July 31st.
If you have not received confirmation for the past nomination, please
resubmit it (until you get confirmation!) please!
Th
35 matches
Mail list logo
