Hi Ben, Please see answers in line for PART-II. > -----Original Message----- > From: Ben Campbell [mailto:ben@xxxxxxxxxxxx] > Subject: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 > > 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 wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-mext-binding-revocation-10 > Reviewer: Ben Campbell > Review Date: 25 Aug 2009 > IESG Telechat date: 27 Aug 2009 > > Note: I was assigned to review revision 08 of this draft for > the last call ending 28 Aug, as well as this version (10) for > the 27 Aug Telechat. This review serves both purposes. > > Summary: This draft is on the right track, but there are open > issues. > Additionally, I have a number of editorial comments. > [PART-II] > > Nits/editorial comments: > > -- General: > > This draft has some significant organization issues that make > it harder to read than it needs to be. In particular, the > sections that discuss protocol details keep repeating text > that is effectively the same for each type of device. It > would be much easier to read if you did things like separate > out acknowledgement handling, race condition handling, > binding identification, retransmissions, handovers, etc into > their own sections, and have the sections on specific device > roles only discuss things specific to those devices. You have > some of the common bits separated out, but you still repeat > them over and over in the role specific sections. Not only is > this hard to read, it is prone to error. [Ahmad] Thanks. I appreciate this comment. Will make every effort to correct any error or unnecessary duplication. It may be worth noting that describing a protocol which handles the interactions of several entities and usecases that are established using different protocols is not the easiest job ever:) > > As an example, I found that this structure confused my > attempts to understand when an acknowledgement is required. > Some sections said "if the Acknowledge bit was set", but > other sections that did not mention the A bit also required > acknowledgement. [Ahmad] I think we discussed this in PART-I and will follow up on your follow-up comments after addressing all of PART-II comments. > > The sentence structure tends to be very long and wordy, with > very little punctuation. This is aggravated by the fact that > you don't make use of the acronyms and device role names once > you establish them. For example, spelling out phrases like > Binding Revocation Indication and Local Mobility Anchor every > time they are used makes for very long sentences. [Ahmad] I see what you are saying. However, we are trying to follow the style of main IP mobility protocols specifications. It seems that there are two styles for doing this. One is to always use acronyms as soon as they are established. TWO: do not use acronyms except in figures and tables, if they exist and text related to them. I personally prefer a combination of these two styles but the comments we received earlier during the development of this specification is to use one or the other:) > > Please proof read the draft again. [Ahmad] Sure. Will try again. Appreciate your effort in finding some of them; I should say many! > I found lots of missing > articles and plural/singular mismatches. I report a few of > these below, but I gave up on capturing them part way > through. The RFC editor will probably fix any of these that > get through, but if you fix it yourself, there is less danger > of the meaning being changed by edits. [Ahmad] Will do our best to catch the remaining ones. > > -- S1, paragraph 2: > > Please expand MH on first use. [Ahmad] Ok. > > "notify its local mobility anchor peer with a bulk termination" > > Does it really notify "with" a bulk termination, or "about" a > bulk termination? [Ahmad] Thx. Will use about. > > -- S3: "describe the protocol overview" > > s/describe/present [Ahmad] Ok. > > -- S3.1, paragraph 1:"the Acknowledge (A) bit is set" > > The description seems to mix the two elements--the > notification and the request for acknowledgement. It might be > easier to read and understand if you separated out a single > section on sending BRA when the A bit is set, rather than > repeating it for each scenario. > > -- Paragraph 3: "On the other hand, the mobile access gateway > usually sends a de- registration message by sending a Proxy > Binding Update with a lifetime of zero to indicate to the > local mobility anchor of the termination of the PMIPv6 mobile > node binding registration." > > Sentence logic is inverted. Suggest " ... indicate the > termination...to the local mobility anchor" This sentence > structure repeats throught the document. While the inverted > form is not technically wrong, it's difficult to read (for > me, anyway). > > -- Last Paragraph: "anchor, mobile access" > > I suggest " ...anchor, or mobile access gateway..." [Ahmad] Ok. Thx. > > -- S3.2, first sentence > s/Binding.../The Binding... [Ahmad] Ok. > > -- Same paragraph, last sentence: > > Do you mean "user" or "mobile node"? [Ahmad] I meant the user, because if the reason, administrative, then it probably requires the user intervention. > > -- S3.3, title: > > s/"Multi-Care of"/"Multiple Care-of" [Ahmad] Ok. > > -- 3.4, first paragraph: "...where Binding Revocation > mechanism is needed..." > > s/Binding/"The Binding" [Ahmad] Ok. > > -- S3.4.1, first paragraph, first sentence: > > Unclear sentence: What is doing the "hosting"? The LMA, the > MAG, or the BRI message? I think you mean the MAG, but the > sentence structure is ambiguous. [Ahmad] What about the following? " The local mobility anchor may send a Binding Revocation Indication message with the appropriate revocation trigger value to the mobile access gateway which hosts a specific PMIPv6 binding to indicate that the mobile node binding has been terminated and the mobile access gateway can clean up the applicable resources. " > > -- same paragraph: "In this case, the mobile access gateway > could send a Router Advertisement message to the mobile node > with the home network prefix valid lifetime set to zero." > > In order to accomplish what? [Ahmad] Since in PMIPv6, the MN does not participate in any mobility signaling, the mobile node is not aware that the advertised HNP is not anchored at the MAG. So, when the MAG receives a BRI for a specific binding, i.e., specific HNP binding to the current pCoA, the MAG clears associated resources; but until the mobile node receives such Router Advertisement, it wont know that it CAN not use this HNP. > > -S 7.1, first paragraph: "node, initiator, constructs" > > Confusing sentence structure. Is "initiator" a name for the > sending mobility node? If so, it would help to use it later [Ahmad] Sure. Will remove it. > (the next paragraph uses the same structure again.) > > -- 2nd paragraph: "In the BRI message, the initiator MUST set > the Sequence Number field to the next sequence number > available for Binding Revocation" > > Does this conflict with the section 6.1 statement that it > "could be random" [Ahmad] I do not see a conflict with sec 6.1. If the sequence random is set using a random generator, then the next sequence number is random too. > > -- Same Paragraph: "Since sending Binding Revocation > Indication message is not done on a regular basis, a 16 bit > sequence number field is large enough to allow the initiator > to match the Binding Revocation Acknowledgement to the > outstanding Binding Revocation Indication with Acknowledge > (A) bit set using the sequence number field only." > > Sentence is hard to follow. I suggest separating the idea > that you can match BRAs to BRIs with a 16 bit sequence number > from the idea that you only get a BRA if the BRI had it's A bit set. > [Ahmad] Sure. What about the following: "Since sending Binding Revocation Indication message is not done on a regular basis, a 16 bit sequence number field is large enough to allow the initiator to match the Binding Revocation Acknowledgement to its outstanding Binding Revocation Indication that had the Acknowledge (A) bit set." > -- last paragraph: "A mobility entity MUST secure Binding > Revocation Indication and Binding Revocation Acknowledgement > messages with the same underlying security association, e.g., > IPsec SA, that has been used to secure the mobile node > binding registration signaling." > > You stated this normatively in section 4. Also, that section > said "if IPSec is used"--what if it's not? [Ahmad] Will follow on this in PART-I. > > -- S7.2, paragraph 2: "Since some mobility entities, e.g., > local mobility anchor and mobile access gateway, are allowed > to receive and possibly send a Binding Revocation Indication > or Binding Revocation Acknowledgement for different cases, > therefore, if IPsec is used to secure signaling between the > local mobility anchor and mobile access gateway, it prevents > any of them from processing a Binding Revocation message that > was not constructed by an authorized party." > > I have trouble parsing this sentence. > > -- Paragraph 3: "Upon receiving a packet carrying a Binding > Revocation Indication or Binding Revocation Acknowledgement, > the receiving mobility entity verifies that the packet was > received protected with the security association that has > been used during the binding registration signaling phase, > e.g., an IPsec SA." > > Normative? [Ahmad] Sure. Will use "MUST verify". To make it clearer, what about the following: " Upon receiving a packet carrying a Binding Revocation Indication or Binding Revocation Acknowledgement, the receiving mobility entity MUST verify that the packet was received protected with the security association that is being used for the protection of the binding registration signaling between the two peers, e.g., an IPsec SA. " Hopefully this clarifies the question related "if SA has been renewed etc." > > -- paragraph 5: "value that NOT supported" > > Normative NOT does not make sense here. I think you meant > "... set to a value that is not supported." [Ahmad] Yes. Thx. > > -- S 8.1, 2nd bullet: "The Revocation Trigger may be used by > the mobile node to take further steps if necessary" > > I'm not sure what this means. More specification needed? [Ahmad] I think this is similar to the comment about S11.1. in PART-I. I assume it is resolved. > > -- 4th bullet: "unless an Alternate Care-of Address mobility > option is included" > > In which case you do what? [Ahmad] Thanks! It is a long story:) What it means here is the following: The destination IP address of the packet is set to the care-of address. However, if the home agent include an Alternate care-of address option in the BRI, the destination IP address MUST NOT be set to the care-of address. When the home agent is able to include an Alternate Care-of Address in the BRI? ONLY when the mobile node sends a BU message with the Alternate Care-of address included in the BU. If the MN include the Alternate Care-of address inside the BU, the source IP address of the packet carrying the BU is different than the IP address inside the Alternate Care-of address. NOW: It depends on the home agent implementation: 1. The home agent can send the BRI message to the care-of address regardless, if this care-of address received as the source IP address of the packet carrying the BU or inside the BU in the Alternate Care-of address option. 2. If the home agent saves the source address of the packet carried the BU in addition to the MN care-of address in the MN BCE, then the home agent can send the packet that carries the BRI message to the source IP address of the packet that carried the BU. 3. Depends on implementation of the home agent, the home agent may send the BRI to the MN care-of address all the time. The key point here is: If the HA include the Alternate care-of address inside the BRI, then the destination IP address of the packet carrying the BRI is set to the source IP address of the packet that carried the BU. All of this to avoid a long debate and allow all options to exist without mandating one or the other. One more clarification: when it says the "care-of address of the Binding" it means the care-of address that the home agent is saving inside the MN BCE. > > -- 1st paragraph after bullets: "terminating its IP connection" > > What do you mean by terminating an IP connection? [Ahmad] Removing the mobile node routing entry that associates the mobile node HoA to the IP-in-IP tunnel pointing to the mobile node care-of address. In other words, the MN will not be reachable using its HoA, Home Address. > > -- 2nd para after bullets: > > Please expand BCE on first use. [Ahmad] Sure. > > -- S9.1.1, third bullet: "The Revocation Trigger may be used > by the mobile access gateway to learn the mobile node's > latest movement." > > I don't understand what you mean here. [Ahmad] The Revocation Trigger has some values like: Inter-MAG handover Same access type, inter-MAG handover different access type, etc. When the MAG receives a such BRI, the MAG learns something about the MN movement and may verify if the MN is still attached or not. > > -- 7th bullet: > > Please expand HNP on first use. [Ahmad] Sure. > > -- last bullet: "unless an Alternate Care-of Address mobility > option is included in the Binding Revocation Indication message." > > in which case do what? [Ahmad] The same comment as the one under 4th bullet of S8.1. > > -- S 9.1.2, last bullet: "SHOULD examine mobility options" > > What will it do with them? Is there more guidance that can be > offered, or is it entirely a matter "local policy"? [Ahmad] If the status is partial success, the MAG may include the HNP options of the mobile nodes which failed revocation. In the case of Binding Does Not exist, the BRA may include the HoA, etc. It becomes useful, if the LMA/HA per local policy is required to log the event, it could list those mobile nodes HNP(s) or HoA. > > S 9.2.1, first bullet: "Binding Revocation Indication is > formatted as in Section 6.1" > > Missing word(s)? Did you mean to say "Validate that..." [Ahmad] Yes. Thanks. > > -- 2nd bullet: "If the Global (G) bit is set and the > Revocation Trigger value is "Per-Peer Policy", the Proxy (P) > bit MUST be set and the Binding Revocation Indication SHOULD > contain the mobile access gateway ID in the MN-ID option." > > What if it's not? [Ahmad] If the MN-ID option is not included, the LMA will not be able to verify whether the MAG is authorized to use Global revocation or not. In this case, the LMA sends a BRA with status code "Global Revocation NOT Authorized". > Also, the language here sounds more like > you are talking about the initiator. The responder validates > these are true, but does not set the values, correc"t" [Ahmad] True. Will reword it. > > -- Bullet 5: > > Why not MUST? [Ahmad] Good question. Since the sub-bullets include the proper normative, I believe we can remove "SHOULD" and rely on the sub bullet normative text. " o If the Global (G) bit is NOT set, the local mobility anchor uses the included mobility options to identify the impacted mobile node binding as follows: " > > -- S 10.1.1, paragraph 1: "MUST validate the packet > according to Section 7.2 and the following" > > Much of "the following" involves things well beyond validation. [Ahmad] Sure, what about "MUST process"? > > -- 4th bullet: "which SHOULD include at least the MN-ID option" > > What if it doesn't? [Ahmad] The MAG should silently discard the BRI. > (and this seems like a strange place for > a normative SHOULD, as we are talking about responder > behavior not initiator behavior.) [Ahmad] Will reword it to say: If only the MN-ID is included, ... Will also check to see if a normative text is needed under the MAG being a sender and fix it accordingly. > > -- 5th bullet: "The mobile access gateway SHOULD validate > that the mobile node is no longer attached to the mobile > access gateway before sending a successful Binding Revocation > Acknowledgement message to the local mobility anchor. > However, if the mobile access gateway verified that the > mobile node is still directly attached, the mobile access > gateway MUST set the status field in the Binding Revocation > Acknowledgement to "Revocation failed - MN is Attached"." > > These two sentences seem to contradict each other. I think > you mean to check if the node is attached, then do one thing > if not and another thing if it is. [Ahmad] That is what the text supposed to mean. Will replace the word "validate" by "ensure" for the bullet to read as follows: " o If the Revocation Trigger field value in the received Binding Revocation Indication message indicates inter-MAG handover, e.g., Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set, the mobile access gateway uses the mobility option(s) included in the Binding Revocation Indication message to identify the mobile node binding. The mobile access gateway SHOULD ensure that the mobile node is no longer attached to the mobile access gateway before sending a successful Binding Revocation Acknowledgement message to the local mobility anchor. However, if the mobile access gateway verified that the mobile node is still directly attached, the mobile access gateway MUST set the status field in the Binding Revocation Acknowledgement to "Revocation failed - MN is Attached. " > > -- S 10.1.2, title: "Sending Binding Revocation Acknowledgement" > > The previous section said a lot about sending BRAs as well. [Ahmad] Okay; will see if we can optimize. > > -- S 11.1, 5th bullet: "with this home address are being revoked" > > s/are/as > > -- bullet 6: "has multi Care-of Address bindings" > > s/multi/multiple [Ahmad] Sure. > > -- same bullet: "consider all of its registered care-of > addresses bindings with this home address are being revoked" > > s/are/as [Ahmad] Sure. Thx. > > -- IANA considerations: "<IANA-TBD>" > > It's worth noting to the RFC editor to please replace this > with the actual value assigned by IANA. [Ahmad] Sure. > > "Binding Revocation Message" > > Can you include a URL pointing to the table that this is to > be inserted into? > > "new name space" > > Where does the new name space go? Can you offer a URL to the > registry for it? (applies to all 3 name spaces) > > Also, in the various name spaces, do you want a column > indicating what RFC or other document specifies a given value? [Ahmad] Yes. IANA has already created those fields as needed. Do you think that we still need a URL, etc.? > > -- References: > > A later version (-15) exists of > draft-ietf-netlmm-pmip6-ipv4-support-14 [Ahmad] Sure; it came out after we published revision 10. Once again, Thanks a lot for the detailed and thorough review, we appreciate it! Regards, Ahmad > > > > > > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf