[Ballot comment]
Thank you for the work put into this document. It is really easy to read with very nice ASCII art figures.

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
As my esteemed colleague from East US Coast, I liked the introduction but I would prefer to have the EARO acronym expanded.

-- Section 2.3 --
I wonder whether using "6LBBR" would be more readable and consistent (with "6LN" and "6LBR") than using "6BBR"

-- Section 3 --
Should the method to achieve "ensure that the Address is not duplicated over the Backbone" be specified? E.g., DAD ?

-- Section 3.2 --
"The RS sent initially by the 6LN(STA) is transmitted as a multicast
  but since it is intercepted by the 6BBR, it is never effectively
  broadcast."
Perhaps worth mentioning "layer-3 multicast" hence "layer-2 broadcast"... And "never... broadcast" it would important to mention the scope of the broadcast. This ambiguity about layer & scope happens quite often in the document. Knowledgeable readers will understand of course but what about less knowledgeable ones?

== NITS ==

I found the use of acronyms a little too heavy, complicating the reading for little benefits: e.g., ODAD = Optimistic DAD, SLLAO = Source LLA Option. On the contrary, well-known acronyms are not used :-) E.g., multiple instance of "Link Local addresses" rather than the well-known "LLA".

In the same vein, it is sometimes "Layer 2 Address" and other times "MAC address"

[Ballot discuss]
Section 11.  Can assumptions of the about the security properties of the links be clarified.

This specification applies to LLNs and a backbone in which the
  individual links are protected against rogue access, e.g., by
  authenticating a node that attaches to the network and encrypting at
  the MAC layer the transmissions that may be overheard.  In
  particular, the LLN MAC is required to provide secure unicast to/from
  the Backbone Router and secure Broadcast from the Backbone Router in
  a way that prevents tampering with or replaying the RA messages.

-- what are the specific assumptions about the protections that will be on the link.  Is the list of properties in the “e.g.” the full list?

-- As the second sentence references the only the LLN MAC, using Figure 1 and 2 as a reference (realizing they are non-normative), what’s expected properties of the links between the router-and-6BBR or IPv6 node-and-6BBR (i.e., the links connecting to the “backbone side”)?

[Ballot comment]
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

[Ballot comment]
I'm curious if what is specified in this document affects any of the considerations discussed in RFC 8505 Section 8 about how addresses should be formed. RFC 8505 discourages the use of EUI-64 to form IIDs, while this spec seems to incentivize or at least make possible use cases where the 6LBR has to store MAC addresses in order to serve as a mapping server. Should this document discuss the privacy considerations associated with Bridging Proxy mode?

[Ballot comment]
For what it's worth, I disagree with my distinguished colleague from London: I find the extensive background given in the Introduction to be readable and useful.

[Ballot comment]
The introduction is hard to read for an non expert like me. It reads “blah blah ... excessive traffic generated, can be optimised”. I think it can be made shorter and crisper.

[Ballot discuss]
Thanks for this -- it was a good read.  I just have a few super-boring
poitns of apparent internal inconsistency to fix before publication.

