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. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
