Re: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Fred

Please see below 

> Le 2 mars 2022 à 21:06, Templin (US), Fred L <[e-mail]> a écrit :
> 
> OK Pascal, I am back again - see below for responses:
> 
> Fred
> 
>> -----Original Message-----
>> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
>> Sent: Tuesday, March 01, 2022 12:43 AM
>> To: Templin (US), Fred L <[e-mail]>; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: RE: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
>> 
>> Hello Fred
>> 
>>> -----Original Message-----
>>> From: Templin (US), Fred L <[e-mail]>
>>> Sent: lundi 28 février 2022 19:09
>>> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
>>> Cc: [e-mail]; draft-ietf-ipwave-vehicular-
>>> [e-mail]; [e-mail]
>>> 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:[e-mail]] On Behalf Of Pascal Thubert
>>>> via Datatracker
>>>> Sent: Monday, February 28, 2022 5:57 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail];
>>>> [e-mail]; [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/its