There seems to be an internal inconsistency relating to the handling of
link-local addresses by a Bridging Proxy: Section 8 descriptively says
that such addresses are (always) registered ("[t]he Bridging Proxy
registers any Binding including for a Link-Local address to the 6LBR"),
but Section 9 has this behavior as optional ("[a] Bridging Proxy MAY
register Link Local addresses at the 6BBR and proxy ND for these
addresses over the backbone").

Similarly, I see Section 6 saying that when a 6BBR generates an NA in
response to an NS(DAD), it "MUST have the Override flag set", but
Section 9.2 says "MUST be answered ... the Override flag not set" (for
the "different registration" case, i.e., second bullet) and nothing at
all about the Override flag for the "not as fresh"/"Moved" case (i.e.,
the third bullet).  Am I misreading something?

Continuing the theme, Section 10 notes that a "Registering Node SHOULD
register all of its IPv6 Addresses to its 6LR, which is the 6BBR when
they are connected at Layer 2", but Appendix B states the stronger
condition that "[t]he 6BBR assumes that if a node registers at least one
IPv6 Address to it, then the node registers all of its Addresses to the
6BBR."

[Ballot comment]
In Section 3 we talk about the Binding Table as a "distributed
database", but I didn't see much further exposition on that topic.  It
would be great to have a bit of discussion about what the logical
contents of a row in the database are (e.g., IP address, MAC address,
ROVR, registration state, associated host route, ...), as well as what
the concurrency and consistency properties of the distributed database
are expected or required to be.

I also am not quite sure I understand the full picture for backwards
compatibility/incremental deployment: it seems like we may need the
6LBR(s) to be updated to support this spec before anything else can use
it, though I'm not sure.  For example, if we need both IPv6 ND's DAD and
EDAR/EDAC between 6BBR/6LBR, does that mean the 6LBR has to be updated
first?

Section 1

  Because IPv6 ND messages sent to the SNMA group are broadcast at the
  radio MAC Layer, wireless nodes that do not belong to the SNMA group
  still have to keep their radio turned on to listen to multicast NS
  messages, which is a total waste of energy for them.  In order to

nit: "total waste" might be a stronger statement than you want to have
to defend (vs. just "waste").

  These problems can be alleviated by reducing the IPv6 ND broadcasts
  over wireless access links.  This has been done by splitting the
  broadcast domains and routes between subnets, or even by assigning a
  /64 prefix to each wireless node (see [RFC8273]).

"If there are already solutions, why do we need more solutions?" ;)
(Maybe it's worth mentioning that these proposed workarounds have
weaknesses, or even what those weaknesses are.)

  Another way is to proxy at the boundary of the wired and wireless
  domains the Layer 3 protocols that rely on MAC Layer broadcast
  operations.  For instance, IEEE 802.11 [IEEEstd80211] situates proxy-
  ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs).
  The 6BBR provides a proxy-ND function and can be extended for proxy-
  ARP in a continuation specification.

nit-ish: it might be worth saying something about "in an analogous
manner" and/or "for LLNs" in the last sentence.

Section 2.2

  Sleeping Proxy:  A 6BBR acts as a Sleeping Proxy if it answers ND
      Neighbor Solicitations over the Backbone on behalf of the
      Registering Node which might be in a sleep state in a low power
      network.  The Sleeping Proxy that is also a Bridging Proxy will
      preferably forward the relevant messages to the Registering Node
      as unicast frames in accord to the duty cycle of the Registering
      Node and let it respond.

Should we expect the reader to know what "the relevant messages" are
that the bridging proxy forwards to the registering node?  Without
additional context, the text here implies that the ND NS messages are
the "relevant" ones, with the awkward implication that the 6BBR both
answers on behalf of the registering node and forwards messages to it.

  Bridging Proxy:  A Bridging Proxy provides IPv6 ND proxy functions
      while preserving forwarding continuity at the MAC Layer.  The
      Bridging Proxy advertises the MAC Address of the Registering Node
      as the TLLA in the proxied NAs over the Backbone.  In that case,
      the MAC Address and the mobility of 6LN is still visible across
      the bridged Backbone, and the 6BBR may be configured to proxy for
      Link Local Addresses.

nit: I think there's a singular/plural issue for "mobility of 6LN".

Section 2.4

nit: the current structure doesn't do a good job of indicating why the
references are grouped into bullet points as opposed to a single
consolidated list.

Section 3

nit: the list after figure 1 is missing a blank line between the last
two elements.

  *  Advertise a Registered Address over the Backbone using an
      unsolicited NA message, asynchronously or as a response to a NS
      message.  This includes joining the multicast group associated to

nit: I think the binding of "unsolicited" is not quite right, as it
currently also applies to the "as a response to a NS" case.

  The first of these functions enables the 6BBR to fulfill its role as
  a Routing Registrar for each of its attached LLNs.  The remaining
  functions fulfill the role of the 6BBRs as the border routers
  connecting the Multi-link IPv6 subnet to the Internet.

I'm a bit confused by this last sentence (probably just me, but...) --
the functions in question are things like forwarding/briding traffic
between LLN and backbone, so why is "the Internet" required to be in
play?

  The registration to a proxy service uses an NS/NA(EARO) exchange.

