Hi John,
Just finished. Please see below for comments.
CP
General comments:
=================
I am slightly confused about the philosophy behind organization of the
content. I would expect a requirements draft of this sort to contain points of
the following nature.
a) All sections of the RFC's should mention statements of the form
"XXX [RFC-YYYY] MUST be implemented for nodes that blah blah blah". (Note the
usage of the word implemented)
b) If there is a change in the requirement of a certain section in the
RFC mentioned in point a) has been changed (eg from a SHOULD to a MUST),
mention the corresponding section number, and state the change.
c) If there is no change in any of the requirements specified by the
RFC in a) but certain sections have to be emphasized or clarified for any
reason. Mention the reason, and *quote* the section (if possible).
Adherence to the above points would greatly improve the readability of the
document. It would also make it simpler to implement the document.
My review comments check adherence to points a), b), and c).
A section for "Router-specific functionality" is present whereas a similar
section for "Host specific functionality" is absent. Why? Merge the contents
with section 4.1, and 4.4, and remove this section.
The remainder of this email is split into sections - "Unnecessary text"
comments, "Need clarification" comments, and Editorial comments.
===========================================================================
"Unnecessary text" comments:
============================
1. Section 4.1 - "Internet Protocol Version 6 - RFC2460"
The following text should be removed. IMHO, it does not add any more value
than what is already stated in RFC 2460.
"Unrecognized options in Hop-by-Hop Options or Destination Options
extensions MUST be processed as described in RFC 2460."
"The node MUST follow the packet transmission rules in RFC 2460. "
"It should be
noted that there is some discussion about the use of Routing Headers
and possible security threats [IPv6-RH] caused by them."
2. What is the use of this statement in section 3.3? Does it imply additional
behavior for a de facto IPv6/ATM driver? If not, can we remove it? If yes, can
we add some more clarifications?
"Additionally, the specification states:
A minimally conforming IPv6/ATM driver SHALL support the PVC mode
of operation. An IPv6/ATM driver that supports the full SVC mode
SHALL also support PVC mode of operation."
3. Section 4.2.
What is the need of presenting all the requirements in RFC 2461 in concise in
this section? IMHO, it does not help clarify or understand RFC 2461 better.
Organizing text in this manner is a recipe for developing contradictions. For
example, the comment in Thomas's email about DAD. If you still think that
presenting the requirements of RFC 2461 helps...please reorganize the section.
You can probably have two subsections:
1. Main requirements from RFC2461
This section restates the main requirements of RFC2461. It in no
way modifies the content of RFC2461.
2. Deviations from RFC2461
4. Irrespective of how you handle comment 3), some of the text in this section
is redundant.
---[First set of redundant statements]----
"Duplicate Address Detection MUST be supported (RFC2462 section 5.4
specifies DAD MUST take place on all unicast addresses)."
"Sending and Receiving Neighbor Solicitation (NS) and Neighbor
Advertisement (NA) MUST be supported. NS and NA messages are required
for Duplicate Address Detection (DAD)."
---
---[Second set of redundant statements]---
"Neighbor Unreachability Detection (NUD) MUST be supported for all paths
between hosts and neighboring nodes."
"However, when a node receives a unicast Neighbor Solicitation (NS)
message (that may be a NUD's NS), the node MUST respond to it (i.e. send a
unicast Neighbor Advertisement)."
---
===========================================================================
"Need clarification" comments
=============================
1. Section 4.1
What is the intent of the following paragraph? Do you mean that all nodes
should implement the host functionality? If so, does this mean that all
routers should support the capability of being a final destination (host)?
The capability of being a final destination MUST be supported,
whereas the capability of being an intermediate destination MAY be
supported (i.e. - host functionality vs. router functionality).
2. Section 4.2 "Neighbor Discovery for IPv6 - RFC2461"
This section states that Neighbor Discovery SHOULD be supported. After the
quote it states - "Some detailed analysis of Neighbor Discovery follows". In
the following paragraphs, all the requirements are of type MUST. Do you mean
that these following requirements MUST be implemented only if ND is
implemented? Whatever the reason, a clarification must be added.
3. Section 4.2 - Some general comments
"However, an implementation MAY support disabling this function." Clarify why?
"It is not required for paths between routers." Restate the sentence using the
correct keywords?
"However, the implementation MAY support the option of disabling this
function." Clarify why?
"A host implementation MUST support sending Router Solicitations, but
it MAY support a configuration option to disable this functionality." Clarify
why?
"Redirect functionionality SHOULD be supported. If the node is a router,
Redirect functionionality MUST be supported." Is there no need to have a
configuration option to disable this functionality as specified for the other
functionalities?
5. Section 9.
What do you imply by routing-specific functionality? The statement needs some
support to make it unambiguous.
Currently, this section does not discuss routin-
specific requirements.
6. Section 10.1.1
I am a bit ignorant of SNMP. But, does the following sentence have a
well-known meaning?
Support for this MIB does not imply that IPv4 or IPv4 specific
portions of this MIB be supported.
7. Section 11
Thomas's comments on this section are bang on target.
8. Any particular reason for not including a section on "Application API's"?
9. Section 5.3.2
"For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP
upon the receipt of a Router Advertisement with the 'O' flag set (see
section 5.5.3 of RFC2462)"
a) Shouldn't the above sentence apply only to hosts, and not nodes?
b) I do not think the node should always wait for a RA with 'O' flag set
before using DHCP. If the node knows that the parameters that it needs are
going to be provided by DHCP, then it can start DHCP at the same time it sends
the RS to speed up the boot process. Hence, the correct keyword should be
SHOULD.
"Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be..."
Rephrase to "Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, MAY be..."
10. Section 6.
I might have missed the past discussion. Are we planning to eventually fill
this section with references to the various transition mechanisms defined by
IETF? Hmm..may be I can rephrase to a more basic questions - What is the
purpose of this section?
11. Section 4.5.3
A reference should be provided for the statement below. Otherwise,
implementers will not know how to interpret this sentence and identify/fix
related problems.
It is noted that a number of applications do not work
with addresses generated with this method, while other applications
work quite well with them.
===========================================================================
Editorial comments:
===================
1. Remove the acronym of ULP
2. Some of the sentences refer to the implementation as "the implementation",
and some as "an implementation". Some consistency is needed. I prefer "an
implementation"
3. Some consistency nitpicks.
"...an implementation MAY support disabling this function."
"...the implementation MAY support the option of disabling this function."
"..but it MAY support a configuration option to disable this
functionality."
5. s/functionionality/functionality
6. s/routin-/routing
7. As stated by Thomas, retire the word support in favor of implement in the
relevant sections.
8. Section 5.3.2
s/this type of node is/these types of nodes are/
For IPv6 Nodes
that do not implement DHCP, the 'O' flag of a Router Advertisement
can be ignored. Furthermore, in the absence of a router, this type
of node is not required to initiate DHCP.
9. Section 7.1
Use the correct keyword (MAY) in the below sentence.
"Routers do not need to support route optimization or home agent
functionality."
10. Section 10.
Rephrase.
"At least the following two MIBs SHOULD be supported MIBs SHOULD be
supported by nodes that support an SNMP agent."
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
