Hi Folks,
I have some comments regarding this draft.
* The draft does not mention that it is RFC 2119 compliant and it is not.
Hence it is impossible to figure out if something is mandatory or not. For
example in section 2.7.1 page 17 "A node is required to compute and join...".
What is the compliance level for this requirement. MUST/SHOULD or MAY?
* There is no definition of scope. Types of addresses like
unicasr/anycast/multicast are defined but global/local(link/interface)
scope are not defined.
* section 2.1 paragraph 2 third sentence
"Unicast addresses with
scope greater than link-scope are not needed for interfaces that are
not used as the origin or destination of any IPv6 packets to or from
non-neighbors."
Sentence is too complex (double negative). Can be something like
"Unicast addresses with scope greater than link-scope are needed only for
interfaces that are used to communicate with non-neighbors."
* section 2.2 point number 1
The IP address used as an example is a site-local address
(FEDC:...). Since this range may never be used it might be changed to
something non-controversial
* section 2.2 point number 2
typo for unspecified address (it says unspecified addresses)
* section 2.4 address type table
Section number for global unicast(2.5.4) is missing in table
* section 2.5 second address format
Since the interface ID will be 64 bits in most cases it may make
sense to split the address picture more evenly
* section 2.5.1 paragraph 6 last sentence
The simpler alternative would be 1,2,etc.
should be
The simpler alternative would be 0:0:0:1,0:0:0:2,etc.
* section 2.5.3 third sentence
It reads "It may never be assigned to any physical interface". Shouldn't
this be "It MUST never be assigned to any physical interface"?
* section 2.5.4 last paragraph
It mentions that the global routing prefix is assigned to a "site"
which is fuzzy. Is it possible to make it clearer? Similarly I would think
of a link to be some layer2 connection not necessarily comprising a
subnet.
* section 2.7
Shouldn't the site local scope for multicast be removed in the
multicast address format?
"NTP servers in site" example should be removed. The paragraph
following the examples also need to be removed
Typo. The last three paragraphs have scope misspelt as scop.
* section 2.7.1
The list of 16 reserved addresses with group id set to
0:0:0:0:0:0:0 can be replaced with a sentence which goes something like
"All permanently assigned multicast addresses with group id 0:0:0:0:0:0:0
are reserved."
All routers in site example should be removed.
* appendix A
Instead of explaining this procedure for 48 bit MACs isn't it
better to put in a reference to RFC 2464
* appendix A section "Links with other kinds of identifiers" line 2
Typo. EIU should be EUI
That's about it.
Cheers
Suresh
On Fri, 10 Oct 2003
[EMAIL PROTECTED] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
>
> Title : IP Version 6 Addressing Architecture
> Author(s) : R. Hinden, S. Deering
> Filename : draft-ietf-ipv6-addr-arch-v4-00.txt
> Pages : 25
> Date : 2003-10-10
>
>This specification defines the addressing architecture of the IP
>Version 6 protocol [IPV6]. The document includes the IPv6 addressing
>model, text representations of IPv6 addresses, definition of IPv6
>unicast addresses, anycast addresses, and multicast addresses, and an
>IPv6 node's required addresses.
>
>This document obsoletes RFC-3513 'IP Version 6 Addressing Architecture'.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
> "get draft-ietf-ipv6-addr-arch-v4-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
> [EMAIL PROTECTED]
>In the body type:
> "FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt".
>
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
