Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 20 March 2020 17:47 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671B13A0CF0; Fri, 20 Mar 2020 10:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h1uDBH3Vj7q; Fri, 20 Mar 2020 10:47:35 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09A43A0C3E; Fri, 20 Mar 2020 10:47:11 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02KHiCcS003353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 13:44:15 -0400
Date: Fri, 20 Mar 2020 10:44:12 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs <dmm-chairs@ietf.org>, dmm <dmm@ietf.org>, Dapeng Liu <max.ldp@alibaba-inc.com>
Message-ID: <20200320174412.GQ50174@kduck.mit.edu>
References: <158338573858.29475.12173301575622176655@ietfa.amsl.com> <CALypLp9NAHJppV-0bE0WTuhtFykW5D6dAKLNXApVxTO+JnBhqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALypLp9NAHJppV-0bE0WTuhtFykW5D6dAKLNXApVxTO+JnBhqQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/V9laQA7Nk9S5eZPLF8QzrYcaEfo>
Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2020 17:47:50 -0000

Hi Carlos,

Also inline (but not much left to say!)

On Sun, Mar 08, 2020 at 06:58:14PM +0100, CARLOS JESUS BERNARDOS CANO wrote:
> Hi Benjamin,
> 
> Thanks a lot for another very good review. Please find my comments inline
> below.
> 
> On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dmm-pmipv6-dlif-05: Discuss
> >
> > 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-pmipv6-dlif/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I have a very boring Discuss point and a somewhat boring point, and
> > expect to change my ballot to Yes once they're resolved.
> >
> > In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid
> > bursts when the CMD is fanning out PBUs, but in Section 6 we say that
> > pacing "SHOULD" be used; please resolve the inconsistency (preferrably
> > with "MUST" as Mirja requests).
> >
> 
> [CB] Done in version -06 (to be submitted soon).
> 
> 
> >
> > Please also include some discussion of privacy considerations (I give
> > some suggestions in the COMMENT).
> >
> 
> [CB] OK, I'll do.
> 
> 
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thanks for this well-written document!  It is clearly written, and when
> > multiple approaches exist, does well at laying out the different options
> > and their pros/cons, as befits an Experimental document.  Also, several
> > times I have started to write a comment only to realize that it is
> > answered by the following text :)
> >
> 
> [CB] Thanks, very much appreciated.
> 
> 
> >
> > Section 1
> >
> >    The Distributed Mobility Management (DMM) paradigm aims at minimizing
> >    the impact of currently standardized mobility management solutions
> >    which are centralized (at least to a considerable extent).
> >
> > I'd consider saying a little more about which aspects of their operation
> > are centralized.  Perhaps the following paragraph suffices, though.
> >
> 
> [CB] I've added another reference to RFC 7333, where this is explained in
> detail. As you mention below, we go a bit into these aspects of centralized
> operation in the following paragraph, and I personally believe it is better
> not to add too much text on this aspect (which is covered by RFC 7333).
> Please, let me know if you are not happy with this resolution.
> 
> 
> >
> >    Following this idea, in our proposal, the central anchor is moved to
> >    the edge of the network, being deployed in the default gateway of the
> >    mobile node.  That is, the first elements that provide IP
> >
> > (side note: Using the singular "central anchor" poses an interesting
> > rhetorical question: is the (formerly) single central anchor being
> > duplicated and spread amongst all access routers, or does there remain a
> > single central anchor (per MN), just one that moves around along with
> > the MN.)
> >
> 
> [CB] The whole idea of the DMM approach specified in this document is that
> we move from a "single central anchor" to a "multiple distributed anchors".
> Note that the specified approach allows for a central anchor to be still
> present (and used by an MN for communications where it is more
> appropriate), but this is more an operational decision (probably more in
> scope of RFC 8653).
> 
> 
> >
> >    anchors to retrieve the MN's previous location(s).  Also, a key-
> >    aspect of network-based DMM, is that a prefix pool belongs
> >    exclusively to each MAAR, in the sense that those prefixes are
> >    assigned by the MAAR to the MNs attached to it, and they are routable
> >    at that MAAR.
> >
> > It might be worth some statement relating this "ownership" of prefixes
> > to actual mobility events -- e.g., they are assigned to MNs attached to
> > it at that time, but remain with those MNs as mobility occurs, but
> > always remain routable at that MAAR as well as towards the MN itself.
> >
> > [CB] OK, I've added a sentence adopting part of your text. Thanks.
> 
> 
> >    We consider partially distributed schemes, where the data plane only
> >    is distributed among access routers similar to MAGs, whereas the
> >
> > nit: I suggest s/the data plane only/only the data plane/
> >
> 
> [CB] OK, thanks.
> 
> 
> >
> >    control plane is kept centralized towards a cardinal node used as
> >    information store, but relieved from any route management and MN's
> >    data forwarding task.
> >
> > What's the scope of "single" here -- per deployment, per prefix, per
> > MAAR, ...?
> >
> 
> [CB] Sorry, I don't get this comment. I don't see "single" mentioned in the
> quoted textl

Sorry!  I was assuming that the "cardinal node" was a single centralized
information store, and that's the "single" I was trying to ask about.
Re-reading, I would assume that this "cardinal node" is per deployment, so
it may not be worth changing the text if that's in fact the case.

> 
> >
> >    P-MAAR (Previous MAAR).  When a MN moves to a new point of attachment
> >       a new MAAR might be allocated as its anchor point for future IPv6
> >       prefixes.  The MAAR that served the MN prior to new attachment
> >       becomes the P-MAAR.  It is still the anchor point for the IPv6
> >       prefixes it had allocated to the MN in the past and serves as the
> >
> > (side note? Do we expect those previous allocations to eventually "time
> > out" as sessions using them terminate?  Or are the allocations more
> > permanent, with intent to reuse if/when the MN returns to that MAAR?)
> >
> 
> [CB] The expectation is that previous allocations will eventually time-out
> as sessions using them terminate.
> 
> 
> >
> > Section 3
> >
> >    interest and eventually take the appropriate action.  The procedure
> >    adopted for the query and the messages exchange sequence might vary
> >    to optimize the update latency and/or the signaling overhead.  Here
> >
> > nit: wrong pluralization in "messages exchange sequence"
> >
> 
> [CB] OK, fixed.
> 
> 
> >
> > Section 3.1
> >
> >    3.  Since this is an initial registration, the CMD stores a permanent
> >        BCE containing as primary fields the MN-ID, Pref1 and MAAR1's
> >        address as a Proxy-CoA.
> >
> > [how permanent is "permanent"?]
> >
> 
> [CB] I've removed "permanent" as it is not really needed. The BCE stays at
> the CMD until the session is de-registered (it is "more permanent" that the
> BCEs at the P-MAARs).
> 
> 
> >
> > Section 3.2
> >
> >    1.  When the MN moves from its current point of attachment and
> >        attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6
> >        prefix (Pref2), it stores a temporary BCE, and it sends a plain
> >        PBU to the CMD for registration.
> >
> > It's not clear to me at this point how MAAR2 has enough information to
> > determine that this will be a "plain" PBU vs. the the PBU used for
> > initial registration.  (That said, it's also not clear to me that the
> > send PBU actually differs on the wire, so maybe this is just a
> > rhetorical question.  Er, a question of rhetoric, that is.)
> >
> 
> [CB] They are actually the same PBUs, as MAAR2 does not know at that point
> if the MN had been already registered. Both PBUs would be "plain". I've
> removed "plain" and "another" to make it clearer.
> 
> 
> >
> >    4.  The CMD, after receiving the PBA, updates the BCE populating an
> >        instance of the P-MAAR list.  The P-MAAR list is an additional
> >        field on the BCE that contains an element for each P-MAAR
> >        involved in the MN's mobility session.  The list element contains
> >        the P-MAAR's global address and the prefix it has delegated (see
> >        Appendix B for further details).  Also, the CMD sends a PBA to
> >        the new S-MAAR, containing the previous Proxy-CoA and the prefix
> >        anchored to it embedded into a new mobility option called
> >        Previous MAAR Option (defined in Section 4.5), so that, upon PBA
> >        arrival, a bi-directional tunnel can be established between the
> >        two MAARs and new routes are set appropriately to recover the IP
> >        flow(s) carrying Pref1.
> >
> > To check my understanding: there will only be one Previous MAAR Option
> > present and it will describe only a single MAAR, which implies that if
> > there are multiple P-MAARs, traffic directed to an arbitrary prefix
> > based at one of them is expected to traverse multiple tunnels from
> > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN?
> > [Hmm, looks like my understanding is wrong.  I'd consider making
> > "previous Proxy-CoA" and "the prefix anchored to it" plural to give the
> > reader a hint as to what's coming, though I can understand if there is
> > desire to keep the initial mobility example simple and only gradually
> > introduce the complexity in question.]
> >
> 
> [CB] I've been looking at it and changing it back and forth several times.
> I prefer to keep the initial mobility example. Just to answer your
> question, in general there might be multiple options. This is what the text
> you point below should indicate (among other things).
> 
> 
> >    For MN's next movements the process is repeated except the number of
> >    P-MAARs involved increases (accordingly to the number of prefixes
> >    that the MN wishes to maintain).  Indeed, once the CMD receives the
> >    first PBU from the new S-MAAR, it forwards copies of the PBU to all
> >    the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR
> >    prior to handover) and in the P-MAARs list.  They reply with a PBA to
> >    the CMD, which aggregates them into a single one to notify the
> >    S-MAAR, that finally can establish the tunnels with the P-MAARs.
> >
> > I'm not sure I understand the cardinality of P-CoA -- is it one,
> > the single S-MAAR prior to handover, or many, all P-MAARs in the list?
> >
> 
> [CB] There are multiple P-CoAs, but current writing might lead to think
> there is only one. One P-CoA is the one listed in the BCE (the one of the
> previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I've
> rewritten a bit the text trying to make this clearer: "Indeed, once the CMD
> receives the first PBU from the new S-MAAR, it forwards copies of the PBU
> to all the P-MAARs indicated in the BCE, namely the one registered as
> current P-CoA (i.e., the MAAR prior to handover) plus the ones in the
> P-MAARs list."

Thanks, this helps a lot!

> 
> >    When there are multiple previous MAARs, e.g., k MAARs, a single PBU
> >    received by the CMD triggers k outgoing packets from a single
> >    incoming packet.  This may lead to packet bursts originated from the
> >    CMD, albeit to different targets.  Pacing mechanisms MAY be
> >    introduced to avoid bursts on the outgoing link.
> >
> > I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable
> > than "MAY" to me, here.
> >
> 
> [CB] Actually, based on other comments we have decided to go for "MUST".

Indeed.  (It looks like I forgot to change this comment when I added a note
to my discuss point after I read Mirja's position.)

> 
> > Section 3.3
> >
> >    The handover latency experienced in the approach shown before can be
> >    reduced if the P-MAARs are allowed to signal directly their
> >    information to the new S-MAAR.  This procedure reflects what was
> >    described in Section 3.2 up to the moment the P-MAAR receives the PBU
> >    with the P-MAAR option.  At that point a P-MAAR is aware of the new
> >
> > nit(?): I think this is the S-MAAR option, not the P-MAAR option?
> >
> 
> [CB] Right! Thanks.
> 
> 
> >
> >    S-MAAR including the prefix it is anchoring.  This latter PBA does
> >    not need to include new options, as the prefix is embedded in the HNP
> >    option and the P-MAAR's address is taken from the message's source
> >    address.  The CMD is relieved from forwarding the PBA to the S-MAAR,
> >
> > (side note: this assumes there's no NAT or tunneling or similar between
> > MAARs, which seems like a plausible assumption, at least for now.)
> >
> 
> [CB] Yes, that's right.
> 
> 
> >
> > Section 3.4
> >
> >    side.  When P-MAARs complete the update, they send a PBA to the CMD
> >    to indicate that the operation is concluded and the information is
> >    updated in all network nodes.  This procedure is obtained from the
> >
> > Is there anything useful to say about behavior on timeout at the CMD
> > (failing to reive a PBA from one or more P-MAARs)?
> >
> > [CB] A new Section 3.6 "Retransmissions and Rate Limiting" has been added
> (to address also other received comments). I hope this addresses this
> comment.

It doesn't directly give guidance about the CMD's behavior as a recipient,
but it does give some more context for the expected operation of the
system, which should be enough.

> 
> > Section 3.5
> >
> >    The de-registration mechanism devised for PMIPv6 cannot be used as is
> >    in this solution.  The reason for this is that each MAAR handles an
> >
> > nit: s/as is/as-is/
> >
> 
> [CB] Fixed, thanks.
> 
> 
> >
> >    Indeed, when a previous MAAR initiates a de-registration procedure,
> >    because the MN is no longer present on the MAAR's access link, it
> >    removes the routing state for that (those) prefix(es), that would be
> >    deleted by the CMD as well, hence defeating any prefix continuity
> >    attempt.  The simplest approach to overcome this limitation is to
> >
> > nit(?): s/when/if/.  At least, this makes more sense to me if I do that
> > ... maybe I'm just confused.
> >
> 
> [CB] OK, fixed.
> 
> 
> >
> >    serving MAAR to de-register the whole MN session.  This can be
> >    achieved by first removing any layer-2 detachment event, so that de-
> >    registration is triggered only when the session lifetime expires,
> >
> > I see that RFC 5213 has some mechanisms for lifetime management, but
> > didn't get to look closely enough to understand how clear the necessary
> > lifetime management will be in the DMM case when there are multiple
> > prefixes registered to a given MN at different MAARs.  (Also, 5213
> > doesn't seem to use the "session lifetime" phrase verbatim.)
> >
> 
> [CB] I've replaced "session lifetime" with "binding lifetime" to make it
> more consistent with the terminology used in RFC 5213. Note that "mobility
> session" is used in RFC 5213.

Thanks!

> 
> >
> > Section 3.6
> >
> >    requiring special support from the mobile node's IP stack.  This
> >    document defines the Distributed Logical Interface (DLIF), which is a
> >    software construct that allows to easily hide the change of
> >    associated anchors from the mobile node.
> >
> > A software construct in the MAAR, right?
> >
> 
> [CB] Yes, I've added "in the MAAR" to the text.
> 
> 
> >
> >
> > How common is "HMAC" as an abbreviation for "hardware MAC address"?
> > It's also an abbreviation for Hash-based Message Authentication Code,
> > which confuses my poor security-focused brain, though I acknowledge that
> > this does not necessarily extend to most of the target audience for this
> > document...
> >
> 
> [CB] It is not common. To avoid potential confusions I've removed HMAC and
> just used MAC, which I think it is sufficient in the scope of this document
> (as we use LMAC for the logical one).
> 
> 
> >    and MN3, while MAAR2 is serving MN1.  MN1, MN2 and MN3 have two
> >    P-MAARs: MAAR1 and MAAR2.  Note that a serving MAAR always plays the
> >
> > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)?
> >
> 
> [CB] You are right. Here there was a mistake, as P-MAAR was being mixed
> with anchoring MAAR. I've removed that sentence to keep it clearer.
> 
> 
> >    role of anchoring MAAR for the attached (served) MNs.  Each MAAR has
> >    one single physical wireless interface.
> >
> > Have we defined "anchoring MAAR" yet?
> >
> 
> [CB] We have added a definition to the terminology section.
> 
> 
> > Also, I assume that the "single physical interface" is just "as depicted
> > in this example" and not a protocol requirement :)
> >
> 
> [CB] Yes, right.
> 
> 
> >
> >    As introduced before, each MN always "sees" multiple logical routers
> >    -- one per P-MAAR -- independently of its currently serving MAAR.
> >
> > [same P-MAAR vs. S-MAAR split as above]
> >
> 
> [CB] Right, fixed by replacing P-MAAR with anchoring MAAR.
> 
> 
> 
> >
> >    by the serving MAAR (MAAR2) configuring an additional distributed
> >    logical interface: mn1mar1, which behaves exactly as the logical
> >    interface configured by MAAR1 when MN1 was attached to it.  This
> >
> > nit(?): "exactly" is asking for pedants to try and poke holes in the
> > claimed perfection.
> >
> 
> [CB] Right, I removed "exactly".
> 
> 
> >
> >    deprecated).  The goal is to deprecate the prefixes delegated by
> >    these MAARs (which will be no longer serving the MN).  Note that on-
> >
> > nit(?): s/which will be no longer/so that they will no longer be/, IIUC
> >
> 
> [CB] Fixed.
> 
> 
> >
> > Section 4.1
> >
> > The intdir reviewer's comments regarding the flag bits seem apropos (I
> > presume they were allocated by other extensions to 5213, but we should
> > say something about it).
> >
> 
> [CB] OK, I'll address this in my response to the intdir review.

