All, On 1/27/16, 9:45 AM, "netmod on behalf of Juergen Schoenwaelder" <[email protected] on behalf of [email protected]> wrote:
>Eliot, > >I posted a technical review of the ACL draft on December 11th to the >list since the document was send to WG last call. I believe the I-D >has technical issues that need to be resolved. I am not going to >repeat my technical comments. > >Note I have been one of the _few_ who actually read the I-D when it >was sent to WG last call. FWIW, I also read the document both after it was accepted as a WG document and during WG last call. There have been some points of discussion during the document’s life that were discussed on the NETMOD list or during NETMOD open meetings. There are some YANG nodes that I probably would have named differently as well. However, I believe WG last call is a bit late and would not let my personal biases delay document publication. Thanks, Acee > And yes, I believe a standard in this area >needs to be highly extensible (so we better get this right) and I >believe it needs to be resonably match widely deployed open source >packet filters and not just Juniper and Cisco gear. > >/js > >PS: I reduced the CC: list to the NETMOD WG since this is where the > work is supposed to take place. > >On Tue, Jan 19, 2016 at 06:16:47PM +0100, Eliot Lear wrote: >> Hi Juergen, >> >> Skipping down... >> >> On 1/19/16 5:48 PM, Juergen Schoenwaelder wrote: >> >> > While we can have a lengthy debate about terminology, I think more >> > important is to get functionality right. >> >> Agree. We are arguing over labels that aren't generally meant for >> humans ANYWAY. >> >> >>> I am talking about the modularity of the base model, I do not see >>how >> >>> the cited thread relates to this. >> >> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always >>supported. I appreciate your input, but we did this design choice as >>design team and went forward with it. Also, the YANG models are not set >>in stone. I definitely see models evolving. >> > My main concern is that we need to get the extensibility of the model >> > right. One way to make sure we achieved this goal is to actually treat >> > everything as an extension of the core model (this forces us to get >> > the extensibility right). This is essentially what we did with the >> > routing data model and the interfaces data model. >> > >> > >> While I agree I am also becoming concerned that we may be going down a >> rat hole from which we may not return. The above thread snippets have >> lost so much context that one cannot divine what it is we are arguing >> over. While a design team certainly does not represent consensus, can >> we please at least argue over what it is we are supposed to be arguing >> over? With regard to this model, I could imagine innumerable ways to >> represent an access list. The deference due the people who wrote this >> stuff out is at least to recognize that. If you are going to propose an >> alternative at this point, please do it the old fashion way: send text. >> >> Eliot >> > > > >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
