Pascal, thanks - the only obvious hiccup is that I failed to specify that the OMNI overlay RS/RA messaging is unicast-only (or anycast) and never broadcast/multicast. So, it is efficient and only between a vehicle and its nearest IP-RSU without disturbing any other vehicles or IP-RSUs. I am willing to let the dust settle on this for now and see what edits Paul can come up with. Fred > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@xxxxxxxxx] > Sent: Wednesday, March 02, 2022 1:43 PM > To: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> > Cc: int-dir@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-ipwave-vehicular-networking.all@xxxxxxxx; its@xxxxxxxx > Subject: [EXTERNAL] Re: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27 > > EXT email: be mindful of links/attachments. > > > > Hello Fred > > Please see below > > > Le 2 mars 2022 à 21:06, Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> a écrit : > > > > OK Pascal, I am back again - see below for responses: > > > > Fred > > > >> -----Original Message----- > >> From: Pascal Thubert (pthubert) [mailto:pthubert@xxxxxxxxx] > >> Sent: Tuesday, March 01, 2022 12:43 AM > >> To: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx>; int-dir@xxxxxxxx > >> Cc: last-call@xxxxxxxx; draft-ietf-ipwave-vehicular-networking.all@xxxxxxxx; its@xxxxxxxx > >> Subject: RE: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27 > >> > >> Hello Fred > >> > >>> -----Original Message----- > >>> From: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> > >>> Sent: lundi 28 février 2022 19:09 > >>> To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>; int-dir@xxxxxxxx > >>> Cc: last-call@xxxxxxxx; draft-ietf-ipwave-vehicular- > >>> networking.all@xxxxxxxx; its@xxxxxxxx > >>> Subject: RE: [ipwave] Intdir telechat review of draft-ietf-ipwave- > >>> vehicular-networking-27 > >>> > >>> Pascal, I have no issues with what you said below, and I assume that since > >>> you referenced some of my comments you are OK with the rest of the ones > >>> that I sent to Paul? > >>> > >> > >> That would be optimistic. Some of your points are non-technical and Paul is the editor, he should make the decision. > >> I reacted to the technical points I agreed with to add pressure on Paul to act on them. > >> Then again I agreed more with the technical issue you raised and your proposed resolution than with your exact wording, and then again > >> Paul is the editor anyway. > > > > Exact wording is not critical for me. One exception is that the term "Bring Your Own Address > > (BYOA) is not sitting well with me currently - does it simply mean a statistically-unique self- > > generated address that is highly unlikely to conflict with an address chosen by another node > > within the same local network routing region? That is what is currently done using the > > "Temporary Address" facility based on ULAs configured according to the OMNI addressing > > architecture. I am sure there may be other examples that would have similar statistically > > uniqueness properties, but Temporary ULAs is how OMNI would prefer to see it worded. > > All good; we are missing the specifications of statistical characteristics that would allow to lawfully ignore DAD. Without that there can be > no claim that DAD is not needed even for ULAs. > > RFC 8505 models every node to node as IP P2P even in transit networks. DAD for link local need only to be asserting that pair since that pair > is the link. It is thus instantaneous. > > For prefixes owned by a RSU, using RFC 8605 the RSU is garant for the uniqueness of addresses in that prefix so then again we have a DAD > guarantee. > > We could derive something similar for you ULA so they can be decoupled from a GUA MNP, eg the MNP can be private / temporary ULA > like the RPL visitor network. > > > > > >> But first and foremost, I see OMNI as an abstract interface for non-broadcast networks, and MLSN as a network that can be reached via > >> OMNI. I see no opposition but highly complementary stuff. > > > > I agree with complimentary. However, from a higher layer perspective we should > > be more and more seeing OMNI as a new adaptation layer for the Internet moreso than > > focusing on the lower-level details of NBMA, MLSN, etc. The MLSNs are at the mobile > > edges of the network, but the OMNI adaptation layer provides an overlay that extends > > over the edges. So, the underlay network details are important, but so is the higher-level > > overlay perspective. > > > > The OMNI addresses are /128 from the same /64 ULA prefix. You route between them in the underlay. So you underlay is an MLSN. By > definition. > > > >>> I have a discussion point however - the business of multilink subnet. I > >>> used to think the concept was inherently evil, but now that I have a > >>> deeper understanding of the problem statement I am beginning to see some > >>> possibilities. > >> > >> If you pick all the addresses of your MANET from the same /64 you have a MLSN. > > > > OK, that would be fine for me. For example, a /64 such as fd12:3456:789a:bcde::/64 > > would make for a fine shared prefix for a MANET where all MANET nodes receive a > > /128 within that /64 - correct? But then, according to RFC5889, each MANET node > > would use a /128 prefix length in its MANET-local routing exchanges instead of a /64; > > correct? If true, and if that is what you are calling a MLSN, then that is fine for me. > > Exactly. This is how Wi-Sun deploys RPL. Another way of seeing it is that what you do at L2 with spanning tree or L2R is now done at L3. > > > > >> Take RPL: deployed in the smartgrid, it is a MLSN. > >> Deployed between cars with a mobile network prefix (MNP) each, it's more of a MANET of MNPs. > > > > With the OMNI addressing architecture, you get both MLSN and MNP information > > in a single IPv6 address. So, let's say the MLSN /64 is fd12:3456:789a:bcde::/64 and > > a mobile node's MNP is 2001:db8:1:2::/4, then the OMNI address for that particular > > MLSN would be written as: > > > > fd12:3456:789a:bcde:2001:db8:1:2/128 > > > > It is guaranteed unique within the MLSN so the subnet can operated without DAD. > > And, it includes both MLSN and MNP information so you get two pieces of routing > > information for the price of one. > > It can only be guaranteed unique by the OMNI interface if the prefix is uniquely used for OMNI. There are less random bits in the prefix than > in an IID. So collision on the prefix ULA used by another node for non OMNI are more likely to happen than on a random IID in any normal > network. But ok the chances to duplicate that address are negligible and should be neglected. > > > > > >> Even a hub and spoke like Bluetooth is an MLSN. The idea behind it is to decouple the L3 abstraction from the L2 connectivity and build > >> select P2P IP links over whatever L2 gives you. For all I can see, this is exactly what you're also describing, and it's not evil, it's a world of > >> opportunities. In fact, 6LoWPAN explicitly inherits that model from MANET. > > > > Right, but it all comes down to the link model. If the link model you have in mind is > > according to RFC5889 where it says: > > > > "Link-level connectivity is generally qualified as undetermined when > > it is unplanned and/or time-varying in character. Ad hoc networks > > are typical examples of networks with undetermined link-level > > connectivity." > > It is. This is why we build IP link as P2P regardless of the L2 link. > > IOW We decouple the L2 broadcast domain the L3 link and L3 subnet. > > A world of opportunities for IPv6. > > > > then that is fine with me, and we can operate that as an MLSN all day long given > > an appropriate subnet-local routing service and the application of /128 prefix > > lengths. Does that match the model you have in mind? > > > > It is, as it is for you since inception. Part of my 95% > > >>> Am I correct that the document assumes that each IP-RSU > >>> will be the head-end of a "subnet" consisting of a VANET in which all > >>> vehicles configure an address from a common IPv6 prefix? So, for example, > >>> IP-RSU1 could be the head-end of a subnet 2001:db8:1:2::/64 and IP-RSU2 > >>> could be the head-end of a subnet 2001:db8:3:4::/64 - correct? > >> > >> One or more RSUs can share the same /64. If there's only one RSU per /64 this is a hub and spoke (like a BSS at L2). If multiple RSUs, you > >> have to route between them for the host addresses in the prefix, (like an ESS will bridge). > > > > OK, then that is even better and even more well aligned with OMNI. If you are OK with > > multiple RSUs all sharing the same /64, then the way OMNI differentiates the RSUs is by > > giving them each a unique "interface identifier" within the (shared) /64. Is that what > > you mean? > > > > Yes that is MLSN. > > >> 2 cars, even connected to the same RSU, many not be in sight of one another. So the model is that each car has a P2P IP link with the > RSU > >> and the RSU relays. > > > > This is where there might be a slight philosophical divergence - a [MV]ANET can be thought > > of as a loosely-knit grouping of (multiple) P2P links or, alternatively, it could be said that all > > [MV]ANET nodes connect to a (singular) link with undetermined link-level connectivity per > > RFC5889. But, does the distinction matter? > > > If the VANET can leverage the links between RSUs then it becomes more than a MANET. That is again an opportunity not an issue. > > > > >> OSPF called that P2MP as opposed to NBMA which was non broadcast full mesh and did not need routing inside. This is where we have to > >> agree on terms, since you only mention NBMA. > > > > No, the NBMA is only intended in the overlay - I should have made that more clear. > > In underlying [MV]ANETs, it can be based on whatever the underlying network routing > > services entail (RPL, MANET, etc.). > > > Ok > > >> In a Wi-Fi ESS/BSS, the RSU is an Access point and it does bridging. Outside of the context of a BSS in OCB), all you have is L3 and this is > >> called a MLSN, and the RSU is a router. So the goal is the exact same as BSS/ESS. Obtain an address that is externally reachable, > >> topologically correct, and that does not need renumbering as you move within the MLSN. > > > > OMNI does that by having the RSU (or, Proxy/Server in OMNI terms) assign each node > > a /128 unique address within the MLSN /64 when the node enters the [MV]ANET. > > If you’re sure that addresses with that prefix are only formed with GuA prefixes as IID that works fine for sure. The privacy guys will not love > you for it but it’s another story… > > > > >>> But, these subnets are not related to the IPv6 MNPs that are on-board the > >>> individual vehicles and so would not be used as end system addresses for > >>> global-scope comms; correct? > >> > >> Not related is correct. For global comm, partially correct. You can have multiple MNPs. ULA MNPs are useful for local comms between > cars > >> and relaying in V2V2I, but we also want MNPs that can be globally reachable with NEMO. E.g., a device connected to the Wi-Fi inside the > >> car (or train) may want to connect to the internet in which case that MNP is GUA. > >> > >> More details: > >> > >> For V2V, we have a model where the cars have "visitors" MNPs that are ULA and short lived. This helps for anonymizing the MNP owner. > >> Neighbor vehicles can form addresses from the "visitors" MNP when in range using anonymized IIDs, just like they can from RSUs. This > >> forms an IP link and you can route along those links, including source routing. This was the original model for RPL. > >> > >> Then there's a home MNP that is GUA (and BYOP) for NEMO purpose. And the router address inside that prefix is BYOA if you want to see > it > >> that way. This is for sourcing packets to the internet as opposed to relaying as above. > >> > >> Using RPL you can route along the "visitors" MNP between cars to reach the AP of the parking lot, this is how you can do V2V2I. If you > inject > >> that MNP in the RPL then NEMO needs a single tunnel to the parking lot using the parking lot as CoA. If you hide it for privacy reasons, > you > >> need to take your CoA from your own "visitors" MNP, and that's 2 tunnels. OMNI could simplify that. > >> > >> We called that MANEMO long ago, coupling MANET for V2V with NEMO for V2I, in order to solve the famous "nested nemo" problem. > > > > With AERO/OMNI, each vehicle would have one or more GUA MNPs. The RSU would then > > authorize the vehicle to use the MNPs as the lower 64 bits of an address configured from > > the MLSN /64 - again, two pieces of routing information tucked inside a singular address. > > And, this would be based on IPv6 RS/RA messaging between the vehicle and RSU in the > > OMNI overlay (i.e., as opposed to in the [MV]ANET underlay). > > Yes that’s certainly one model for hierarchical network. Broadcasting RS/RA in the overlay will cost like OSPF flooding. Surely you want to > optimize that at least like OLSR did. > > If you look at it the RPL DIO is also flooded and transports the RA options you need like PIO. The little plus is that it forms the routing > DODAG for the same price and RS are not flooded. > > RPL does not require any semantics in the address and does not expose the MNP if you want it private, at the expense of an additional > encapsulation for reaching globally. > > But that is fine pro con discussion; the bottom line is that we route inside the network in a fashion that is independent of routing outside. > > > > >>> So then, what is the purpose of the IP-RSU > >>> based multilink subnet? Is it to simply group vehicles according to their > >>> current IP-RSU affiliation? > >> > >> The vehicle is reachable from the internet with that address while in range. As the doc says, this can be short lived, if the vehicle is > moving > >> fast. My car averages < 20mph in practice, and is parked most if its time, so it's useful. > >> > >>> Is it to inform the VANET routing protocol to > >>> only exchange routing information with other vehicles that share a common > >>> IP-RSU based subnet prefix? Or, are there other benefits that I am not > >>> understanding? > >> > >> Having an address that is routable between RSUs is also useful, say along a road. If the RSUs share the same /64 it is still a MLSN, and > this > >> set gives you a scope for the lookups/advertisements. > > > > All good. > > > >> Now if the car has a BYOA and you extend your VANET using the RSUs along a road, someone has to define how far the advertisements > and > >> lookups propagate, which is how far this car is reachable from another. That works too, just that the MLSN automates it. > >> > >> About BYOA and DAD. There are less random bits in a ULA prefix than in an IID. OTOH there are more random bits in an ULA address > since > >> you randomize both. The question behind is how many randomized bit in the 128 are enough to claim that DAD is not needed. > > > > If the "BYOA" you are referring to is one and the same as what OMNI calls a "Temporary ULA" > > then OMNI is providing (40 + 64) = 104 randomly-assigned bits. That, plus the fact that the > > Temporary ULAs are just that (temporary) and get replaced right away with RSU-delegated > > addresses within the MLSN obviate any need for DAD. > > Actually you can autoconf the IID as long as the RSU can confirm that you formed a unique one. That’s the summary of the functionality in > RFC 8505. Either way works but if folks prefer autoconf then RFC 8505 is the best friend of your design… > > > > >>> If we see benefits for maintaining IP-RSU based multilink subnets, then we > >>> can do that also based on ULA addresses according to the OMNI addressing > >>> architecture. > >>> The ULAs would then include IP-RSU multilink subnet information in the > >>> upper 64 bits and include MNP-based IPv6 global scope addressing > >>> information in the lower > >>> 64 bits. The OMNI addressing architecture would have to be adapted > >>> slightly to make that happen, but before I go there can we have a > >>> discussion of the perceived benefits of the IP-RSU based multilink subnet? > >>> > >> > >> I'd like to see that. The integration of local and global reachability (ULA vs GUA, MANET vs NEMO) does not appear to be fully solved at > this > >> time. > > > > Maybe have a look at the OMNI addressing architecture to see how it can couple > > ULA and GUA information so that a single IPv6 address can carry both MLSN and > > MNP information. Other than that, I see many more similarities than differences > > in the way we are both articulating the problem space. > > > > Indeed… > > Pascal > > Thanks - Fred > > > >> Keep safe; > >> > >> Pascal > >>> > >>>> -----Original Message----- > >>>> From: its [mailto:its-bounces@xxxxxxxx] On Behalf Of Pascal Thubert > >>>> via Datatracker > >>>> Sent: Monday, February 28, 2022 5:57 AM > >>>> To: int-dir@xxxxxxxx > >>>> Cc: last-call@xxxxxxxx; > >>>> draft-ietf-ipwave-vehicular-networking.all@xxxxxxxx; its@xxxxxxxx > >>>> Subject: [EXTERNAL] [ipwave] Intdir telechat review of > >>>> draft-ietf-ipwave-vehicular-networking-27 > >>>> > >>>> EXT email: be mindful of links/attachments. > >>>> > >>>> > >>>> > >>>> Reviewer: Pascal Thubert > >>>> Review result: Ready with Issues > >>>> > >>>> I am an assigned INT directorate reviewer for > >>>> draft-ietf-ipwave-vehicular-networking-27. These comments were written > >>>> primarily for the benefit of the Internet Area Directors. Document > >>>> editors and > >>>> shepherd(s) should treat these comments just like they would treat > >>>> comments from any other IETF contributors and resolve them along with > >>>> any other Last Call comments that have been received. For more details > >>>> on the INT Directorate, see > >>>> https://datatracker.ietf.org/group/intdir/about/ > >>>> <https://datatracker.ietf.org/group/intdir/about/>. > >>>> > >>>> Based on my review, the document IS ready to go to IETF Last Call and > >>>> therefore CAN be forwarded to the IESG. > >>>> > >>>> I find the document well written, well referenced, and very > >>>> informative. It fits the general goal of use-cases and problem statement > >>> publication. > >>>> > >>>> The following are other issues I found with this document that SHOULD > >>>> be corrected before publication: > >>>> > >>>> Fig 1 and section 4.1 show a “Corresponding Node”. Not sure where the > >>>> term comes from, in NMIP and NEMO it is “Correspondent Node” see and > >>>> refer to RFC 4885. > >>>> > >>>> About > >>>> Section 3.1: “ > >>>> To support applications of these V2I use cases, the required > >>>> functions of IPv6 include IPv6-based packet exchange, transport-layer > >>>> session continuity, and secure, safe communication between a vehicle > >>>> and an infrastructure node (e.g., IP-RSU) in the vehicular network. > >>>> > >>>> “ > >>>> Section 3.2: “ To support applications of these V2I use cases, the > >>> required > >>>> functions of IPv6 include IPv6-based packet exchange, transport-layer > >>>> session continuity, and secure, safe communication between a vehicle > >>>> and an infrastructure node (e.g., IP-RSU) in the vehicular network. > >>>> ” > >>>> Section 3.3: > >>>> “ > >>>> To support applications of these V2X use cases, the required > >>>> functions of IPv6 include IPv6-based packet exchange, transport-layer > >>>> session continuity, and secure, safe communication between a vehicle > >>>> and a pedestrian either directly or indirectly via an IP-RSU. > >>>> > >>>> “ > >>>> Each time, the text could clarify what goes in “packet exchange” since > >>>> as written that seems to refer to data plane while the problem for IP > >>>> is mostly control plane. e.g., the problem of discovering adjacent > >>>> peers (addresses, > >>>> networks) should be listed there shouldn’t it? Addressing is an topic > >>>> of interest as well (BYO Address/Prefix vs. obtain a local address, > >>>> how that relates with DAD and global connectivity). The doc discusses > >>>> that heavily (around 5.1) and then there’s the discussion in 4.3 on ND > >>>> variations and > >>>> (MANET) NHDP, that must happen before IPv6 packets can be exchanged. > >>>> > >>>> As a hint, a suggestion can be: > >>>> “ > >>>> … functions of IPv6 include IPv6 communication enablement with > >>>> neighborhood discovery and IPv6 address management, reachability with > >>>> adapted network models and routing methods, transport-layer … “ > >>>> > >>>> Section 3.2 > >>>> > >>>> Fred said ‘ > >>>> 3) Section 3.2, change the paragraph beginning: "The existing IPv6 > >>>> protocol must be augmented through protocol changes..." > >>>> to: > >>>> "The existing IPv6 protocol must be augmented either through protocol > >>>> changes or by including a new adaptation layer in the architecture > >>>> that efficiently maps IPv6 to a diversity of link layer technologies. > >>>> Augmentation is necessary to support wireless multihop V2I > >>>> communications in a highway where RSUs are sparsely deployed, so a > >>>> vehicle can reach the wireless coverage of an RSU through the multihop > >>> data forwarding of intermediate vehicles." > >>>> ‘ > >>>> > >>>> I agree that the document omits V2V2I completely. This is true in > >>>> Fred’s highway case, but true also in a simple parking lot to share > >>>> Wi-Fi access when the AP is too far. In the MIPv6 family we called > >>>> that nested NEMO. The problem statement of nested NEMO is RFC 4888. I > >>>> believe you need to provide a minimum of hint that V2V2I exists and > >>>> for the lack of more reference you can search “nested NEMO”. > >>>> > >>>> Note that the early RPL was a solution for nested NEMO and interworked > >>>> with NEMO. It has been tested successfully by NASA at their Glenn > >>>> Center but I do not think something was published at the time, so no > >>> ref. > >>>> > >>>> Note that I also agree with Fred’s point on 3.3. Maybe you can make it > >>>> more verbose but in each case there’s a need to indicate that V2A2B > >>>> can exist and needs future attention, even if it is a harder problem. > >>>> > >>>> > >>>> Section 4.1: > >>>> “ > >>>> In > >>>> this case, a handover for Vehicle2 needs to be performed by either a > >>>> host-based mobility management scheme (e.g., MIPv6 [RFC6275] … … “ > >>>> Section 4.2: > >>>> > >>>> “ > >>>> Existing network architectures, such as the network architectures of > >>>> PMIPv6 [RFC5213] … > >>>> “ > >>>> > >>>> I see you have a reference to NEMO in the introduction, but this is > >>>> where the reference makes the most sense and it is missing, next to > >>> PMIPv6. > >>>> > >>>> It is easy to confuse network-based mobility (which is PMIPv6 vs. > >>>> MIPv6, and is > >>>> MIPv4 anyway) and network mobility, which is the case of a car that > >>>> has a /64 inside and has to handle mobility for the /64. > >>>> > >>>> Indeed NEMO is the MIPv6 for networks (a mobile prefix inside the car > >>> vs. > >>>> MIP/PMIP which is a host address moving) and vehicles where a main use > >>>> case for it. PMIPv6 is a variation of MIPv6 that distributes the roles > >>>> differently for the lack of support by end devices, but does not route > >>> for a mobile prefix. > >>>> Network-based does not mean “mobile network”, and then you often call > >>>> the mobile network a moving network, again per RFC 4885. > >>>> > >>>> For the latter, please stick to IETF terminology of “mobile network” > >>>> as in RFC 3963, that will help the reader. I suggest you reference RFC > >>>> 3963 here, and add RFC 4888 for completeness. > >>>> > >>>> Section 4.1: > >>>> > >>>> “ > >>>> Alternatively, mobile nodes > >>>> can employ a "Bring-Your-Own-Addresses (BYOA)" technique using their > >>>> own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless > >>>> network, which does not require the messaging (e.g., Duplicate > >>>> Address Detection (DAD)) of IPv6 Stateless Address Autoconfiguration > >>>> (SLAAC) [RFC4862]. > >>>> “ > >>>> Again listing Bring your own prefix a well as address would improve > >>>> completeness. A typical car has a mobile prefix inside. > >>>> > >>>> Section 4.2: > >>>> > >>>> “ > >>>> OMNI can support the > >>>> “ > >>>> > >>>> Suggest “OMNI is designed to support” unless there’s an actual > >>> reference? > >>>> > >>>> Section 4.3 > >>>> Fred says “ > >>>> Section 4.3, final paragraph, there is no reason to cite as examples > >>>> all RFC variants of the OLSR protocol and all extensions of the DLEP > >>>> protocol - pick one (or at most 2) RFCs for each. Also, it is > >>>> important to state that standard OSPF routing has been optimized to > >>>> support MANET applications. Suggested > >>>> rewrite: "...which serves MANET routing protocols such as the > >>>> different versions of Optimized Link State Routing Protocol (OLSR) > >>>> [RFC3626][RFC7181], Open Shortest Path First (OSPF) derivatives (e.g., > >>>> [RFC5614]) and the Dynamic Link Exchange Protocol (DLEP) [RFC8175] with > >>> its extensions." > >>>> > >>>> “ > >>>> I agree. Maybe mention that there are V2V use case with a fixed set of > >>>> cars > >>>> (platooning) and others with variable neighborhood (parking lot, on > >>>> the road), and the optimum solution may vary. > >>>> > >>>> Section 5: > >>>> > >>>> “is 72 seconds” looks precise though in fact it is very rough. Could > >>>> say “in the order of a minute”. Same for V2V, 36s. > >>>> > >>>> Section 5.1.1 > >>>> > >>>> “off-link” > >>>> > >>>> That terminology does not really exist. All we have is “not-onlink”. > >>>> > >>>> Section 5.2 > >>>> > >>>> “There is nonnegligible > >>>> control overhead to set up and maintain routes to such a tunnel home > >>>> over the VANET.” > >>>> > >>>> There again a link to RFC 4888 > >>>> > >>>> “Vehicles can use the TCC as their Home Network having a home agent > >>>> for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213],” > >>>> > >>>> add “and NEMO [RFC 3963]” > >>>> > >>>> Appendix A: Mentions OMNI but fails to document real world implemented > >>>> protocols such as DLEP which abstract the radio modem over ethernet > >>>> > >>>> The following are minor issues (typos, misspelling, minor text > >>>> improvements) with the document: > >>>> > >>>> Section 5.1: > >>>> “ > >>>> This merging and partitioning should be considered for the > >>>> IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) > >>>> [RFC4862]. > >>>> “ > >>>> “ > >>>> they may not communicate with each other not in one > >>>> hop in the same > >>>> > >>>> “ > >>>> I can understand but the language seems incorrect. Also Fred says: > >>>> ‘ > >>>> change: "they need to be configured with a link-local IPv6 address or > >>>> a global > >>>> IPv6 address" to: "they need to be configured with link-local, > >>>> unique-local and/or global IPv6 addresses" > >>>> > >>>> ‘ > >>>> I mostly agree but then, those addresses are not necessarily > >>>> configured. Maybe just says that they need the addresses. > >>>> > >>>> Section 6.1 > >>>> > >>>> “the DAD”: we usually do not have the “the”. This appears throughout. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> its mailing list > >>>> its@xxxxxxxx > >>>> https://www.ietf.org/mailman/listinfo/its -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
