Re: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)

[Martin Vigoureux <[e-mail]>]

Hi Daniele,

thanks.
Please see in-line.

-m

Le 2018-05-24 à 16:47, Daniele Ceccarelli a écrit :
> Hi Martin,
> 
> Regarding the other issues:
> 
>     The PNC functions can be implemented as part of an SDN domain
> 
>     controller, a Network Management System (NMS), an Element Management
> 
>     System (EMS), an active PCE-based controller [Centralized] or any
> 
>     other means to dynamically control a set of nodes and that is
> 
>     implementing an NBI compliant with ACTN specification.
> 
> I have few comments:
> 
> which ACTN specification are you referring to ?
> 
> Usually when I read "comply with a specification", I expect to read a 
> MUST/SHOULD in the same sentence. I can understand that you don't want 
> to put a compliance requirement, but then you might want to use another 
> word than "compliant". NBI is not defined/expanded anywhere in the doc. 
> In fact it's the only place where it appears. And in fact seeing it here 
> while Fig. 2 talks about SBI only makes the reader uncertain. One way 
> out of this would be to make it appear on Fig 2. because it's just the 
> same interface, seen from the other direction.
> 
> [DC] We’re referring to the documents that describe the ACTN MPI and CMI 
> interfaces. (which is basically a set of YANG models like e.g. the 
> TE-Topology, TE-tunnel, etc). Basically the idea is: “I’m not telling 
> you here what you have to implement to be compliant with and ACTN MPI, 
> but it you can implement and ACTN MPI on top of one of the boxes listed 
> above, such box can be put into the ACTN controllers hierarchy and that 
> works just fine”.
ok ...
So you're saying that what an implementation would have to comply with 
is out of the scope of this document. Why not be explicit about that?

What about my comment on NBI?

> 
> You say:
> 
>     A PNC domain includes all the resources under the control of a
> 
>     single PNC.  It can be composed of different routing domains and
> 
>     administrative domains, and the resources may come from different
> 
>     layers.
> 
> Is that consistent with the definition of Domain? More precisely, is 
> that consistent with the last sentence of the Domain definition which says:
> 
>     Network elements will often be grouped into domains based on
> 
>     technology types, vendor profiles, and geographic proximity.
> 
> [DC] I would say yes, in the sense that all the nodes controlled by the 
> same PNC for a PNC domain. Usually all the from the same technology are 
> grouped under the control of the same PNC, or the ones from the same 
> vendor. Obviously can be stated better…
ok. I was probably confused by layer/technology

> 
> 4.1. MDSC Hierarchy
> 
> Can there be more than two levels in the MDSC hierarchy? In other words, 
> can an MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L? As a side 
> note, since I made the mistake while writing this, you have two 
> occurrences of MSDC (instead of MDSC) in the doc .
> 
> [DC] exactly, yes.
Wouldn't it be worth saying it?
> 
> Cheers
> 
> Daniele
> 
>  > -----Original Message-----
> 
>  > From: Martin Vigoureux <[e-mail]>
> 
>  > Sent: giovedì 24 maggio 2018 15:14
> 
>  > To: [e-mail]; 'The IESG' <[e-mail]>
> 
>  > Cc: [e-mail]; [e-mail];
> 
>  > [e-mail]; [e-mail]
> 
>  > Subject: Re: [Teas] Martin Vigoureux's No Objection on 
> draft-ietf-teas-actn-
> 
>  > framework-14: (with COMMENT)
> 
>  >
> 
>  > Adrian,
> 
>  >
> 
>  > thank you for your quick reply.
> 
>  > Actually I prefer the new text :-) but I let you decide which one to use.
> 
>  >
> 
>  > Ok for not capitalising the first letter of domain. I note however 
> there is one
> 
>  > such occurrence:
> 
>  >     border nodes in Domain Y to PE2
> 
>  >
> 
>  > cheers
> 
>  > -m
> 
>  >
> 
>  >
> 
>  > Le 2018-05-24 à 12:36, Adrian Farrel a écrit :
> 
>  > > Hi Martin,
> 
>  > >
> 
>  > > Thanks for the comments. Although I am not a front page author, I am
> 
>  > > answering the first of the comments because some of the text in
> 
>  > > question was probably mine.
> 
>  > >
> 
>  > > I'll leave the rest for Young and Danielle.
> 
>  > >
> 
>  > >> * I'm not sure to understand your definition of Domain. You say:
> 
>  > >> Specifically within this document we mean a part of an operator's
> 
>  > >> network that is under common management. I'm not sure to understand
> 
>  > >> what common means.
> 
>  > >
> 
>  > > The definition of "common" we're using is:
> 
>  > > "belonging to or shared by two or more individuals or things or by all
> 
>  > > members of a group"
> 
>  > >
> 
>  > > So we could say (note, we also forgot to comma a subclause) OLD
> 
>  > >          Specifically within this document
> 
>  > >          we mean a part of an operator's network that is under common
> 
>  > >          management.
> 
>  > > NEW
> 
>  > >          Specifically, within this document,
> 
>  > >          we mean a part of an operator's network that is under shared
> 
>  > >          operational management using the same instances of a tool and
> 
>  > >          the same policies.
> 
>  > > END
> 
>  > >
> 
>  > > (But actually, I find the original cleaner)
> 
>  > >
> 
>  > >> Also, you add a sentence after that but it didn't help me, in fact it
> 
>  > >> confused me further. Is it the managed entities which have something
> 
>  > >> in common or is that the managing entities which have something in
> 
>  > >> common? In the latter case what would be the common thing?
> 
>  > >
> 
>  > > The following sentence is:
> 
>  > >          Network elements will often be grouped into
> 
>  > >          domains based on technology types, vendor profiles, and
> 
>  > >          geographic proximity.
> 
>  > >
> 
>  > > Examples of this would be:
> 
>  > > - WDM equipment is managed using different instances of tools and
> 
>  > >     different policies from TDM equipment
> 
>  > > - Optical equipment from vendor A is managed using different instances
> 
>  > >     of tools and different policies from vendor B
> 
>  > > - A ring or a metro network is usually managed using different 
> instances
> 
>  > >    of tools and different policies from other networks
> 
>  > >
> 
>  > >> On that matter, I would suggest to capitalise the first letter of all
> 
>  > >> the occurrences of domain which correspond to this definition (with
> 
>  > >> the hope that all of them do).
> 
>  > >
> 
>  > > My experience of the RFC Editor is that they really hate that form of
> 
>  > > capitalisation. And since *all* mentions of "domain" in this document
> 
>  > > conform to this definition, I think the document is consistent and no
> 
>  > > capitalisation is needed.
> 
>  > >
> 
>  > > Cheers,
> 
>  > > Adrian
> 
>  > >
> 
>  > >
>