Brian,
What you're apparently missing is that the client is using the zoneid to choose
a network interface to route packets to that link local address. If the server
returns a uri in its response that uses the same link local address but without
the client's zoneid, then the client will be
See my previous response.
Sent from my iPad
On 2013-05-23, at 1:27 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
Again, completely wrong for the same reason that Erratum 3630 is wrong.
Regards
Brian Carpenter
On 23/05/2013 15:59, RFC Errata System wrote:
The following
On Thu, 23 May 2013, Michael Sweet wrote:
Brian,
What you're apparently missing is that the client is using the zoneid to
choose a network interface to route packets to that link local address.
If the server returns a uri in its response that uses the same link
local address but without the
Michael, you are asking that the consensus of the WG be reversed. The errata
process is not the way to handle this. You have to go through the motions:
write a draft, submit it, get consensus...
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : Updates to the IPv6 Multicast Addressing Architecture
Author(s) : Mohamed Boucadair
Dear all,
We prepared a new version which lists the changes to be added to RFC 3956, RFC
3306 and RFC 4607:
http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-01
We are interested to hear your feedback on the proposed changes and also on the
better approach to actually do
I happen to agree that a change like this would be a good change, but I also
agree that it needs to be done as a consensus document, not as an erratum.
This is true not only for process reasons, but because I think the change as
proposed was too broad. Is there a working group alive where
Mikael,
On 2013-05-23, at 2:26 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Thu, 23 May 2013, Michael Sweet wrote:
Brian,
What you're apparently missing is that the client is using the zoneid to
choose a network interface to route packets to that link local address. If
the server
On 5/23/13 9:42 AM, Ted Lemon wrote:
I happen to agree that a change like this would be a good change, but I also
agree that it needs to be done as a consensus document, not as an erratum.
This is true not only for process reasons, but because I think the change as
proposed was too broad.
The following errata report has been submitted for RFC6874,
Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource
Identifiers.
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6874eid=3632
Michael,
I rejected the errata since they were both changing the consensus
of a WG. That level of change is not how the errata system is to be
used. Your approach of writing a new draft proposing these changes is
the correct approach to changing that consensus.
Regards,
Brian
On
The following errata report has been submitted for RFC6874,
Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource
Identifiers.
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6874eid=3633
Michael,
Let me repeat myself... This is not how the errata report system
is to be used. It is *not* a notification system for future proposals.
That type of notification can be accomplished by posting to the
appropriate IETF mailing list (ipv6@ietf.org in this case).
Regards,
Brian
I first want to thank Dave who took the time to read and comment on my draft
and to discuss the problems associated with it. Based on some offline
discussions with Dave, I have changed this document to better address the
current issues with RFC 4941 which are actually related to differences in
Follow up,
I forgot to post the link to the draft :-)
http://tools.ietf.org/rfcdiff?url2=draft-rafiee-6man-ra-privacy
Thanks,
Best,
Hosnieh
I first want to thank Dave who took the time to read and comment on my draft
and to discuss the problems associated with it. Based on
On May 23, 2013, at 11:01 AM, Michael Sweet msw...@apple.com wrote:
I've seen plenty of pending (not approved, not rejected) errata for other
RFCs for stuff like this. Posting to the ipv6 mailing list is useful for
people involved in RFC development but is completely opaque to ordinary
follow up to the follow up:
sorry, I sent the wrong link the last time. this is the correct link:
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy
:-| it is not my day.. :-/
Hosnieh
IETF IPv6 working group
On May 23, 2013, at 10:04 AM, Brian Haberman br...@innovationslab.net wrote:
6MAN.
Really? I would have assumed that this would be an http document, but if it
can be done in 6man, that would be cool.
IETF IPv6 working group
On 5/23/13 11:23 AM, Ted Lemon wrote:
On May 23, 2013, at 10:04 AM, Brian Haberman br...@innovationslab.net wrote:
6MAN.
Really? I would have assumed that this would be an http document, but if it
can be done in 6man, that would be cool.
RFC 6874 was published by 6MAN. There was input
I happen to agree that a change like this would be a good change, but I also
agree that it needs to be done as a consensus document, not as an erratum.
This is true not only for process reasons, but because I think the change as
proposed was too broad. Is there a working group alive
On 5/23/13 11:42 AM, Ole Troan wrote:
I happen to agree that a change like this would be a good change, but I also
agree that it needs to be done as a consensus document, not as an erratum.
This is true not only for process reasons, but because I think the change as
proposed was too broad.
Hosnieh Rafiee wrote:
follow up to the follow up:
sorry, I sent the wrong link the last time. this is the correct link:
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy
:-| it is not my day…… :-/
Hosnieh
I have read this draft and I don't particularly like it for several
On behalf of Apple I apologise. I will talk with Michael Sweet directly and try
to resolve his concerns without any more errata reports.
Stuart Cheshire
On 23 May, 2013, at 07:45, Brian Haberman br...@innovationslab.net wrote:
Michael,
Let me repeat myself... This is not how the errata
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
Hi, Tim,
Thanks so much for your feedback! -- Please find my comments in-line...
On 05/22/2013 10:19 AM, Tim Chown wrote:
Overall, I think this is good work and should be progressed.
Thanks!
First, some general comments:
You may wish to be clearer earlier in the document (abstract
Hi,
I haven't noticed a single comment on this version, so is it
fair to assume everybody has read it and is in agreement? If so,
we'll ask the WG Chairs to move it towards WGLC. If there are
more comments, we still have to time to update the draft before
Berlin.
Regards
Brian Carpenter
On
Christian,
I'm happy to write up a new draft proposing my changes and go through that
process. I'm not happy that my errata have been summarily rejected in less than
24 hours with no time for review.
Consider: hundreds of millions of printers, computers, and mobile devices have
been certified
Brian,
I've seen plenty of pending (not approved, not rejected) errata for other
RFCs for stuff like this. Posting to the ipv6 mailing list is useful for
people involved in RFC development but is completely opaque to ordinary
implementers of RFCs (which I have to deal with on a daily
28 matches
Mail list logo
