Hi all, Assigned as issue 18, comments in line.
> -----Original Message----- > From: ext Jari Arkko [mailto:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
