Erik Kline has entered the following ballot position for draft-ietf-pce-stateful-pce-lsp-scheduling-18: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ section 1 ] * "the service really being used" -> "the service is really being used"? [ section 4.1 ] * "SHALL check ... and computes" -> "... and compute" * "on the scheduling usage expires" -> "on scheduled usage expiration"? [ section 4.2.2 ] * If there is no possible path do you want some text, maybe even just a lowercase should, about "should report to an administrator" or something? [ section 4.3 ] * In the first of the 4 bullet points at the end of this section, should the "required" and "shall" be capitalized? [ section 4.5 ] * "In other case," -> "In all other cases," or just "Otherwise,"? [ section 5.1 ] * Perhaps there's a way to strengthen the "PD requires B" text by saying what an endpoint should do if it sees PD without B? [ section 5.2.1 & 5.2.2 ] * R bit. WRT to R=0 and the wraparound, it would seem to me that in this case the receiver really needs to check if start-time is less than the current time, and if so treat that as wrap-around (2106) + start-time number of seconds. Otherwise, I think you'll need to be more precise about what it means to be "near" the wrap-around. Even still, if times are not sync'd carefully and the start-time is not a moderate amount of time in the future there remains a chance that an endpoint could receive a start-time it perceives as "in the past". What should an endpoint in this circumstance? Yet another alternative is to take a flag bit to indicate that start-time is after the wrap-around, and say that by 2242 CE some other solution should be found. :-) * Duration: Is a value of 1 just as nonsensical as 0? What about a value of 0 if grace-before and grace-after are non-zero? I may not understand the grace and elastic uses properly, but it seems to me that the thing to forbid is an "effective duration" of 0 (i.e. factoring in grace or elastic values). * Grace and Elastic fields: If it cannot provide both simultaneously why have both fields? What just have a "lower" and "upper" pair of fields and choose a new flag value to indicate whether the fields are grace values or elastic values? _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
