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

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 <alexandre.petrescu@gmail.com>님이
작성:

> 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 :
>
> 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 <
> Fred.L.Templin@boeing.com> 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
>>
>>
> _______________________________________________
> its mailing listits@ietf.orghttps://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://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: pauljeong@skku.edu, jaehoon.paul@gmail.com
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>