Subject: Re: [Gen-art] Gen-art review of draft-ietf-monami6-multiplecoa-10.txt

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 5 Dec 2008 03:47:17 -0600

Hi Elwyn

Thanks a lot for detailed reviews.
Please find my comments inline...

I fixed the most of comments and attach the -11.txt and diff files.
The updated version contains the modifications for Gerardo's comments,  
too.

On 2008/11/24, at 19:45, 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).

I added the following text in the Protocol Overview.

NEW
This specification keeps backwards compatibility with [RFC-3775].  If
   a receiver (either home agent or correspondent node) does not support
   this specification, it does not understand the binding identifier
   mobility option.  The receiver skip the unknown mobility option (i.e.
   Binding Identifier mobility option) and process the Binding Update as
   defined in [RFC-3775].  In order to keep the backward compatibility
   with [RFC-3775], when a mobile node sends a Binding Update message
   with extensions described in this document, the receiver needs to
   reflect the Binding Identifier mobility option in the Binding
   Acknowledgement.  If the mobile node finds no Binding Identifier
   mobility options in the received Binding Acknowledgement, it assumes
   the other end node does not support this specification.  In such
   case, the mobile node needs to fall back to the legacy RFC-3775
   compliant mobile node.  If it is the home registration, the mobile
   node MAY try to discover another home agent supporting BID mobility
   option for the home registration.

> Extension to IPv4 correspondents etc: Something about this in the
> ontroduction would also help.

OK

> 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.

zero BID might be used to specify some meaning to a binding.
For example, a binding using BID zero can be treated as a default  
binding.
The zero BID is not forbidden, but it's reserved.
I removed "MUST NOT" for using the zero BID.

OLD
   Binding ID (BID)
      The BID which is assigned to the binding indicated by the care-of
      address in the Binding Update or the BID mobility option.  The BID
      is a 16-bit unsigned integer.  The value of zero is reserved and
      MUST NOT be used.

NEW
   Binding ID (BID)
      The BID which is assigned to the binding indicated by the care-of
      address in the Binding Update or the BID mobility option.  The BID
      is a 16-bit unsigned integer.  The value of zero is reserved and
      may not be used without special purpose.

> s2: Specifying that the BID must not be negative is sloghtly confusing
> because the protocol is specified so that negative values cannot be  
> carried.

right. I erased this sentence.

> 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.

thanks, we did fix these errors.

> s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored  
> by
> the receiver'.  Makes it easier to cope with later changes.

fixed.

> 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

OK. see my comments to the same question at the end of this mail.

> s4.3 (MCOA MALFORNED): Some indoication of the circumstances under  
> which
> this can occur would be useful.

Added more texts in section 4.3

OLD
   MCOA MALFORMED (TBD more than 128)
      Registration failed because Binding Identifier mobility option was
      not formatted correctly.

NEW
   MCOA MALFORMED (TBD more than 128)
      Registration failed because Binding Identifier mobility option was
      not formatted correctly.  This value is used when the wrong length
      value is specified (neither 4, 8 nor 20) in the length field of
      the Binding Identifier mobility or when invalid address is
      specified in the care-of address field.

> 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

This comment is related to the Backwards compatibility.
If a legacy RFC-3775 node receives a BU in the bulk registration mode,
it can simply process only the BU and skip the binding identifier  
option.
It does not use this BULK REG PROHIBITED value in the BA status code.

The MN can distinguish whether the receiver of BU is legacy RFC-3775  
node or MCoA extended node by
checking Binding Acknowledgement.

See the second paragraph of section5.7.
" If a mobile node includes a Binding Identifier mobility option in a
   Binding Update with the 'A' flag set, a Binding Acknowledgement MUST
   carry a Binding Identifier mobility option.  According to [RFC-3775],
   the receiver of the Binding Update ignores unknown mobility options
   and process the Binding Update without the unknown mobility option.
   Therefore, if no such mobility option is included in the Binding
   Acknowledgement in response to a Binding Update for multiple care-of
   address registration, this indicates that the originating node of the
   Binding Acknowledgement does not support processing the Binding
   Identifier mobility option regardless of status value.  In such case,
   the receiver of the Binding Update may create a regular binding.  The
   mobile node then stop multiple care-of address registration with that
   node.  If it is home registration, the mobile node MAY attempt to
   discover another home agent supporting BID mobility option for the
   home registration."

> s5.3: What error status is sent if the user has an Alernate care-of
> address option with a bulk registration?

Very good comment.
I re-checked this parts and found this part is very unclear.

