Thanks Pete for extensive review. I'll come back to your major issues in a bit.
- Jouni On Apr 14, 2011, at 10:23 PM, Pete McCann wrote: > 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
