Re: [Teas] WG adoption and draft naming process (Re: 答复: Poll on draft-lee-teas-actn-requirements-01 a WG documents)

[Lou Berger <[e-mail]>]

Daniele,

On September 26, 2015 2:58:14 PM Daniele Ceccarelli 
<[e-mail]> wrote:

> I would like to just comment on the file name.
>
> I would really appreciate keeping the ACTN name for the solution.

We hadn't really discussed a renaming of the  solutions docs, only the 
requirements doc which read as pretty generic.

> The reason is probably futile, but now when I say ACTN to a customer or a 
> colleague they would understand what I mean. There are publications, papers 
> and also the ONF and ITUT refer to ACTN (see the incoming liaison), so 
> unless the WG and the chairs strongly feel the need for a different name, 
> I'd really appreciate it to be left unchanged.
>

I'm not sure that arguing for using a marketing name for a set of 
technology solutions helps your case much. But that said,  renaming the 
ACTN solution set isn't something we have discussed or been discussing.

I personally didnt expect a name change  on the solutions drafts,  but am 
ambivalent on the topic. If others hold counter opinions, they should 
express them.  Although,  please note that we have yet to consider any 
solutions documents for WG adoption.

Lou

> That said, I see three options:
> 1. Widening the scope of the requirements work (hence finding a new name 
> for it) and leaving ACTN as a solution for a sub-set of such requirements. 
> I'm fine with that
> 2. Keeping the scope of the requirements and solution aligned and as broad 
> as possible. I'm less comfortable with that but it's fine if it doesn't 
> imply changing the name.
> 3. Not only improving but also changing the scope of the requirements and 
> the solution...please don't do so.
>
> From what you write below
>> While this understanding lead us to name the requirements draft independently
>> from the solution in an attempt to highlight why the requirements don't apply
>> to existing work, perhaps it would be fine to tie the two directly together 
>> -- I'll
>> talk off line with Pavan.
>
> I tend to understand that you're in favor of option 2...
>
> BR
> Daniele
>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: giovedì 24 settembre 2015 14:37
>> To: Leeyoung; Vishnu Pavan Beeram
>> Cc: TEAS WG; Daniele Ceccarelli; Varma, Eve L (Eve); draft-lee-teas-actn-
>> [e-mail]
>> Subject: WG adoption and draft naming process (Re: [Teas] 答复: Poll on draft-
>> lee-teas-actn-requirements-01 a WG documents)
>>
>> NOTE:I've changed the title so that we can keep separate process discussion
>> from the definition discussion.  Please keep comments limited to the
>> appropriate thread so folks (like Adrian) that don't care about the process can
>> ignore it.
>>
>> <This is the process thread>
>>
>> On 9/23/2015 1:21 PM, Leeyoung wrote:
>> > Hi Lou and Pavan,
>> >
>> > OK, I think we are converging. I personally have not seen any cases where
>> WG chairs demanded the name change of the adopted work, but this may have
>> been limited to my own experience.
>>
>> Yes. It must be.  Perhaps because (a) it isn't an every day occurrence, and (b)
>> I've never seen a set of authors balk to this level on a name change -- in 
>> fact I
>> can't recall *ever* seeing authors protest a change by a chair.
>>
>> For examples, take a look at the replaced by section of
>> http://tools.ietf.org/wg/ccamp/
>>
>> Another good example is draft-giacalone-ospf-te-express-path which was
>> replaced by draft-ospf-te-metric-extensions
>>
>> If you/anyone else has questions about WG draft adoption process -- please ask
>> them by replying to this thread.  It seems that there a more than a few
>> confused on this.
>>
>> > ...
>>
>> WRT the draft filename:
>>
>> To me the definition still reads as ACTN is a set of solutions (i.e., = "new
>> methods and capabilities to support virtual network operations") .
>> While this understanding lead us to name the requirements draft independently
>> from the solution in an attempt to highlight why the requirements don't apply
>> to existing work, perhaps it would be fine to tie the two directly together 
>> -- I'll
>> talk off line with Pavan.
>> Either way, vn-orchestration or vn-operation would be/have been a better
>> choice than vn-controller.
>>
>> Lou
>>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas