Subject: [spring] Deborah Brungard's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

From: Deborah Brungard <[email-masked]>
Date: Thu, 14 Dec 2017 06:38:12 -0800

Deborah Brungard has entered the following ballot position for
draft-ietf-spring-oam-usecase-09: 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-oam-usecase/

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

Substantive Comments:
General:
I consider Informational status as appropriate. I found the draft title "oam-usecase"
a bit misleading as the document is specifically about a centralized OAM system,
but the document title is accurate so I'm ok as the draft title will not be visible once
an RFC. "Framework and use cases" would of been more appropriate (to me).

Because of the draft title, I found the document a bit confusing initially as I was not sure
if "system" was used in the BFD sense e.g. a functional component or as hinted at initially,
and as Section 4, Fig. 1 shows, a physically separate "system". Suggest it would help the
reader to more clearly say this in the Abstract (the rtgdir reviewer also hinted at this).

I'm not sure why the choice was to specifically specify a physically separate system? Why
not as a functional component with a use case as being physically separate? And considering
the document is scoped to a physically separate system, there is not much information
on what is needed to support a physical separation (other AD comments). I'd suggest
strongly to do a simple rewording to scope as a functional component. SDN architectures
are based on functional components as everyone has different ideas on the physical location
of a component and "functional" provides a flexibility. Suggest looking at RFC5623 on the
VNTM component.

Nits:
I found multiple sentences lacked clarity/grammar. Ben noted several. Will depend if
restructure to not preclude as a functional component. The first sentence
of the abstract could be improved:
a path monitoring/s/an MPLS path monitoring

---

From: <[email-masked]>
Date: Fri, 15 Dec 2017 07:42:17 +0000

Hi Deborah,

thanks for your comment. Your suggestion to describe the PMS as a functional component (and a use case "separate physical unit") is good. I have no command of SDN or RFC5623 related terminology yet. I'll have to read a little before I start to parse the draft and adapt text.

I'll also adapt 

Noone of the author team is a native speaker. Text of teams like ours admittedly has a certain tendency to be grammatically challenging. Missing clarity should be removed.

Regards, 

Ruediger

-----Ursprüngliche Nachricht-----
Von: Deborah Brungard [mailto:[email-masked]] 
Gesendet: Donnerstag, 14. Dezember 2017 15:38
An: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Deborah Brungard's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Substantive Comments:
General:
I consider Informational status as appropriate. I found the draft title "oam-usecase"
a bit misleading as the document is specifically about a centralized OAM system, but the document title is accurate so I'm ok as the draft title will not be visible once an RFC. "Framework and use cases" would of been more appropriate (to me).

Because of the draft title, I found the document a bit confusing initially as I was not sure if "system" was used in the BFD sense e.g. a functional component or as hinted at initially, and as Section 4, Fig. 1 shows, a physically separate "system". Suggest it would help the reader to more clearly say this in the Abstract (the rtgdir reviewer also hinted at this).

I'm not sure why the choice was to specifically specify a physically separate system? Why not as a functional component with a use case as being physically separate? And considering the document is scoped to a physically separate system, there is not much information on what is needed to support a physical separation (other AD comments). I'd suggest strongly to do a simple rewording to scope as a functional component. SDN architectures are based on functional components as everyone has different ideas on the physical location of a component and "functional" provides a flexibility. Suggest looking at RFC5623 on the VNTM component.

Nits:
I found multiple sentences lacked clarity/grammar. Ben noted several. Will depend if restructure to not preclude as a functional component. The first sentence of the abstract could be improved:
a path monitoring/s/an MPLS path monitoring

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 08:06:30 +0000

Hi Deborah, hi Ben,

after having received an IESG state change to "Approved-announcement to be sent::Revised I-D Needed", we've submitted

https://www.ietf.org/id/draft-ietf-spring-oam-usecase-10.txt

We didn't agree on two issues. However we added text trying to improve the draft. It is marked [RG] below.

Regards, Ruediger

Deborah wrote:

[RG] We've kept "system" in the Abstract. We've reworded the second section of the Introduction to express that the PMS is a functional component.
   
   [Version -10, Introduction, 2nd section]
   This document describes a system as a functional component called
   (MPLS) Path Monitoring System, PMS.  The PMS is using MPLS data plane
   path monitoring capabilities.  The use cases introduced here are
   limited to a single Interior Gateway Protocol (IGP) MPLS domain.  The
   use cases of this document refer to the PMS system realised as a
   separate node.  Although many use cases depict the PMS as a physical
   node, no assumption should be made, and the node could be virtual.
   This system is defined as a functional component abstracted to have
   many realizations.  The terms PMS and system are used interchangeably
   in the following.

There's been an open issue with Ben, too. 

> -- [BC1]  10, last paragraph: I don't understand the intent of this paragraph.
> 
>   [RG1]

>   NEW: A PMS may be configured to permanently surveil a set of LSPs. Changes of the Segment Routing topology may occur at any time. The PMS design must stop a permanent LSP measurement, as soon as it detects that its locally stored SR domain topology information related to an LSP to be monitored is stale.

[BC2]  Sorry, I’m still not following it. Is the point that a PMS may continuously monitor a set of LSPs, but it needs to stop doing that for a particular LSP if that LSP changes?

[RG2] Yes. I've tried to explain that better in  [Version -10, Security, last section]

   A PMS may operate routine measurements on large scale.  Care must be
   taken to avoid unintended traffic insertion after topology changes
   which result , e.g., in changes of label assignments to routes or
   interfaces within a domain.  If the labels concerned are part of the
   label stack composed by the PMS for any measurement packet and their
   state is stale, the measurement initially needs to be stopped.  Set
   up and operation of routine measurements may be automated.  Secure
   automated PMS operation requires a working automated detection and
   recognition of stale routing state.

-----Ursprüngliche Nachricht-----
Von: Deborah Brungard [mailto:[email-masked]] 
Gesendet: Donnerstag, 14. Dezember 2017 15:38
An: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Deborah Brungard's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

Substantive Comments:
General:

Nits: