[Top] [All Lists]

Re: Genart last call review of draft-ietf-spring-oam-usecase-06

2017-07-02 15:15:00
Hi, Pete,

Many thanks for the time to read and review this document!

Like Ruediger, I will let the shepherd, chairs, and AD weight in — but in the 
meantime, I wanted to offer a couple of observations for consideration. Please 
see inline.

On Jun 28, 2017, at 2:31 PM, Pete Resnick 
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:

Reviewer: Pete Resnick
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-spring-oam-usecase-06
Reviewer: Pete Resnick
Review Date: 2017-06-28
IETF LC End Date: 2017-06-30
IESG Telechat date: Not scheduled for a telechat

Summary: Not Ready for publication as Informational, but might be Ready for
publication as Proposed Standard

Major issues:

This is an admittedly unusual review. I have read through the entire document,
and the technical work seems fine, but is well beyond my technical expertise,
so I can't really comment on the technical correctness. However, it is
absolutely clear to me that this is *not* a "use case" document at all

I agree with the assessment that this is not a “use-case” document (in a strict 
or traditional sense); this document describes a deployment case and a solution 
to a use case, using existing technology blocks. It does not define new 
protocol nor (more importantly) creates interoperability considerations. 

and I
don't think it's appropriate as an Informational document.

Now, regarding the most appropriate intended status, I could personally argue 
both sides, and frankly, I do not have a strong preference or concern either 

The net of it is that this (informational/specification) document does not 
create requirements for SPRING nodes, changes in SPRING, nor exposes 
interoperability issues. It basically leverages as-is the underlying 
capabilities created with SPRING. From that angle, Informational is a very 
appropriate fit. On the other hand, I do not disagree with this document 
specifying a system, and the play-of-words that results in standards-track — so 
it is a spec for the path monitoring system, but provides information to the 
network and to SPRING specs on how the new tech can be used.

Net-net, I see Informational but can understand your rationale.

In any case, what does concern me more is whether a potential change of 
intended status would add significant delay and reset process timers on a 
timeline that is already overstretched and a very slow progress…

This is clearly a
*specification* of a path monitoring system. It gives guidances as to 
recommended, and optional parameters, and specifies how to use different
protocol pieces. It is at the very least what RFC 2026 refers to as an
"Applicability Statement (AS)" (see RFC 2026, sec. 3.2). It *might* be a BCP,
but it is not strictly giving "common guidelines for policies and operations"
(2026, sec. 5), so I don't really think that's right, and instead this should
be offered for Proposed Standard. Either way, I think Informational is not
correct. Importantly, I think there is a good likelihood that this document 
not received the appropriate amount of review; people tend to ignore
Informational "use case" documents,

This, however, I think is an inappropriate extrapolation. Although the 
shepherd, WG and chairs already considered the intended status, I think it is 
important to re-think what’s best for this document in the context of the 
merits, structure and goals. But justifying it not being informational because 
“people tend to ignore […]” seems a red herring. 

and there have been no Last Call comments
beyond Joel's RTG Area Review.

Within SPRING, this document dates the origins of the WG. It was presented in 
many WGs numerous times and iterated through many versions (within three 
filenames) as various reviews came in. I’d recommend you also go back and check 
the timeline. I would not also make hard conclusions based on LC traffic.

Even in IESG review, an Informational document
only takes the sponsoring AD to approve; every other AD can summarily ignore
the document, or even ballot ABSTAIN, and the document will still be published
(though that does not normally happen). This document should have much more
than that level of review. I strongly recommend to the WG and AD that this
document be withdrawn as an Informational document and resubmitted for 
Standard and have that level of review and scrutiny applied to it.

As I said, I am happy with either status and can see arguments both ways. I 
would not object to a change. 

However, personally, I do not see the need.

Minor issues:


Nits/editorial comments:

This document refers to RFC 4379, which has been obsoleted by RFC 8029. It
seems like the references should be updated.

Indeed. Done in -07 and -08.

Thanks again, Pete!

Carlos Pignataro, carlos(_at_)cisco(_dot_)com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

<Prev in Thread] Current Thread [Next in Thread>