RE: Node requirement nits (was: AD review of draft-ietf-ipv6-node-requirements-05.txt)

[john.loughney@xxxxxxxxx]

Hi all,

Assigned as issue 18, comments in line.

> -----Original Message-----
> From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi]
> Thomas Narten wrote:
> 
> >>   Routers do not need to support route optimization or home agent
> >>   functionality.
> >>
> >>   Routers SHOULD support the generic mobile IP requirements.
> > 
> > 
> > I think it would be better to replace the above with something like:
> > 
> >   Routers SHOULD support the router-specific extensions defined in
> >   Section 8.3 of MIPv6
> 
> Yes.

Updated as per Jari's update on Mobile IP.
 
> >>   The goal of this document is to define the set of functionality
> >>   required for an IPv6 node; the functionality common to 
> both hosts and
> >>   routers.  Many IPv6 nodes will implement optional or additional
> > 
> > 
> > Sentence with semi-colon doesn't parse. :-(
> 
> Yes. "The goal of this document is to define the common functionality
> required from both IPv6 hosts and routers."

Updated.

> >>3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
> >>
> >>   Transmission of IPv6 Packets over Ethernet Networks 
> [RFC-2464] MUST
> >>   be supported for nodes supporting Ethernet interfaces.
> > 
> > 
> > I don't quite like the way this (and subsequent) sentences is
> > worded. We don't want to  imply that nodes that support IPv4 over
> > Ethernet must also support this...
> > 
> > How about:
> > 
> >    Nodes supporting IPv6 over Ethernet interfaces MUST implement
> >    Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
> >    
> > same applies to remaining LL sub-sections.
> 
> Sounds better.

OK.
 
> >>   IPv6 over ATM Networks [RFC2492] MUST be supported for nodes
> >>   supporting ATM interfaces.  Additionally, the 
> specification states:
> > 
> > 
> > what does "the specification" refer to? How about saying
> > 
> >    Additionally, RFC 2492 states:
> 
> Right.

OK

> >>   option of disabling this function. The ability to 
> understand specific
> >>   Router Advertisement optionss is dependent on supporting the
> > 
> > s/optionss/options/
> 
> Yes.

OK

> >>   Redirect functionionality SHOULD be supported. If the node is a
> > 
> > spelling
> 
> Speling is bad inteed.

Fixed.
 
> >>   Nodes that are routers MUST be able to generate link 
> local addresses
> >>   as described in this specification.
> > 
> > 
> > "this specification" is ambiguious. Do you mean 2460?
> 
> Yes. s/this specification/RFC 2460 [RFC-2460]/

OK

> >>   If an application is going join any-source multicast, it SHOULD
> >>   support MLDv1.  If it is going to support 
> Source-Specific Multicast,
> > 
> > 
> > s/join any-source multicast/to join any-source multicast 
> group addresses/
> 
> Ok.

Got it.

> >>  This document is currently being updated.
> > 
> > 
> > s/this document/RFC2893/
> 
> Ok.

Got it

> > 
> >>  7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473
> > 
> > 
> > nit: indention is wrong on this heading.
> 
> Yes.

got it.
 
> > 
> >>   3DES-CBC does not suffer from the issues related to 
> DES-CBC. 3DES-CBC
> >>   and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be 
> supported. AES-
> >>   128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is 
> expected to
> >>   be a widely available, secure algorithm that is required for
> >>   interoperability. It is not required by the current IPsec RFCs,
> >>   however.
> > 
> > 
> > Perhaps add to last sentence, "but is expected to become required in
> > the future" ???
> 
> Ok.

Got it.
 
> >    act as routers.  Currently, this section does not discuss routin-
> >    specific requirements.
> > 
> > s/routin/routing/
> 
> Yes.

Got it.
 
> >>   At least the following two MIBs SHOULD be supported MIBs 
> SHOULD be
> >>   supported by nodes that support an SNMP agent.
> > 
> > 
> > duplicate words.
> 
> Yes. s/MIBs SHOULD be supported MIBs SHOULD be supported/MIBs 
> SHOULD be supported/

Yes
 
> >>10.1.1  IP Forwarding Table MIB
> >>
> >>   Support for this MIB does not imply that IPv4 or IPv4 specific
> >>   portions of this MIB be supported.
> > 
> > 
> > Which MIB is this? (No reference provided...)
> 
> Yes. Its [RFC-2096-BIS], I think.

Got it.

> >>10.1.2 Management Information Base for the Internet Protocol (IP)
> > 
> > 
> > Ditto.
> 
> Yes. [RFC-2011-BIS]

Got it.

> >>12.1 Normative
> >>
> >>   [DHCPv6-SL]    R. Droms, "A Guide to Implementing 
> Stateless DHCPv6
> >>                  Service", Work in Progress.
> > 
> > 
> > For all the references, please include the ID name, so folk can
> > actually figure out which ID it refers to. Also the RFC editor will
> > want to know this too, so they can put in the right references, in
> > case any are already RFCs.

Got all of these.

> 
> Agree. This one is draft-ietf-dhc-dhcpv6-stateless-00.txt
> 
> The rest are:
> 
>     [MIPv6]        D. Johnson and C. Perkins, "Mobility 
> Support in IPv6",
>                    Work in progress.
> 
> draft-ietf-mobileip-ipv6-24.txt. one author missing, too.... ;-)
> 
>     [MIPv6-HASEC]  J. Arkko, V. Devarapalli, F. Dupont, 
> "Using IPsec to
>                    Protect Mobile IPv6 Signaling between 
> Mobile Nodes and
>                    Home Agents", Work in Progress.
> 
> draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. an "and" between the last
> two authors?
> 
>     [MLDv2]        Vida, R. et al., "Multicast Listener 
> Discovery Version
>                    2 (MLDv2) for IPv6", Work in Progress.
> 
> draft-vida-mld-v2-07.txt
> 
>     [RFC-1886-BIS] Thomson, S., et al., "DNS Extensions to support IP
>                    version 6", Work In Progress.
> 
> draft-ietf-dnsext-rfc1886bis-03.txt
> 
>     [RFC-2096-BIS] Wasserman, M. (ed), "IP Forwarding Table 
> MIB", Work in
>                    Progress.
> 
> draft-ietf-ipv6-rfc2096-update-05.txt. the authors should be 
> "Haberman, B.
> and Wasserman, M.". No "(ed)", I think, because it doesn't say in the
> I-D boilerplate.
> 
>     [RFC-2011-BIS] Routhier, S (ed), "Management Information 
> Base for the
>                    Internet Protocol (IP)", Work in progress.
> 
> draft-ietf-ipv6-rfc2011-update-03.txt
> 
>     [ANYCAST]      Hagino, J and Ettikan K., "An Analysis of 
> IPv6 Anycast"
>                    Work in Progress.
> 
> draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
> 
>     [SOI]          C. Madson, "Son-of-IKE Requirements", Work 
> in Progress.
> 
> Expired, I think. Better replace this reference with
> draft-ietf-ipsec-ikev2-10.txt.
> 
>     [IPv6-RH]      P. Savola, "Security of IPv6 Routing 
> Header and Home
>                    Address Options", Work in Progress, March 2002.
> 
> draft-savola-ipv6-rh-ha-security-03.txt
> 
>     [SSM-ARCH]     H. Holbrook, B. Cain, "SSM Architecture", 
> Work in Pro-
>                    gress.
> 
> I think this is draft-ietf-ssm-arch-03.txt, but then the title
> is wrong: Source-Specific Multicast for IP
> 
> --Jari
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------