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

From: Pete Resnick <[email-masked]>
Date: Wed, 28 Jun 2017 11:31:24 -0700

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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 and I
don't think it's appropriate as an Informational document. This is clearly a
*specification* of a path monitoring system. It gives guidances as to required,
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 has
not received the appropriate amount of review; people tend to ignore
Informational "use case" documents, and there have been no Last Call comments
beyond Joel's RTG Area Review. 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 Proposed
Standard and have that level of review and scrutiny applied to it.

Minor issues:

None.

Nits/editorial comments:

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

---

From: <[email-masked]>
Date: Thu, 29 Jun 2017 07:28:17 +0000

Hi Pete,

thanks for proposing to make this an Applicability Statement, BCP or standard.

I don't object, but if the status of this draft is supposed to be changed, my chairs and AD need to support this. Bruno and Alvaro, what's your view on Pete's proposal? We may have to invest some more time and text then. I personally don't object to "informational" as an aim, but if that means removing major parts of the content, I'd be rather unhappy.

Pete, also Alvaro gave us a routing AD review on Friday, 16. June (and he had comments). Bruno's shephard review as part of the WG Last Call resulted in better structuring and definitions in the document. So far, no AD or reviewer "tends to ignore [this] Informational "use case" document". You’re the third AD to comment and ask for changes (and I recall to have had serious AD and IESG reviews with other informationals).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Pete Resnick [mailto:[email-masked]] 
Gesendet: Mittwoch, 28. Juni 2017 20:31
An: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Genart last call review of draft-ietf-spring-oam-usecase-06

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.

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 and I don't think it's appropriate as an Informational document. This is clearly a
*specification* of a path monitoring system. It gives guidances as to required, 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 has not received the appropriate amount of review; people tend to ignore Informational "use case" documents, and there have been no Last Call comments beyond Joel's RTG Area Review. 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 Proposed Standard and have that level of review and scrutiny applied to it.

Minor issues:

None.

Nits/editorial comments:

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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 29 Jun 2017 10:18:17 -0500

On 29 Jun 2017, at 2:28, [email-masked] wrote:

> I don't object, but if the status of this draft is supposed to be 
> changed, my chairs and AD need to support this. Bruno and Alvaro, 
> what's your view on Pete's proposal? We may have to invest some more 
> time and text then. I personally don't object to "informational" as an 
> aim, but if that means removing major parts of the content, I'd be 
> rather unhappy.

Thanks for considering this. IMO, I don't see why doing this as PS would 
require removing anything; lots of PSs have informational content in 
them.

> Pete, also Alvaro gave us a routing AD review on Friday, 16. June (and 
> he had comments). Bruno's shephard review as part of the WG Last Call 
> resulted in better structuring and definitions in the document. So 
> far, no AD or reviewer "tends to ignore [this] Informational "use 
> case" document". You’re the third AD to comment and ask for changes 
> (and I recall to have had serious AD and IESG reviews with other 
> informationals).

Oh, I didn't mean to say that serious reviews of Informational docs 
didn't happen; it quite often does. But the bar is lower, and I know for 
myself (both as a participant and as an AD) that sometimes I would skip 
reading a particular document because I had run out of time and "it was 
only going for Informational", or see something that I didn't like in a 
Informational document and say, "Well, it's only going for 
Informational, so I'm not going to cause too much of a fuss". For a 
document that is actually a consensus specification of an IETF WG, that 
shouldn't be allowed to happen; everybody should be aware that this 
document should get the full scrutiny of a standards-track document.

> Ruediger

Cheers,

pr

> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> 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.
>
> 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 and I don't think it's appropriate as an 
> Informational document. This is clearly a
> *specification* of a path monitoring system. It gives guidances as to 
> required, 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 has not received the appropriate amount 
> of review; people tend to ignore Informational "use case" documents, 
> and there have been no Last Call comments beyond Joel's RTG Area 
> Review. 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 Proposed Standard and have that level of review 
> and scrutiny applied to it.
>
> Minor issues:
>
> None.
>
> Nits/editorial comments:
>
> This document refers to RFC 4379, which has been obsoleted by RFC 
> 8029. It seems like the references should be updated.

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478