Pete, thanks for your review. I have entered a No Objection ballot. I don’t have a strong feeling about moving this document to PS or keeping it as-is.
Alissa > On Jul 7, 2017, at 9:07 AM, [email protected] wrote: > > Hi Pete, Carlos, > >> From: Carlos Pignataro (cpignata) [mailto:[email protected]] > Sent: >> Sunday, July 02, 2017 10:14 PM >> >> 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 <[email protected]> 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 >>> >>> <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 >> >> 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. > > As the doc shepherd, I agree that this document is more than a use case and > describes both a use case (sections 1, 4) and a monitoring system (sections 3 > and 6 to 8). And there is even an implementation report: > https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00 > > However, the solution related part does not require stand track document as > it runs as a standalone device with no need for interoperability. Indeed, the > solution leverages Segment Routing/SPRING so that a unique node is used as > both the sender and the receiver. As such, the system is free to use any OAM > protocol/packet format with no interoperability consideration. It looks to me > that such freedom is part of this Path Monitoring System use case/system. > Plus, I fear that moving to standard track would mean changing the document > into a precise specification (e.g. which OAM tool(s) to use and the way to > use them) which was not the goal, may require significant work and delay, and > may even be suboptimal in removing freedom. > > TL;DR: On my side, I don't feel that the document needs to be standard track. > But I guess that ultimately the decision is on the AD/IESG side. > > Thanks, > --Bruno > >>> 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 way. >> >> 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 >>> 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, >> >> 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 >>> Proposed >>> 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: >>> >>> 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. >>> >>> >> >> Indeed. Done in -07 and -08. >> >> Thanks again, Pete! >> >> — >> Carlos Pignataro, [email protected] >> >> “Sometimes I use big words that I do not fully understand, to make myself >> sound more >> photosynthesis." > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
