Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-00.txt

From: Suresh Krishnan <[email-masked]>
Date: Thu, 16 Oct 2003 23:27:18 -0400 (EDT)

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-masked] 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-masked].
>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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Sellers, Julian P" <[email-masked]>
Date: Fri, 17 Oct 2003 16:26:17 -0500

>-----Original Message-----
>From: Suresh Krishnan [mailto:[email-masked]]
.
.
.
>of a link to be some layer2 connection not necessarily comprising a 
.
.
.
(Actually it's the first paragraph of 2.5.4.)

The document should refer to the "link" definition in [ipv6] as it does for
"interface" (see 2.0).  This should happen at or before the first reference
to "link," which is at the end of 2.1:

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

Julian