It looks like the plan is to reference the IANA registry for the flags?
That sounds good, though I assume it's still only in the editor's copy.

> 
> >
> >
> >    A new flag (D) is included in the Proxy Binding Update to indicate
> >    that the Proxy Binding Update is coming from a Mobility Anchor and
> >
> > "D" is for "DMM", I trust?  It could be worth mentioning.
> 
> 
> [CB] Yes, done.
> 
> 
> >
> 
> 
> > Is the D bit set for the PBUs sent from CMD to P-MAAR as well?
> >
> 
> [CB] Yes, I've fixed that.
> 
> 
> > (I see that the PBA description uses a slightly different formulation to
> > cover the 'D' bit; is there a reason to diverge?)
> >
> 
> [CB] No reason. I've updated the text to use the same formulation.
> 
> 
> >
> >    Mobility Options
> >
> >       Variable-length field of such length that the complete Mobility
> >       Header is an integer multiple of 8 octets long.  This field
> >       contains zero or more TLV-encoded mobility options.  The encoding
> >       and format of defined options are described in Section 6.2 of
> >       [RFC6275].  The MAAR MUST ignore and skip any options that it does
> >       not understand.
> >
> > MAARs that *receive* PBUs must be P-MAARs, right?
> >
> 
> [CB] Yes, but also a CMD. Therefore I've replaced "MAAR" with "receiving
> node".
> 
> 
> > Section 4.2
> >
> >    MAAR (D)
> >
> >       The D is set to indicate that the sender of the message supports
> >       operating as a Mobility Anchor and Access Router.  When a MAG that
> >       does not support the extensions described in this document
> >       receives a message with the D-Flag set, it MUST ignore the message
> >       and an error MUST be returned.
> >
> > Is the CMD considered a MAAR for this purpose?
> >
> 
> [CB] I've replaced "operating as a Mobility Anchor and Access Router" with
> "operating as a MAAR or a CMD".
> 
> 
> >       contains zero or more TLV-encoded mobility options.  The encoding
> >       and format of defined options are described in Section 6.2 of
> >       [RFC6275].  The MAAR MUST ignore and skip any options that it does
> >       not understand.
> >
> > What about the CMD?
> >
> 
> [CB] Same.. Therefore I've replaced "MAAR" with "receiving node".
> 
> 
> >
> > Section 4.3, 4.4
> >
> >    Prefix Length
> >
> >       8-bit unsigned integer indicating the prefix length of the IPv6
> >       prefix contained in the option.
> >
> >    Anchored Prefix
> >
> >       A sixteen-byte field containing the mobile node's IPv6 Anchored
> >       Prefix.  Only the first Prefix Length bytes are valid for the
> >       Anchored Prefix.  The rest of the bytes MUST be ignored.
> >
> > Is the prefix length bits or bytes?
> >
> 
> [CB] Bits. Fixed (also mentioned by another review).
> 
> 
> >
> > Section 4.4
> >
> > Is this also used to convey "local" prefixes in the PBA from CMD to
> > S-MAAR?  (If not, how does the S-MAAR know to advertise them from its
> > DLIF?)
> >
> 
> [CB] Yes, this is right. I've rewritten the text to reflect it.
> 
> >
> > Section 4.5
> >
> > What's the alignment requirement?
> > (There's no need to put in a Reserved octet to keep things word
> > aligned?)
> >
> 
> [CB] You are right. And this is embarrassing, as the internal code we use
> is actually using the format with the extra reserved byte that was not
> reflected in the document.
> 
> 
> >    Prefix Length
> >
> >       8-bit unsigned integer indicating the prefix length of the IPv6
> >       prefix contained in the option.
> >    [...]
> >    Home Network Prefix
> >
> >       A sixteen-byte field containing the mobile node's IPv6 Home
> >       Network Prefix.  Only the first Prefix Length bytes are valid for
> >       the mobile node's IPv6 Home Network Prefix.  The rest of the bytes
> >       MUST be ignored.
> >
> > [is the prefix length bits or bytes?]
> >
> 
> [CB] Bits. Fixed.
> 
> 
> >
> > Section 4.6
> >
> > Is there an alignment requirement for this option?
> >
> 
> [CB] Yes, added.
> 
> 
> >
> >    This new option is defined for use with the Proxy Binding Update and
> >    Proxy Binding Acknowledgement messages exchanged between the CMD and
> >
> > When is this option used in a PBA?
> >
> 
> [CB] Right, it is only used in a PBU. Fixed.
> 
> 
> >
> > Section 4.7
> >
> >    A new DLIF Link-local Address option is defined for use with the
> >    Proxy Binding Update and Proxy Binding Acknowledgment messages
> >    exchanged between MAARs.  This option is used for exchanging the
> >
> > MAARs but not CMDs?
> > When is this used in the PBU?
> >
> 
> [CB] Also CMDs. And only in PBA. Fixed.
> 
> 
> >
> > Section 4.8
> >
> >    A new DLIF Link-layer Address option is defined for use with the
> >    Proxy Binding Update and Proxy Binding Acknowledgment messages
> >    exchanged between MAARs.  This option is used for exchanging the
> >
> > MAARs but not CMDs?
> > When is this used in the PBU?
> >
> 
> [CB] Same as before.
> 
> 
> >
> > Section 6
> >
> > Unfortunately it seems that RFC 5213 does not include any privacy
> > considerations discussion.  While the privacy properties of this
> > protocol bear similarities to those of RFC 5213, it seems that there are
> > also some significant differences, so I do think it is important to
> > produce some documentation of privacy considerations for this document.
> > The main factor would, of cousre, be tracking which entities obtain
> > updates/information about the location of the MN, what those entities
> > are expected to do with that data, and how trusted they are to be proper
> > custodians of it.  Other factors may exist as well, including the
> > potential for side-channel information leakage, e.g., due to traffic
> > analysis.  There might also be a reverse situation where exposing the
> > link-layer address(es) of a P-MAAR have privacy considerations, though I
> > don't have anything particular in mind at the moment.
> >
> 
> [CB] OK, I see your point. I've tried to add something in version -06. Let
> me know if you think it is sufficient (I tried to keep it short and simple,
> while still addressing your point).