nit(?): does the "(EARO)" apply to just NA, or to NS as well?

  The 6BBRs use the Extended Address Registration Option (EARO) defined
  in [RFC8505] as follows:
      [...]
  *  The Link Layer Address (LLA) that the 6BBR advertises for the
      Registered Address on behalf of the Registered Node over the
      Backbone can belong to the Registering Node; in that case, the
      6BBR (acting as a Bridging Proxy (see Section 8)) bridges the
      unicast packets.  Alternatively, the LLA can be that of the 6BBR
      on the Backbone interface, in which case the 6BBR (acting as a
      Routing Proxy(see Section 7)) receives the unicast packets at
      Layer 3 and routes over.

I'm not seeing how the EARO is used as part of this.

Section 3.1

Would it be worth a forward-reference to Section 9 (for it's list of
"6LR operation is modified as follows")?

  Note: [RFC6775] requires that the registration NS(EARO) contains an
  SLLAO and [RFC4862] that the NS(DAD) is sent from the unspecified

nit: RFC 6775 predates RFC 8505 that introduces the EARO, so it's hard
to see how 6775 specifically requires this of a registration NS(EARO).

Section 3.3

side note: some of our previous discussions on 6lo documents gave me the
impression that a 6LBR was more of a privileged/distinguished thing than
Figure 4 makes it out to be, e.g., that there would be one logical 6LBR
per network.  Going back and re-reading (e.g., RFC 8505) it seems I was
mistaken, and it's okay to have many independent 6LBRs like this; they
just need to be managing distinct LLNs.

Section 3.4

  *  Identical registrations (same TID, same ROVR) from the same
      Registering Node are accepted with a status of 0 (Success).  In
      Tentative state, the response is held and may be overwritten, but

nit: is this still "the EDAC response" as in the previous item?

Section 3.5

  A 6BBR may optionally be primary or secondary.  The primary is the

I'm not sure what the "optionally" means here -- is it an implementation
choice to just not think about the question of primary vs. secondary and
alawys behave the same [as primary]?  The next paragraph implies that it
is so, but perhaps more clarity is warranted.

Section 4

  Nodes located inside the subnet do not perform the IPv6 Path MTU
  Discovery [RFC8201].  [...]

nit(?): I couldn't find where in RFC 8201 it's specified that PMTUD is
not performed for same-subnet paths; is that specified elsewhere or just
a consequence of the nature of a subnet?

Section 5

  This specification allows for an address to be registered to more
  than one 6BBR.  Consequently a 6LBR MUST be capable of maintaining
  state for each of the 6BBR having registered with the same TID and
  same ROVR.

This seems like something worth calling out in the "Updating RFC 6775"
section.

Section 6

  The 6BBR advertises and defends the Registered Addresses over the
  Backbone Link using RS, NS(DAD) and NA messages with the Registered
  Address as the Source or Target address, respectively.

nit: I don't think "respectively" is right, since there are three
elements in the first list (RS, NS(DAD), and NA) but only two in the
second (Source address, Target address).

  An NA message generated in response to an NS(DAD) MUST have the
  Override flag set and a status of 1 (Duplicate) or 3 (Moved) in the
  EARO.  An NA message generated in response to an NS(Lookup) or an
  NS(NUD) MUST NOT have the Override flag set.

I think there's an implicit "by the 6BBR" in both the "message
generated"s here, but please confirm.

  This specification enables proxy operation for the IPv6 ND resolution
  of LLN devices and a prefix that is used across a Multi-Link Subnet
  MAY be advertised as on-link over the Backbone.  This is done for
  backward compatibility with existing IPv6 hosts by setting the L flag
  in the Prefix Information Option (PIO) of RA messages [RFC4861].

Are there any drawbacks to providing this backwards-compatible behavior
worth mentioning?

Section 7

  EUI-48).  Since a 6LN may not be able to resolve an arbitrary
  destination in the MLSN directly, the MLSN prefix MUST NOT be
  advertised as on-link in RA messages sent towards the LLN.

nit(?): is there a single distinguished MLSN prefix to merit the
definite article here?  (I note that in the previous section we speak
only of "a prefix that is used across a [MLSN]".)

Section 8

  If the Registering Node owns the Registered Address, then its
  mobility does not impact existing NCEs over the Backbone.  Otherwise,
  when the 6LN selects another Registering Node, the new Registering
  Node SHOULD send a multicast NA with the Override flag set to fix the
  existing NCEs across the Backbone.

I think I'm confused about the distinction between "Registering Node"
and "6LN", here -- in my head they are the same entity.  (If I replace
"Registering Node" with "6BBR" in the second and third occurrences,
things seem to make more sense and are roughly analogous to the
discussion in Section 7...but looks can be deceiving.)
[ed. Section 10 does describe a case where Registering Node and 6LN are
different]

Section 9

  even for a duplicate address.  Consequently, and unless
  administratively overridden, the 6BBR still needs to perform IPv6 ND
  DAD over the backbone after an EDAC with a status code of 0 or 9.

I'd be curious to see a pointer to the discussions that caused "unless
administratively overridden" to be introduced, as naively that note does
not seem necessary.

  If a registration is received for an existing Binding with a non-null
  Registration Lifetime and the registration is fresher (same ROVR,
  fresher TID), then the Binding is updated, with the new Registration
  Lifetime, TID, and possibly Registering Node.  In Tentative state
  (see Section 9.1), the current DAD operation continues unaltered.  In
  other states (see Section 9.2 and Section 9.3 ), the Binding is
  placed in Reachable state for the Registration Lifetime, and the 6BBR
  returns an NA(EARO) to the Registering Node with a status of 0
  (Success).

Does this mean we don't re-do DAD for registrations already in a Stale
state when we receive an updated registration for them?

  Upon a registration that is identical (same ROVR, TID, and
  Registering Node), the 6BBR returns an NA(EARO) back to the
  Registering Node with a status of 0 (Success).  A registration that
  is not as fresh (same ROVR, older TID) is ignored.

What (if anything) happens to the registration lifetime in this case?

  registering node.  It MAY preserve a temporary state in order to
  forward packets in flight.  The state may be a NCE formed based on a
  received NA message, or a Binding in Stale state and pointing at the
  new 6BBR on the backbone.

nit: is this an exhaustive list of permitted ways to implement
"temporary state"?

  The implementation should also use REDIRECT messages as specified in
  [RFC4861] to update the correspondents for the Registered Address,
  pointing the new 6BBR.

s/should/SHOULD/?

Section 9.1

  *  The Binding MUST be removed if an NA message is received over the
      Backbone for the Registered Address with no EARO, or containing an
      EARO with a status of 1 (Duplicate) that indicates an existing
      registration owned by a different Registering Node.  In that case,
      an NA MUST be sent back to the Registering Node with a status of 1
      (Duplicate) in the EARO.  This behavior might be overriden by
      policy, in particular if the registration is trusted, e.g., based
      on the validation of the ROVR field (see [I-D.ietf-6lo-ap-nd]).

I suggest to reword this to say "an NA is sent back to the Registering
Node" to avoid having a normative "MUST" that is then overridden by the
last sentence.  (Similarly for the next item as well.)

Also, to check my understanding, the first two bullets in combination
mean that if we somehow end up in a state with identical Tentative
bindings at two different 6BBRs, they will both respond to each others'
NS(DAD) with an NA, causing both bindings to be removed (i.e., "everyone
loses")?

Section 10

  The Registering Node may be the 6LN owning the IPv6 Address, or a
  6LBR that performs the registration on its behalf in a Route-Over
  mesh.

Having this earlier would probably have saved me some confusion :)

  The Registering Node SHOULD register all of its IPv6 Addresses to its
  6LR, which is the 6BBR when they are connected at Layer 2.  Failure
  to register an address may result in the address being unreachable by
  other parties if the 6BBR cancels the NS(Lookup) over the LLN or to
  selected LLN nodes that are known to register their addresses.

I'm not sure I'm parsing the second sentence correctly -- what's the
antecedent for "or to selected LLN nodes"?

  The Registering Node SHOULD also follow [RFC7772] in order to limit

This is BCP 202, right?

Section 11

We force a sequencing that has EDAR/EDAC occur before normal NS(DAD); does
this provide a new DoS avenue by virtue of delaying the normal NS(DAD)
procedure by (e.g.) dropping the EDAC messages?

It might be worth a brief preface that since we're modifying the
ND and DAD processes, the attacks in scope are basically limited to
blocking discovery of taking over addresses from other nodes (which, to
be fair, can in some cases have substantial consequences in terms of
reading the "stolen" traffic!).

  This specification applies to LLNs and a backbone in which the
  individual links are protected against rogue access, e.g., by
  authenticating a node that attaches to the network and encrypting at
  the MAC layer the transmissions that may be overheard.  In
  particular, the LLN MAC is required to provide secure unicast to/from
  the Backbone Router and secure Broadcast from the Backbone Router in
  a way that prevents tampering with or replaying the RA messages.

It seems like it would be worth stating these requirements/applicability
statement much earlier in the document (possibly in addition to here),
e.g., in the Introduction.

  provide the proof-of-ownership.  A possible attack over the backbone
  can be done by sending an NS with an EARO and expecting the NA(EARO)
  back to contain the TID and ROVR fields of the existing state.  With
  that information, the attacker can easily increase the TID and take
  over the Binding.

The 6BBR can also perform such an attack, right?  It might be worth
explicitly stating that we trust it to behave honestly in order for this
stuff to work properly.

We could also discuss how things break if the "distributed database" of
registrations gets out of sync across 6BBRs/etc..

How do things degrade if a secondary 6BBR "stands back" to let a primary
handle a given message but the primary 6BBR has gone offline unbeknownst
to the secondary?

