Subject: Re: [ipwave] Comments on draft-ietf-ipwave-vehicular-networking-23

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 9 Oct 2021 16:25:00 +0900

Hi Fred,
I have address all your comments on the revision of IPWAVE PS Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-24

Thanks for your suggestion.

Best Regards,
Paul

On Fri, Sep 24, 2021 at 11:05 PM Templin (US), Fred L <
[email-masked]> wrote:

> Paul, a couple of comments on the -23 draft version:
>
> 1) For AERO, change the title expansion to “Automatic Extended Route
> Optimization”.
>
> 2) The correct references for AERO and OMNI are:
>
> https://datatracker.ietf.org/doc/draft-templin-6man-aero/34/
> https://datatracker.ietf.org/doc/draft-templin-6man-omni/47/
>
> 3) Appendix B now seems to say a lot about RPL and not much about
> AERO/OMNI.
> Please add the following to Appendix B:
>
> "AERO and OMNI together securely and efficiently address the “6 M’s of
> Modern Internetworking” for mobile V2V, V2I and V2X Clients, including:
>
> 1. Multilink – a Client's ability to coordinate multiple diverse
> underlying data links as a
> single logical unit (i.e., the OMNI interface) to achieve the required
> communications
> performance and reliability objectives.
>
> 2. Multinet - the ability to span the OMNI link over a segment routing
> topology with multiple
> diverse administrative domain network segments while maintaining seamless
> end-to-end
> communications between mobile Clients and correspondents such as air
> traffic controllers,
> fleet administrators, etc.
>
> 3. Mobility - a Client's ability to change network points of attachment
> (e.g., moving between
> wireless base stations) which may result in an underlying interface
> address change, but
> without disruptions to ongoing communication sessions with peers over the
> OMNI link.
>
> 4. Multicast - the ability to send a single network transmission that
> reaches multiple
> Clients belonging to the same interest group, but without disturbing other
> Clients not
> subscribed to the interest group.
>
> 5. Multihop - a mobile Client vehicle-to-vehicle relaying capability
> useful when multiple
> forwarding hops between vehicles may be necessary to "reach back" to an
> infrastructure
> access point connection to the OMNI link.
>
> 6. MTU assurance - the ability to deliver packets of various robust sizes
> between peers
> without loss due to a link size restriction, and to dynamically adjust
> packets sizes to
> achieve the optimal performance for each independent traffic flow."
>
> That is all I have for now, but will let you know if I notice anything
> else.
>
> Thanks - Fred
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 9 Oct 2021 12:00:59 +0200

Thank you for the update.

With respect to authorship: there is a list of Authors, and an Editor.  
But the address on page 50 is titled 'Author's Address' whereas it 
should be titled 'Editor's address'.

Maybe that is a problem with xml2rfc, or something else.

Alex

Le 09/10/2021 à 09:25, Mr. Jaehoon Paul Jeong a écrit :
> <https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-24>
>
> On Fri, Sep 24, 2021 at 11:05 PM Templin (US), Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     1) For AERO, change the title expansion to “Automatic Extended
>     Route Optimization”.
>
>     <https://datatracker.ietf.org/doc/draft-templin-6man-aero/34/>
>     <https://datatracker.ietf.org/doc/draft-templin-6man-omni/47/>
>
>     single logical unit (i.e., the OMNI interface) to achieve the
>     required communications
>     2. Multinet - the ability to span the OMNI link over a segment
>     routing topology with multiple
>     diverse administrative domain network segments while maintaining
>     seamless end-to-end
>     communications between mobile Clients and correspondents such as
>     air traffic controllers,
>     3. Mobility - a Client's ability to change network points of
>     attachment (e.g., moving between
>     wireless base stations) which may result in an underlying
>     interface address change, but
>     without disruptions to ongoing communication sessions with peers
>     over the OMNI link.
>
>     4. Multicast - the ability to send a single network transmission
>     that reaches multiple
>     Clients belonging to the same interest group, but without
>     disturbing other Clients not
>     5. Multihop - a mobile Client vehicle-to-vehicle relaying
>     capability useful when multiple
>     forwarding hops between vehicles may be necessary to "reach back"
>     to an infrastructure
>     6. MTU assurance - the ability to deliver packets of various
>     robust sizes between peers
>     without loss due to a link size restriction, and to dynamically
>     adjust packets sizes to
>     That is all I have for now, but will let you know if I notice
>     anything else.
>
>     Thanks - Fred
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 9 Oct 2021 20:57:31 +0900

Hi Alex,
the issue of Author's Address seems to be caused by xml2rfc for the xml
file of our IPWAVE PS draft.

Later an RFC editor will be able to handle this issue when our draft is
approved as an RFC.

Thanks.

Best Regards,
Paul

2021년 10월 9일 (토) 오후 7:02, Alexandre Petrescu <[email-masked]>님이
작성:

> But the address on page 50 is titled 'Author's Address' whereas it should
> be titled 'Editor's address'.
>
>> Clients belonging to the same interest group, but without disturbing
>> other Clients not
> its mailing [email-masked]://www.ietf.org/mailman/listinfo/its
>
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>