Hi Adam, Thank you for the review. Please see inline.
Sri On 8/15/17, 11:33 PM, "Adam Roach" <[email protected]> wrote: >Adam Roach has entered the following ballot position for >draft-ietf-dmm-mag-multihoming-04: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Figure 1 labels the bottom-left most construct "Flow0-4" -- I suspect this >should be "Flow-4." Ack. > >I see the requests to remove MPTCP from the document, and the rationale >seems >sound. If, by some chance, any mention of MPTCP remains in the final >version, >please make sure it gets expanded (as an acronym) and cited. Please see new text that we discussed with Warren > >The final paragraph in section 3.2 starts with "Because latency introduced >by..." -- this isn't the reason damage can arise. The problem is the >*variation* in latency. Suggest something like: "Because the variation in >packet latency, also known as jitter, introduced by per-packet scheduling >between access networks can cause..." Please see the new text that we discussed with Warren > >Section 4.1, definition of If-ATT -- suggest citing the specific section: >"[RFC5213] section 8.5." Ack > >Section 4.1, definition of If-Label -- the value of 0 appears to be >reserved? >Ideally, this would prescribe specific behavior for an LMA if they >receive an >If-Label of 0. No real reason as with most fields we just eliminated zero value field. > >Section 4.1, definition of BID -- same comment; ideally, this would >specify >recipient behavior if set to 0 or 255. Same response. > >Section 4.3 defines a new response code for LMAs that don't implement this >spec. Existing, already deployed LMAs will necessarily have a different >reaction to receiving these unknown options than sending this response >code. >This section should provide guidance for MAGs letting them know what >observable >behavior they should expect when sending these options to LMAs unaware of >this >extension at all. Additionally, _if_ such observable behavior is >sufficient for >the MAG to understand what is happening, I would assert that the new >response >code is unnecessary and should be removed. Ack. We will add a sentence on the default LMA behavior with respect to dealing with unknown options. > >Please expand the following acronyms upon first use and in the title; >see https://www.rfc-editor.org/materials/abbrev.expansion.txt for >guidance. > > - MAG - Mobile Access Gateway (in the title) > - GRE - Generic Routing Encapsulation > - LMA - Local Mobility Anchor > - LTE - Long-Term Evolution > - MN - Mobile Node > - BCE - Bonding Channel Entity Ack > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