The reason of eliminating Alternate care-of address option is not only  
for bulk registration.
In RFC-3775, Alternate CoA is mandatory for home registration, but not  
for binding registration to correspondent node.
Alternate CoA mobility option is required when BU is protected with  
IPsec ESP.

Therefore, we clearly mention this point in the draft.

In section 5.2
OLD
When IPsec ESP is used for protecting the Binding Update,
   the care-of address can be carried in the Care-of Address field of
   the Binding Identifier mobility option.  If this is done, the
   alternate care-of address option MUST NOT be included in the Binding
   Update.

NEW
   When IPsec ESP is used for protecting the Binding Update, a care-of
   address MUST be carried in an alternate care-of address mobility
   option as described in [RFC-3776].  However, in this specfication,
   the care-of address MUST be carried in the Care-of Address field of
   the Binding Identifier mobility option.  In order to save bits of the
   Binding Update, the alternate care-of address option MUST NOT be
   included.

In section 5.3
OLD
The alternate care-of address option MUST NOT be used.

NEW
   When IPsec ESP is used for protecting the Binding Update, a care-of
   address MUST be carried in an alternate care-of address mobility
   option as described in [RFC-3776].  However, in the bulk
   registration, the care-of addresses are always carried in the Care-of
   Address field of the Binding Identifier mobility option.  In order to
   save bits of the Binding Update, the alternate care-of address option
   MUST NOT be included in such Binding Update.

In section 6.2
ADD
   o  If the Binding Update is protected with IPsec ESP, the care-of
      address MUST be appeared in the Binding Identfier mobility option.
      If no address is appeared in the care-of address field in that
      mobility option, it MUST reject the Binding Identifier mobility
      option and returns the status value set to [MCOA MALFORMED].

   o  If the care-of address is appeared in both the alternate care-of
      address mobility option and the BInding Identifier mobility option
      at the same time, it MUST ignore the alternate care-of address
      mobility option and can continue processing the Binding Update
      with the care-of address specified in the BInding Identifier
      mobility option.

> s5.5.2, last para: Arguably, if the interface is shut down the node os
> not (IP) connected to its home link!

right. This was discussed on the ML, too.
There is no specific description of returning home in this section,
but we explain how MN de-registers the binding of the shut-down  
interface from the active interface.

> 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.

fixed.

> 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'.

If the link between HA and MN is P2P (example is 3GPP/WiMAX),
we expect HA might be able to get the LL address in the L2 mechanism.
Therefore, we use SHOULD instead of MUST.

> 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'.

see above. A home link can be P2P link in some scenario.

>
> 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.

OLD
   o  If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the
      mobile node SHOULD stop using bulk registrations with the node
      that sent the Binding Acknowledgement.
NEW

   o  If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], all
      the attemped registration in the bulk registration mode are
      failed.  Therefore, the mobile node MUST stop using bulk
      registrations with the node that sent the Binding Acknowledgement.
>
> s5.7 (3rd bullet): Explain what could cause the packet to be  
> malformed.

It is now explained in section 4.3.

> 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).

fixed.

> 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.

It is not designed as transactional.
However, it might be a case when HA cannot accept more than two  
bindings, but MN sends 3 CoAs in bulk BU.
In such case, HA should accept two bindings and reject one. In the BA,  
HA should set  either one of those error codes for the rejected BID.
      128 Reason unspecified
      129 Administratively prohibited
      130 Insufficient resources

I didn't make any modification to this comments.
If this reason is reasonable and is worth to write in the draft,
I will add new texts.

> 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?

This address verification is mainly to check the CoA is truly unicast  
routable address or not.
The same verification is defined in RFC3775.

OLD
   o  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].

NEW
   o  When the Length value is either 8 or 20, the care-of address MUST
      be present in the Binding Identifier mobility option.  If the
      unicast routable address [RFC-3775] is not present in the care-of
      address field, the receiver MUST reject the Binding Identifier
      mobility option and returns the status value set to [MCOA
      MALFORMED].

> 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).

If the care-of address is not required, the length value must be 4.
There is no space to include the care-of address in the binding  
identifier option.

> s6.2 (1st para after lost of bullets): s/can be omitted/MAY be  
> omitted/

fixed.

> Editorial:
> I have sent a Word document with many nits marked up to the authors.

I have fixed all the editorial comments. Thanks!!!!

regards,
ryuji

ps. I'm away from the office on a business trip for two weeks.
I am now in New Orleans, but will catch flights to Spain this morning.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art