Hi Pekka,
> In general, I think the approach is a good one. Thanks, I was initially trying to get feedback on the format ... > However, in the next revisions (as was probably intended) there possibly needs to > be much more detailed descriptions on what is really necessary and what > not. Also, in some areas there may be need for a "Discussion" part. Definately, feel free to suggest text. > > > And more detailed ones.. > > 3.2 RFC2467 - A Method for the Transmission of IPv6 Packets > over FDDI > Networks > > A Method for the Transmission of IPv6 Packets over FDDI Networks > [RFC-2467] is conditionally mandatory if the node has a FDDI > interface. > [and others] > > ==> I'm not sure if this 'has XXX interface' is the right wording. IMO, > it's perfectly ok for an OS to be a conformant IPv6 node and NOT support > some legacy interfaces like FDDI or Token Ring, or whatnot. This is more > of a question what are the supported interfaces. The idea is that these only need to be implemented if there to use one of the interfaces. In most cases, you won't need support for legacy interfaces. > 3.6 RFC2492 - IPv6 over ATM Networks > > IPv6 over ATM Networks [RFC2492] is conditionally mandatory if the > node has an ATM interface. > > ==> PVC features yes, but are SVC functionalities also mandatory? This one I need to dig into more, I must admit to not being an IPv6 over ATM expert. > 4.1.1 RFC2460 - Internet Protocol Version 6 > > Nodes must always be able to receive fragment headers. However, if it > does not implement path MTU it may not need to send fragment headers. > > ==> path MTU discovery. will fix. > ==> take a look at draft-savola-ipv6-rh-hosts-00.txt, does some text > regarding the processing of RH's belong here or do we need to > issue some corrective/clarificative RFC's? I will look at it and see what kind of text is needed. > 4.2.1 RFC2461 - Neighbor Discovery for IPv6 > > Receiving Router Advertisement is unconditionally > mandatory for host > implementation, with a configuration option to disable this > functionality. > > ==> I guess the node must also process the RA, but that's semantics. Are > all features (now and future :-) in RA's a must to implement > and support? I will need look into clarification fior this. > 4.3.2 RFC2675 - IPv6 Jumbograms > > IPv6 Jumbograms [RFC2675] is unconditionally optional. > > 4.4 ICMPv6 > > ICMPv6 [RFC 2463] is Unconditionally Mandatory. > > ==> there seem to be some differences with the capitalization > of the magic > words. Will fix. > 4.6.2 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > > Multicast Listener Discovery [RFC-2710] is Conditionally Mandatory, > where the condition is if the node joins any multicast groups other > than the all-nodes-on-link group (which will always be the case if it > runs ND or DAD on the link). > > ==> That condition is this? The node always joins its solicited multicast > addresses (at least for link-local addresses), so this section would seem > to always evaluate to "Mandatory" ?? There has been some off-list discussion that hosts may not be able to depend on MLD if there is no connection to a router, therefore this may not be Mandatory. I think we need some discussion on this. > 9.1 RFC2711 - IPv6 Router Alert Option > > The Router Alert Option [RFC-2711] is conditionally > mandatory if the > node does performs packet forwarding at the IP layer. > > ==> s/does performs/does perform/ ? Will fix. > ==> what kind of IP router is it if it doesn't forward > packets at the IP layer? (I have no idea..) I get your point ... John -------------------------------------------------------------------- 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] --------------------------------------------------------------------
