Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

That seems OK to me. There are some aspects that we need to
discuss over in Anima in due course.

   Brian
On 09/07/2015 01:53, Pierre Pfister wrote:
> Thank you for this proposal.
> 
> In the same spirit (but reducing the amount of changes), what about 
> « and can therefore be used in fully autonomic as well as configured networks »  ?
> 
> I think « configured » has a smaller scope than « professionally managed network ».
> 
> - Pierre
> 
> 
>> Le 7 juil. 2015 à 23:54, Meral Shirazipour <meral.shirazipour@ericsson.com> a écrit :
>>
>> Hi,
>>  Thanks for including me. Adding back gen-art list to this thread. I am ok with Brian's suggested text. 
>>
>> Best,
>> Meral
>>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
>> Sent: Tuesday, July 07, 2015 2:25 PM
>> To: Pierre Pfister
>> Cc: IESG; homenet@ietf.org; Meral Shirazipour
>> Subject: Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment
>>
>> Pierre,
>>
>> Thanks for the prompt reply. I am not too worried about the process issue, and I do understand why that whole paragraph was added (I've added Meral in cc).
>>
>> Your explanation is fine but the phrase "and can therefore be used in fully autonomic as well as professionally managed networks" still makes some big assumptions. How about "and can therefore be used more widely than in unmanaged home networks"?
>>
>>> I will be in Prague as well and would be happy to discuss whether PA could be useful to Anima.
>>
>> I can easily imagine an autonomic service agent (in Anima terminology) using this algorithm (quite independent from whether it uses DNCP).
>>
>> Regards
>>   Brian
>>
>> On 08/07/2015 08:38, Pierre Pfister wrote:
>>> Hello Brian,
>>>
>>> This change was introduced after the Gen-ART review from Meral Shirazipour, I quote:
>>>  "I found the draft a bit hard to follow as the incentive was not clear at first. 
>>>  A few sentences in abstract or introduction on 'why' we need this algorithm and what would the 'alternatives' be would be useful. Right now it only says 'what' the algorithm does."
>>>
>>> This whole paragraph was therefore added:
>>>   This document specifies a distributed algorithm for automatic prefix
>>>   assignment.  The algorithm provides a generic alternative to
>>>   centralized (human or software based) approaches for network prefixes
>>>   and addresses assignment.  Although it does not require to be
>>>   configured to operate properly, it supports custom configuration by
>>>   means of variable priority assignments, and can therefore be used in
>>>   fully autonomic as well as professionally managed networks.
>>>
>>> Its purpose is to clarify the goal of the algorithm in a short sentence.
>>>
>>> Digging back into my mails, I realize that the exchange I had about this update with Meral was private.
>>> My mistake, i thought the mailing list was cc’d to the discussion. Apologies for that.
>>> Too bad we did not settled this situation earlier, but anyway, I am glad we can discuss the change now.
>>>
>>> Still digging, I see you invited the Anima mailing list to discuss 
>>> that change as well. Feedback from Anima is very welcome. I mean, not 
>>> about the scopyness or not of a sentence, but rather on the value of the algorithm for Anima. I see there were no reactions though.
>>>
>>> Now, concerning the correctness of this sentence. I think it can be proven this way:
>>>
>>> 1. Professionally managed networks are configured by the mean of human configuration or by orchestrators.
>>> 2. The prefix assignment algorithm can be configured with preferred prefixes either by humans, or by orchestrators.
>>> Therefore: You can use the algorithm to configure a professionally managed network.
>>>
>>> Example 1:
>>> The prefix assignment algorithm can be configured with static prefixes.
>>> Static and automatic assignments can even be done depending on the link or the delegated prefix.
>>> For example, an enterprise could want part of the network to be 
>>> numbered statically, and another part of the network to be numbered automatically.
>>> This is perfectly possible by configuring some links with preferred assignment with a greater priority than auto-assigned prefixes.
>>>
>>> Example 2:
>>> Now, about your example of managed network with geographical constraints.
>>> Nodes executing the prefix assignment are allowed to *not* make assignments from a given delegated prefix.
>>> Which means if you have two areas (A and B), and two delegated prefixes (X and Y), nodes in A can be configured to only assign prefixes within X, and nodes in B configured to only assign prefixes from Y.
>>>
>>>
>>> The prefix assignment algorithm is a network management tool enabling auto-configuration *where you want it to happen*.
>>> It does not mandate auto-configuration (it does when used by HNCP, but that is only one possible use of the prefix assignment algorithm).
>>> The document mostly explains:
>>> - The main detailed specification of the algorithm.
>>> - The rules that you MUST respect if you want the algorithm to work.
>>>
>>> And the thing is that about everything that does not create prefix collision is, in the end, authorized.
>>> You could put anything as a configuration tool on top of PA, from a 
>>> netconf/Yang orchestrator to the usual linux ‘ip addr’ utility, or even what the Anima working group could end-up specifying.
>>>
>>> I hope this helps with your concern about the correctness of this sentence.
>>>
>>> I will be in Prague as well and would be happy to discuss whether PA could be useful to Anima.
>>>
>>>
>>> Thanks,
>>>
>>> - Pierre
>>>
>>>
>>>> Le 7 juil. 2015 à 21:45, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
>>>>
>>>> Hi,
>>>>
>>>> Sorry to be so late with this but I had some personal distractions recently.
>>>>
>>>> I am very surprised by a change that was made to this draft after 
>>>> IETF Last Call and with no discussion, as far as I am aware, on the 
>>>> WG list. It is this additional sentence in the first paragraph:
>>>>
>>>> "Although it does not require to be
>>>> configured to operate properly, it supports custom configuration by 
>>>> means of variable priority assignments, and can therefore be used in 
>>>> fully autonomic as well as professionally managed networks."
>>>>
>>>> Firstly, this is a substantive change so I believe it should have 
>>>> been discussed by the WG.
>>>>
>>>> Secondly, the second half of the sentence seems completely 
>>>> unjustified, and is way outside the Homenet context anyway. I believe 
>>>> that the range of requirements for autonomic and/or professionally 
>>>> managed networks is far too great to assert that "variable priority 
>>>> assignments" meet the needs; much more general policy intent might be 
>>>> needed in autonomic networks, for example, and the work on this topic 
>>>> is only just starting in Anima. As a specific example, an 
>>>> international enterprise network might have geographical requirements for prefix assignmnent.
>>>>
>>>> Quite apart from the process issue, I believe that the second half of 
>>>> the added sentence is wrong and must be deleted.
>>>>
>>>> Regards
>>>>  Brian Carpenter
>>>>
>>>>
>>>> _______________________________________________
>>>> homenet mailing list
>>>> homenet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>>
>>
> 
> 