Re: [Last-Call] Genart last call review of draft-ietf-ippm-ioam-deployment-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ines, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On Nov 17, 2022, at 01:47, Ines Robles via Datatracker <noreply@xxxxxxxx> wrote:
> 
> Reviewer: Ines Robles
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-ippm-ioam-deployment-02
> Reviewer: Ines Robles
> Review Date: 2022-11-16
> IETF LC End Date: 2022-11-16
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> The document provides a framework for "In-situ" Operations, Administration, and
> Maintenance (IOAM) deployment and discusses IOAM Deployment, Types of IOAM,
> IOAM Encapsulations, IOAM Data Export, Deployment Considerations and IOAM
> Manageability The document is well written, and has a good set of references.
> 
> I have some minor questions that I set as nits.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments/Questions:
> 
> 1- Page 19: "... defining performance limits on IOAM encapsulation and IOAM
> exporting" -> how are defined the performance limits? 2- What about the IOAM
> Data overhead? if it is possible to have it, how to handle it? 3- The IOAM data
> is inserted in the packet, even if the data payload is zero? or this scenario
> is not possible? 4- In
> [https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-ipv6-options-00.pdf]
> states: "Packet forwarding behaviour or decisions should not change due to
> presence of IOAM". Does this apply to this document as well, right?
> 
> Thanks for this document,
> Ines.
> 
> 
> 
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call

Attachment: signature.asc
Description: Message signed with OpenPGP

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux