RE: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"

["Elwyn Davies" <[e-mail]>]

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 draft says:
   The ambiguity of site local addresses also creates problems for the
   routers. In theory, site local addresses are only used within a
   contiguous site, and all routers in that site can treat them as if
   they were not ambiguous. In practice, problem occurs when sites are
                                         -------
                                         the problem   
   disjoint, or when routers have to handle several sites

I am not sure that the word 'disjoint' is right here.  When I read it I
wasn't sure whether the intention was to callout situations where 'sites'
overlapped and the word 'not' was missing.  The next sentence clarifies that
we a dealing with sites which are partitioned but the components are not
directly connected.   I think partitioned might be a better description.

Editorial nits:

Section 1: It might be desirable to add 'unicast' to site local on the first
occurrence (as this what the discussion has been about) and would be
desirable for the second occurrence.

Section 2.2, para 3:
   The experience with RFC1918 addresses also shows some non trivial
   leaks, besides pacing these addresses in IP headers. Private
                  ------ s/b
                  placing

Section 2.2, last para:
The second sentence may be a little too colloquial.

Section 2.3, 4th para:
 In multi-homed routers, such as for example site border routers, the
   routing process should be complemented by a filtering process, to
   guarantee that packets sourced with a site local address never leave
   the site. This filtering process will in turn interact with the
   routing of packets, as it may cause the drop of packets sent to a
                                           ----
                                           dropping

Section 2.5: Spurious blank line in 1st para.

Section3:
Non-ambiguous should be hypenated throughout - currently there is a mixture
of hyphenated and non hyphenated(sic).

Section3, last para:
   One question remains, anycast addressing. Anycast addresses are
   ambiguous by construction, since they refer by definition to any
   host that has been assigned a given anycast address. Link-local or
   global anycast addresses can be"baked in the code". 
                                 ---- missing space

Regards,
Elwyn Davies
> -----Original Message-----
> From: Brian Haberman [mailto:[e-mail]] 
> Sent: 05 November 2003 18:27
> To: [e-mail]
> Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses"
> 
> 
> 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 has been thoroughly reviewed
> and agreed upon.
> 
> If you have reviewed the document, have no issues with it, and agree
> on its content, please let the chairs and/or the working group know.
> 
> Thanks,
> Brian & Bob
> IPv6 WG Chairs
> 
> Brian Haberman wrote:
> 
> > This is a IPv6 working group last call for comments on advancing the
> > following document as an Proposed Standard:
> > 
> >     Title        : Deprecating Site Local Addresses
> >     Author(s)    : C. Huitema, B. Carpenter
> >     Filename    : draft-ietf-ipv6-deprecate-site-local-01.txt
> >     Pages        : 10
> >     Date        : 2003-10-13
> > 
> > Please send substantive comments to the ipv6 mailing list, and minor
> > editorial comments to the authors.  This last call period 
> will end on 5
> > November 2003.
> > 
> > Brian Haberman / Bob Hinden
> > IPv6 W.G. Chairs
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>