I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
