Re: [Teas-ns-dt] FW: New Version Notification for draft-nsdt-teas-ns-framework-03.txt

[Eric Gray <[e-mail]>]

Greg,

              Thanks for your comments.  😊

              John and I need to discuss all but your last three Nits; we will probably fix the last two, and the one immediately prior to that is not correct, as SBI is expanded in the 2nd paragraph of the Introduction, already.

              Your 1st Nit points out capitalization inconsistency of which your instance is but one of many – and we need to decide what to be consistent with.

              Note that we cannot simply follow the example in the current definitions draft, as that is not entirely consistent either.

--
Eric

From: Greg Mirsky <[e-mail]>
Sent: Saturday, April 25, 2020 3:02 PM
To: Eric Gray <[e-mail]>
Cc: [e-mail]
Subject: Re: [Teas-ns-dt] FW: New Version Notification for draft-nsdt-teas-ns-framework-03.txt
Importance: High

Hi Eric,
thank you and John for a great document. Below, kindly find one question and several minor nits.

  *   As I understand, TSC receives customer/user request, formulated as a set of intentions, and translates into technology-specific instructions to instantiate a transport slice. Is that correct? I think that part of the user-specified intention may be related to the TS resiliency, i.e., protection, restoration. If that is the case, wouldn't TSC not only notify the user about a crossed SLO threshold but take an appropriate action to restore the TS's performance to the required level? If that makes sense, perhaps the list of the controller provided functions in Section 3..3 can be appended with text like:
Via SBI, the controller modifies the underlying components of the transport slice according to the resiliency part of the consumer-defined abstraction.


Nits:

  *   Abstract.

     *   seems that "are" should be removed and a word is missing in
Note that there are is a rather large of these technologies ...
Would the following be acceptable?
Note that there is a rather large number of these technologies ...

  *   Section 3.3

     *   Capitalization s/transport Slices/transport slices/
     *   SBI needs the full form (southbound interface) on the first use
     *   why capitalize Telemetry data, Statistics, States?

  *   Section 3.3.1

     *   extra "passed over" (the first sentence fourth para)
Regards,
Greg

On Wed, Apr 22, 2020 at 8:52 AM Eric Gray <eric.gray=[e-mail]<mailto:[e-mail]>> wrote:
This new version fixes a few minor typos and updates the reference to the definitions draft.

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 22, 2020 11:51 AM
To: Eric Gray <[e-mail]<mailto:[e-mail]>>; John Drake <[e-mail]<mailto:[e-mail]>>; Eric Gray <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-nsdt-teas-ns-framework-03.txt
Importance: High


A new version of I-D, draft-nsdt-teas-ns-framework-03.txt
has been successfully submitted by Eric Gray and posted to the IETF repository.

Name:           draft-nsdt-teas-ns-framework
Revision:       03
Title:          Framework for Transport Network Slices
Document date:  2020-04-22
Group:          Individual Submission
Pages:          17
URL:            https://www.ietf.org/internet-drafts/draft-nsdt-teas-ns-framework-03.txt
Status:         https://datatracker.ietf.org/doc/draft-nsdt-teas-ns-framework/
Htmlized:       https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nsdt-teas-ns-framework
Diff:           https://www.ietf.org/rfcdiff?url2=draft-nsdt-teas-ns-framework-03

Abstract:
   This memo discusses setting up special-purpose transport connections
   using existing IETF technologies.  These connections are called
   transport slices for the purposes of this memo.  The memo discusses
   the general framework for this setup, the necessary system components
   and interfaces, and how abstract requests can be mapped to more
   specific technologies.  The memo also discusses related
   considerations with monitoring and security.

   This memo is intended for discussing interfaces and technologies.  It
   is not intended to be a new set of concrete interfaces or
   technologies.  Rather, it should be seen as an explanation of how
   some existing, concrete IETF VPN and traffic-engineering technologies
   can be used to create transport slices.  Note that there are is a
   rather large of these technologies, and new technologies or
   capabilities keep being added.  This memo is also not intended
   presume any particular technology choice.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


--
Teas-ns-dt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt