[As some of you know, I've been away from email for the past two months.
I am still not on any email lists, ipng included.]
See comments below...
> -----Original Message-----
> From: Mauro Tortonesi [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 29, 2001 11:54 AM
> To: Richard Draves
> Subject: draft-ietf-default-addr-select-04.txt (fwd)
>
>
>
> you've probably missed this mail i've posted to the ipng ml ;-)
>
> --
> Aequam memento rebus in arduis servare mentem...
>
> Mauro Tortonesi [EMAIL PROTECTED]
> Ferrara Linux User Group http://www.ferrara.linux.it
> Project6 - IPv6 for Linux http://project6.ferrara.linux.it
>
> ---------- Forwarded message ----------
> Date: Fri, 20 Jul 2001 19:07:29 +0200 (CEST)
> From: Mauro Tortonesi <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: draft-ietf-default-addr-select-04.txt
>
>
> last monday i have revised
> draft-ietf-default-addr-select-04.txt, and i have some
> questions and minor editorial comments:
>
>
> Page 1:
>
> Abstract
>
> [...]
>
> All IPv6 nodes, including both hosts and routers, must implement
> default address selection as defined in this specification.
>
> why "must" and not "MUST"?
I have the vague impression that it's best to avoid overuse of
capitalized MUST/SHOULD/etc, but I am happy to defer here to those with
more RFC experience.
> Page 5:
>
>
> 2.3. IPv6 Addresses with Embedded IPv4 Addresses
>
> IPv4-compatible addresses [2] and 6to4 addresses [12] contain an
> embedded IPv4 address. For the purposes of this document, these
> addresses should be treated as having global scope.
>
> IPv4-compatible addresses should be treated as having "preferred"
> configuration status.
>
> what about 6to4 addresses? shouldn't they be treated as
> having "preferred" configuration status too? what about other
> embedded address types?
6to4 addresses will typically be acquired via usual address
configuration means (like receiving a prefix in a Router Advertisement)
so their configuration status will depend on their lifetime, just like
other global addresses.
> 2.4. Loopback Address and Other Format Prefixes
>
> The loopback address should be treated as having link-local
> scope [9, section 4] and "preferred" configuration status.
>
> this has already been (partly) stated in section 2.1.
I don't see how section 2.1 says anything about the loopback address.
> 2.5. Policy Table
>
> [...]
>
> The precedence value Precedence(A) is used for sorting destination
> addresses. If Precedence(A) > Precedence(B), we say that address A
> has higher precedence than address B, meaning that our algorithm
> will prefer to sort destination address A before
> destination address
> B.
>
> i would change this into:
>
> The precedence value Precedence(A) is used for sorting destination
> addresses. If Precedence(A) > Precedence(B), we say that address A
> has higher precedence than address B, meaning that our algorithm
> will prefer to sort destination (or source) address A before
> destination (or source) address B.
I disagree. Because the Precedence value is used only when sorting
addresses for use as a destination (section 5) it would be highly
misleading to insert a reference to source addresses.
> Page 10:
>
> 6. Interactions with Routing
>
> [...] One router is advertising a global prefix A and
> the other route is advertising global prefix B.
> ^^^^^
>
> i think you wanted to say router here.
Yes, thanks.
> IMHO, draft-ietf-default-addr-select-04.txt is a very well
> done work. i wonder how many implementations already support
> source and destination address selection. does any of you
> have some information about this?
The MS implementation supports the draft.
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
