Subject: [Gen-art] Genart last call review of draft-ietf-dmm-mag-multihoming-03

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Jun 2017 12:26:06 -0700

Reviewer: Robert Sparks
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dmm-mag-multihoming-03
Reviewer: Robert Sparks
Review Date: 2017-06-14
IETF LC End Date: 2017-06-16
IESG Telechat date: Not scheduled for a telechat

Summary: Not Ready

This document has several issues that need to be addressed before publication
as a proposed standard.

1) The document defines some wire syntax, but does not define (or refine) the
protocol for using these bits of wire syntax. For instance, the document does
not discuss if/when the MAG Identifier Option is necessary. It does not
discuss when the new error code it defines should be sent, nor what a recipient
should do if it receives that error code (I would have expected discussion
similar to some of the paragraphs in sections 5.4.1.2 and 6.9.1.2 of RFC5213).

2) There are sentence fragments that indicate information was lost at some
point in editing. 

    - "In the continuation of c, a Proxy" : what should have been where the 'c'
      is?

    - "or at When operating" : This looks a clause (and the end of a sentence)
      was lost after 'or at'. 'When operating' is clearly starting a new
      sentence.

Nits: 

* How are Preference Settings either a goal or a benefit? It seems out of 
  place in the list.
  
* at "leverage on latest" do you mean "leverage the latest"?
  
* at "allowing to make appropriate traffic steering decision", _what_ are you
  allowing to make a decision (who is the actor)?
  
* 'For example, the operator may have policy which binds traffic for 
   Application "X" needs to interface with Label "Y".' does not make sense. 
   Is the word "needs" extraneous?
  
* The last sentence in the definition of the Binding-Identifier appears to be
  describing the Interface Label.
  
* Something is missing at "and either based on" in the security considerations
  section.
  
* Consider using RFC8174 instead of RFC2119

---

From: <[email-masked]>
Date: Thu, 29 Jun 2017 14:53:57 +0000

Hello,

Thanks for the review; please find below clarifications and answers. We will update the document accordingly.

Regards,

> -----Message d'origine-----
> De : Robert Sparks [mailto:[email-masked]]
> Envoyé : mercredi 14 juin 2017 21:26
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Genart last call review of draft-ietf-dmm-mag-multihoming-03
>
> Reviewer: Robert Sparks
> Review result: Not Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
> (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
> Chair.  Please treat these comments just like any other last call comments.
>
> This document has several issues that need to be addressed before publication as
> a proposed standard.
>
> protocol for using these bits of wire syntax. For instance, the document does not
> discuss if/when the MAG Identifier Option is necessary. It does not discuss when
> the new error code it defines should be sent, nor what a recipient should do if it
> receives that error code (I would have expected discussion similar to some of the
> paragraphs in sections 5.4.1.2 and 6.9.1.2 of RFC5213).
>

> For instance, the document does not discuss if/when the MAG Identifier Option is necessary.

The following text covers that aspect:

"The MAG Multipath-Binding option is a new mobility header option
defined for use with Proxy Binding Update and Proxy Binding
Acknowledgement messages exchanged between the local mobility anchor
and the mobile access gateway.

This mobility header option is used for requesting multipath support.
It indicates that the mobile access gateway is requesting the local
mobility anchor to register the current care-of address associated
with the request as one of the many care-addresses through which the
mobile access gateway can be reached.  It is also for carrying the
information related to the access network associated with the care-of
The MAG Multipath-Binding option has an alignment requirement of
 8n+2.  Its format is as shown in Figure 3:”

>  It does not discuss when the new error code it defines should be sent, nor what a recipient should do if it receives that error code (I would have expected discussion similar to some of the paragraphs in sections 5.4.1.2 and 6.9.1.2 of RFC5213).

Reasons for the LMA to send error code are as follows

- The LMA does not support multiple care-of-address registration
- a binding entry with the requested Care-of-address already exist

We will clarify this point and expecting MAG behavior as well.

> 2) There are sentence fragments that indicate information was lost at some point in
> editing.
>

From version1:

   In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based multi homed achitecture could be defined.

We can delete this sentence as the next sentence covers this point.

> * How are Preference Settings either a goal or a benefit? It seems out of

One may prefer one access network over other. Example: Use Wi-Fi when its available and do not use LTE. One can extend this further and provide preference settings that allow Voice traffic to go only over LTE.

> * at "leverage on latest" do you mean "leverage the latest"?

OLD:
The motivation to update [RFC4908]  with proxy Mobile IPv6 is to leverage on latest mobility working group achievements, namely:

NEW:

>   describing the Interface Label.

Interface label is a descriptive string. Binding identifier is an identifier for the binding. Each Binding  is tied to an interface on the MAG.

      This 8-bit field is used for carrying the binding identifier.  It
      uniquely identifies a specific binding of the mobile node, to
      which this request can be associated.  Each binding identifier is
      represented as an unsigned integer.  The permitted values are 1
      through 254.  The BID value of 0 and 255 are reserved.  The mobile
      access gateway assigns a unique value for each of its interfaces
      and includes them in the message.

> * Something is missing at "and either based on" in the security considerations
OLD:
   This essentially allows the mobile node's IP traffic to be
   routed through any of the tunnel paths and either based on a static
   or a dynamically negotiated flow policy.

NEW:

   This essentially allows the mobile node's IP traffic to be
   routed through any of the tunnel paths, based on a static
   or a dynamically negotiated flow policy.

> * Consider using RFC8174 instead of RFC2119

OK

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.