Re: [ipwave] [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 -subnet structure, multicast

[Alexandre Petrescu <[e-mail]>]

Le 11/04/2019 à 22:49, Brian E Carpenter a écrit :
> Hi,
> 
> If there are multiple interfaces, it seems to me that you
> automatically have the situation described by Pascal, in which
> traditional Ethernet-like multicast ND, DAD and RA simply do not
> work.

Brian,

IPv6 ND on multiple OCB interfaces of an IP-OBU Router works ok.  Each 
interface has its own subnet, with its own ND, DAD and RA.  The router 
forwards IP packets between these interfaces.  It has a routing table.

I do not understand what do you mean when you say that EThernet-like 
multicast ND, DAD and RA simply do not work.

>> a standard that works even if there's a single OCB interface.
> 
> That's the easy case.

I agree.

Alex

> 
> Regards Brian
> 
> On 12-Apr-19 03:15, William Whyte wrote:
>> Hi Alex -- there *can* be multiple OCB interfaces in one car, but
>> should the standard be written assuming that there are multiple OCB
>> interfaces? I would have thought that the goal would be to write a
>> standard that works even if there's a single OCB interface.
>> 
>> If we're relying on multiple OCB interfaces to make this work, how
>> many of those interfaces per car are we relying on? We can't
>> presumably be assuming a distinct interface for each remote car
>> that the local car is communicating with. If we aren't assuming a
>> distinct interface for each remote car, then doesn't the problem
>> that Pascal identifies come up?
>> 
>> (You also mention that the antenna at the front of car B
>> communicates with the one at back of car A -- but what if A
>> overtakes B? And to be clear, I'm not asking for a direct answer to
>> that question, I'm saying that if there are assumptions about the
>> physical topology that we're relying on, we need to make those
>> assumptions very clear and make them clear up front)
>> 
>> I'd be very concerned if we were writing a standard that didn't
>> work if there was only one OCB interface in the car. Can you
>> reassure me on that?
>> 
>> Cheers,
>> 
>> William
>> 
>> 
>> 
>> 
>> On Thu, Apr 11, 2019 at 5:25 AM Alexandre Petrescu
>> <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> 
>> Pascal,
>> 
>> Do you agree there can be multiple IP OCB interfaces in one car?
>> 
>> Alex
>> 
>> Le 11/04/2019 à 11:23, Alexandre Petrescu a écrit :
>>> Pascal,
>>> 
>>> Please allow me to change the subject of this, to reflect the
>>> content. It helps tracking the discussion.
>>> 
>>> Le 11/04/2019 à 04:36, Pascal Thubert (pthubert) a écrit :
>>>> Hello Brian
>>>> 
>>>> I meant broadcast at layer 2 not layer 3. L3 uses multicast but
>>>> it requires a service at the lower layer to implement it. This
>>>> is rarely if ever a real L2 multicast service.
>>> 
>>> I can agree.
>>> 
>>>> IOW the IETF has thrown the problem over the fence to the IEEE
>>>> but it is not really solved to this day.
>>> 
>>> I think indeed there is redirection of responsability to IEEE.
>>> Maybe IEEE does not like to do it, because of some reasons.
>>> 
>>> With respect to link-layer multicast: there is indeed no IEEE
>>> messaging for creation or removal of link-layer multicast groups
>>> (like in IP there is MLDv2).  But there is concept of link-layer
>>> multicast groups at IEEE. This is used extensively by mapping IP
>>> groups into link-layer groups, and it helps IP.
>>> 
>>> Should IEEE develop a mechanism using messages (not just local
>>> filters) for creating these link-layer groups?
>>> 
>>>> In practice, the service that is performed on IEEE std 802.3 is
>>>> a broadcast over a broadcast domain, and the subnet has to be
>>>> contained within that domain.
>>> 
>>> Well yes and no.
>>> 
>>> Yes it is a broadcast  on 802.3 if we talk IPv4, but it is still 
>>> link-layer multicast on 802.3 if we talk IPv6: the link-layer
>>> addresses ofIPv6 on Ethernet are link-layer multicast addresses.
>>> 
>>>> The broadcast operation is emulated on IEEE std 802.11 by the
>>>> BSS operation whereby the AP reflects the message to be
>>>> broadcasted, so the broadcast domain is that of the AP as
>>>> opposed to that of the source STA.
>>> 
>>> I agree.
>>> 
>>>> By the proposed definition, if car A sees car B they are in the
>>>> same subnet. If car B sees car C they are in the same subnet.
>>>> Transitively Car A is in the same subnet as car C.
>>> 
>>> PAscal, again, this depends on how you set up the OCB interfaces
>>> on cars A, B and C.
>>> 
>>> There are two options: - use a single OCB interface with antenna
>>> sitting on top of each automobile.  Make them all in the same
>>> channel frequency (e.g. CCH - Control Channel).  That indeed has
>>> that A-B-C transitivity aspect. Worse, it has scalability issues:
>>> one cant grow a convoy beyond a few tens of meters and be sure
>>> the frontmost talks directly to the rearmost.  One never knows
>>> whether somebody in the middle repeats, or not.  Or one needs to
>>> rely on MANET protocols that may forward on a single interface.
>>> It has some PHY issues as well, that I can describe.  The
>>> powerpoint is readily filled with my last PHY experiments of
>>> propagation. - use multiple OCB antennas situated at some
>>> strategic places in a car. This is in the same way as when
>>> placing the other ultra sound, radar and lidar sensors in the
>>> automobile.
>>> 
>>> An OCB interface in the front bumper of one car forms a subnet
>>> with another OCB interface in the rear bumper of another car, on
>>> a particular channel (SCHx - service channel number x).  The
>>> front and rear subnets of a car are in distinct channels.  There
>>> is no A-B-C transitivity.  There is IP forwarding between front
>>> and rear interfaces of a car.
>>> 
>>> This can be described.  But I dont think it should be described
>>> in the IP-over-OCB document.  It is a PHY MAC setting for OCB.
>>> 
>>>> But car C may not be in the radio broadcast domain of car A,
>>>> and there is no BSS by definition of OCB to emulate a broadcast
>>>> domain between them via an AP. End result is that a DAD or a
>>>> lookup by car A will not reach car C.
>>> 
>>> That may be true, but it is true mostly in a setting where each
>>> car uses a single OCB interface whose antenna is placed on the
>>> roof of the car (placed at same place as the the GPS, LTE, FM or
>>> DVB-T antennas are placed).
>>> 
>>> In settings where each car has multiple OCB interfaces and
>>> multiple antennas placed at strategic places (strategic: places
>>> that are relevant to PHY propagation conditions), rather than
>>> simply on the roof, the issue you describe in the above
>>> paragraph.
>>> 
>>> Now, if you read up to here, I would like to ask you (without
>>> claiming to be all-knowing), whether you think a car could have
>>> several OCB interfaces?
>>> 
>>>> By traditional MANET and 6lo definition, the radio broadcast
>>>> domain of a node is his link.
>>> 
>>> It is good, and I agree with it.
>>> 
>>> For my part, I do not use the traditional MANET and 6lo
>>> definitions because I believe they are not sufficient for
>>> vehicular environments.
>>> 
>>>> In you lab you can arrange that the broadcast domains of 3 cars
>>>> fully overlap.
>>> 
>>> I agree, people do that.  It is in small lab, with size in the
>>> range of a few meters; there is much reflexion from the walls.
>>> It is not outdoors.
>>> 
>>>> In that case, the link appears to match the common sense of a
>>>> link in wires and the classical IPv6 operations will work
>>>> pretty much the same as in a BSS over that Link. It is for
>>>> example easy to place a subnet that matches that Link. It is
>>>> also easy to confuse a Link with a Subnet, which is what the
>>>> definition does. As soon as the broadcast domains start
>>>> diverging, things get hairy, see all the work by Erik about
>>>> split subnet etc...
>>> 
>>> I fully agree with this paragraph.
>>> 
>>> I think if one puts several interfaces and antennas in a car,
>>> and carefully design the use of the propagation models (e.g.
>>> avoid 'omni', consider 'directional', etc) then one can avoid
>>> many problems forbidding IP from running on wireless.
>>> 
>>>> The IETF has studied this situations for 10+ years at MANET,
>>>> 6TiSCH and 6lo. We have an architecture that cover single link
>>>> and multilink subnets.
>>> 
>>> Yes, there is.
>>> 
>>>> In the former case, the link is defined by one node that owns
>>>> the prefix. In the latter case, routing is required inside the
>>>> subnet and we created RPL to cover the situation.
>>> 
>>> YEs, but these are departures from what might be called
>>> traditional IP forwarding.  That forwarding happens between two
>>> distinct interfaces.
>>> 
>>> In practice it means little software for MANET-6lo-multilink is
>>> publicly available, and the engineer skill about them is hard to
>>> find.  This translates to equipment being very expensive.
>>> 
>>> I want to tell you that communication equipment for cars is
>>> already very high compared to an off-the-shelf WiFi router.  That
>>> high price tag is due also to specification of things that are
>>> too intelligent and that require high skills from few people.
>>> This is the case of V2X stacks doing ETSI CAM with GeoNetworking
>>> and similar.  You end up with a 3000Eur IP-OBU when its
>>> underlying hardware with linux and traditional IP forwarding
>>> costs around 700Eur.
>>> 
>>> To that 3000Eur one may need to add costs of complexity of MANET 
>>> protocols and 6lo multilink subnet moels you arrive at a cost
>>> per communication box that is the equivalent of a small car.
>>> 
>>> This high cost is less and less acceptable.
>>> 
>>> Compare that to the 1Eur LTE-WiFi dongle retrofitted recently in
>>> some cars.
>>> 
>>>> We created RFC 8505 for an host to connect to the network in
>>>> either situation, without the requirement that the L2 broadcast
>>>> domain of the host (its Link) overlaps with that of other nodes
>>>> in the subnet (because they don't). We have made RFC 8505
>>>> abstract to the routing protocol if any, IOW without the
>>>> requirement that the host knows there is a MLSN, understands
>>>> RPL or whatever other routing is used
>>> 
>>> MLSN?
>>> 
>>>> to put together the MLSN. To get there we had to abandon the 
>>>> dependency that a L2 broadcast from the host reaches all nodes
>>>> in the subnet, IOW that the subnet is contained within the Link
>>>> of all of
>>> 
>>> IOW?
>>> 
>>>> its members, IOW that the Links of all the nodes in the subnet
>>>> fully overlap. This meant we had to abandon the idea of using
>>>> multicast in ND for DAD and AR.
>>>> 
>>>> Maybe someone can explain that better than I did. I so please
>>>> be my guest. I really tried but I'm not convinced I did not
>>>> waste my time with the authors of the draft.
>>> 
>>> You did not waste your time, no more than I did.
>>> 
>>> Alex
>>> 
>>>> 
>>>> All the best,
>>>> 
>>>> Pascal
>>>> 
>>>>> -----Original Message----- From: Int-dir
>>>>> <[e-mail]> <mailto:[e-mail]> 
>>>>> On Behalf Of Brian E Carpenter Sent: jeudi 11 avril 2019
>>>>> 09:54 To: NABIL BENAMAR <[e-mail]>
>>>>> <mailto:[e-mail]>; Pascal Thubert (pthubert) 
>>>>> <[e-mail]> <mailto:[e-mail]> Cc:
>>>>> [e-mail] <mailto:[e-mail]>; [e-mail]
>>>>> <mailto:[e-mail]>; [e-mail]
>>>>> <mailto:[e-mail]>; draft-ietf-ipwave-ipv6-over-
>>>>> [e-mail] <mailto:[e-mail]>;
>>>>> Alexandre Petrescu <[e-mail]>
>>>>> <mailto:[e-mail]>; Ole Troan
>>>>> <[e-mail]> <mailto:[e-mail]> Subject:
>>>>> Re: [Int-dir] Intdir early review of
>>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming IPv6'
>>>>> - fe80::/10 vs fe80::/64
>>>>> 
>>>>> Hi Nabil,
>>>>> 
>>>>> On 11-Apr-19 03:40, NABIL BENAMAR wrote:
>>>>>> Do we still talk about broadcast in IPv6 ?
>>>>> 
>>>>> No, we talk about multicast. Pascal was using shorthand. But
>>>>> if multicast fails with high probability, several aspects of
>>>>> IPv6 will fail too, unless the LAN provides an NBMA
>>>>> (non-broadcast multiple access) emulation of multicast, or
>>>>> suitable alternatives to SLAAC, ND, NUD, and RA.
>>>>> 
>>>>> An earlier draft of this spec mentioned this problem:
>>>>> 
>>>>>>>> The operation of the Neighbor Discovery protocol (ND)
>>>>>>>> over 802.11-OCB links is different than over 802.11
>>>>>>>> links.  In OCB, the link layer does not ensure that all
>>>>>>>> associated members receive all messages, because there
>>>>>>>> is no association operation.  Neighbor Discovery (ND)
>>>>>>>> is used over 802.11-OCB.
>>>>> 
>>>>> but it was inconsistent and was removed. If Ole is correct
>>>>> below about real-life conditions, the *problem* was not
>>>>> removed and the draft is not going to work in the real
>>>>> world.
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> 
>>>>>> On Wed, Apr 10, 2019, 14:45 Pascal Thubert (pthubert)
>>>>> <[e-mail] <mailto:[e-mail]>
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>> wrote:
>>>>>> 
>>>>>> Hello Ole:
>>>>>> 
>>>>>> Better remove, it is wrong anyway.
>>>>>> 
>>>>>> Because it is transitive, the description extends the
>>>>>> so-called subnet step
>>>>> by step to a potentially large number of cars such that there
>>>>> is no broadcast domain that covers them all. If there is no
>>>>> broadcast domain and no multicast emulation like a BSS does,
>>>>> how can we run ND? Yes, it works with 3 cars in a lab.
>>>>>> 
>>>>>> The description looks like it is confused with the MANET /
>>>>>> 6LoWPAN
>>>>> concept of link, whereby my link joins the collection of
>>>>> nodes that my radio can reach.
>>>>>> 
>>>>>> All the best,
>>>>>> 
>>>>>> Pascal
>>>>>> 
>>>>>>> -----Original Message----- From: Ole Troan
>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>>> Sent: mercredi 10 avril 2019 20:41 To: Alexandre Petrescu
>>>>>>> <[e-mail]
>>>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>>
>>>>>>> Cc: Pascal Thubert (pthubert) <[e-mail]
>>>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>;
>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>;
>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]>; [e-mail]
>>>>>>> <mailto:[e-mail]> <mailto:int-
>>>>> [e-mail] <mailto:[e-mail]>>;
>>>>> draft-ietf-ipwave-ipv6-over-
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]>; Brian E
>>>>> Carpenter <[e-mail]
>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>>
>>>>>>> Subject: Re: [Int-dir] Intdir early review of
>>>>>>> draft-ietf-ipwave-ipv6-over- 80211ocb-34 - 'conforming
>>>>>>> IPv6' - fe80::/10 vs fe80::/64
>>>>>>> 
>>>>>>>> You said: if OCB is still 48bit, and if there is
>>>>>>>> bridging OCB-Ethernet, then
>>>>> no
>>>>>>> reason to be different than rfc2464.
>>>>>>>> 
>>>>>>>> I said: OCB is still 48bit, but there is no bridging
>>>>>>>> OCB-Ethernet.
>>>>>>>> 
>>>>>>>> The conclusion is: there is reason to be different from
>>>>>>>> RFC 2464.
>>>>>>> 
>>>>>>> Why?
>>>>>>> 
>>>>>>>> Now, you give a different conclusion.
>>>>>>>> 
>>>>>>>> Excuse me, I would like to clarify this please?
>>>>>>> 
>>>>>>> Clarify what? That a link-layer that looks an awfully lot
>>>>>>> like Ethernet should not follow
>>>>> the
>>>>>>> 64-bit boundary and the definition of the link-local
>>>>>>> address mapping of rfc2464? Section 4.5.1 is already
>>>>>>> clear on that.
>>>>>>> 
>>>>>>> I think the only thing we are asking you is to change the
>>>>>>> following
>>>>> paragraph:
>>>>>>> 
>>>>>>> OLD: A subnet is formed by the external 802.11-OCB
>>>>>>> interfaces of vehicles that are in close range (not by
>>>>>>> their in-vehicle interfaces).  This subnet MUST use at
>>>>>>> least the link-local prefix fe80::/10 and the interfaces
>>>>>>> MUST be assigned IPv6 addresses of type link-local.
>>>>>>> 
>>>>>>> NEW: A subnet is formed by the external 802.11-OCB
>>>>>>> interfaces of vehicles that are in close range (not by
>>>>>>> their in-vehicle interfaces). A node MUST form a
>>>>>>> link-local address on this link.
>>>>>>> 
>>>>>>> Not quite sure what value that paragraph adds in the
>>>>>>> first place. You
>>>>> could
>>>>>>> probable remove it.
>>>>>>> 
>>>>>>> Cheers, Ole
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Alex
>>>>>>>> 
>>>>>>>> Le 10/04/2019 à 12:28, Ole Troan a écrit :
>>>>>>>>> Alexandre, Right, so it doesn’t sound like you have
>>>>>>>>> any reason to be different
>>>>> from
>>>>>>> RFC2464.
>>>>>>>>> Just reference or copy that text (section 5,
>>>>>>>>> rfc2464). Ole
>>>>>>>>>> On 10 Apr 2019, at 11:22, Alexandre Petrescu
>>>>>>> <[e-mail]
>>>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Le 10/04/2019 à 11:04, Ole Troan a écrit :
>>>>>>>>>>>>>>> "At least" does not mean "the value
>>>>>>>>>>>>>>> should be at least 10" in
>>>>> that
>>>>>>> phrase.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Do you think we should say otherwise?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> To me there is nothing in the actual text
>>>>>>>>>>>>>> to tell me that "at
>>>>> least"
>>>>>>>>>>>>>> qualifies the "/10". I think you could
>>>>>>>>>>>>>> rephrase as "This subnet's prefix MUST lie
>>>>>>>>>>>>>> within the link-local prefix fe80::/10
>>>>>>>>>>>>>> ..."
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> However, see Jinmei's messages about
>>>>>>>>>>>>>> conformance with RFC
>>>>> 4291.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think there might be unexpected side
>>>>>>>>>>>>>> effects from using an address like
>>>>>>>>>>>>>> fe80:1::1. What if some code uses matching
>>>>>>>>>>>>>> with fe80::/64 to test if an address is
>>>>>>>>>>>>>> link-local? I agree that would be faulty
>>>>>>>>>>>>>> code, but you would be the first to
>>>>>>>>>>>>>> discover it.
>>>>>>>>>>>>> Indeed. If you absoultely must cut and paste
>>>>>>>>>>>>> text from 2464:
>>>>>>>>>>>> 
>>>>>>>>>>>> YEs, that is how we started.  We cut and paste
>>>>>>>>>>>> from 2464.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 5.  Link-Local Addresses The IPv6 link-local
>>>>>>>>>>>>> address [AARCH] for an Ethernet interface is
>>>>>>>>>>>>> formed by appending the Interface Identifier,
>>>>>>>>>>>>> as defined above,
>>>>> to
>>>>>>>>>>>>> the prefix FE80::/64. 10 bits            54
>>>>>>>>>>>>> bits 64 bits
>>>>>>>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> 
|1111111010|         (zeros)       |    Interface Identifier    |
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +----------+-----------------------+----------------------------+
>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 
I presume there is support for bridging 802.11p and
>>>>>>>>>>>>> other 802.3
>>>>> links?
>>>>>>>>>> 
>>>>>>>>>> In the IP-OBUs that I know there is IP forwarding
>>>>>>>>>> between 802.11-
>>>>> OCB
>>>>>>> (earlier 802.11p) and 802.3, not bridging.
>>>>>>>>>> 
>>>>>>>>>> In some IP-OBU (Internet Protocol On-Board Unit)
>>>>>>>>>> some non-OCB
>>>>>>> interfaces are indeed bridged.  E.g. the Ethernet
>>>>>>> interface is bridged to
>>>>> the
>>>>>>> WiFi interface; that helps with DHCP, tcpdump and others
>>>>>>> to see one a
>>>>> single -
>>>>>>> bridged - interface.
>>>>>>>>>> 
>>>>>>>>>> Bridging may be, but it is not a MUST.  There is no
>>>>>>>>>> necessarily any
>>>>> bridging
>>>>>>> between the 802.11-OCB interface and other interface,
>>>>>>> neither bridging between the multiple 802.11-OCB
>>>>>>> interfaces that might be present in
>>>>> the
>>>>>>> same computer.
>>>>>>>>>> 
>>>>>>>>>> Do you assume bridging of 802.11-OCB interface to
>>>>>>>>>> Ethernet
>>>>> interface is
>>>>>>> always there?
>>>>>>>>>> 
>>>>>>>>>> Note: I also heard many comments suggesting that
>>>>>>>>>> EAL is akin to
>>>>>>> 'bridging'.  I do not know whether you refer to that
>>>>>>> perspective.  If yes,
>>>>> we can
>>>>>>> discuss it separately.
>>>>>>>>>> 
>>>>>>>>>> Alex
>>>>>>>>>> 
>>>>>>>>>> [...]
>>>>>>>>>> 
>>>>>>>>>>>>> And that the MAC address length of this link
>>>>>>>>>>>>> type is also 48 bits?
>>>>>>>>>>>> 
>>>>>>>>>>>> YEs, the length of MAC address on 802.11 mode
>>>>>>>>>>>> OCB is also 48.
>>>>>>>>>>>> 
>>>>>>>>>>>>> If the two assumptions above hold, then I see
>>>>>>>>>>>>> zero justification
>>>>> for
>>>>>>> pushing the 64 bit boundary in this draft.
>>>>>>>>>>>> 
>>>>>>>>>>>> Let me try  to understand the first
>>>>>>>>>>>> assumption.
>>>>>>>>>>> Ole
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Int-dir mailing list [e-mail]
>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>>>> 
>>>>>>>> _______________________________________________ Int-dir
>>>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>>>>>> 
>>>>> 
>>>>> _______________________________________________ Int-dir
>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/int-dir
>> _______________________________________________ its mailing list 
>> [e-mail] <mailto:[e-mail]> 
>> https://www.ietf.org/mailman/listinfo/its
>> 
>> 
>> 
>> --
>> 
>> ---
>> 
>> I may have sent this email out of office hours. I never expect a
>> response outside yours.
> 
>