Re: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT)

[Lou Berger <[e-mail]>]

Stephen,

No problem and I was trying to respond to the comment.  I just didn't
quite understand the point you were making.  It sounds like the comment
is addressed so we don't need to discuss and further.  Do feel free to
respond privately if you want more background info...

Thanks,
Lou

On 05/26/2015 03:48 PM, Stephen Farrell wrote:
> 
> 
> On 26/05/15 19:26, Lou Berger wrote:
>> Hi Stephen,
>>
>> See below.
>>
>> On 05/26/2015 10:10 AM, Stephen Farrell wrote:
>>> Stephen Farrell has entered the following ballot position for
>>> draft-ietf-ccamp-wson-signaling-12: 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-ccamp-wson-signaling/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>>
>>> Just wondering: does this (or some other document) provide me
>>> with a way to say that node X should take an input lambda and
>>> replicate it out twice? 
>>
>> RFC4875 allows this under signaled control. So nothing new is introduced
>> by this document.
> 
> Thanks. That's all I was after - I really was just curious
> and not trying to find a problem with this draft:-)
> 
> S.
> 
>>
>>> (I.e. forking the traffic) If so, then
>>> that probably ought be noted somewhere as it'd enable forms of
>>> monitoring that might otherwise require a visit to the physical
>>> node.
>>>
>>
>> I'm sorry, I don't understand this.  signaling allows one to automate
>> what is already possible via other mechanisms, e.g., network management.
>>  If the equipment requires a physical change to provision/split (aka
>> drop and continue) a lambda, adding support for signaling doesn't change
>> this.
>>
>> Lou
>>
>>
>>
>