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:rjsparks(_at_)nostrum(_dot_)com]
Envoyé : mercredi 14 juin 2017 21:26
À : gen-art(_at_)ietf(_dot_)org
Cc : ietf(_at_)ietf(_dot_)org; dmm(_at_)ietf(_dot_)org;
draft-ietf-dmm-mag-multihoming(_dot_)all(_at_)ietf(_dot_)org
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.
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).
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.
- "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.
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.
Nits:
* How are Preference Settings either a goal or a benefit? It seems out of
place in the list.
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:
The motivation for this work is to extend Proxy Mobile IPv6 protocol with
multihoming extensions [RFC4908] and realize the following capabilities:
* 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.
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
section.
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.