Hi Ben, With apologies to the WG for adding a late comment.
On 02.08.18 02:30, Benjamin Kaduk wrote: > In particular, in its current form, it's not clear to me why this document > is targeting the standards-track -- there are lots of places where > determinations of what works best or how to do some things is left for > future work. Are there lots of implementations or consumers clamoring for > this stuff that it makes sense to go for PS as opposed to Experimental (so > as to figure out what works and nail down a slimmer protocol for the > standards track)? I see in A.4 that the choice of RPL was motivated by > experience with a pre-standard version of ACP; it would have been great to > hear more about those deployments in an Implementation Status section (per > RFC 7942) or the Shepherd writeup. FWIW I do not think experimental is appropriate. Experiments have beginnings and endings, and exit conditions. Nor for PS should an implementation report be required (quite the opposite). I think PS is more appropriate. This is a pretty big document, and it is architectural in nature, and there are multiple building blocks in this document. How they fit together may change based on operational experience, and to me that means that a future revised PS of this document would be considerably firmer. To require that everything be spelled out for this PS would be a bit much. On the other hand, there are no fewer than *44* uses of the word "future" prior to the appendices. Some of this is a certain writing style for a general architecture, but at the end of the day I was left wondering whether https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01 should be taken to heart in this instance. In particular, the following stands out to me: > "rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits > of using rsub may depend on the results of future work on enhancing > routing for the ACP. Why define rsub now if it has no semantic value? Is that the garnish that nobody eats? I see three different things going on in this document: * Some real future proofing with extension mechanisms. * Some implicit and explicit forward references to work that is a bit behind this work. I think the purpose of this text is to justify particular functionality as fulfilling some envisioned dependency. * Stuff like the above that doesn't seem well justified. The big concern with all of this is when an extension is used on one system and no by another, will there be interoperability problems? Especially as relates to ACP domain membership. I don't have a good feel for that in a few of these cases. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
