Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt

From: [email-masked]
Date: Thu, 9 Oct 2003 09:44:55 +0300

Hi Chirayu,

Thanks for the comments.  The document has already passed WG last call
and I am finalizing some text based upon AD review.  I am uncomfortable
about making major changes to the document at this point, unless there
is strong reason to do so & strong consensus in the WG.

> 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)

Do you have a reason for thinking this?  Other requirement drafts do not
adhere to this type of layout.
 
> 	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.

There are no such changes.
> 
> 	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).

There shouldn't be such changes; I believe Thomas' review clarified
text in a few sections.

> "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."

At this point, I don't see the reason to remove the text, it has wg consensus
and I don't think it hurts the document.

> 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."

This comes from the RFC, therefore I don't see the need for changes.
 
> 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)."
> ---

I believe we've gone through some of this text with Thomas, so I think
the updated text is now sufficient.

> "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).

All nodes need to be able to terminate packets.  All nodes may be able
to route packets.

> 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.

The 2461 has specific text about what must be supported.  We've already
clarified some of the text.  We've adjusted some of the text already.  The
analysis is meant to provide some clarification.

> 3. Section 4.2 - Some general comments
> 
> "However, an implementation MAY support disabling this 
> function." Clarify why?

Text is already removed.
 
> "It is not required for paths between routers." Restate the sentence using the
> correct keywords?

I didn't think we needed keywords here.

> "However, the implementation MAY support the option of disabling this
> function." Clarify why?

Text is removed, as per Thomas' comments.

> "A host implementation MUST support sending Router Solicitations, but
> it MAY support a configuration option to disable this functionality." Clarify
> why?

Discussions on the mailing list indicated that it is required to implement
the code to send RS, but not required to peform RS.
 
> "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?

During the discussions in the WG, no one suggested that such functionality is
requiered.

> 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.

Do you have text, I am not sure what you are expecting.
 
> 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.

The MIBs have support for both IPv4 and IPv6 - however, we are not 
concerned with the IPv4 funcion
 
> 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"? 

API's are purely optional.

> 
> 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?

I can clarify text.
 
>    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.

You are talking about behavior.  There is no requirement in the above text
that states that nodes must wait to get the 'O' flag.  It just is saying
what the node must do when it gets an 'O' flag.

>    "Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be..."
> 
> Rephrase to "Stateless DHCPv6 [DHCPv6-SL], a subset of 
> DHCPv6, MAY be..."

Text is removed, as per Thomas' comments.

> 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? 

We are not going to handle all of the transition mechanism, as transition
mechanisms are not requirements.

> 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.   

The wg could come to no consensus on what to put here.  It is partially
implementation specific; partly deployment specific.

> 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."

Will look at updating according to your editiorial suggestions.

thanks,
John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Chirayu Patel" <[email-masked]>
Date: Thu, 09 Oct 2003 17:43:22 +0530

> is strong reason to do so & strong consensus in the WG.

Hi John,

Thanks for your reply. I wasn't aware of the last call. That said, I
agree that this is not the time for major changes.

Please see below for my replies.

CP

> adhere to this type of layout.

IMHO, it (formatting all sections in as per the points that I had listed)
makes the document more organized. It is a matter of personal taste, and
is not important at this juncture.

I am not complaining about the current format, but if there was going to
be a next version I would have liked to see the text moved around in some
of the sections. 

> All nodes need to be able to terminate packets.  All nodes may be able

The capability of being a final destination includes support for sending
NS, RS messages etc (basically being a host). If all nodes MUST support
the capability of being a final destination, then they (all nodes) must
be able to behave as hosts. Thus the requirement is that all routers
should be able to behave as hosts.  

Is my interpretation correct?
 
> During the discussions in the WG, no one suggested that such

Ok. Seems a bit odd though.

> Do you have text, I am not sure what you are expecting.

I wanted to know the meaning of "routing specific" requirements. Does it
mean - the types of routing protocols that the routers must support?
 
> implementation specific; partly deployment specific.

Hmm.. Is there an example of atleast one application that does not work
with RFC 3041 addresses?

---

From: [email-masked]
Date: Fri, 24 Oct 2003 18:06:23 +0300

Hi Chirayu,

> mean - the types of routing protocols that the routers must support?

More-or-less, yes.

> Hmm.. Is there an example of atleast one application that does not work

There has been much discussion on this, you probably might like to see
the archives, for blow-by-blow details.  FTP will have problems with 3041
addresses, for example.  There has been discussion of 3041-bis being
needed.

John

---

From: [email-masked]
Date: Fri, 24 Oct 2003 18:11:25 +0300

Hi Dave,

thanks for the comments!

John

> -----Original Message-----
> From: ext Dave Thaler [mailto:[email-masked]]
> Sent: 23 October, 2003 00:06
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]
> Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt
> 
> 
> The following issue was just brought to my attention today:
> > Duplicate Address Detection MUST be supported (RFC2462 section 5.4
> > specifies DAD MUST take place on all unicast addresses).
> 
> DAD is not defined on NBMA links (e.g. 6to4).
> RFC 2461 already allows for restricting some requirements to
> non-NBMA links in the text already quoted.
> 
> So if you had a device which only supported NBMA links for which
> DAD is not done, we're currently saying it has to have DAD code
> that can never be used.
> 
> I'd propose the simple clarification:
>  Duplicate Address Detection MUST be supported on all links
>  supporting link-layer multicast (RFC2462 section 5.4
>  specifies DAD MUST take place on all unicast addresses).
> 
> Also typo:
> >  router, Redirect functionionality MUST be supported.
>                     ^^^^^^^^^^^^^^^^
> -Dave
>