Title: RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"
I am generally happy with the document after reviewing it. I found a number of fairly trivial nits, plus one wording query:
Section 2.3, first para - also an editorial nit in same para:
In the first para the
Silly me!
Brian
JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B wrote:
>
> > On Thu, 06 Nov 2003 16:57:14 +0100,
> > Brian E Carpenter <[EMAIL PROTECTED]> said:
>
> > I also don't think we should rewrite all the RFCs that refer to SL.
> > I have no problem with listing them, as in
>
> > N
Yes, correct, and SL-IMPACT must not become a blocking reference.
Brian
Pekka Savola wrote:
>
> On Thu, 6 Nov 2003, Brian E Carpenter wrote:
> > Pekka, it's been a while, but my recollection is that we (the authors)
> > didn't agree and didn't see any support for your comments on the list.
>
On Thu, 6 Nov 2003, Brian E Carpenter wrote:
> Pekka, it's been a while, but my recollection is that we (the authors)
> didn't agree and didn't see any support for your comments on the list.
>
> I could be wrong.
There was no opposition, and there was support for at least referencing
the SL-IMPA
> On Thu, 06 Nov 2003 16:57:14 +0100,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> I also don't think we should rewrite all the RFCs that refer to SL.
> I have no problem with listing them, as in
> Note that the following documents refer to link local addresses
> and will require ap
Well, I agree with Christian's responses. We need to prevent panic
(people rushing to switch off FEC0 immediately) and we need to prevent
people continuing to write code to support it. I find it hard to see
any wording that is better than the current draft. The IETF often
specifies what must or mus
06, 2003 7:59 AM
> To: Pekka Savola
> Cc: Brian Haberman; [EMAIL PROTECTED]
> Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"
>
> Pekka, it's been a while, but my recollection is that we (the authors)
> didn't agree and didn't see any
Pekka, it's been a while, but my recollection is that we (the authors)
didn't agree and didn't see any support for your comments on the list.
I could be wrong.
Brian
Pekka Savola wrote:
>
> On Wed, 5 Nov 2003, Brian Haberman wrote:
> > This is a reminder that the last call on the deprecation
On Wed, 5 Nov 2003, Brian Haberman wrote:
> This is a reminder that the last call on the deprecation document
> ends today. In particular, the chairs would like to ensure that
> the WG agrees on the actual deprecation text in Sections 4 & 6.
> There has been few comments on this draft and it canno
Brian,
In response to your last call, I'd like to comment on the following
sections of the document:
Section 2.4 "Site is a Vague Concept"
This section does overstate the case. The last paragraph itself is
sufficient cause for concern, regarding the concept as it was
envisioned. There is no
Christian Huitema wrote:
Suggested text to address both comments:
"The special behavior of this prefix MUST no longer be supported."
Well, we did not intend to force every implementation developer to go
fix the problem immediately, recall the products that have already
shipped, etc. T
> Suggested text to address both comments:
>
> replace:
> "The special behavior of this prefix MUST no longer be supported in
new
> implementations."
>
> by
>
> "The special behavior of this prefix MUST no longer be supported."
Well, we did not intend to force every implementation developer to
Christian Huitema wrote:
> 4 Deprecation
>
> This document formally deprecates the IPv6 site-local unicast
prefix
> defined in [RFC3513], i.e. 111011 binary or FEC0::/10.
I think this section is not ready yet. Couple comments:
1) This is not the IETF job to mandate what a
> From: Erik Nordmark, October 22, 2003 1:34 PM
> To: Brian Haberman
> Cc: [EMAIL PROTECTED]
> Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"
>
>
> Overall I support this document, but there are two things that have
> me concerned.
I have no problems with the document content (and I did NOT try to read it
for editorial nits...).
--On Wednesday, November 05, 2003 13:27 -0500 Brian Haberman
<[EMAIL PROTECTED]> wrote:
If you have reviewed the document, have no issues with it, and agree
on its content, please let the chairs a
On Wed, Nov 05, 2003 at 11:45:56AM -0800, Christian Huitema wrote:
>
> Well, we still have link local scope, so there is still that. Do you
> suggest that we write a line for each of the RFC that currently mention
> site local and explain how to change them?
It would be interesting to know how m
> > 4 Deprecation
> >
> > This document formally deprecates the IPv6 site-local unicast
prefix
> > defined in [RFC3513], i.e. 111011 binary or FEC0::/10. The
> > special behavior of this prefix MUST no longer be supported in
new
> > implementations.
>
> I think this section i
On Wed, Nov 05, 2003 at 10:47:33AM -0800, Alain Durand wrote:
>
> 1) This is not the IETF job to mandate what an implemention choose
>to support or not.
But, for example, isn't that what the node requirements draft does? Ok it
does not "mandate" but it uses wordage like "all IPv6 nodes can b
Sections 4 and 6 seem fine.
Minor nit in 2.2 "which may cause" rather than "causing".
Minor nit in 3, "QoS" for "QOS".
Also in 3, "in which addresses are not ambiguous and do not have a simple
explicit scope." is maybe better left as "in which addresses are not
ambiguous" or maybe change to "a
> 4 Deprecation
>
> This document formally deprecates the IPv6 site-local unicast prefix
> defined in [RFC3513], i.e. 111011 binary or FEC0::/10. The
> special behavior of this prefix MUST no longer be supported in new
> implementations.
I think this section is not ready yet. Coupl
This is a reminder that the last call on the deprecation document
ends today. In particular, the chairs would like to ensure that
the WG agrees on the actual deprecation text in Sections 4 & 6.
There has been few comments on this draft and it cannot proceed
unless the chairs can be sure that it ha
Overall I support this document, but there are two things that have
me concerned.
1. The document talks about a replacement in section 2 and section 5.
While finding replacement for what folks perceived as being benefit
with site local addresses is useful (and perhaps even required),
the text in
> A simple method would be to check the first 48 bits of the IP addresses
> that are suspected of having "local" reachability. But this doesn't
> allow for the merging of two sites, which was presented as a rather
> prominent requirement during the site local wars (or at least the part
> I got
23 matches
Mail list logo
