Re: [Gen-art] Genart last call review of draft-ietf-extra-imap4rev2-24

[Alissa Cooper]

Robert, thanks for your review. I entered a No Objection ballot.

Alissa


> On Jan 14, 2021, at 5:08 PM, Robert Sparks via Datatracker  
> wrote:
> 
> Reviewer: Robert Sparks
> Review result: Ready
> 
> 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
> 
> .
> 
> Document: draft-ietf-extra-imap4rev2-24
> Reviewer: Robert Sparks
> Review Date: 2021-01-14
> IETF LC End Date: 2021-01-20
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready for publication as a Proposed Standard RFC
> 
> I approached reviewing this document first by diffing it with RFC3501, then
> doing a linear read-through. Errata seem appropriately handled. This looks 
> like
> it was a huge effort - it is very well done. I sent the few nits I could find
> directly to the editors.
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-mpls-rfc6374-sfl-08

[Elwyn Davies via Datatracker]

Reviewer: Elwyn Davies
Review result: Not Ready

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

.

Document: draft-ietf-mpls-rfc6374-sfl-??
Reviewer: Elwyn Davies
Review Date: 2021-02-02
IETF LC End Date: 2021-01-26
IESG Telechat date: Not scheduled for a telechat

Summary:  Not Ready.  Apologies that this review is rather late, but I found 
this 
document extremely hard to work with.  There appear to be a number of areas 
where 
the work is rather too much in progress rather than ready for publication as an 
RFC.  
I also found it very difficult, not just as someone who is not at all familiar 
with this
area of work, but at a basic technical level to work out what the protocol was 
going 
to be able to achieve and whether a LSR would garner the information it 
appeared 
to need to deliver what was clamed.  Part of this appeared to be due to 
multiple 
names being used for the same thing and being used with other than their 
natural 
meaning particulaly in sections 7.1 and 7,2. 

Major Issues:

s7, What is being standardized?:

> A number of methods are described.  The expectation is that the MPLS
> WG possibly with the assistance of the IPPM WG will select one or
> maybe more than one of these methods for standardization.
>
I find this statement very confusing.  This document is intended for
standards track, so if it goes ahead as is, the three methods are
standardised and implementors would be expected to provide support for
all of them unless there are to be words to indicate that not all need
to be supported.   Is this the intention? Or is it that this document
should only support the methods chosen by the MPLS working group?  In
the latter case, this document is definitely not ready for
standardization; I assume the unused method(s) would be removed in this
case.  Otherwise the second sentence is speculative and should be removed.

s7, Title, purpose and general method:

Note that I have very limited knowledge of this area of performance
measurement so there may be misunderstandings here. However, given that
caveat, I did not find the document very helpful in enlightening me and
a considerable amount of background reading was needed to try and
determine what was going on.

Firstly, I assume that this section covers the 'additional techniques'
mentioned in the Abstract  and described as 'more sophisticated
measurements' in s1. [Perhaps common phraseology would be desirable
between the two cases.]  I suggest a sentence to make this clear would
be desirable.

Secondly, AFAICS these techniques are basically about measuring and
communicating  delay jitter in various ways.  It might be helpful to
link what is being offered here with RFC 5481 and the discussion of
delay variation measurement in RFC 6374.  Section 7.1 is, as I
understand it, covering IPDV measurement using (in general) normal
service packets rather than just specialised RFC 6374 packets and
working primarily on one LSR.  I assume that the technique in s7.2 is
primarily a means for reporting measurements derived from s7.1 and/or
s7.4, but given that actual delays are mentioned rather than
inter-packet gaps, the

s7.1: After the first sentence, the first paragraph talks about delay. 
Since the receiving LSR has no knowledge of the transmission time of
each individual packet, it is not possible for the LSR to calculate
actual delays without additional information - I take it that the
packets are not intended to be RFC 6374 Delay Measurement Packets as
these would require corresponding responses which would contravene the
query interval setting  and there does not appear to be a way for the
LSR doing the measurements to be told the inter-packet transmission
interval.  Should this be written in terms of inter-packet gaps rather
than delays throughout?  Further, The first paragraph describes two
methods of operation without saying which one should be standardised or
AFAICS providing a selection flag to allow either to be used.

It seems to me that an outline of how this facility might be used is
pretty much essential.  Would I be right in thinking that to measure the
delay jitter between a source LSR (S) and destination LSR (D), the
operator decides to send a set of packets at equally spaced intervals
from S to D and decides on the interval and the number of packets.  S
then issues a Query setting the query interval to a time greater than
that needed to send the  set of packets and using the Bucket Jitter
Measurement Message to set the bucket delay intervals around the
sending  interval according to the Operator's expectations of the
network.  D then sets up to measure the inter-packet delays up until the
next Bucket Jitter Measurement message arrives after the