Subject: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jul 2003 12:41:48 +0300 (EEST)

Hi all,

This is a WG Last Call for comments on sending the following first three 
"Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents 
to the IESG for consideration as Informational RFCs:

Introduction to the Survey of IPv4 Addresses in Currently
Deployed IETF Standards
  http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01.txt

Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
  http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-01.txt

Survey of IPv4 Addresses in Currently Deployed IETF Operations & 
Management Area Standards
  http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt

Please review these documents carefully, and send your feedback to the
list (editorial modifications may also be sent to the editor, Andreas).  
Please also indicate whether or not you believe that this document is
ready to go to the IESG.  Silence does NOT indicate consent.  Unless
sufficient support is demonstrated on the list, the documents will not be
send to the IESG.

Please note that the first document ("introduction") includes the summary
of all the results, which are subject to change; please ignore the details
of section 3 when reviewing it.

The last call will end in 3 weeks, on 12th August.

Pekka, Margaret & Bob

---

From: [email-masked]
Date: Tue, 22 Jul 2003 19:40:48 +0900

i made a quick one-path on the draft.
	i dunno how the references between sections are managed,
	i hope it is automated somehow...

itojun

overall
	"this problem has been fixed..." to state that there's IPv6 variant
	available for the document looks strange to me.

line 250
	wrong: STD 44/RFC 891 in Section 3.44
	right: STD 44/RFC 891 in Section 3.1.17
line 274 (3.1.1)
	why this document suggests updates to RFC1812 to include IPv6 routing
	requirement, while suggesting separate IPv6 variant for RFC1122?
	not sure which is the right way to go.
line 280 (3.1.3)
	these "has been updated" statement look strange to me.  how about:

	RFC791 defines IPv4.  RFC2460 defines IPv6.
	Similarly to RFC922 which defines IPv4 addressing architecture,
	RFC2373 defines IPv6 addressing architecture.
	RFC792 defines ICMP for IPv4.  RFC2463 defines ICMPv6, which is ICMP
	for IPv6.
	RFC1122 defines IGMP, Internet Group Management Protocol for IPv4.
	RFC2710 defines MLD, Multicast Listener Discovery, which is basically
	IGMP for IPv6.
line 303 (3.1.6)
	which document deprecates the use of literal IP address?  RFC2822 still
	has domain-literal syntax, i.e. itojun@[10.1.1.1].
line 335 (3.1.13)
	how about:
	RFC2467 defines a method for the transmission IPv6 over FDDI networks.
line 339 (3.1.14)
	how about:
	RFC2464 defines a method for the transmission IPv6 over ethernet networks.
line 358 (3.1.19)
	how about:
	RFC2497 defines a method for the transmission IPv6 over ARCnet networks.
line 383 (3.1.23)
	how about:
	RFC2740 defines OSPF for IPv6.
line 388 (3.1.24)
	how about:
	RFC2080 defines RIPng, RIP for IPv6.
line 397 (3.2.1)
	i don't think there's enough specification for DHCPv6 options to
	replace bootp as a whole.
line 410 (3.2.3)
	how about:
	RFC1981 defines path MTU discovery for IPv6.
line 560 (3.3.8)
	I don't think there's applicability statement for OSPFv3 in RFC2740.
line 756 (3.3.43)
	I don't think RFC2492 defines IPv6 *broadcast* over ATM.
	how about:
	IPv6 does not utilize link-layer broadcast.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jul 2003 15:05:55 +0300 (EEST)

> 	available for the document looks strange to me.

Well, it's good (IMHO) for one purpose, explicitly stating that the 
problem no longer exists.  That is, if you just say "RFC X defines Foo2, 
which is Foo for IPv6", it is not clear whether RFC X and Foo2 provide all 
the features the original Foo did.  Saying it fixes the problem is a bit 
awkward but OK.  However, I'm not sure if Phil actually analyzed whether 
the same functions are being provided..

That said, I think something like "RFC2080 defines RIPng, RIP for IPv6." 
is slightly better, editorial-wise.  

I could go either way, but I'd like to try to avoid a lot of (editorial)
extra work for our editors if it doesn't have an acceptable cost/benefit
ratio.

Other thoughts?

...

Responding to a few comments only which might possibly warrant more 
discussion.

> 	not sure which is the right way to go.

Yes, I agree with that.  I think it should say that router reqs for v6 
should be defined.

> 	has domain-literal syntax, i.e. itojun@[10.1.1.1].

Very good point.  I also thought it was done in 2822 but it seems it only 
removed certain older versions.  Something to bring up to the apps folks, 
but I think there's already a person looking into these.

> 	replace bootp as a whole.

I don't know bootp in particular, but I'd bet DHCPv6 provides enough of 
options to provide for bootp functionality.  Do you have some particular 
options in mind?  DHCPv4 certainly has quite a bit more of them than 
DHCPv6, though.

> 	I don't think there's applicability statement for OSPFv3 in RFC2740.

True.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Tue, 22 Jul 2003 21:24:41 +0900

>options in mind?  DHCPv4 certainly has quite a bit more of them than 

	most importantly, boot file name ("file" in RFC951 page 4).

itojun

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jul 2003 05:37:47 -0400

The dhc WG considered two ways to go about defining options
in DHCPv6:

- carry forward all of the existing DHCPv4 options
- define DHCPv6 options "on demand" as specific
   requirements are recognized

The WG decided to adopt the second strategy, so the base
DHCPv6 specification includes all of the options needed
for the basic DHCPv6 machinery, and some additional
options have been defined in several other drafts.

If there are specific options for which we can identify
requirements, we can start the process to define those
options...

- Ralph