Subject: [netext] #9: Gen-art review by Pete McCann of I-D: draft-ietf-netext-redirect-07

From: "netext issue tracker" <[email-masked]>
Date: Wed, 20 Apr 2011 17:31:35 -0000

#9: Gen-art review by Pete McCann of I-D: draft-ietf-netext-redirect-07

 Please resolve these comments along with any other Last Call comments you
 may receive.

 Document: draft-ietf-netext-redirect-07
 Reviewer: Pete McCann
 Review Date: 2011-04-14
 IETF LC End Date: 2011-04-10 (sorry this is late) IESG Telechat date:
 (unknown)

 Summary: Has Issues

 Major issues:

 Section 5.4:
 You should add a paragraph on the possibility of loops in the LMA
 assignment operation and specify that the MAG must take some action to
 detect and terminate such loops, such as a maximum redirection count or
 tracking the IP addresses of the LMAs it has been assigned so far and
 looking for duplicates.

 Section 6: (Multi-Homing)
 This section makes a major assumption that all of the MN's sessions are
 somehow able to be correlated and that all MAGs will direct their tunnels
 back to the same LMA.  In fact this may not be possible when the MN has
 interfaces on multiple different technologies with multiple different
 network operators and different subscriber credentials.  There is no way
 to enforce that all sessions go to the same LMA.  Besides, why is this
 even necessary?  The section does not give a concrete justification for
 why all the sessions need to go through the same LMA.

 Minor issues:

 Section 5.2:
    Otherwise, the rfLMA MUST act as a normal RFC 5213
    defined LMA for the MAG.
 The sentence just prior talks about rejecting the PBU with a PBA 130
 Insufficient resources.  I think you need an extra if clause here:
    If the rfLMA is able to make the assignment to an r2LMA,
    it returns a PBA with the Redirect extension as defined
    below.  Otherwise, the rfLMA MUST act as a normal RFC 5213
    defined LMA for the MAG.

 You need a paragraph at the end of Section 5.2 that describes what is
 about to happen in the document:
    We next describe two models for the runtime assignment of
    the LMA.  In Section 5.3, we describe a model where the
    assignment by the rfLMA and the binding at the r2LMA are
    created at the same time.  This scenario is optimized for
    the case where the rfLMA and r2LMA are co-located or
    integrated by a "proxy MAG" protocol which is described
    in Section 5.3.4.  In Section 5.4, we describe a mode where
    the assignment by the rfLMA takes place first, and then the
    binding at the r2LMA is created by a separate PBU/PBA
    exchange that happens in a second round-trip.
 When I first read Section 5.3 I thought it was the only model being
 supported and was quite concerned.

 Nits/editorial comments:

 Section 1:
    reasons, why
 SHOULD BE:
    reasons why

    practise
 SHOULD BE:
    practice

    in-line what
 SHOULD BE:
    in-line with what

 Section 3:
    domain, is not
 SHOULD BE:
    domain is not

    assignment, unless
 SHOULD BE:
    assignment unless

 Section 4.1:
    There can zero
 SHOULD BE:
    There can be zero

 Section 5.1:
    the of the
 SHOULD BE:
    the

 Section 5.2:
    a reason or other
 SHOULD BE:
    some reason

    The rfLMA MUST only assign the MAG with a new r2LMA that it knows the
    MAG has a SA with or the MAG and the r2LMA are able to create it
    dynamically.
 SHOULD BE:
    The rfLMA MUST only assign the MAG to a new r2LMA with which it knows
    the MAG has an SA or with which it knows the MAG can establish an SA
    dynamically.

    and the r2LMA, are again deployment
 SHOULD BE:
    and the r2LMA are again deployment

    transport, if the MAG
 SHOULD BE:
    transport if the MAG

 Section 5.3.1:
    Address where the PBU was sent to
 SHOULD BE:
    Address to which the PBU was sent

 Section 5.3.2:
    considerations has to taken
 SHOULD BE:
    considerations have to be taken

    BUL to correspond the r2LMA address
 SHOULD BE:
    BUL to contain the r2LMA address

 Section 5.3.4:
    then the proceeds as mentioned in Section 5.2), SHOULD BE:
    then the PBU is processed as described in Section 5.2,

 Section 5.4.1:
    Address where the PBU was sent to
 SHOULD BE:
    Address to which the PBU was sent

-- 
---------------------------------------+------------------------------------
 Reporter:  basavaraj.patil@…          |       Owner:  jouni.nospam@…        
     Type:  defect                     |      Status:  new                   
 Priority:  major                      |   Milestone:                        
Component:  redirect                   |     Version:                        
 Severity:  -                          |    Keywords:                        
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/9>
netext <http://tools.ietf.org/netext/>