I just went through 2461bis having not looked in detail for a while.
The intention was to check consistency and comprehensibility for those not so close to the subject.
Editorial nits:
S2.1: Last item (random delay seed) - missing newline so title of definition runs onto end of previous
S2.3: Copying the actual values of the all-nodes and all-routers multicast addresses and the unspecified address from [ADDR-ARCH] is undesirable - it makes a potential double maintenance problem.
S3: The capitalisation of the mechanism titles is inconsistent: Address resolution and Next-hop determination vs. Router Discovery etc
S3: There is a spurious blank line after the Router Solicitation item.
S6.3.4: there is a spurious blank line in the 6th para on page 49 (starting 'After extracting information...')
S6.1, 7.1, 8.1: The sentences such as in 6.1.1 next to last para: 'The only defined option that may appear...' would be better as a reference to the appropriate one of sections 4.1-4.5 to avoid double maintenance problems (5 places in total).
S7.3: 3rd para: since 'next hop determination' is not a section title a ref to s.5.2 would be useful.
Appendix C: Check the page breaks to improve readability.
Substantive comments:
S2.2 and S3:
The note after the NBMA definition says that '...all link types (including NBMA) are expected to provide multicast service for IP...'.
A naive interpretation of the phrase in S3 'On multicast-capable links...' (just after the Redirect bullet) in conjunction with the previous note might take it that actually all links are multicast-capable. The term should be explicitly defined so as to explicitly exclude NBMA and any other sort of links that this phrase is not supposed to apply to - or to allow it to be done optionally on this sort of link - the current wordings are too vague. This is also related to the comment on 6.2.1 below.
S3: Technically DAD is not defined in 2461 but in 2462
S3.1: Next to last para: 'Using the Hop Limit equal to 255 trick' is rather informal and also what the trick is should either be defined here or a forward ref given as this is the first mention of this 'trick'. [Metaquestion: should the same trick be used in MLD?]
S4.1, 4.2, 4.3, 4.4 and 4.5: I believe that in many circumstances the addressing of the ND packets does not meet the standard scope consistency rules for source and destination addresses. This is not a problem but it would probably be wise to add a note that these packets should not be subject to such consistency checks.
S4.6, S4.6.1, S4.6.3: Option lengths are measured in units of 8 octets but nothing is said about padding out options if the content does not make it up to an even multiple of 8 bytes. Some link layer addresses (s4.6.1) might not be obliging and there is no guarantee that the packet body in 4.6.3 will be an obliging multiple of 8 octets.
[S5: Prefix List: Having removed the 'assume it is on link' if no routers, it might be useful to allow a prefix to be inserted into the prefix list by manual configuration when dealing with a single link net.]
s5.2: It ought to be stated that if the default router list is empty then off-link unicast packets will have to be dropped and an 'unreachable' ICMP message sent.[whether the packet ought to have got as far as the interface processing is a moot point].
s 6.3.4: (next to last para on p49): The restriction in setting the LinkMTU to be not greater than the default value specified in the link type specific document is odd and actually inconsistent with the statements in RFC2590 for example (which allows LinkMTUs both larger and smaller than the default).
S6.3.6 (Item 3) should be removed (agreed elsewhere) - but it should be emphasised that this may result in the default router list being empty
S6.1, 7.1, 8.1: S7.1 refers to checking that if the message has an AH header then it should authenticate correctly: S6.1 and 8.1 should be consistent with this and there should probably be mention of authentication with ESP and ensuring that the packet decrypts properly (or alternatively remove the note from 7.1 perhaps).
s6.2.1: What is a 'multicast interface'? Is it a 'multicast-capable' interface? But most of this ought to apply to any interface on a router if it does ND. This is tied into the lack of precision as to what a 'multicast capable' interface is.
S6.2.2, 7.2.1,7.2.8: The _expression_ 'join the multicast group' needs to be reinforced to explicitly call out the use of MLD i.e. the interface has to be configured to listen to the multicast address and send the appropriate MLD Listener message in all cases. It should probably also be made clear that the the Listener report has to be sent again after the interface has acquired a preferred address.
Regards,
Elwyn
----------------------------------------------------------------------------------
Elwyn B Davies
Routing and Addressing Strategy Prime & IPv6 Core Team Leader
CTO Office, Portfolio Integration Solutions Ready
Nortel Networks plc Email: [EMAIL PROTECTED]
Harlow Laboratories ESN 6-742-5498
London Road, Harlow, Direct Line +44-1279-405498
Essex, CM17 9NA, UK Fax +44-1279-402047
Registered Office: Maidenhead Office Park, Westacott Way,
Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so any
unauthorised disclosure, copying or distribution of its contents is strictly prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
==================================================================================
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
