Elwyn, Thank you for the in-depth review! Authors, when will you be addressing these issues? Jari Elwyn Davies wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-monami6-multiplecoa-10.txt Reviewer: Elwyn Davies Review Date: 24 November 2008 IETF LC End Date: 17 November 2008 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. It has a number of minor issues plus a fair number of editorial nits. I am sending the editirial issues to the authors separately as there are lots of acronyms needing expansion and minor english improvements that woild be tedious to transcribe. Apologies for the late review. Comments: Minor Issues: Backwards compatibility: It would be helpful to explain in the introduction why this proposal is backwatds compatible with the RFC 3775 scheme. The explanations are there but are buried in the error cases of s5.7 and is easily mossed (as I did on early reading). Extension to IPv4 correspondents etc: Something about this in the ontroduction would also help. s2 and several other places (s4.2, s5.1): Use of zero as a binding ID (BID) is forbidden. It is unclear why this value is not allowed - it does not AFAICS specify reversion to RFC 3775 behaviour or anything similar: Forbidding it seems gratuitous. s2: Specifying that the BID must not be negative is sloghtly confusing because the protocol is specified so that negative values cannot be carried. s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub-bullet): The length of the Binding Address mobility option for the IPv4 case is specified inconsistently. Some places have been corrected from 12 to 8 but several others remain. s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored by the receiver'. Makes it easier to cope with later changes. s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2): I am dubious about the non-transactional nature of bulk registrations: some additional discussion of why it should be reasonable that a bulk registration can fail in part would be useful s4.3 (MCOA MALFORNED): Some indoication of the circumstances under which this can occur would be useful. s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there is a 'crner case' in which a bulk registration is sent to a leagcay RFC 3775 node: the node would not be capable of this response. This corner case is not described in s5.3 s5.3: What error status is sent if the user has an Alernate care-of address option with a bulk registration? s5.5.2, last para: Arguably, if the interface is shut down the node os not (IP) connected to its home link! s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It is not a standard abbreviation. I take it 'except' is meant. s5.6.3 (3rd bullet): 'The mobile node SHOULD include the Link-layer Address (LLA) Option': I do not understand how the home agent would be able to send to the mobile node if the LLA option was omitted. I think this is a 'MUST' or maybe a 'needs to'. s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link-layer address carried by the Link Layer Address option': Again I am not sure what alternative there is? Replace with either 'MUST' or 'needs to'. s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat is an option in the protocol. Also I think it should state that the mobile node needs to assume that none of the attempted registrations were successful. s5.7 (3rd bullet): Explain what could cause the packet to be malformed. s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'. Explain that the 2nd case can occur during 'bootsatrpa' (pointer to s5.9). s6.2 (para 2): If bulk registrations are not transactional (which I would have preferred) need to make it clear what happens with the vrarious multiple mobility options when some are succcessful and some fail. s6.2 (2nd bullet): 'When the Length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the valid care-of address is not present, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED].' This is poorly phrased. If the length is set to 8 or 20, then there is space in the option for an address of some sort. It sort of implies that the bit pattern can be tested to see if it is a valid address - how is this done? It strikes me tht it would simpler just to day that the address is ignored if present when not required (or, if being paranoid, must be the same as was previously registered (if present) when deleting a registration). s6.2 (1st para after lost of bullets): s/can be omitted/MAY be omitted/ Editorial: I have sent a Word document with many nits marked up to the authors.
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf