IPv6 Backbone Router
draft-ietf-6lo-backbone-router-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-11-02
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-10-07
|
20 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-06-04
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-04-03
|
20 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2020-04-03
|
20 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Tina Tsou was marked no-response |
2020-03-24
|
20 | (System) | RFC Editor state changed to EDIT |
2020-03-24
|
20 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-03-24
|
20 | (System) | Announcement was received by RFC Editor |
2020-03-23
|
20 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2020-03-23
|
20 | (System) | IANA Action state changed to In Progress |
2020-03-23
|
20 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-03-23
|
20 | Cindy Morgan | IESG has approved the document |
2020-03-23
|
20 | Cindy Morgan | Closed "Approve" ballot |
2020-03-23
|
20 | Cindy Morgan | Ballot approval text was generated |
2020-03-23
|
20 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-03-23
|
20 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-20.txt |
2020-03-23
|
20 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-03-23
|
20 | Pascal Thubert | Uploaded new revision |
2020-03-22
|
19 | Benjamin Kaduk | [Ballot comment] Thank you for all the updates for my Discuss and Comment points! |
2020-03-22
|
19 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-03-21
|
19 | Roman Danyliw | [Ballot comment] Thanks for addressing my DISCUSS points. |
2020-03-21
|
19 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-03-06
|
19 | Carles Gomez | This document now replaces draft-thubert-6lo-backbone-router instead of None |
2020-03-03
|
19 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-19.txt |
2020-03-03
|
19 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-03-03
|
19 | Pascal Thubert | Uploaded new revision |
2020-03-02
|
18 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-18.txt |
2020-03-02
|
18 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-03-02
|
18 | Pascal Thubert | Uploaded new revision |
2020-02-20
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-02-20
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-02-20
|
17 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-17.txt |
2020-02-20
|
17 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-02-20
|
17 | Pascal Thubert | Uploaded new revision |
2020-02-20
|
16 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-02-20
|
16 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-02-20
|
16 | Éric Vyncke | [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 … [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" |
2020-02-20
|
16 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-02-19
|
16 | Alvaro Retana | [Ballot comment] This document should be tagged as replacing draft-thubert-6lo-backbone-router. |
2020-02-19
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-02-19
|
16 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-02-19
|
16 | Roman Danyliw | [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 … [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”)? |
2020-02-19
|
16 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-02-19
|
16 | Adam Roach | [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." … [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. |
2020-02-19
|
16 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-02-19
|
16 | Alissa Cooper | [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 … [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? |
2020-02-19
|
16 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-02-19
|
16 | Mirja Kühlewind | [Ballot comment] Thanks for quickly addressing the TSV-ART review (and thanks Kyle for the review!)! |
2020-02-19
|
16 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2020-02-19
|
16 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-02-18
|
16 | Barry Leiba | [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 … [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. |
2020-02-18
|
16 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-02-18
|
16 | Alexey Melnikov | [Ballot comment] The introduction is hard to read for an non expert like me. It reads “blah blah ... excessive traffic generated, can be optimised”. … [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. |
2020-02-18
|
16 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2020-02-17
|
16 | Benjamin Kaduk | [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 … [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." |
2020-02-17
|
16 | Benjamin Kaduk | [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. … [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. |
2020-02-17
|
16 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-02-14
|
16 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-02-14
|
16 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-02-13
|
16 | Amy Vezza | Placed on agenda for telechat - 2020-02-20 |
2020-02-13
|
16 | Suresh Krishnan | Ballot has been issued |
2020-02-13
|
16 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2020-02-13
|
16 | Suresh Krishnan | Created "Approve" ballot |
2020-02-13
|
16 | Suresh Krishnan | Ballot writeup was changed |
2020-02-08
|
16 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-16.txt |
2020-02-08
|
16 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-02-08
|
16 | Pascal Thubert | Uploaded new revision |
2020-02-07
|
15 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-15.txt |
2020-02-07
|
15 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-02-07
|
15 | Pascal Thubert | Uploaded new revision |
2020-02-06
|
14 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list. |
2020-02-06
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-02-06
|
14 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-14.txt |
2020-02-06
|
14 | (System) | New version accepted (logged-in submitter: Pascal Thubert) |
2020-02-06
|
14 | Pascal Thubert | Uploaded new revision |
2020-02-06
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-02-05
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2020-02-05
|
13 | Sabrina Tanamal | (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 … (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 |
2020-02-03
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-02-03
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-02-03
|
13 | Kyle Rose | Request for Last Call review by TSVART Completed: Almost Ready. Reviewer: Kyle Rose. Sent review to list. |
2020-01-30
|
13 | Dominique Barthel | Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Dominique Barthel. Sent review to list. |
2020-01-30
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2020-01-30
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2020-01-30
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2020-01-30
|
13 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Melinda Shore was withdrawn |
2020-01-30
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2020-01-30
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2020-01-27
|
13 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Kyle Rose |
2020-01-27
|
13 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Kyle Rose |
2020-01-23
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2020-01-23
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2020-01-23
|
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-01-23
|
13 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-02-06): From: The IESG To: IETF-Announce CC: 6lo-chairs@ietf.org, Shwetha Bhandari , suresh@kaloom.com, draft-ietf-6lo-backbone-router@ietf.org, … The following Last Call announcement was sent out (ends 2020-02-06): From: The IESG To: IETF-Announce CC: 6lo-chairs@ietf.org, Shwetha Bhandari , suresh@kaloom.com, draft-ietf-6lo-backbone-router@ietf.org, shwethab@cisco.com, 6lo@ietf.org, Samita Chakrabarti , Carles Gomez Reply-To: last-call@ietf.org Sender: Subject: Last Call: (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' 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/ |
2020-01-23
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-01-23
|
13 | Amy Vezza | Last call announcement was changed |
2020-01-22
|
13 | Suresh Krishnan | Last call was requested |
2020-01-22
|
13 | Suresh Krishnan | Last call announcement was generated |
2020-01-22
|
13 | Suresh Krishnan | Ballot approval text was generated |
2020-01-22
|
13 | Suresh Krishnan | Ballot writeup was generated |
2020-01-22
|
13 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2020-01-22
|
13 | Ari Keränen | Assignment of request for Last Call review by IOTDIR to Emmanuel Baccelli was marked no-response |
2019-12-23
|
13 | Ari Keränen | Request for Last Call review by IOTDIR is assigned to Dominique Barthel |
2019-12-23
|
13 | Ari Keränen | Request for Last Call review by IOTDIR is assigned to Dominique Barthel |
2019-12-19
|
13 | Bernie Volz | Closed request for Last Call review by INTDIR with state 'Overtaken by Events' |
2019-12-19
|
13 | Bernie Volz | Assignment of request for Last Call review by INTDIR to Ole Trøan was marked no-response |
2019-11-14
|
13 | Samita Chakrabarti | Request for Last Call review by IOTDIR is assigned to Emmanuel Baccelli |
2019-11-14
|
13 | Samita Chakrabarti | Request for Last Call review by IOTDIR is assigned to Emmanuel Baccelli |
2019-11-05
|
13 | Bernie Volz | Request for Last Call review by INTDIR is assigned to Ole Trøan |
2019-11-05
|
13 | Bernie Volz | Request for Last Call review by INTDIR is assigned to Ole Trøan |
2019-11-04
|
13 | Suresh Krishnan | Requested Last Call review by IOTDIR |
2019-11-04
|
13 | Suresh Krishnan | Requested Last Call review by INTDIR |
2019-11-04
|
13 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2019-10-25
|
13 | Amy Vezza | Changed consensus to Yes from Unknown |
2019-10-25
|
13 | Amy Vezza | Intended Status changed to Proposed Standard from None |
2019-10-25
|
13 | Shwetha Bhandari | 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 … 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. |
2019-10-25
|
13 | Shwetha Bhandari | Responsible AD changed to Suresh Krishnan |
2019-10-25
|
13 | Shwetha Bhandari | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-10-25
|
13 | Shwetha Bhandari | IESG state changed to Publication Requested from I-D Exists |
2019-10-25
|
13 | Shwetha Bhandari | IESG process started in state Publication Requested |
2019-10-02
|
13 | Shwetha Bhandari | 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 … 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. |
2019-09-26
|
13 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-13.txt |
2019-09-26
|
13 | (System) | New version approved |
2019-09-26
|
13 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Eric Levy-Abegnoli , Charles Perkins |
2019-09-26
|
13 | Pascal Thubert | Uploaded new revision |
2019-09-02
|
12 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-12.txt |
2019-09-02
|
12 | (System) | New version approved |
2019-09-02
|
12 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Eric Levy-Abegnoli , Charles Perkins |
2019-09-02
|
12 | Pascal Thubert | Uploaded new revision |
2019-08-08
|
11 | (System) | Document has expired |
2019-07-10
|
11 | Carles Gomez | 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>, … 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> |
2019-07-10
|
11 | Carles Gomez | Document shepherd changed to Shwetha Bhandari |
2019-02-28
|
11 | Carles Gomez | Notification list changed to "Samita Chakrabarti" <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu> from "Samita Chakrabarti" <samitac.ietf@gmail.com> |
2019-02-28
|
11 | Carles Gomez | Document shepherd changed to Carles Gomez |
2019-02-04
|
11 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-11.txt |
2019-02-04
|
11 | (System) | New version approved |
2019-02-04
|
11 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Eric Levy-Abegnoli , Charles Perkins |
2019-02-04
|
11 | Pascal Thubert | Uploaded new revision |
2019-01-16
|
10 | Samita Chakrabarti | IETF WG state changed to In WG Last Call from WG Document |
2019-01-16
|
10 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-10.txt |
2019-01-16
|
10 | (System) | New version approved |
2019-01-16
|
10 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Eric Levy-Abegnoli , Charles Perkins |
2019-01-16
|
10 | Pascal Thubert | Uploaded new revision |
2018-12-05
|
09 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-09.txt |
2018-12-05
|
09 | (System) | New version approved |
2018-12-05
|
09 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , 6lo-chairs@ietf.org, Charles Perkins |
2018-12-05
|
09 | Pascal Thubert | Uploaded new revision |
2018-10-22
|
08 | Charles Perkins | New version available: draft-ietf-6lo-backbone-router-08.txt |
2018-10-22
|
08 | (System) | New version approved |
2018-10-22
|
08 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Charles Perkins |
2018-10-22
|
08 | Charles Perkins | Uploaded new revision |
2018-09-03
|
07 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-07.txt |
2018-09-03
|
07 | (System) | New version approved |
2018-09-03
|
07 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , 6lo-chairs@ietf.org |
2018-09-03
|
07 | Pascal Thubert | Uploaded new revision |
2018-08-27
|
06 | (System) | Document has expired |
2018-02-23
|
06 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-06.txt |
2018-02-23
|
06 | (System) | New version approved |
2018-02-23
|
06 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert |
2018-02-23
|
06 | Pascal Thubert | Uploaded new revision |
2018-01-09
|
05 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-05.txt |
2018-01-09
|
05 | (System) | New version approved |
2018-01-09
|
05 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert |
2018-01-09
|
05 | Pascal Thubert | Uploaded new revision |
2017-08-11
|
Jasmine Magallanes | Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-6lo-backbone-router | |
2017-07-17
|
04 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-04.txt |
2017-07-17
|
04 | (System) | New version approved |
2017-07-17
|
04 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert |
2017-07-17
|
04 | Pascal Thubert | Uploaded new revision |
2017-07-17
|
03 | (System) | Document has expired |
2017-01-11
|
03 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-03.txt |
2017-01-11
|
03 | (System) | New version approved |
2017-01-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Pascal Thubert" |
2017-01-11
|
03 | Pascal Thubert | Uploaded new revision |
2016-09-19
|
02 | Pascal Thubert | New version approved |
2016-09-19
|
02 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-02.txt |
2016-09-19
|
02 | Pascal Thubert | Request for posting confirmation emailed to previous authors: "Pascal Thubert" |
2016-09-19
|
02 | (System) | Uploaded new revision |
2016-09-19
|
01 | (System) | Document has expired |
2016-09-14
|
01 | Samita Chakrabarti | Notification list changed to "Samita Chakrabarti" <samitac.ietf@gmail.com> from "Samita Chakrabarti" <samita.chakrabarti@ericsson.com>, "Samita Chakrabarti" <samitac.ietf@gmail.com> |
2016-09-14
|
01 | Samita Chakrabarti | Notification list changed to "Samita Chakrabarti" <samita.chakrabarti@ericsson.com>, "Samita Chakrabarti" <samitac.ietf@gmail.com> from "Samita Chakrabarti" <samita.chakrabarti@ericsson.com> |
2016-09-14
|
01 | Samita Chakrabarti | Document shepherd changed to Samita Chakrabarti |
2016-03-18
|
01 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-01.txt |
2016-01-05
|
00 | Samita Chakrabarti | Notification list changed to "Samita Chakrabarti" <samita.chakrabarti@ericsson.com> |
2016-01-05
|
00 | Samita Chakrabarti | Document shepherd changed to Samita Chakrabarti |
2016-01-05
|
00 | Pascal Thubert | New version available: draft-ietf-6lo-backbone-router-00.txt |