I think it covers the key points.  Since all the parties are highly trusted
anyway, we don't need to go into great detail.

> 
> >
> >    security concerns of Proxy Mobile IPv6 [RFC5213].  It is recommended
> >    that the signaling messages, Proxy Binding Update and Proxy Binding
> >    Acknowledgment, exchanged between the MAARs are protected using IPsec
> >    using the established security association between them.  This
> >
> > This is essentially unchanged from 5213, just with different names for
> > the endpoints, right, and so the existing guidance/experiences apply?
> >
> 
> [CB] Yes, it should apply. We haven't identified anything different.
> 
> 
> >
> > I think we should also say something about all MAARs and the CMD being
> > trusted parties.  We should also say something about the authorization
> > model (I assume it's just "all trusted parties are trusted to perform
> > all operations relevant to their role", but that's still useful to say).
> >
> 
> [CB] OK, I've added a sentence on that.
> 
> 
> >
> >    When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a
> >    single PBU to multiple previous MAARs.  In situations of many fast
> >    handovers (e.g., with vehicular networks), there may exist multiple
> >    previous (e.g., k) MAARs exist.  In this situation, the CMD creates k
> >
> > nit: remove the redundant "exist"
> >
> 
> [CB] Done.
> 
> 
> >
> >    When the CMD acts as MAAR locator, mobility signaling (PBAs) is
> >    exchanged between P-MAARs and current S-MAAR.  This requires security
> >    associations to exist between the involved MAARs (in addition to the
> >    ones needed with the CMD).
> >
> > Is this relevant because of scaling/resource-consumption concerns or
> > keying/trust ones?
> >
> 
> [CB] This is relevant because RFC 5213 uses a model in which signalling is
> exchanged only between LMA (the anchor) and MAGs (the access routers),
> while in this document there are some operation modes that also involve
> signalling between MAARs (the access routers). This was just to highlight
> this point (it is related to the point you made before about the trust
> model).

Okay, thanks for the clarification.

> 
> >
> > Appendix A.5
> >
> >    not implement existing mobility protocols.  Furthermore, a DMM
> >    solution SHOULD work across different networks, possibly operated as
> >    separate administrative domains, when the needed mobility management
> >
> > Hmm, separate administrative domains makes the risk of NAT relatively
> > higher (per previous comment about NAT).
> >
> >    intervention.  The partially distributed DMM solution can be deployed
> >    across different domains with trust agreements if the CMDs of the
> >    operators are enabled to transfer context from one node to another.
> >
> > It would probably be worth expounding a bit more about this scenario and
> > the necessary trust/authorization relationships, in the security
> > considerations.
> >
> > [CB] As per other comment from IESG evaluation I've removed the two
> appendixes.
> 
> Huge thanks for your very good points!

And thanks for all the updates!
I will go update my ballot position now.

-Ben