Subject: [spring] Ben Campbell's No Objection on draft-ietf-spring-resiliency-use-cases-11: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Dec 2017 19:23:28 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-spring-resiliency-use-cases-11: 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-spring-resiliency-use-cases/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Requirements Language: The 2119 keywords in this draft are not used in the
sense of RFC 2119. That RFC talks explicitly about interoperability among
protocol implementations. This draft uses them to define requirement for
protocol and architecture design. That's not necessarily a problem, but please
change the Requirements Language section to describe the actual usage.

-2, third paragraph from end:    "o  SPRING architecture MUST provide a way to
compute paths that MUST NOT be protected by local repair techniques..." The
MUST NOT seems a statement of fact. Consider something to the effect of "...
compute paths that are not protected by local repair techniques..."

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Dec 2017 14:52:36 +0100

Hi Ben,

I took the editor role from Stefano.

Please see inline:

> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/

do you have an example of what exactly should we put in the Requirements 
Language?

Is it sufficient to say following?

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 
this document are used to define requirements for protocol and 
architecture design."

> compute paths that are not protected by local repair techniques..."

agree. Changed to "are not protected"

I will post the new revision once we close on all open items from you 
and other reviewers.

thanks,
Peter

>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> .
>