Are there any noteworthy scaling requirements to the bridging and
routing proxy modes?  (I don't think so, and we just allude to
"dimensioned for the number of registrations that each needs to support"
in Appendix B, but it doesn't hurt to ask.)

Section 15

RFC 6550 is only mentioned once, as a "non-normative example", so seems
more appropriately placed in the Informative References.

Section 16

It might be worth replacing RFC 6830 with draft-ietf-lisp-rfc6830bis,
which is both significantly different from RFC 6830 and fairly close to
done.

We have "SHOULD [...] support Packet-Loss Resiliency for Router
Solicitations [RFC7559]" which, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
would put it in the Normative References.  Likewise for RFC 7772.

Appendix A

  By default the specification does not have a trust model, e.g.,
  whereby nodes that associate their address with a proof-of-ownership
  [I-D.ietf-6lo-ap-nd] should be more trusted than nodes that do not.
  Such a trust model and related signaling could be added in the future
  to override the default operation and favor trusted nodes.

Well, we kind of have a trust model: "anyone on the backbone and anyone
that can authenticate to the LLN MAC is trusted equally; others are not
trusted".  So perhaps it's more appropriate to go with "does not have a
fine-grained trust model: all nodes that can authenticate to the LLN MAC
or attach to the backbone are equally trusted.  It would be desirable to
provide a stronger authorization model, e.g., [...]"?

  Future documents may extend this specification by allowing the 6BBR
  to redistribute Host routes in routing protocols that would operate
  over the Backbone, or in MIPv6, or FMIP, or the Locator/ID Separation

Is there a reference for FMIP?  We don't mention it elsewhere in the
document, as we do for MIPv6.

Appendix B

We seem to cover the requirements from Appendix B of RFC 8505 out of
order: B.3, B.1, B.4, B.6, then B.2.  I didn't think very hard about
whether there's good rhetorical reason for the current order, though.

  The impact if the IPv6 ND operation is limited to one of the
  federated LLNs, enabling the number of 6LNs to grow.  The Routing

nit: I don't think this is a well-formed sentence.  Possibly it's just
suffering from a typo (s/if/of/), though I'm not entirely sure.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6lo-backbone-router-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-06):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: 6lo-chairs@ietf.org, Shwetha Bhandari <shwethab@cisco.com>, suresh@kaloom.com, draft-ietf-6lo-backbone-router@ietf.org, shwethab@cisco.com, 6lo@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-6lo-backbone-router-13.txt> (IPv6 Backbone Router) to Proposed Standard

The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'IPv6 Backbone Router'
  <draft-ietf-6lo-backbone-router-13.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

  This document updates RFC 6775 and RFC 8505 in order to enable proxy
  services for IPv6 Neighbor Discovery by Routing Registrars called
  Backbone Routers.  Backbone Routers are placed along the wireless
  edge of a Backbone, and federate multiple wireless links to form a
  single MultiLink Subnet.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3050/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-6lo-backbone-router-13 is a 'standards track' document. The intended status is indicated
in the document header. The document updates RFC 6775 and RFC 8505 to enable proxy
services for IPv6 Neighbor Discovery to federate multiple wireless links.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document updates RFC 6775 and RFC 8505 in order to enable proxy
  services for IPv6 Neighbor Discovery by Routing Registrars called
  Backbone Routers.  Backbone Routers are placed along the wireless
  edge of a Backbone, and federate multiple wireless links to form a
  single MultiLink Subnet.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft has evolved from early days of 6lo group and has gone through
13 iterations as a workgroup draft since 2016. It has received and incorporated
reviews from 6lo, ROLL, RPL and 6man experts.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A prototype implementation exists in closed source (Cisco IOS).
One major vendor has indicates plans to implement the draft in
shipping product.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
Document shepherd: Shwetha Bhandari, Responsible AD: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Document shepherd has reviewed the -12 and -13 version of the document.
The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No particular concerns. The document has been reviewed by 6lo and related groups as
well as 6man volunteer.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document required a detailed review from 6man that was done and -13
updated with the comments.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

It has been reviewed by a number of WG members and the shepherd. It is ready to advance.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Yes. https://datatracker.ietf.org/ipr/3050/ is the only known IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Yes. https://datatracker.ietf.org/ipr/3050/
This was announced to the workgroup - https://mailarchive.ietf.org/arch/msg/6lo/5iFTwQNQsLgb64PnL0EiXon8BEw
There was no objection / further discussion on this.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Yes. RFC 6775 and RFC 8505 will be updated.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

No IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Not applicable.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Manual checks are performed by the shepherd. No formal sections that require validation are present.
The document is seeking Standards track.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-6lo-backbone-router-13 is a 'standards track' document. The intended status is indicated
in the document header. The document updates RFC 6775 and RFC 8505 to enable proxy
services for IPv6 Neighbor Discovery to federate multiple wireless links.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document updates RFC 6775 and RFC 8505 in order to enable proxy
  services for IPv6 Neighbor Discovery by Routing Registrars called
  Backbone Routers.  Backbone Routers are placed along the wireless
  edge of a Backbone, and federate multiple wireless links to form a
  single MultiLink Subnet.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft has evolved from early days of 6lo group and has gone through
13 iterations as a workgroup draft since 2016. It has received and incorporated
reviews from 6lo, ROLL, RPL and 6man experts.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A prototype implementation exists in closed source (Cisco IOS).
One major vendor has indicates plans to implement the draft in
shipping product.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
Document shepherd: Shwetha Bhandari, Responsible AD: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Document shepherd has reviewed the -12 and -13 version of the document.
The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No particular concerns. The document has been reviewed by 6lo and related groups as
well as 6man volunteer.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document required a detailed review from 6man that was done and -13
updated with the comments.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

It has been reviewed by a number of WG members and the shepherd. It is ready to advance.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Yes. https://datatracker.ietf.org/ipr/3050/ is the only known IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Yes. https://datatracker.ietf.org/ipr/3050/
This was announced to the workgroup - https://mailarchive.ietf.org/arch/msg/6lo/5iFTwQNQsLgb64PnL0EiXon8BEw
There was no objection / further discussion on this.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Yes. RFC 6775 and RFC 8505 will be updated.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

No IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Not applicable.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Manual checks are performed by the shepherd. No formal sections that require validation are present.
The document is seeking Standards track.

Notification list changed to "Samita Chakrabarti" <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>, Shwetha Bhandari <shwethab@cisco.com> from "Samita Chakrabarti" <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>