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.shirazip...@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.carpen...@gmail.com] > Sent: Tuesday, July 07, 2015 2:25 PM > To: Pierre Pfister > Cc: IESG; home...@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.carpen...@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 >>> home...@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
