Re: Adam Roach's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT)

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


>
>