Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
A few nits: "This document may not necessarily be published as an IETF Stream RFC but may be maintained in draft form to support the efforts of the Working Group and help newcomers." Personally I think that this document should be published as an RFC - if it is written to "support the efforts of the WG and help newcomers" it will also be useful for newcomers to the technology once the primary work product is published. When the point-haired-boss walks into your office and says "Oi, Dilbert! Go deploy 'RFCxxx - Time Variant Aware OSPFv10'", a problem statement which explains what actual *issue* RFCxxx is supposed to solve is really helpful.... If we do keep this, can we at least appease Warren's OCD? Every time I'm on an plane and hear: "Cover your nose and mouth with the mask. The bag may not inflate. Put on your own mask first before you help others." I get annoyed; I picture an oxygen mask falling from the ceiling, someone putting it on, watching the bag inflate and then squishing all of the oxygen out, because of the implied imperative "The bag may not inflate"... I get that this says: "may not necessarily", but still, could it be reworded to something like: "This document exists to support the efforts of the Working Group and help newcomers, and might not become an RFC"? Note that I still think that it should be dropped -- I personally thing that Use Case, Architecture, Applicability Statement, Deployment Guides, etc are all very useful documents...
Thanks for addressing my concerns.
A fascinating WG... Some comments below: From a non-English speaker.. Should there be an hyphen between 'time' and 'variant' as in 'Time-Variant Routing' ? `The TVR WG will provide its outputs for consideration by other Routing Area Working Groups`, why only within RTG ? I could see link to TSV and INT at least (and of course OPS/SEC). Suggest to simply say "other IETF WGs". Information model: will the information cover the 'forwarding' even if the WG name (and charter) is only about routing ? Information model: usually an information goes beyond a set of attributes as it should/must at least include relationships among those attributes. `YANG Data Model(s)`, it should probably be either "YANG data model" (singular) or "YANG data modules" (plural). Applicability: "models" ? as in data/information models ? Or is it something else ?
“Solutions are expected to satisfy the non-terrestrial networks' requirements as their main driver. Still, they should be general enough to encompass other types of networks and use cases. They should also be applicable to routing and other protocols.” I don’t understand what it means for a solution to be “applicable to routing”. Surely, routing is an enabling technology, not a use case requiring a solution in and of itself? Related, I don’t know what it means to be “applicable to… other protocols”. Would it be reasonable to remove this sentence?
Thanks for addressing my suggestions.
I'm not sure that I have a good feeling what the shape of the solution will look like and what impact it will have on the routing protocols (hence there is a bit of me that wonders whether this is really more IRTF than IETF). The key to it seems to be wanting to calculate a likely new topology that will happen at a future time and to be able to move from current topology to the new topology whilst minimizing traffic interruptions (e.g., presumably along the lines of gracefully draining links and moving traffic off them before they known to become unavailable). One question that I have is whether this WG is only tasked with looking at solutions in the routing protocols themselves? E.g., presumably there are also possible solutions here either making use of a controller that directly orchestrates the network changes via modifying the configuration across the network (e.g., draining links, changing metrics, etc., although I can appreciate that won't work with deep space satellites), or the use of time dependent configuration. E.g., regular configuration that is annotated with metadata such that parts of the configuration are only active (i.e., only applied) at particular times of day. I think that some vendors (Juniper?) support some form of time dependent configuration, although I've not aware of any efforts to standardize it. One potential benefit of trying to solve this in the configuration layer could be that the same broad common solution may work for all protocols. I'm also somewhat struggling to really see whether TVR can really have meaningful environment benefits, or specifically, whether the additional complexity will be worth the gain. Having said all of that, I don't think that this proposal will do any harm, possibly except the increase in complexity in the protocols, so, no formal objection to this WG being started. Regards, Rob